📚 喵喵的笔记库

这就是工科写作

31分钟阅读

1. 全书概览

这本书的目标读者很明确——工程师和技术从业者。不是教你写小说，不是教你写散文，而是教你如何在专业场景下，把技术内容写得清楚、准确、有说服力。

两位作者都来自英国雷丁大学，长期从事工程类学生的学术写作训练，书里的建议不是空中楼阁，而是从大量真实的学生论文、项目报告、技术文档中提炼出来的。全书结构清晰，从写作的基本原则出发，逐步覆盖报告、论文、说明书、邮件等不同工程文体的具体写法。

这本书的核心观点可以概括为一句话：好的技术写作不是天赋，而是一套可以训练的技能。 工程师最常犯的错误不是不懂技术，而是默认"读者跟我一样懂"，导致信息传递效率极低。

全书大约分为三大部分：

  • 第一部分（基础）：写作思维、读者意识、信息组织、清晰表达
  • 第二部分（文体）：技术报告、学术论文、说明书、提案、邮件等具体场景
  • 第三部分（进阶）：修改技巧、图表使用、引用规范、答辩准备

对于在国内技术环境下工作的工程师来说，这本书最有价值的部分不是具体的模板（毕竟中英文环境差异很大），而是它反复强调的**"读者思维"**——写之前先想清楚：谁会读这篇东西？他们需要什么？他们已经知道什么？

为什么值得读？

工程领域有一个普遍现象：技术很强的人往往写得一塌糊涂。这不是能力问题，是训练缺失。大多数工科教育只教怎么做实验、怎么算公式，几乎不教怎么把成果写出来。结果就是，一份技术方案改了十几稿还是逻辑混乱，一封跟客户的邮件写得像加密报文。

这本书解决的正是这个痛点。它不卖弄理论，给的每条建议都附有正反对比示例，看完马上就能用。

2. 逐章要点

第1章：工程师为什么需要写作能力

"在工程领域，写作能力不是加分项——它是你的专业能力被看见的前提。"

作者一开篇就破除一个常见误解：很多工程师觉得"我把活干好就行了，写东西不重要"。但现实是，你做的实验再漂亮，如果报告写不清楚，评审就看不懂；你的方案再牛，如果提案写得像流水账，客户就不会买单。

这一章的核心论点：

| 观点 | 说明 | |------|------| | 写作是工程工作的延伸 | 设计、实验、计算完成之后，写作是最后一个环节，但决定了前面所有工作的呈现效果 | | 读者不是你自己 | 你脑子里清楚的逻辑，写下来别人未必看得懂 | | 写作可以反过来理清思路 | 写的过程本身就是一次深度思考 | | 职场晋升的隐形门槛 | 越往高层走，越需要通过文字影响他人 |

作者引用了一项调查数据：雇主在招聘工程师时，除了技术能力之外，沟通能力（尤其是书面沟通）是被提及频率最高的软技能，排名超过了团队协作和领导力。

  • [ ] 反思：我最近一次技术写作中，有没有因为"默认读者懂"而跳过了关键解释？
  • [ ] 行动：下次写技术文档前，先花3分钟写下"我的读者是谁、他们知道什么、他们需要什么"

第2章：理解你的读者

"如果你不知道自己在跟谁说话，你就不知道该说什么。"

这一章是全书最有含金量的章节之一。作者提出了一个简单但有效的"读者画像"框架：

读者分析三问：

  1. 他们是谁？ 同行、管理层、客户、监管机构、还是普通用户？
  2. 他们知道多少？ 这决定了你的专业术语密度和背景解释深度。
  3. 他们想要什么？ 决策依据？操作指南？技术细节？还是结论？

不同读者需要不同的写作策略：

| 读者类型 | 写作重点 | 术语使用 | 细节程度 | |----------|----------|----------|----------| | 技术同行 | 方法论、创新点 | 正常使用 | 高 | | 管理层 | 结论、ROI、风险 | 尽量少 | 低（摘要为主） | | 客户 | 能解决什么问题、怎么用 | 避免或解释 | 中 | | 监管/审计 | 合规性、数据完整性 | 标准术语 | 高 | | 普通用户 | 操作步骤、注意事项 | 零术语 | 低 |

一个容易犯的错是"一份文档服务所有读者"。作者明确反对这种做法，建议根据主要读者群体来调整内容。如果确实需要兼顾多类读者，可以用分层结构：执行摘要给管理层，详细技术内容给同行。

  • [ ] 下次写文档时，在标题下方写一行"本文主要读者：___"
  • [ ] 审视自己过去的技术文档，看看有没有"术语轰炸"的问题

第3章：组织你的信息

"好的写作不是从第一句话开始写的，而是从最后一句话开始想的。"

这一章讲的是信息结构。作者推荐的方法是：先写大纲，再填内容，最后润色。 听起来是常识，但大部分工程师的习惯是打开文档直接写，写到哪算哪，结果逻辑经常跳来跳去。

书中给出了几种实用的组织工具：

金字塔原理的工程版应用：

  • 先写结论（你要传达的核心信息）
  • 再写支撑结论的3-5个要点
  • 每个要点下再展开细节和证据

技术报告的标准结构：

  1. 摘要（Executive Summary）
  2. 引言（背景 + 目的）
  3. 方法（做了什么、怎么做）
  4. 结果（发现了什么）
  5. 讨论（意味着什么）
  6. 结论（建议/下一步）
  7. 参考文献
  8. 附录

作者特别强调摘要的重要性——很多读者（尤其是管理层）只看摘要。摘要写得烂，整份报告等于白写。

  • [ ] 尝试用"结论先行"的方式重写一份最近的报告
  • [ ] 为自己的技术文档建立一套固定的章节模板

第4章：写出清晰的句子和段落

"如果一个句子需要读两遍才能看懂，那就是作者的问题，不是读者的问题。"

这一章进入具体的写作技巧层面。作者对"清晰的写作"给出了几条可操作的标准：

好句子的标准：

  • 平均长度 15-20 个单词（英文语境，中文约 30-40 字）
  • 一个句子只表达一个主要意思
  • 主动语态优于被动语态（虽然工程文献中被动语态很常见，作者认为应该在合理范围内减少）
  • 避免名词堆砌（nominalization），比如把"make a recommendation"简化为"recommend"

好段落的标准：

  • 一个段落只讨论一个主题
  • 第一句是主题句（告诉读者这段讲什么）
  • 段落之间有逻辑衔接（不是简单罗列）

书中用了大量正反对比示例，比如：

❌ 差："The implementation of the proposed methodology resulted in the achievement of a significant reduction in the overall error rate." ✅ 好："The new method cut the error rate by 34%."

这个对比特别能说明问题：前者是典型的学术腔，信息密度极低；后者直接说结果，读者一目了然。

  • [ ] 找出自己最近写的一份技术文档，随机挑3个长句，尝试缩短到原来的60%
  • [ ] 检查每个段落的第一句话，看是否能单独作为该段的摘要

第5章：技术报告写作

"一份技术报告的价值不在于它有多厚，而在于它能让读者多快做出正确的判断。"

技术报告是工程师最常写的文体。这一章是全书篇幅最大的章节，几乎可以单独作为一本小册子来用。

作者详细拆解了技术报告的每个组成部分：

摘要写作要点：

  • 控制在 200-300 词（英文）
  • 必须包含：目的、方法、关键结果、结论
  • 最后写（写完全文后再回头写摘要）
  • 不要引用文献、不要用缩写

图表使用规则：

  • 每张图/表必须有编号和标题
  • 图表在正文中必须有引用（"如图3所示"）
  • 图表要能独立阅读（不看正文也能看懂）
  • 避免用图表重复正文已经说过的内容
  • 数据可视化优先选择最简单有效的形式

常见错误清单：

  • 报告开头没有明确说明目的

  • 结果和讨论混在一起

  • 图表和正文脱节

  • 结论里出现新的信息

  • 附录放了应该在正文里的内容

  • [ ] 用书中的技术报告结构清单，对照自己最近写的一份报告打分

  • [ ] 练习为一份已有报告写一份200字以内的摘要

第6章：学术写作与论文发表

"学术论文不是把你做了什么按时间顺序列一遍，而是讲一个有逻辑的故事。"

这一章针对需要发表论文的工程师（包括硕博士）。作者指出了工程类论文和纯理科论文的一个关键区别：工程论文更强调应用价值和方法创新，纯理科论文更强调理论突破。

论文写作的关键建议：

  1. 选题和定位：先明确你的贡献是什么（新方法？新数据？新应用？），在引言中就要说清楚
  2. 文献综述：不是罗列别人做了什么，而是通过分析别人的工作来衬托你的贡献
  3. 方法部分：要写得让同行能够复现你的实验
  4. 结果部分：客观呈现，不要在这里讨论（那是讨论部分的事）
  5. 讨论部分：解释结果意味着什么，承认局限性
  6. 审稿回复：不要情绪化，逐条回应，即使不同意也要礼貌说明理由

作者还特别提醒了一个实操问题：写论文不要从引言开始写。推荐顺序是：方法 → 结果 → 讨论 → 结论 → 摘要 → 引言。引言需要你对全文有全局把握之后才能写好。

  • [ ] 下次写论文时，尝试按"方法→结果→讨论→结论→摘要→引言"的顺序写
  • [ ] 在文献综述中，刻意加入"然而，现有方法的局限是___"这类过渡句

第7章：说明书和操作文档

"好的说明书是用户自己能看懂的，而不是需要你站在旁边解释的。"

这一章讲的是面向用户的技术文档，包括产品说明书、操作手册、维护指南等。

说明书写作的核心原则：

| 原则 | 说明 | |------|------| | 按用户任务组织 | 不是按系统架构组织，而是按"用户想做什么"组织 | | 步骤清晰可执行 | 每一步都是一个明确的动作 | | 警告前置 | 危险操作在步骤之前提醒，不要藏在最后 | | 可测试 | 用户读完能立即验证自己做对了没有 | | 一致性 | 同一个操作用同一个词，不要"点击"和"按下"混用 |

作者举了一个很生动的反面例子：某设备的维护手册写得极其专业，用了大量行业术语，结果维修工程师在实际操作中根本看不懂，最后还是打电话问技术支持。这说明说明书的第一读者是一线操作人员，不是写说明书的工程师本人。

  • [ ] 找一个自己熟悉的产品，试着为它写一份"3步上手"极简指南
  • [ ] 检查自己项目中的 README，看是否包含：安装前提、快速开始、常见问题

第8章：提案和商业写作

"提案的本质是说服——说服别人给你钱、给你时间、给你机会。"

工程师不只需要写技术文档，还需要写提案（proposal）来争取项目、申请经费、获得审批。这一章针对的就是这类"说服性写作"。

提案的结构建议：

  1. 问题陈述（客户/决策者面临什么问题）
  2. 你的解决方案（概述，不是细节）
  3. 为什么选你（资质、经验、独特优势）
  4. 项目计划（时间线、里程碑、交付物）
  5. 预算和资源
  6. 风险和应对

说服的三个层次：

  • 逻辑说服：用数据和事实说话
  • 可信度说服：展示你的专业能力和过往业绩
  • 情感说服：让读者感受到你理解他们的痛点

作者指出，工程师写提案最常见的毛病是"只讲技术细节，不讲商业价值"。决策者关心的往往不是你用了什么算法，而是这个方案能帮他省多少钱、提多少效率、降多少风险。

  • [ ] 下次写提案时，在技术方案之前先加一页"商业价值摘要"
  • [ ] 准备一份自己的"项目业绩清单"，写提案时可以直接引用

第9章：邮件和日常沟通

"邮件不是聊天，也不是论文——它是用最少的文字传递最准确的信息。"

这一章虽然看起来最简单，但实际上可能是日常工作中最实用的。

邮件写作的基本规则：

  • 邮件标题要具体（❌"关于项目" ✅"Q2系统升级方案 - 需审批"）
  • 第一句话就说目的（不要铺垫三段才进入正题）
  • 如果需要对方行动，明确说出需要什么、什么时候要
  • 控制长度——如果超过5段，考虑换成会议或附件文档
  • 发送前重读一遍，检查语气和措辞

语气管理： 作者特别提醒，工程师在邮件中容易显得"冷淡"或"不耐烦"，原因很简单——省略了礼貌用语，全是陈述句。不需要花言巧语，但基本的"请""谢谢""辛苦了"还是要有的。

  • [ ] 审查自己最近发出的5封工作邮件，看看标题是否足够具体
  • [ ] 建立几个邮件模板（进度汇报、问题反馈、审批请求），减少重复劳动

第10章：修改和润色

"好文章是改出来的，不是写出来的。第一稿存在的意义就是给你提供修改的材料。"

最后一章讲的是修改技巧。作者给出了一个分层次的修改流程：

修改的三个阶段：

  1. 结构层面：逻辑是否通顺？信息组织是否合理？有没有缺失或冗余？
  2. 段落层面：每段是否只讨论一个主题？过渡是否自然？
  3. 句子层面：语法是否正确？措辞是否精确？有没有冗余？

自我审阅清单：

  • [ ] 文档的目的在第一页就说清楚了吗？
  • [ ] 每个章节之间有逻辑衔接吗？
  • [ ] 所有图表都被正文引用了吗？
  • [ ] 有没有读者可能不理解但未解释的术语？
  • [ ] 结论是否只总结了正文已有的内容？
  • [ ] 读一遍，标记所有需要读两遍才能理解的句子，然后改掉
  • [ ] 如果可能，找一个不了解这个项目的人读一遍，记录他哪里卡住了

作者还建议了一个很实用的技巧：改完之后放24小时再看。刚写完的时候你对自己的文字有"脑补"能力，能自动补全逻辑跳跃。放一段时间再来看，这些问题就会暴露出来。

  • [ ] 给自己定一个规矩：重要文档写完后至少放一晚再提交
  • [ ] 建立一个"常见写作问题清单"，每次修改时对照检查

3. 关键概念速查

3.1 读者意识（Reader Awareness）

写作前明确读者是谁、知道什么、需要什么。这是所有技术写作的起点。不做读者分析的写作，本质上是在自说自话。

3.2 结论先行（BLUF - Bottom Line Up Front）

把最重要的信息放在最前面。技术文档不是悬疑小说，不要让读者猜你要说什么。这个原则适用于报告、邮件、提案等几乎所有场景。

3.3 信息分层（Information Layering）

用摘要/正文/附录三层结构满足不同深度的阅读需求。管理层看摘要就够了，技术人员需要正文，细节狂人去翻附录。

3.4 主动语态优先（Active Voice Preference）

虽然传统工程文献大量使用被动语态（"the experiment was conducted"），作者建议在合理范围内多用主动语态（"we conducted the experiment"），因为主动语态更直接、更清晰、更容易理解。

3.5 可复现性（Reproducibility）

学术论文和方法文档中的描述必须足够详细，让同行能够独立复现你的工作。这是科学写作的底线要求，也是区分"合格"和"优秀"的分水岭。

3.6 修改三阶段（Three-Stage Revision）

结构修改 → 段落修改 → 句子修改。不要一上来就纠结措辞，先确保整体逻辑没问题，再打磨细节。

3.7 术语管理（Terminology Management）

同一概念全文统一用一个术语，首次出现时给出定义或解释。不要在一个文档里对同一个东西用三个不同的名字。

4. 核心框架/模型

4.1 工程写作的 PACES 模型

虽然书中没有正式命名这个模型，但贯穿全书的核心逻辑可以归纳为 PACES：

| 步骤 | 内容 | 说明 | |------|------|------| | P - Plan | 规划 | 分析读者、明确目的、列出大纲 | | A - Arrange | 组织 | 确定结构、分配信息到各章节 | | C - Create | 初稿 | 快速写完，不要边写边改 | | E - Edit | 修改 | 按三阶段流程修改 | | S - Submit | 提交 | 最终检查格式、引用、错别字 |

4.2 读者-目的-内容 三角模型

        读者（Reader）
         /        \
        /          \
       /            \
  内容 ←———— 目的（Purpose）
（Content）

每次写作之前，先确认这三个角的平衡：

  • 读者决定了语言风格和专业深度
  • 目的决定了信息重点和结构
  • 内容是你要传递的具体信息

如果三个角中任何一个模糊不清，写出来的东西就会跑偏。

4.3 文档质量自评量表

作者提供了一个快速自评框架（满分5分）：

| 维度 | 1分 | 3分 | 5分 | |------|-----|-----|-----| | 目的明确性 | 读完不知道想说什么 | 大致能猜到 | 第一页就说清楚了 | | 逻辑结构 | 东一榔头西一棒 | 有结构但衔接弱 | 层次清晰、过渡自然 | | 可读性 | 需要反复读 | 基本能读懂 | 一遍就能理解 | | 术语使用 | 全是术语无解释 | 大部分能懂 | 恰当使用且有解释 | | 图表质量 | 没有或看不懂 | 有但不够清晰 | 信息准确、一目了然 | | 行动指引 | 不知道下一步该干嘛 | 有暗示但不明确 | 明确告知该做什么 |

5. 金句摘录

  1. "写作不是思考的产物，写作本身就是思考的过程。" —— 很多人以为先想清楚再写，实际上写的过程就是在帮你想清楚。

  2. "如果你的摘要写得够好，读者应该不需要读完全文就能抓住要点。" —— 摘要不是缩写版正文，而是独立的信息单元。

  3. "最危险的假设是：'他们应该能看懂。'" —— 在技术写作中，"应该"这两个字害死人。

  4. "工程师花在设计上的时间是写作时间的10倍，但写作质量决定了那10倍的时间是否被浪费。" —— 一个不够夸张的比例，但道理很硬。

  5. "好文档的标准不是'写完了'，而是'读者能用了'。" —— 写完只是你的事，读者能用才是文档的使命。

  6. "不要让读者做你的编辑——如果你自己都不愿意重读一遍，凭什么让别人读？" —— 修改是对读者的基本尊重。

  7. "术语不是用来炫技的，是用来精确沟通的。如果术语不能提高沟通效率，就不要用。" —— 技术文档中最大的噪音就是不必要的术语。

6. 行动清单

📅 每天可做

  • [ ] 写任何技术内容前，花30秒默念"我的读者是谁"
  • [ ] 邮件写完后重读一遍，删掉至少一个多余的字/词/句
  • [ ] 遇到需要解释的概念，尝试用一句话说清楚（电梯演讲练习）
  • [ ] 读到写得好的技术文档时截图保存，建立自己的"好文样本库"

📅 每周可做

  • [ ] 挑一份自己过去写的文档，用"修改三阶段"方法重新审视一遍
  • [ ] 写一段200字以内的技术总结，练习"结论先行"
  • [ ] 检查自己的文档模板，看看有没有需要更新的地方
  • [ ] 看一篇本领域的高质量论文，分析其写作结构和技巧

📅 每月可做

  • [ ] 用"文档质量自评量表"给自己本月的主要文档打分，追踪进步
  • [ ] 整理一次自己的"常见写作问题清单"，添加新发现的问题
  • [ ] 和同事交换文档互相审阅，获取外部反馈
  • [ ] 回顾本月的技术写作，找出一个最大的改进点，下月重点攻克

7. 一句话总结

技术写作的本质是"为读者设计信息的传递路径"——想清楚谁在读、需要什么、按什么顺序给，然后把它写清楚。

8. 读者热议

观点一："为什么工程教育不教写作？"

很多读者反馈，这本书最大的价值不是教了什么新东西，而是把大家隐约知道但没系统化的写作知识整理成了一套方法论。更普遍的感慨是：大学四年学了无数门专业课，却没有一门教"怎么把你的专业成果写出来"。这种缺失导致大量工程师在职场上走了弯路——技术能力强但表达弱，在晋升和项目争取中吃亏。有人建议这本书应该成为工科学生的必读书目。

观点二："方法论简单，执行起来难"

有读者指出，书里讲的道理都不复杂——"结论先行""了解读者""写完要改"，这些谁不知道？但知道和做到之间有巨大的鸿沟。真实的工作环境中，工程师面对的是紧迫的deadline、不明确的评审要求、多轮反复的修改意见，很难静下心来按 PACES 模型一步步走。这本书的局限在于，它更适用于"有充足时间准备"的场景（论文、正式报告），对日常高频的邮件和即时文档指导相对薄弱。

观点三："英文语境下的建议，中文环境需要适配"

一些中国读者提到，书中的很多示例和建议基于英文写作习惯（比如被动语态的问题、句子长度的建议），直接搬到中文技术写作中需要做调整。中文技术文档有自己的一套行文习惯和潜规则（比如某些场景下"废话"是必要的社交润滑剂）。不过，核心原则——读者意识、信息组织、清晰表达——是跨语言通用的，值得借鉴。

笔记生成：2026-04-28 by 喵喵 🐈

相关笔记

同作者仅有此篇 同主题：

关系图谱