内部沟通

内部沟通

帮你写清楚、写得体的团队内部沟通文档：周报、进展更新、发布公告、项目复盘。核心不是把发生的事罗列一遍，而是让特定的读者在最短时间里拿到他需要的信息、知道下一步该关注什么。

目标

产出一份结构清晰、语气匹配受众、信息密度高的内部沟通文档（Markdown）。好的内部沟通满足三条：读者一眼看到重点（不用从流水账里挖）、语气匹配关系（团队内、跨部门、对上各不相同）、每条信息都有落点（要么是进展、要么是计划、要么是需要对方做的动作）。

工作流步骤

步骤 1：确定文档类型与受众

先问清楚两件事，它们决定了结构和语气：

文档类型（决定用哪个结构模板）：

• 进展更新 / 周报 → 用 Progress-Plans-Problems（3P） 结构。
• 项目复盘 / 事故回顾 → 用 STAR（Situation-Task-Action-Result）或"发生了什么 / 影响 / 根因 / 改进项"结构。
• 发布公告 / 通知 → 用"一句话摘要 → 变更内容 → 影响范围 → 行动项/时间点"结构。
• 对上汇报 → 用"结论先行（BLUF, Bottom Line Up Front）→ 关键数据 → 风险与决策建议"结构。

受众（决定语气与详略）：

• 团队内：可以用行话和细节，语气平实直接，重协作与阻塞点。
• 跨部门：去掉本团队黑话，补充背景，说清楚"和你有什么关系"，重接口与依赖。
• 对上 / 管理层：结论先行，用数据支撑，控制篇幅（通常一页内），突出商业价值、风险和需要的决策。少讲过程，多讲结果和判断。

如果用户没说清类型或受众，先确认再动笔——同样一批事实，写给同事和写给 CEO 是两份完全不同的文档。

步骤 2：收集与筛选素材

• 如果用户提供了原始材料（会议记录、任务列表、日志、已有文档），用 Read 读取并提炼。
• 筛选而非搬运：把素材按"进展 / 计划 / 问题"或所选结构分桶，删掉对当前受众无意义的细节。
• 区分事实与判断：进展写事实（"完成了 X"），问题写判断和请求（"Y 有风险，需要 Z 支持"）。
• 缺失的关键信息（比如某项进展的量化结果、某个问题的负责人）主动向用户补充，不要编造数字。

步骤 3：套用结构撰写

3P 结构（周报 / 进展更新）——最常用：

• Progress（进展）：本周期完成了什么。每条尽量带可见的结果或里程碑，能量化就量化（"完成用户权限模块，覆盖 5 类角色"优于"做了权限相关工作"）。
• Plans（计划）：下周期要做什么。具体、可跟踪，最好对应到人和时间。
• Problems（问题 / 阻塞）：遇到了什么阻碍，明确写出需要谁提供什么支持。问题部分是周报最有价值的地方——它不是抱怨，是求助和预警。

STAR / 复盘结构：

• Situation 背景 → Task 目标 → Action 采取的行动 → Result 结果与数据。复盘额外加"根因分析"和"改进项（Action Items，带负责人和时间）"。

公告结构：

• 开头一句话说清"什么变了 / 什么时候"，再展开变更内容、影响范围、需要读者做的动作和截止时间。读者可能只看第一句，所以第一句必须自足。

对上汇报结构（BLUF）：

• 第一段就是结论和建议，后面才是支撑论据。管理层时间稀缺，把答案放最前面。

撰写通则：

• 重点前置：每个段落、每条 bullet 第一句就是重点，细节跟在后面。
• 一条一事：用 bullet 承载信息，不写大段流水。
• 动词开头、结果导向：写"完成/上线/修复了 X"，而非"进行了 X 相关的工作"。
• 量化：有数字用数字，没有真实数字就不编。

步骤 4：语气校准与精简

• 按步骤 1 确定的受众调整措辞：对上更简洁克制、突出决策；跨部门更多背景、更少黑话；团队内更直接。
• 删冗余：删掉"我觉得可能大概"这类模糊限定词、重复表述、无信息量的客套。内部沟通以清晰高效为最高标准。
• 通读一遍：读者读完能否立刻知道"我该关注什么 / 我该做什么"？不能就再改。

步骤 5：输出

按下面的格式组装 Markdown。默认在对话中给出；用户要求存档时用 Write 保存，文件名建议 <类型>-<周期或主题>.md（如 weekly-2026-W28.md）。

输出格式

周报 / 进展更新（3P）：

# <项目名> 周报（<周期>）

> 一句话摘要：本周<最关键的一件事>。

## Progress 进展
- ✅ <完成事项 + 可见结果/数据>
- ✅ ...

## Plans 计划
- ⏭️ <下周期事项>（负责人 / 预计时间）
- ⏭️ ...

## Problems 问题与需要的支持
- ⚠️ <问题描述> → **需要**：<谁 / 提供什么 / 何时前>

复盘（STAR + 改进项）：

# 复盘：<主题>

- **背景 / 目标**：...
- **过程与行动**：...
- **结果**：<含数据>
- **根因**：...

## 改进项
| 事项 | 负责人 | 截止 |
|------|-------|------|

公告：

# 公告：<一句话说清变更与时间>

- **变更内容**：...
- **影响范围**：<谁会受影响>
- **你需要做的**：<行动项 + 截止时间>
- **联系人 / 疑问**：...

边界

• 不编造数据和结果：进展里的数字、指标、完成度必须来自用户提供的素材；信息缺失时留占位并向用户询问，绝不虚构"看起来合理"的数据。
• 只写不发：本技能仅产出文稿，不代替用户发送到任何渠道（邮件、群聊、公告栏）。发布动作由用户自己执行。
• 不美化问题：Problems / 复盘部分要如实反映阻塞和风险，隐藏问题会误导决策。语气可以专业克制，但事实不打折。
• 匹配受众优先于套模板：模板是脚手架，最终以"这个读者读起来是否清楚、得体、够用"为准。类型混合时（如既要汇报进展又要发公告）以主受众为准拆分或合并结构。
• 保护敏感信息：涉及人事评价、未公开数据、个人隐私的内容，按内部沟通的最小披露原则处理，不确定是否可写入时提醒用户确认。