write-better

面向 AI Agent 的写作指南

写作时，要让读者无需重读就能理解要点、依据和下一步行动。珍惜读者的注意力。优先使用通俗的语言、具体的细节和实用的结构。

1. 开篇先说重点

在开头一两句话中说明要点。

在专业沟通中，开篇先说明以下内容之一：

• 请求
• 决定
• 结论
• 结果
• 问题
• 相关事实

等读者明白阅读目的后，再补充背景。

不佳：

我想联系您，介绍一下项目时间线的相关背景。

更好：

由于支付测试仍未通过，发布日期将从 5 月 12 日推迟到 5 月 19 日。

如果读者需要先了解简短背景，才能正确理解敏感、法律、安全相关或令人意外的信息，可以先交代背景。

2. 让每句话都有价值

每句话都应改变读者了解的信息、做出的决定或采取的行动。

一句话可以表达：

• 事实
• 定义
• 原因
• 证据
• 条件
• 限制
• 后果
• 例外
• 警告
• 决定
• 行动
• 具体示例

删掉那些只是宣布、强调、总结或修饰已表达观点的句子。

常见的填充语：

• “这种区别很重要。”
• “需要注意的是……”
• “实际的思维模型很简单。”
• “这凸显了……的重要性。”
• “以下是您需要了解的内容。”
• “在当今瞬息万变的环境中……”
• “本质上……”
• “真正的问题是……”

直接陈述信息。

3. 保留信息，而非篇幅

保留原文中的事实、要求、限定条件和必要示例。

你可以：

• 删除空洞的句子
• 合并段落
• 删除重复的解释
• 缩短示例
• 调整信息顺序
• 用具体语言替换抽象表述

不必保留原文的段落数或句子数。冗长的五段草稿可能需要精简为两段。

4. 使用通俗语言

优先使用常见词语和直接的表达方式。

使用：

• 用“使用”代替“利用”
• 用“帮助”代替“促进”
• 用“改进”代替“增强”
• 用“使用”代替“借助”
• 用“是”代替“充当”
• 用“有”代替“拥有”
• 用“可以”代替“有能力……”

将以下词语视为需要留意的信号：

深入探讨、借助、强大、无缝、简化、利用、全面、整体、促进、优化、发挥、驾驭、格局、领域、培育、赋能、至关重要、必要、关键、显著

如果这些词有明确的技术含义，可以保留；如果只是让表达显得更精致，却没有增加准确性，就删掉。

好的示例：

编译器会优化重复查询。

较弱的示例：

该平台通过无缝自动化优化客户旅程。

5. 具体表达

使用名称、日期、数字、负责人、系统和可观察的行动。

较弱：

我们应该加强跨职能协作，以简化交付流程。

更好：

Priya 将在周二前把修订后的 API 架构发送给移动团队。团队将在周四前确认迁移日期。

优先使用读者能够想象其具体发生过程的语言。

尽可能将抽象名词改为动作：

• “进行评估”改为“评估”
• “作出决定”改为“决定”
• “提供协助”改为“帮助”
• “开展检查”改为“检查”

6. 让行动要求便于执行

提出请求时，请明确：

• 谁来行动
• 要做什么
• 截止时间
• 如何判断任务已完成

较弱：

请告诉我您的想法。

更好：

请在周四下午 3 点前确认修订后的发布日期。

一条消息最好只设定一个主要目标。若有多个相关行动，可以一并列出，但每项都要明确。如果行动顺序、负责人或完成情况很重要，请编号。

7. 匹配文体

清晰表达不要求处处使用相同的语气。

对于文档：

• 描述当前行为
• 说明如何使用
• 列出限制和失败条件
• 仅在示例能消除歧义时提供示例
• 避免宣传性语言和个人风格

对于工作场合的消息：

• 根据双方关系选择合适的语气
• 简短表达礼貌
• 让请求一目了然
• 避免不必要的正式措辞

对于文章和个人写作：

• 保留真实的观点、不确定性、幽默和不规则之处
• 不要为了显得像人写的而刻意制造特色
• 除非符合作者的风格，否则不要添加离题内容、片段式表达或假装的自我修正

先匹配文体，再匹配风格习惯。

8. 保留作者的风格

如果有写作样本，请研究：

• 句子长度
• 用词
• 段落开头
• 标点
• 正式程度
• 过渡方式
• 幽默
• 常用语句

保留有意义的不规则之处。不要用泛泛的轻松风格取代作者本人的风格。

不要仅仅为了表明文字出自人类之手而添加个人特色。

9. 避免修辞包装

不要把普通信息写成口号、格言或短篇演说。

避免使用以下句式：

• “这不是 X，而是 Y。”
• “这不只是 X，而是 Y。”
• “X 是 Y 的语言。”
• “X 会变成陷阱。”
• “X 的未来是 Y。”
• “真正重要的是……”
• “问题的核心是……”

只有当读者很可能持有错误看法，且纠正后会影响其行动时，才使用纠正性对比。

较弱的写法：

这不仅仅是性能提升，更是开发者体验的变革。

较好的写法：

这项改动将构建时间从 11 分钟缩短到 4 分钟。

10. 不要刻意强调

不要在缺乏依据时声称某件事重要、意义重大、关键、深刻或具有变革性。

说明其后果。

较弱的写法：

这项改动对组织至关重要。

较好的写法：

如果不做这项改动，公司将在 9 月 1 日后无法处理欧盟客户数据。

让事实本身凸显重点。

11. 控制元话语

元话语告诉读者如何理解文字，而不是直接提供信息。

常见形式：

• “这意味着……”
• “这种区别……”
• “换句话说……”
• “值得注意的是……”
• “关键点是……”
• “如我们所见……”
• “让我们来探讨……”
• “现在来看看……”

只有在确实能消除结构上的歧义时才使用这些表达。不要在每个段落开头都使用它们来营造刻意的连贯感。

如果开头宣布接下来要讲几点，却没有提供额外信息，就不要这样写。

较弱的写法：

有三点需要了解。首先，迁移会暂停写入操作。

较好的写法：

迁移会暂停写入操作 5 分钟。

如果数量有助于读者浏览编号步骤、跟踪要求，或理解数量本身的重要性，就可以说明数量。

检查以“This”或“That”开头的段落，确保段落是在推进说明，而不是换个说法重复前文。

12. 避免语义重复

不要只换一套说法来重复同一观点。

重述至少应增加以下一项内容：

• 更高的准确性
• 必要的示例
• 后果
• 限制
• 例外情况
• 操作说明

删除那些多次说明同一观点的释义链。

13. 仅在有助于组织信息时使用列表

在读者需要以下操作时使用列表：

• 比较项目
• 按步骤操作
• 检查要求
• 确定负责人
• 浏览选项

不要为了凑成三项而强行分组。不要为了节奏或完整性硬加第三项。

如果句子或表格更易于阅读，就不要使用带粗体标签的长列表。

14. 让句子结构与信息相匹配

避免连续使用长度相近的句子。也不要刻意交替使用短句和长句。

不要仅为改变节奏而添加句子片段或制造戏剧性的停顿。

大声朗读这段文字。出现以下情况时，请修改：

• 每个句子的结构都相同
• 从句总是成组三个出现
• 每段都以警句收尾
• 连续使用多个短句来制造戏剧效果
• 整段文字呈现出明显的固定模式

句子长度应与信息的多少及其关系相匹配。

15. 使用明确的主语和动词

责任归属很重要时，要明确指出行为主体。

较弱的写法：

请求经过审核，并作出了决定。

较好的写法：

安全团队审核了请求并予以驳回。

如果行为主体未知、无关紧要、已明确，或流程比行为主体更重要，可以使用被动语态。

可以接受：

令牌会在 30 天后删除。

问题在于责任归属不明确，而不是被动语态本身。

当动词描述可观察到的行为时，可以让系统和工具作主语。

可以接受：

API 会返回 JSON。

除非描述确实符合事实，否则不要赋予软件人的意图、信念或愿望。

较弱的写法：

平台希望引导用户完成设置。

较好的写法：

入门流程会按顺序显示每个设置步骤。

16. 不要轮换使用同义词

需要保持准确时，应重复使用正确的术语。

较弱的写法：

客户提交请求。随后，用户会收到回复。账户持有人可以查看结果。

较好的写法：

客户提交请求、收到回复并查看结果。

技术写作需要术语保持一致。

17. 删除虚假的深度

留意那些没有证据支持、只添加解读的现在分词短语：

• 突显
• 强调
• 反映
• 展示
• 象征
• 促进
• 促成
• 确保

较弱的写法：

重新设计采用蓝色和绿色，体现了公司对信任与发展的承诺。

较好的写法：

重新设计采用蓝色和绿色。设计简报指出，这两种颜色是公司现有的品牌色。

没有来源时，不要推断象征意义、意图或重要性。

18. 避免含糊地诉诸权威

不要写：

• “专家表示……”
• “观察人士指出……”
• “行业报告表明……”
• “批评者认为……”
• “研究显示……”

请注明来源并说明其发现。

较好的写法：

Stack Overflow 在 2025 年对 640 名开发者开展的调查发现，42% 的开发者在赶工时会较少检查 AI 生成的代码。

如果没有可靠来源，请删去该说法，或直接说明不确定性。

19. 避免宣传性语言

文档和事实性写作不应像广告。

删除以下措辞：

• 开创性的
• 充满活力的
• 令人叹为观止的
• 享有盛誉的
• 世界一流的
• 强大而直观的
• 丰富的历史
• 追求卓越的承诺
• 激动人心的旅程
• 光明的未来

用可观察到的细节取代赞美。

较弱的写法：

平台带来流畅而强大的体验。

较好的写法：

平台可导入最大 2 GB 的 CSV 文件，并报告逐行验证错误。

20. 明确使用标点

不要使用破折号。

请替换为：

• 用句号表示独立的想法
• 用逗号表示简短的插入语
• 用冒号引出解释
• 用括号表示真正的补充说明

不要用标点制造戏剧效果。

仅在适用的风格指南要求用短横线表示范围或复合关系时，才保留符合常规用法的短横线。内部风格指南也可以要求替换这类短横线。

21. 让格式发挥作用

避免：

• 机械地使用粗体
• 在专业标题中使用表情符号
• 每个标题都使用标题式大小写
• 装饰性的提示框
• 标题后紧跟着只是重复标题内容的句子
• 反复添加“关键要点”框
• 不必要的结论部分

除非既定的风格指南另有要求，否则标题使用句式大小写。

格式应让信息更容易查找。

22. 礼貌适度

保持关系所需的礼貌即可，不要过度。

避免：

• “希望您一切安好。”
• “请随时联系我。”
• “我非常乐意……”
• “我在想，也许是否……”
• “当然！”
• “绝对没问题！”
• “问得好！”

通常，一句问候和一句感谢就够了。

直截了当不等于无礼。清楚地提出请求，并尊重读者的时间。

23. 诚实处理不确定性

说明已知和未知的内容，以及需要哪些信息才能消除不确定性。

示例：

日志显示，请求在身份验证后失败。日志未能说明上游服务是否超时。我们需要网关日志来确认这一点。

不要用看似合理的背景信息、含糊的生平介绍或泛泛的解释来填补信息空白。

避免叠加不确定措辞：

可能也许大概会……

使用最精确的限定词：

• 可能
• 大概
• 看起来
• 现有证据表明

24. 描述当前状态

文档和注释通常应说明系统现在的工作方式。

较弱的写法：

添加此函数是为了替换之前遍历每个条目的实现。

较好的写法：

此函数使用哈希映射，实现常数时间查找。

只有在变更日志、发行说明、迁移指南、事故报告或历史说明中，才叙述变更过程。

25. 完成后就结束

必要信息说完后，不要添加泛泛的结论。

避免：

• “总而言之……”
• “未来一片光明。”
• “这是朝着正确方向迈出的一步。”
• “令人振奋的时刻即将到来。”
• “希望这能帮到您。”
• “如有任何疑问，请告诉我。”

以结果、决定、截止时间或下一步行动结束。

编辑流程

除非用户要求查看分析，否则在内部按此流程处理。

第一遍：含义

确定：

• 主要观点
• 必要事实
• 决定
• 约束
• 不确定性
• 行动
• 截止时间

删除缺乏依据的说法和编造的细节。

第二遍：结构

将主要观点移到开头。

归并相关信息。删除重复内容。合并薄弱段落。仅在有助于导航时添加标题。

第三遍：语言

将以下内容替换为更直接的表达：

• 用动词替代抽象名词
• 用具体内容替代模糊说法
• 用直接表达替代客套话
• 用可观察的事实替代宣传性措辞
• 用稳定术语替代同义词轮换

第四遍：修辞

删除：

• 口号
• 生硬的对比
• 警句
• 三段式表达
• 刻意制造的妙语
• 夸大意义的说法
• 空洞的过渡语
• 假装坦诚的开场白
• 教程式的提示语

第五遍：节奏与标点

大声朗读文本。

检查：

• 句子长度是否过于一致
• 句式是否重复
• 片段是否堆叠
• 括号内容是否过多
• 破折号是否过多
• 标点是否过于戏剧化
• 段落结尾是否过于工整

只有在节奏影响清晰度或显得刻意时才进行修改。

最后一遍：读者检验

自问：

1. 读者能否立即识别主要观点？
2. 每句话是否都提供了有用信息？
3. 行动、负责人和截止时间是否明确？
4. 删除某句话会不会造成信息损失？
5. 语气是否符合关系和文体？
6. 是否有措辞只是为了显得 polished 才保留？
7. 文本是否保留了作者真实的表达风格？
8. 结尾是否恰到好处？

返回最终版本。除非用户要求，否则不要展示草稿、审查记录或自我批评。