内部沟通最容易出错的地方，不是句子不够顺，而是事实、推测、风险和行动被写成了同一种语气。Internal Communications Skill 的价值，是把真实材料整理成不同受众能读懂的状态更新、通知、FAQ 或摘要，同时保留证据和审批边界。
先看结论：先做事实表，再做文案
把工单、会议纪要、发布记录、服务状态和负责人确认放进事实表，逐项标记来源、时间、状态和保密范围。之后再决定是写项目成员更新、管理层摘要还是故障通报。没有来源的内容只能列为待确认，不应写成“已经完成”。
开始前先分清受众、渠道和权限
准备目标受众、发布渠道、截止时间、必须包含的行动项，以及不能公开的字段。项目成员需要下一步和依赖关系；管理层需要影响、风险和决策；支持团队需要用户影响、处理进展和可复制话术。相同事实可以有不同表达，但不能改变事实本身。
把人员姓名、客户信息、内部链接、密钥、事故细节和未发布计划单独标记。Skill 可以帮助删减或改写，但发布范围仍由负责人确认。
按这个顺序完成一次沟通
第一步：建立可回查的事实清单
从原始工单、日志、会议记录和负责人消息中提取事实，每条附时间和来源。把完成、进行中、阻塞、风险和下一步分列，避免一句话同时包含几种状态。
第二步：写出面向任务的初稿
先给出当前结论，再列影响对象、行动项、负责人和截止时间。不要为了让文章完整而补背景，也不要把“计划修复”改写成“已修复”。
第三步：按渠道做受控改写
在不改变事实的前提下，把同一信息改成 Slack 短消息、邮件、FAQ 或管理层摘要。保留需要回查的链接、时间和术语；删掉不应扩散的内部细节。
第四步：人工审批并记录发布版本
由事实负责人核对数字、状态和行动项，由渠道负责人确认受众与时机。发布后保存最终版本、来源快照和后续修订原因，避免下次把旧草稿当最新状态。
一个可复核的任务示例
可以给 Codex 这样的任务：读取本周已确认的 Jira 状态、会议纪要和服务事件记录，只整理“已完成、风险、阻塞、下周计划”四栏；先输出事实表和缺失材料，不写结论；再分别生成项目群更新和管理层摘要；隐藏客户姓名、内部链接和未批准计划；把每项结论附回原始记录，等待负责人确认后再进入发布流程。
输出时可以要求一张核对表，列为“沟通稿句子、原始来源、事实负责人、状态、可发布范围”。如果某句话找不到来源，就把它移到待确认清单。这样做会比反复要求“写得更专业”更有效，因为每次润色都不会越过事实边界。
故障通报还需要明确时间线：首次发现、已采取的动作、当前影响、下次更新时间和仍未知的部分。服务状态尚未恢复时，不能写“已解决”；没有确认受影响用户范围时，不能凭工单数量估算。对外客户通知属于另一条审批路径，不应该从内部群消息直接复制发布。
最容易误判的地方
- 把模型从上下文猜出的状态当成负责人确认。
- 把多个渠道的字数限制当成可以删掉限制条件。
- 将内部草稿直接复制到客户、公众或社交渠道。
- 只保留“好消息”，隐藏风险、阻塞和需要决策的事项。
- 发布后没有标明版本和更新时间，导致团队继续引用过期内容。
完成后的检查
- 每个关键事实都有来源、时间和责任人。
- 已完成、进行中、风险、阻塞和计划没有混写。
- 受众、渠道和发布范围经过确认，敏感字段已处理。
- 行动项包含负责人、时间和完成判断，链接可以实际访问。
- 最终稿与原始记录一致，模型生成内容没有绕过审批直接发布。
