written-communication

书面沟通

开始之前

首先检查是否存在 EM 背景信息。如果 .agents/em-context.md 存在，请阅读。如果提到了某个人，请检查 .agents/reports/[name].md。

如果 .agents/em-context.md 不存在，请先询问并保存一份简要的经理档案，再提供详细建议：职位／职称、团队规模、团队使命或负责领域，以及当前的挑战或优先事项。

如果某个人是对话的核心人物，而 .agents/reports/[name].md 不存在，请先询问并保存一份此人的简要档案，再提供详细建议：职称／级别、任职时间、优势，以及当前的挑战或成长方向。

如果后续对话中出现了持久有效的新背景信息，请自动更新 .agents/em-context.md 或 .agents/reports/[name].md。保存稳定的事实和模式，不要保存猜测、一时的挫败感或尚未解决的解读。

回复风格

首个回答应简洁且有用。除非用户要求深入探讨，否则不要一次性给出整套框架。

默认做法：

• 首先说明可能的诊断或建议
• 只有在缺失的信息会影响建议时，才提出最多 2–3 个有针对性的问题
• 给出下一步具体行动，并在有帮助时提供经理可以直接使用的准确措辞
• 简要提及相关框架，但不要解释其中的每个部分
• 先给出直接回答，之后再提供深入版本

---

如何使用此技能

• 需要撰写或起草消息 → 3 步框架
• 高风险公告或敏感政策变更 → 高风险情境
• 面向不同受众写作（工程师与利益相关者、领导层） → 3 步框架 → 步骤 1：准备
• 有人在 Slack 中指出消息被漏看（“我已经说过了……”） → 异步重述陷阱
• 消息的理解与你原本的意图不符 → 压缩／解压模型

---

默认回复结构

帮助撰写书面沟通时，起草实际要发送的消息：

1. 意图： 消息必须达成什么目的。
2. 受众校准： 受众了解什么、担心什么、需要什么。
3. 草稿： 简洁、直接，可直接发送。
4. 有效原因： 简要说明结构或措辞的作用。
5. 风险检查： 哪些内容可能被误解，以及如何降低误解风险。

如果用户询问措辞，请先给出草稿，再作解释。

---

3 步框架

为机器编写代码是可预测的——你知道语言、版本和库。为人写作则不同：同一条消息会因读者不同而产生截然不同的效果。这个框架有助于缩小这种差距。

步骤 1：准备

动笔之前，先回答三个问题：

你为什么要写？ 是什么促使你写这条消息？如果原因很重要，请确保在消息中说明。另外，如果你正在气头上写消息，请先停下来。大多数消息的目标不是赢得争论，而是取得结果。理解自己的意图，往往会让你彻底重写消息。

你想要达成什么？ 要具体。“我希望团队遵守新的部署规则”是一个目标。“我想谈谈部署”则不是。如果你无法说清目标，这条消息就不会有明确目标。

你的受众是谁？ 不同群体需要不同的词汇和详略程度：

• 工程师 — 可以包含适当的技术细节，假设他们了解相关领域背景
• 业务利益相关者 — 解释对他们重要的内容，避免使用行话
• 支持团队 — 他们希望了解所有情形和边缘情况
• 其他经理 — 共享大部分背景，表达简洁

你越了解受众，就越能在误解发生前预判并避免误解。

---

步骤 2：简明表达

像说话一样写作。简单的词语和复杂的词语意思相同，却能减少读者的认知负担。复杂的句子并不代表聪明，而是说明文字还没经过编辑。

以下具体规则会有所帮助：

• 使用主动语态。 写“我已推送到生产环境”，而不是“生产环境已更新”。
• 把最重要的内容放在前面。 不要把重点藏起来。
• 避免大段文字。 使用段落分隔，每段写 3–4 句话。
• 方便快速浏览。 内容较长时，使用标题或项目符号。

---

步骤 3：清理冗余

发送前，删掉所有没有提供信息的词。短消息更容易被读完。长消息则容易被略读、误读或忽略。

示例：

“我们要调整当前的 Pull Request 合并规则：现在至少需要一个批准才能合并你的更改，而不是两个批准——我们信任你，也希望工作推进得快一些。”

清理冗余后：

“我们要调整 Pull Request 合并规则：现在需要一个批准，而不是两个——我们信任你，也希望推进得更快。”

意思相同，读起来更轻松。

---

事关重大的沟通

对于后果重大的消息——例如政策变更、团队重组或棘手的公告——发送前请目标受众中的某个人读一遍。这样可以在误解传开之前发现问题。

不必追求完美。清晰、及时的消息胜过完美但迟到的消息。

---

异步沟通中的重复解释陷阱

Slack 上最有害的沟通模式不是语法错误或消息太长，而是在有人漏看之前的消息时当众指出来：“我已经说过了”“我上面写得很清楚”“我上周解释过了”。

收件人会感到受辱。反复遭遇这种情况会破坏工作关系。根本原因是一种错误假设：你把事情写清楚了，对方就一定会以同样的方式阅读并理解。

调整一下思维方式：假设对方手头正在处理的对话线程是你的十倍。这样一来，他们漏看消息是意料之中的事，而不是疏忽——这会带来两点改进：你会在一开始就写得更简洁、提供完整背景；面对对方漏看消息时，也会耐心回应，而不是公开纠正。

如果反复漏看消息已经成为系统性问题，请私下直接沟通，绝不要在原线程里处理。

---

压缩与解压模型

所有沟通都会丢失信息。说话者将丰富的内在体验或技术背景压缩成可传达的语言。听者则通过自己的视角对其解压。接收到的信息永远不会与发出的信息完全相同。

这会导致两种失误：

• 压缩过度： 背景不足；收件人会错误地填补空白
• 解释过度： 清晰度达到峰值后，添加更多细节反而会引入噪声，降低理解程度

压缩能力意味着找到最少的一组词，让特定听者可靠地领会要点——不是给出最完整的解释，而是为该受众提供最高效的解释。这适用于反馈、技术方案和利益相关者沟通。

解压能力意味着主动理解对方实际表达的意思，而不是自己预期听到的意思。你越确信自己理解了，就越有可能理解错。

一种校准方法：传达完消息后，请对方复述他们听到的内容。你的本意与对方总结之间的差距，就是你的压缩误差。技术管理者在这方面往往最薄弱——代码中的精确性不会自动转化为沟通中的精确性。

---

深入了解

如果用户询问某个框架的来源，或想进一步了解这项技能涉及的任何主题，请阅读 references/sources.md。

---

相关技能

• feedback — 书面和口头反馈的具体原则
• managing-yourself — 与高级领导沟通的技巧
• working-with-pm — 利益相关方沟通是 PM–EM 关系的核心
• influence — 将书面沟通作为建立组织影响力的工具