stakeholder-comms ：把同一件事说给四种人听

你写过周报吗？不是那种写了也没人看的，是真的会让老板做决策的那种。大部分 PM 的时间不是花在做决策上，是花在把同一个决策用四种不同的方式讲给四个人听。给老板要讲战略和风险，给工程师要讲优先级和阻塞，给客户要讲新功能和好处，给跨部门伙伴要讲时间线和影响。

这事听起来简单，做起来是另一回事。大多数人图省事，写好一份群发所有人。老板看到满屏的技术细节皱眉，工程师看到”战略层面的深度思考”翻白眼，客户看到内部术语完全不知道你在说什么。信息的价值不在内容本身，在于接收者能不能用上。你写得再详细，如果对方看不懂或者不关心，等于没写。

Anthropic 的 stakeholder-comms 这个 Skill，解决的问题就是这个。它不是帮你写周报，是帮你把同一组事实，按四种受众分别包装成他们能消化的样子。从 Exec Summary 到工程 Update，从客户面向到跨部门同步，每种场景都有结构化的模板和核对清单。更关键的是，它把状态评估、风险沟通、决策记录这些东西整合到了一起。

说白了这篇文章就想讲明白一件事：为什么”写给不同的人看”这件事值得用一个 AI Skill 来管，它到底管了什么，以及管完之后你的沟通效率会发生什么变化。如果你也在团队里当那个”沟通枢纽”，这个 Skill 的设计思路比你想象的更有参考价值。

环境准备

这个 Skill 的安装门槛低到几乎不存在。它来自 Anthropic 的 knowledge-work-plugins 仓库，本质就是一个 SKILL.md 文件，定义了一套完整的 PM 通信规则。你不需要登什么平台，不需要申请什么 API Key，只要有支持 Skill 协议的 AI 编程助手就行。

目前兼容的 Agent 数量相当可观：

• Claude Code（~/.claude/skills/）
• Cursor（~/.cursor/skills/）
• GitHub Copilot（~/.copilot/skills/）
• Windsurf、Cline、Roo Code
• Gemini CLI、Codex CLI、OpenCode、OpenClaw
• Kiro、Junie、Augment Code、Warp、Goose

14 个主流工具都能直接加载。安装就一条命令：

npx skills add https://github.com/anthropics/knowledge-work-plugins --skill stakeholder-comms

跑完之后 Skill 文件会被放到对应 Agent 的技能目录下，重启 Agent 即生效，不需要额外配置。

唯一需要注意的是，这个 Skill 不提供任何自动化集成。它不会连接你的 Jira，不会同步你的 Slack 频道，不会自动拉取你的 OKR 数据。它是一个纯文本层的”沟通教练”，你给它事实，它帮你组织和表达。如果你期待的是那种一键生成全组周报还能自动分发的东西，这不是它。但如果你需要的是每次沟通都能保持质量下限，它的价值比你想象的大。

操作流程

这个 Skill 的核心工作流可以拆成三层：状态评估、受众匹配、模板填充。每一层都在帮你做一件事，把你脑子里零散的信息，转成特定受众能直接拿去用的结构化更新。

状态评估是第一环。Skill 内置了一套红黄绿框架，不是简单的”好、一般、差”，而是有明确的切换标准。绿灯代表按计划推进，没有显著风险。黄灯意味着进度慢了或者风险开始显现，但已有缓解方案在进行中。红灯代表已经偏离计划，需要外部干预。关键在于切换时机的判断规则写得很具体：在第一次出现风险信号时就切到黄灯，而不是等事情确实变糟了。从黄灯回绿灯，必须是风险真正解除，不是暂停。

受众匹配是第二环。同一个项目进展，给老板和给工程师讲的东西完全不同。这个 Skill 内置了四种受众画像和对应的话术策略。给老板：“先说结论，保持 200 字以内，只提需要他们介入的风险”。给工程师：“链到具体的 PR 和 Ticket，解释为什么优先级变了”。给客户：“零内部术语，所有功能用’你现在能做什么’的方式表达”。给跨部门伙伴：“这件事什么时候影响到你们部门，你需要准备什么”。

模板填充是第三环。每类受众都有固定的输出格式，但每个空怎么填，Skill 给了非常具体的提示。Executive Update 的结构是 Status → TL;DR → Progress → Risks → Decisions Needed → Next Milestones，六段式，精炼到 200 字以内。Engineering Update 是 Shipped → In Progress → Decisions → Priority Changes → Coming Up，五段式，每条都链接到具体的 PR 或 Ticket。Customer Update 是 What’s New → Coming Soon → Known Issues → Feedback，四段式，全程禁技术术语。

最容易被忽视但最高频的场景是风险管理。Skill 内置了 ROAM 框架，每一个风险都必须归类到以下四种状态之一：

• Resolved：风险已解除，记录解决方式
• Owned：有人认领并主动管理，注明负责人和缓解方案
• Accepted：已知但选择不缓解，记录接受理由
• Mitigated：已采取措施降低风险至可接受水平还配套了一套”怎么把风险说清楚”的五步法：陈述风险本身、量化影响、评估概率、说明缓解方案、明确提出需要什么帮助。这个框架的价值不是分类，是逼你在写之前先把风险想透。大多数人汇报风险的问题是，说了风险但没说影响，说了影响但没说概率，说了概率但没说你在干什么。

关键设计

拆开这个 Skill 的设计，最聪明的地方不是那些模板本身，是它把”沟通”这件事从一个艺术活变成了一个工程活。如果你仔细看每条模板提示，会发现每个字段都附带了”为什么这么写”的说明，而不只是”写什么”的填空指令。

比如 Executive Update 的 tips 里有一条：Status color should reflect YOUR genuine assessment, not what you think they want to hear. Yellow is not a failure, it is good risk management. 这句话放在别的地方可能只是一条建议，但放在一个 AI Skill 的系统提示里，它改变了 AI 生成内容的基调。AI 不再试图美化事实，而是被明确要求诚实。Risk communication 那章还有一句杀伤力更大：Burying risks in good news 把风险藏在好消息里，这是 PM 最常见也最致命的沟通习惯。

另一个设计选择值得注意。这个 Skill 把”会议主持”也纳入了通信范畴，四种会议各有一套主持指南：

• Standup：限时 15 分钟，聚焦阻塞项
• Sprint Planning：先定优先级再估容量，推回过度承诺
• Retro：限 1-3 条行动项，聚焦系统而非个人
• Stakeholder Review/Demo：用真实产品 demo，不用幻灯片Standup 限时 15 分钟、聚焦阻塞项，Retro 限 1-3 条行动项、重点在系统而非个人。把会议主持放在通信 Skill 而不是项目管理 Skill 里，这个归类本身就说明了设计者的价值观：实时表达的质量，和文档沟通的质量，底层是同一件事。

但这个设计也有明显的取舍。四个受众模板的深度是不均匀的。Executive Update 和 Engineering Update 写得最详细，有完整的格式定义和注意事项。Customer Update 和 Cross-functional Partner Update 相对简略，更像是一个快速参考卡。这可能是刻意为之，面向外部受众的沟通确实变数更多、更依赖具体语境。但如果让我挑一个改进点，我会希望 Customer Update 也能有类似 Executive Update 的写作原则指导，而不只是一个模板结构。毕竟客户沟通出错，代价往往比内部沟通大得多。

使用场景

这个 Skill 最典型的场景是周报。一个 PM 手上同时跑着三个项目，每个项目涉及不同的工程团队和业务方。周五下午要发更新，对着空白的文档发愁。用这个 Skill，你只需要把当周的事实列出来：完成了什么、遇到了什么风险、下周要做什么。剩下的组织工作交给 Skill，它会根据受众自动调整每份更新的结构和措辞。

第二个高频场景是版本发布通知。一次大版本上线，工程团队关心的是回滚方案和监控告警，市场团队关心的是对外宣传口径，客户关心的是新功能什么时候能用、会不会影响现有服务。以前你可能要开三个会分别同步，现在同一个事实库、不同的通信模板，三条提示的事。更关键的是，每份更新都能保持独立的质量基准，不会因为时间紧就随便写了发出去。

第三个场景更”反常规”一点：决策记录。Skill 内置的 ADR 格式，实际上是给未来三年回头看的人准备的。一个好的 ADR 不是记录”我们做了什么决定”，是记录”当时为什么做这个决定、考虑了哪些替代方案、放弃了什么”。这个 Skill 把 ADR 的触发时机也写得很清楚：需要写 ADR 的决策包括以下几种：

• 战略性决策（选哪个市场、支持哪个平台）
• 有争议的决策（团队意见分歧，需要记录定论理由）
• 限制未来选项的决策（选了某个技术栈、签了某个合作）
• 你预期以后会有人质疑的决策（趁上下文还在，先记下来）

但也要说实话，这个 Skill 对于非常初级的 PM 可能有些”用力过猛”。如果你管理的项目只有一个团队、一类受众，大部分模板可能用不上。它最适合的场景是：你同时在跟三个以上的利益相关方打交道，每类人需要的信息粒度完全不同，而你已经厌倦了手动改写同一份更新。这种情况下，这个 Skill 的价值不只是省时间，是提升你输出内容的质量下限。哪怕你今天状态不好，按照模板走一遍，出来的东西也不会太差。

洞察与反思

用了这种”通信框架化”的 Skill 之后，有一个反直觉的发现：它最大的价值不在”写得更好”，在”想得更清楚”。ROAM 框架逼你在写风险之前先判断它是已解决的、被认领的、被接受的还是被缓解的。Executive Update 的格式逼你明确区分”做完了”和”正在做”。这些分类在你填模板的时候就发生了，不是写完才回顾。

这让我重新想了一个问题：AI 在 PM 工作中应该扮演什么角色？过去一年的主流叙事是 AI 替代重复劳动：

• 自动写会议纪要
• 自动生成周报
• 自动跟踪任务但 stakeholder-comms 这个 Skill 暗示了另一种可能：AI 不替代你的思考和判断，但它在你的思考路径上设置了一些”质量关卡”。你不能随便写”本周进展顺利”，因为模板要求你具体到”哪个 Milestone 达成了、哪个指标动了”。

对比其他”AI 写周报”类的产品，这个 Skill 的差异点很明显。大多数 AI 周报工具做的是”把你的碎片信息拼成一封邮件”，核心能力是自然语言生成。stakeholder-comms 做的是”给你一套沟通方法论，AI 只是执行这个方法的工具”。前者追求”写完就行”，后者追求”写完有用”。二选一的话，长期价值明显在后者的方向上。但短期来看，前者确实更省力，这也是为什么大部分人还是会选择一键生成的方案。

也有一个我没想清楚的问题：这种”结构化沟通”的训练效果，是否会在你停止使用 Skill 之后消失？就像很多人用 Grammarly 改完语法，自己写还是老样子。如果 PM 长期依赖模板来组织沟通，会不会反而弱化了独立判断”这个受众关心什么”的能力？我个人的倾向是，把它当训练工具用，而不是长期拐杖。用一段时间，把框架内化，然后逐渐减少依赖。

资源地址

总结

回头重新审视这个 Skill，它的核心价值可以缩成一句话：把”对不同的人说不同的话”这件事，从直觉变成了流程。

• 四个受众画像，覆盖 Exec、Eng、Customer、Cross-functional
• 红黄绿状态体系，定义了风险升级的触发线
• ROAM 风险框架，强制在写之前先分类
• ADR 决策记录，给未来的自己留上下文
• 四种会议主持指南，把实时沟通也纳入质量管控

每一块都服务于同一个目的，让 PM 的每次对外沟通，都有最低质量保障。

它不是万能的。没有自动化集成、模板深度不均匀、对单一受众场景性价比不高，这些都在上面说过了。但这些局限恰恰说明了它的定位：不是”帮你写东西的 AI”，是”教你写好东西的框架”。它不会替你写周报，但会逼你写出一份有用的周报。

如果你在做 PM，或者在做任何需要同时跟技术、业务、客户三边沟通的工作，这个 Skill 值得装上试试。不一定要每封邮件都用它的模板，但里面的沟通原则值得过一遍。尤其是那条 “Lead with the conclusion, not the journey”，大部分人的周报输就输在这一句话上。