内部沟通写作助手

内部沟通写作的三个真实痛点

工程师团队在写内部沟通时，常遇到三类问题：

• 格式不统一：同样是"周报"，A 组用 3P（Progress/Plans/Problems），B 组写成流水账，C 组直接发一段话让领导自己提炼。
• 信息收集不完整：写事故报告时漏掉影响范围，写 FAQ 时答案只有结论没有上下文，导致读者反复追问。
• 语气与受众错配：给全员的公司通讯写成技术债评审会的语气，或者给管理层的更新缺少关键决策项。

这个技能的核心是按文体模板强制结构化输出，而不是让模型自由发挥。

核心能力与工作流

支持的文体

• 3P 更新：Progress（已完成）/ Plans（下一步）/ Problems（阻碍），每条需具体可量化。
• 公司通讯：头条 + 分栏目（团队动态/业务亮点/提醒），语气积极、面向全员。
• FAQ：问答对列表，问题口语化、答案先结论再补细节。
• 通用沟通：按"背景—要点—行动项—联系人"结构，明确受众与下一步。

四步工作流

1. 判定沟通类型：从用户请求中识别文体，匹配对应模板。
2. 收集信息：按该文体的要点追问缺失项（如 3P 缺 Problems 就主动索要），不编造数据。
3. 按模板撰写：套用结构化模板生成初稿。
4. 语气与格式校验：检查语气是否符合文体，行动项是否带负责人与时限。

输出格式

最终产出是 CommsDoc 对象，包含：

• type（文体类型）
• audience（受众）
• title（标题）
• sections（分段落内容）
• action_items（带 owner 和 due 的行动项）

下游可直接转成 docx/pdf 发邮件，或转成 pptx 做汇报页。

适用边界与注意点

不适用的场景

• 对外公关稿或法律声明：需法务或公关团队审核，内部模板不保证合规性。
• 虚构业务数据：技能不会编造未提供的指标（如"转化率提升 30%"），缺失时会主动追问。

使用建议

• 先补全信息再生成：按步骤索要字段，避免生成后反复修改。
• 明确受众与语气：给管理层的更新要精简结论，给全员的通讯要解释背景。
• 行动项必须可执行：每条行动项需指定 owner 和 due，否则视为未完成。