---

name: stakeholder-update language: zh-TW 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，它有自己的關卡），不新增批准文字中沒有的 @，不轉發到其他地方。

驗證

• 確認訊息出現在頻道或會話中（獲取永久連結）並報告連結。
• 確認傳送的文字與批准的文字逐位元組一致。

回滾

• 如果平臺允許，只有在使用者明確指示時才可以刪除剛發出的訊息；否則發一條更正回覆。
• 遇到以下情況，停下來問使用者：找不到頻道、傳送部分失敗、批准的文字與即將傳送的內容不再一致。

示例觸發語

• “寫一份進度更新。”
• “替主管寫進度報告。”
• “替利害關係人寫專案更新。”
• “寫一份高階主管簡報。”