Stakeholder update writer

何时使用

当需要把一段工作进展，按受众和节奏整理成一条得体的干系人更新时使用。典型场景：

• 周期性汇报：给领导/团队的周报、月报。
• 发布公告：功能或产品上线，说明范围、影响与反馈渠道。
• 风险升级：把某个风险或阻塞点向上抛出，明确诉求。
• 一次性更新：转向、重大决策、需要拍板的事项。
• 同一进展改写多版：高管简报版 / 工程明细版 / 跨职能版 / 对客版。

不该用（负边界）：

• 对客户对外回复（用客户回复类技能）。
• 纯营销/落地页/获客文案（用营销文案类技能）。
• 纯财务模型搭建或三表预测（那是数据准备，本技能聚焦「如何讲清楚」）。
• 本技能只产出草稿，数字与承诺发送前仍需人工核验。

步骤

1. 定更新类型：周报（进展/阻塞/下一步）/ 月报（趋势/里程碑/战略对齐）/ 发布公告 / 一次性（升级/转向/决策）。
2. 定受众：高管（结果导向、战略框定、极简）/ 工程团队（技术细节、阻塞、待定决策）/ 跨职能伙伴（共同目标、依赖）/ 客户外部（收益导向、清晰时间线、零黑话）/ 董事会（指标驱动、聚焦风险、极简）。
3. 拉取背景：从可用来源补齐——项目跟踪（路线图/里程碑状态、自上次更新已完成项、在险/受阻项、迭代进度）、团队聊天（讨论与异步决策、暴露的阻塞）、会议记录/转录（决策与行动项）、知识库（决策文档、设计评审）。无可用工具时，向用户索取四要素：自上次更新完成了什么 / 当前阻塞与风险 / 已做或待定的决策 / 接下来做什么。
4. 按受众生成：套用下方对应模板与状态/风险框架。
5. 复核交付：主动问是否调语气、详略或侧重；按渠道排版（邮件/聊天贴/文档/幻灯片）；需要时直接代写可发送的消息。

指令

核心原则：

• 别埋导语——开头就讲最重要的那件事；有坏消息先讲，别藏在好消息后面。
• 状态灯反映真实判断，不是对方爱听的话。黄不是失败，是良好的风险管理。
• 诉求必须具体可执行——「需要支持」不是诉求，「周五前对 X 拍板」才是。
• 对高管一律用结果与目标框定，不堆活动与任务（「我们上线 X 并拉动了 Y 指标」，而非「开了 14 次站会、关了 23 个工单」）。
• 长度匹配受众注意力：高管几条要点；工程给到所需细节。

状态灯（绿/黄/红）判据：

• 绿（On Track）：按计划推进、无重大风险、能如期兑现承诺。真的顺利才用绿，别当默认值。
• 黄（At Risk）：进度慢于计划或风险已出现，缓解进行中但结果不确定；不干预可能误期。越早标黄，可选项越多。
• 红（Off Track）：显著落后、有重大阻塞且无清晰缓解，不重大干预（砍范围/加资源/延期）必误期。真正需要求助时才用红，别等到来不及。

改灯规则：见到风险首个苗头即转黄（而非确定变坏时）；自己手段用尽、需要升级时转红；风险真正解除才转回绿（仅暂停不算）；每次改灯都注明「因 X 转黄」。

ROAM 风险框架：Resolved（已解除，记录如何解的）/ Owned（有人正在管，写明 owner 与缓解计划）/ Accepted（已知但选择不缓解，记录理由）/ Mitigated（已降到可接受，记录所做动作）。

讲清一个风险的五步：①清晰陈述「存在 X 风险，因为 Y」→ ②量化影响「若发生，后果是 Z」→ ③说明概率「这件事可能/也许/不太可能，依据是…」→ ④给出缓解「我们正用 … 应对」→ ⑤提出诉求「需要你给 … 来进一步降低风险」。常见错误：把风险埋进好消息、含糊（不说清是什么/多久/为何）、只报风险不给缓解、拖太久（早报是规划输入，晚报是救火）。

输出规范：保持可扫读，关键点加粗、列表用要点。高管更新控制在 200–300 字以内；工程更新可长，但仍要分块便于略读。

示例

高管 / 领导版（结果导向，<200 字）：

状态: [绿 / 黄 / 红]

TL;DR: [一句话——最该知道的事]

进展:
- [已达成结果，挂到目标/OKR]
- [里程碑及其影响]
- [关键指标变动]

风险:
- [风险]: [缓解计划]。[如需，附诉求]。

待定决策:
- [决策]: [选项 + 推荐]。需在 [日期] 前。

下一里程碑:
- [里程碑] —— [日期]

工程团队版（多给链接，便于点进细节）：

已交付:
- [功能/修复] — [PR/工单链接]。[如有，影响]。

进行中:
- [事项] — [Owner]。[预计完成]。[如有，阻塞]。

决策:
- [已定]: [理由]。[ADR 链接（如有）]。
- [待定]: [背景]。[选项]。[推荐]。

优先级变化:
- [变了什么、为什么]

接下来:
- [下批事项] — [为何是这些]

对客 / 外部版（按收益讲，零内部黑话，无工单号）：

新功能:
- [功能] — [对客户意味的收益]。[如何使用/链接]。

即将推出:
- [功能] — [预计时间]。[为何与你相关]。

已知问题:
- [问题] — [状态]。[绕行方案（如有）]。

反馈:
- [如何反馈或提需求]

源命令：/stakeholder-update <更新类型与受众>。调用示例：「给领导写一份本周状态更新」「升级这个阻塞风险」「把这版进展改写成对客版本」。

注意事项

• 草稿仅供发送前参考：所有数字、时间线、承诺均须人工核验，不得超出授权。
• 严防外泄不可对外的路线图、内部口径或敏感信息（尤其对客版）。
• 对客版只在「影响客户且已有解决计划」时才提已知问题；时间线宁可写「本季度晚些」也别承诺一个可能错过的日期。
• 高管版只列「需要他们帮忙」的风险；已在自己掌控中的风险，除非必须知会，否则不必列。
• 状态灯宁可提前标黄，也别用绿色粉饰；这是风险沟通，不是乐观表态。

互见

• related：board-meeting-prep —— 高风险对抗式董事会/投资人审查的备会演练，本技能聚焦常规分受众进展更新
• related：adr-writer —— 更新中「已定决策」可链接到正式 ADR 留痕
• related：meeting-transcript-analyzer —— 从会议转录提取决策与行动项，作为更新的输入
• combines_with：board-deck-builder —— 把更新内容沉淀为面向董事会/高管的演示材料

---

采编自 anthropics/knowledge-work-plugins（Apache-2.0）。