writing-internal-comms

撰写内部沟通内容

概述

内部沟通要么太长，让人读不下去；要么过于含糊，没有实用价值。两者的根源相同——写的是作者知道什么，而不是读者需要知道什么才能做出决定。

核心原则： 开门见山，先讲结论。读者应在第一句话中 get 到重点，后续内容只需阅读补充细节。

铁律

NO INTERNAL COMMS WITHOUT GATHERING THE FACTS FIRST

凭记忆拼凑的更新内容，满篇都是模棱两可的说法。动笔之前，先查阅实际情况——提交记录、工单、讨论串、指标、文档。沟通内容含糊，几乎总是因为调研不足，而不是写得不好。

如果确实无法获取事实，请向用户询问。不要用“取得了重大进展”来掩盖信息缺口。

检查清单

1. 确定类型——参照下方的指南文件
2. 确定受众及其要做的决定——谁会阅读这份内容？读完后，他们需要采取什么不同的行动？
3. 收集事实——从真实来源获取，并记录日期和数字
4. 按格式起草——严格遵循指南文件的结构
5. 进行精简——见下文
6. 检查语气——尤其是涉及问题、事件或人员的内容

路由

请求	文件
每周／每两周的团队或公司更新	examples/3p-updates.md
全公司范围的通讯	examples/company-newsletter.md
回答常见问题	examples/faq-answers.md
其他内容——公告、事件、政策、发布	examples/general-comms.md

阅读对应的文件，并遵循其中的结构。 这些格式能让读者每次都以相同的方式快速浏览；自行采用新结构会破坏这种价值。

受众与决策

动笔前先回答以下两个问题。若无法回答，请先询问。

谁会阅读？ 受众的背景知识水平决定一切。

他们读完后会做出什么改变？ 每份内部沟通内容都应促成一项决定、一个行动，或纠正一种认知。如果三者皆无，就不需要发送。

受众	关注点	不想了解的内容
高管	结果、风险、需要他们提供什么	如何构建、关闭了哪些工单
协作团队	会影响他们的变化、何时发生、迁移路径	内部推理、团队流程
自己的团队	具体情况、负责人、后续步骤	重复说明他们已经了解的背景
全公司	这件事为何与他们有关、应该采取什么行动	团队行话、组织细节

收集事实

可用的集成因环境而异——先确认实际连接了哪些集成，不要想当然。

来源	查找内容
Git／问题跟踪器	这段时间内发布了什么，以及具体日期
Slack／Teams	互动活跃度高的讨论串；频道中做出的决定
Docs／Drive	最近编辑过的规格说明和决策记录
仪表板	具体数字，让论断有量化依据
日历	非定期会议——评审、事件、发布

每项论断都要有一个数字、名称或日期。 “性能有所提升”毫无信息量。“p95 延迟从 840ms 降至 210ms”才有实际信息。如果没有数字，就具体说明发生了什么。

精简

对每份草稿都执行这一流程。大部分质量都来自这里。

1. 删掉铺垫。“你可能知道……”“我想联系你分享……”“团队一直在努力……”——真正的第一句话通常是第三句。
2. **把结论放在开头。**如果结果在最后一段，那位置就不对。
3. 删掉程度副词。“非常”“确实”“相当”“显著”“大幅”等词会拉长篇幅、降低精确度。
4. 用事实或明确说明未知事项，替换模棱两可的说法。“应该很快就绪”→“周四就绪”或“日期未定——等待供应商回复。”
5. 每段只表达一个观点，最多三句话。
6. 把散文中的列表改成项目符号，把散文中的比较改成表格。
7. **单独读第一句话。**它是否表达了重点？如果没有，就重写。

**篇幅目标：**3P 更新 ≤ 250 词。高管更新 ≤ 200 词。公告 ≤ 300 词。事件报告按需撰写，但顶部需附上 ≤ 100 词的摘要。

如何描述问题

这是人们最容易写错的部分，也是决定沟通能建立还是损害信任的关键。

• **第一句话就说明问题。**把问题藏起来会让人觉得你在隐瞒；读者越晚发现问题，就越不信任其他内容。
• 坦诚负责，不要表演。“我们发布了一项回归，导致结账中断 40 分钟”——不要写成“部分用户遇到了问题”。
• 描述故障时不要用被动语态。“犯了一些错误”是最典型的反面例子。
• **归咎于系统，而非个人。**指出导致故障的原因——缺少检查、责任人不明确、路径未经测试。绝不要点名指责个人。
• **明确提出请求。**没有请求的问题只是抱怨。“受阻于 X；需要 Y 在周四前作出决定。”
• **把影响和原因分开。**读者需要先了解影响；原因可以随后说明。

语气

• 使用简洁的陈述句和主动语态。
• 为那些在会议间隙用手机快速浏览的人写作。
• 不用企业套话：“优化人员规模”“协同效应”“经验总结”“稍后再议”，也不要把“借助”当动词使用。
• 不要刻意营造热情。感叹号只用于真正值得庆祝的事，而且只用一次。
• 不要感谢读者阅读。不要为篇幅道歉——直接缩短内容。
• 与组织现有的表达风格保持一致；如果有之前的更新，就先读一读。

自我检查

• 第一句话点明重点
• 每项陈述都有数字、名称或日期
• 没有未说明不确定原因的模棱两可说法
• 清楚说明问题，使用主动语态，并提出请求
• 符合对应类型的篇幅目标
• 没有上下文的读者也能理解发生了什么变化及其重要性
• 已核实每个名称、日期、数字和链接，而非凭记忆填写
• 没有向超出预期范围的受众泄露机密信息

常见错误

把活动写成成就。“召开了 6 次规划会议”不代表有进展。交付了什么、作出了什么决定、发生了什么变化？

**把重点放在结尾。**读者会提前停止阅读。始终先给结论。

**每项内容的细节程度都一样。**重大上线和依赖项升级都写成同样的三行。按重要性分配篇幅。

**因为问题不好看就把它省略。**真正难看的是隐瞒问题——尤其是问题后来暴露时。

**直接复制粘贴工单标题。**工单标题是写给负责团队看的。要把它改写成适合当前受众理解的结果描述。

**所有受众共用一份更新。**高管摘要和团队更新是不同的文档，不是同一份文档的长短版本。

关键词

3P 更新，公司通讯，公司沟通，周报，状态报告，高管更新，领导层更新，常见问题，事件报告，事后分析，公告，内部沟通

相关技能

• coauthoring-docs — 用于撰写重要文档（规范、提案、RFC），而非更新
• verifying-before-completion — 在书面声明某项内容已交付或通过之前，先核实情况