---

name: stakeholder-update language: zh description: "用 BLUF（结论先行）框架撰写简洁的高管和干系人进展汇报。当被要求写状态更新、进度报告、项目沟通或给领导层、干系人的简报时使用。产出结论先行的汇报：状态、关键指标、风险、即将到来的里程碑和需要的决策，两分钟内读完。中国职场的周报请使用 cn-weekly-report。"

stakeholder-update 的简体中文翻译，英文版本为规范版本。

干系人汇报

这个技能按 BLUF（结论先行）原则，为高管和干系人撰写有效的进展汇报。

所需输入

如未提供，请向用户询问：

• 汇报的项目或产品
• 读者（CEO、董事会、跨部门负责人、投资人，会改变深度和格式）
• 周期（本周 / 本迭代 / 本月）
• 当前状态（正常 / 有风险 / 受阻）
• 关键指标及其当前值与目标对比

从大脑读取 / 写入大脑

如果存在 professional-brain（brain/），先用它再提问：

• 先读： 相关的 stakeholders/ 文件（每个人关心什么、之前提过什么请求）、context.md（语气）以及最近的 decisions/，了解上次汇报以来的变化。
• 之后写： 把新出现的请求、顾虑或承诺追加到相关的 stakeholders/ 文件，并标注来源（会议上说了但还没有书面记录的，标为 [verbal]）。

延伸材料

• references/status-honesty-guide.md：🟢/🟡/🔴 判断的校准（西瓜问题、连续 🟡 规则、诚实地重设基线），以及坏消息的"事实 → 影响 → 行动 → 请求"表达方式。只要状态是 🟡/🔴，或输入的笔记看起来比指标乐观，就使用它。
• templates/update-skeleton.md：一页可填写的汇报模板，质量关卡写在里面，并附发送前检查清单。提供给想自己写汇报的用户。

汇报结构

1. BLUF（结论先行）

从最重要的信息开始：

• 状态：🟢 正常 / 🟡 有风险 / 🔴 受阻 / ✅ 已完成
• 核心结论：一句话总结当前状态
• 需要的行动：你需要干系人做什么（如有）

2. 进展摘要

简要概述成果：

• 本周期上线了什么
• 达成的里程碑
• 关键指标的变化

最多 3 到 5 条。

3. 指标看板

关键指标

指标	当前	目标	趋势	状态
[指标名称]	[数值]	[目标]	↑/→/↓	🟢/🟡/🔴

只放最重要的 3 到 5 个指标。

4. 风险与阻碍

高优先级问题：

• 问题：简要描述
• 影响：涉及什么
• 应对：你正在做什么
• 需要的帮助：干系人能做什么（如适用）

只写对高管层面重要的问题。

5. 即将到来的里程碑

未来 30 天：

• 里程碑（预计日期）
• 里程碑（预计日期）

未来 90 天：

• 重大里程碑（月份）
• 重大里程碑（月份）

6. 需要的决策（如适用）

• 决策：清楚的描述
• 选项：2 到 3 个选项及利弊
• 建议：你建议什么，为什么
• 时间：何时需要决定

写作指南

语气：专业、简洁、以行动为导向 长度：不超过一页（或两分钟阅读时间） 频率：活跃项目每周一次，维护期每两周一次

与高管沟通的原则：

1. 先说结论，不说过程

   • ❌ "我们本周做了 5 个实验并分析了数据……"
   • ✅ "优化工作使转化率提升了 15%"

2. 关注影响，而不是活动

   • ❌ "进行了 12 次客户访谈"
   • ✅ "找到了采用的头号障碍（设置太复杂）"

3. 尽早暴露问题

   • 不要粉饰风险
   • 提出解决方案，而不只是问题
   • 具体说明需要什么帮助

4. 用数据讲故事

   • 尽可能量化
   • 展示趋势，而不只是快照
   • 把指标和业务结果联系起来

5. 便于扫读

   • 使用标题和要点
   • 加粗关键信息
   • 使用视觉标识（🟢🟡🔴、↑→↓）

状态标准

🟢 正常：所有目标都在达成，没有重大风险 🟡 有风险：存在可能影响交付的潜在问题 🔴 受阻：关键问题阻碍了进展，需要介入

汇报示例

# 产品更新：新用户引导改版
**2026 年 1 月 20 日当周**

## BLUF
**状态**：🟡 有风险
**核心结论**：新的引导流程在测试中表现良好（完成率 +35%），但由于与计费系统的集成问题，上线推迟一周。
**需要的行动**：需要决定是先单独上线引导流程，还是等计费集成修复后一起上线。

## 进展摘要
- 完成 24 名参与者的用户测试（94% 正面反馈）
- 上线首次使用体验改进
- 解决了测试中发现的 15 个缺陷中的 12 个
- 工程团队已为计费集成修复调配资源

## 关键指标
| 指标 | 当前 | 目标 | 趋势 | 状态 |
|--------|---------|--------|-------|--------|
| 引导完成率 | 45% | 60% | → | 🟡 |
| 首次获得价值的时间 | 4.2 分钟 | 3.0 分钟 | ↓ | 🟢 |
| 设置相关工单 | 45 / 周 | <30 / 周 | ↓ | 🟢 |
| 用户激活率 | 52% | 65% | → | 🟡 |

## 风险与阻碍

**高：计费系统集成延迟**
- **影响**：用户无法完成引导流程；上线推迟 1 到 2 周
- **根本原因**：支付服务商弃用了 API，需要重写代码
- **应对**：工程团队已重新分配资源，预计 2 月 3 日修复
- **需要的决策**：不带支付集成先上线引导，还是等修复？（见下文）

**中：移动端测试覆盖**
- **影响**：较旧的安卓设备上部分边界情况未测试
- **应对**：与测试团队合作扩大测试矩阵；在多种设备上进行内部用户内测

## 即将到来的里程碑

**未来 30 天：**
- 解决计费集成（2 月 3 日）
- 上线引导改版（2 月 5 日或 2 月 12 日，取决于决策）
- 开始衡量对转化的影响（2 月 12 日）

**未来 90 天：**
- 根据生产数据迭代（3 月）
- 扩展到移动端 App（4 月）
- 上线高级功能（5 月）

## 需要的决策

**是否把引导流程与计费集成分开上线？**

**选项 A：现在上线（建议）**
- 优点：立即把 35% 的完成率提升带给用户，收集生产数据，保持节奏
- 缺点：用户需要在旧流程中完成支付，体验略有割裂
- 时间：2 月 5 日上线

**选项 B：等计费修复**
- 优点：从第一天起就是完整集成的体验，没有技术债
- 缺点：收益推迟 2 周，第一季度指标目标有风险，团队节奏受影响
- 时间：2 月 12 日上线

**建议**：选项 A。引导改进本身就有价值，旧的支付流程运行正常。等待可能错过第一季度目标，并让已验证的改进晚到用户手中。

**时间**：为了 2 月 5 日上线，需要在 1 月 22 日前决定。

---

**有问题？** 回复这封邮件或在 Slack 上找我。

频率指引

每日站会：

• 极简（3 条）
• 昨天上线了什么
• 今天要上线什么
• 阻碍

每周汇报：

• 使用上面的完整模板
• 关注进展和风险
• 控制在一页

月度回顾：

• 更深入的指标分析
• 战略反思
• 季度目标进展
• 可以更长（2 到 3 页）

季度业务回顾：

• 全面分析
• 长期趋势
• 战略建议
• 演示形式

按读者调整

面向最高管理层

• 先说业务影响
• 对应到公司 OKR
• 关注战略和结果
• 尽量减少技术细节

面向产品与工程负责人

• 包含技术背景
• 展示迭代或里程碑进度
• 讨论架构影响
• 提及技术债

面向跨部门团队

• 平衡技术和业务背景
• 突出依赖关系
• 指出需要的协作
• 明确提出请求

面向董事会和投资人

• 关注指标和增长势头
• 竞争定位
• 市场机会
• 财务影响

评分量表（0 到 40）

交付前给这个技能的任何产出打分；32 分以上才算可以交付。

维度	0	5	10
BLUF 与状态诚实度	状态埋没或缺失；汇报读起来像活动日记	状态和结论在前，但颜色美化了指标（外绿内红）	前三行给出状态、一句话结论和请求；🟢/🟡/🔴 的判断与最差的关键指标一致并说明原因
指标背景	只有原始数字，没有目标、趋势或周期对比	有目标，但指标是与业务结果脱节的活动计数	3 到 5 个指标，每个都有目标、趋势和状态，重要的那些与收入、客户或关键目标挂钩
风险可行动性	风险只是担忧，没有负责人、应对或影响	写了应对，但影响没有量化，看不出读者是否需要做什么	每个风险都有量化的影响、带日期或成功条件的应对，以及明确的"需要的帮助"（或"无"）
决策表述	向高管抛出开放式问题，或根本没有提出决策	列出了选项，但没有成本、取舍或建议	每个决策有 2 到 3 个计算过成本的选项、带理由的明确建议，以及需要决策的日期和为什么是这个日期

质量检查

• 汇报以 BLUF 开头：任何细节之前先写状态、核心结论和需要的行动
• 每个指标都有与目标的对比（而不只是原始数字）
• 每个风险都有应对，需要干系人行动时标注"需要的帮助"
• 需要的决策有具体选项和明确建议
• 总长度不超过一页或两分钟阅读时间

反模式

• 不要把状态判断放在最后：BLUF 意味着最重要的信息先说
• 不要报告没有目标或上期对比的指标：没有背景的原始数字没用
• 不要列出没有应对措施、也没有标明需要干系人帮助的风险
• 不要把需要的决策写成没有明确建议的问题：高管需要的是选项，不是开放式问题
• 不要让汇报超过一页：如果需要更多，说明信息需要精简，而不是扩写

执行

供能够访问团队沟通渠道（Slack、邮件）的工具型智能体使用。发送汇报是对外的行为：绝不自动进行。没有工具权限的运行环境忽略这一部分。参见 SKILLSPEC.md §5。

前提条件

• 最终汇报文本已逐字展示给用户并得到明确批准，包括确切的频道或收件人列表。
• 频道或收件人列表由用户指定，而不是从历史中推断。
• 如果状态是 🔴 或包含"需要的决策"，确认指定的决策人在收件人中。

允许的操作

• 把批准的文本原样发到唯一批准的频道，或用批准的邮件标题作为一封邮件发给批准的收件人。
• 把副本保存到用户指定的位置（文档、大脑、仓库文件）。
• 其他一律不做：不设置定期发送（如需要，见 schedule-recipe，它有自己的关卡），不添加批准文本中没有的 @，不转发到其他地方。

验证

• 确认消息出现在频道或会话中（获取永久链接）并报告链接。
• 确认发送的文本与批准的文本逐字节一致。

回滚

• 如果平台允许，只有在用户明确指示时才可以删除刚发出的消息；否则发一条更正回复。
• 遇到以下情况，停下来问用户：找不到频道、发送部分失败、批准的文本与即将发送的内容不再一致。

示例触发语

• “写一份进度更新。”
• “给领导写进展报告。”
• “给相关方写项目更新。”
• “写一份高管简报。”