把同一件事说给四种人听：stakeholder-comms的精准沟通法则

同一个项目状态，跟CEO汇报一个版本，跟工程师同步另一个版本，跟客户沟通又一个版本——这不是话术分裂，而是专业沟通的基本功。

stakeholder-comms的核心命题很简单：同一件事，用四种方式说给四种人听。以下是一套可落地的操作框架。

安装就一条命令：

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

第一步：用权力-利益矩阵给受众分类

沟通之前，先搞清楚你在跟谁说话。最经典的工具是权力-利益矩阵（Power-Interest Grid），按两个维度把 stakeholders 分成四类：

高权力 × 高利益：决策者。CEO、高管、投资人。他们的时间最贵，要的是结论和决策点。

低权力 × 高利益：执行者。工程师、设计师、一线运营。他们需要知道“我该做什么、什么时候做”。

高权力 × 低利益：支持者。法务、合规、财务等职能团队。他们不关心细节，但会在关键时刻卡你。

低权力 × 低利益：观望者。偶尔过问的跨部门同事、外部合作方。维持信息透明即可，不需要主动 push。

花15分钟把你要沟通的人放进这四个格子里，后面所有工作都围绕这个分类展开。

第二步：针对四类人，调整四样东西

同一份信息，针对不同受众需要调整四个维度：颗粒度、语言体系、呈现形式和决策焦点。

给决策者（高权力×高利益）：结论先行，3页以内

决策者不需要知道过程，只需要知道三件事：现状是什么、需要我做什么、不做会怎样。一份合格的 executive briefing 应该包括：当前状态摘要（1-2句话）、关键风险与机遇（列表式）、明确的决策请求（“请批准X”或“请确认Y”）、建议的行动路径。

篇幅控制在3页以内，第一页就要让读者知道“这跟我有什么关系”。

给执行者（低权力×高利益）：可操作的行动清单

工程师和一线团队需要的是“做什么”而不是“为什么做”。他们不关心宏观叙事，但需要明确的上下文来理解任务优先级。沟通结构按“背景—任务—依赖—截止时间”展开。

执行者沟通的核心原则是：每一条信息都必须能转化为一个行动。如果一段话不能回答“然后呢”，就不该出现在给执行者的简报里。

给支持者（高权力×低利益）：只讲“会影响到你什么”

法务、合规、财务不会主动跟进项目细节，但他们会在审批节点上卡住你。给他们发简报的原则是：只讲他们需要知道的，不讲他们不需要知道的。

比如产品上线计划，法务只需要知道上线时间、涉及哪些新地区的合规审查、需要他们什么时候完成审批。不需要告诉他们用了什么技术栈。

给观望者（低权力×低利益）：保持透明，不主动打扰

这类人不需要定期简报。在他们偶尔问起时，给一个“目前进展正常、按计划推进”的简短回复即可-。过度沟通反而会制造不必要的关注和干预。

第三步：建立统一的“信息骨架”

给不同人讲不同版本，不代表信息可以前后矛盾。

stakeholder-comms 要求先建立一个统一的“信息骨架” ——项目当前的真实状态、核心风险、关键里程碑、需要的决策。这个骨架是所有版本的基础，无论给谁看，事实部分完全一致。

区别只在于呈现方式：对决策者压缩成3页结论，对执行者展开成行动清单，对支持者提炼出影响范围，对观望者保持一句话概括。

这样做有两个好处：一是防止不同版本之间出现事实矛盾；二是一旦项目状态发生变化，只需要更新骨架，四个版本自动同步更新。

第四步：选对渠道和节奏

四种人不仅需要不同的内容，还需要不同的触达方式。

决策者的时间最稀缺，书面简报让他们提前消化信息，当面汇报只用来做决策-。执行者需要实时同步，文档比会议更高效。支持者不需要高频打扰，里程碑节点统一同步即可。

第五步：闭环——确认对方听懂了

信息发出不等于沟通完成。stakeholder-comms的最后一步是确认对方接收到的信息与你发出的一致。

对决策者：在简报末尾附上一个“决策请求”清单，让对方用“同意/驳回/需讨论”三种状态之一回应。

对执行者：在任务描述末尾加一句“如果你理解有偏差，请在24小时内反馈”，给沉默者一个开口的出口。

对支持者：在邮件末尾附上一个“如果你没有异议，我们将按此推进”的默认确认机制。

对观望者：不需要主动确认，但保持随时可查的状态文档。

资源地址

总结

stakeholder-comms 不是让你学会“见人说人话、见鬼说鬼话”。它的核心是：用同一套事实，为不同的人提供不同粒度的决策支持。

决策者要结论，执行者要行动，支持者要边界，观望者要透明。把这四件事分开做好，沟通这件事就没那么难了。