---

name: meeting-notes language: zh-TW description: "按產品經理的最佳實踐整理會議紀要。當被要求寫會議紀要、整理討論記錄、記錄待辦事項或記錄任何型別會議的決定時使用。產出結構化紀要：決定、待辦事項（負責人加截止日期）、待解決問題和下一步。"

meeting-notes 的繁體中文翻譯，英文版本為規範版本。

會議紀要

這個技能整理會議紀要，讓它發揮最大價值，並確保事情落地。

所需輸入

如未提供，請向使用者詢問：

• 會議名稱和日期
• 參會人（姓名和角色）
• 原始筆記或文字記錄（貼上討論筆記、文字記錄，或描述討論了什麼）
• 會議型別（一對一 / 迭代規劃 / 產品評審 / 干係人同步 / 其他），決定使用哪個模板

從大腦讀取 / 寫入大腦

如果存在 professional-brain（brain/），紀要就在這裡變成長期記憶：

• 先讀： 相關的 stakeholders/ 檔案（這樣你進會議時就知道每位參會人未解決的請求和顧慮），以及會議要重新討論的 decisions/。
• 之後寫： 把每個決定（附理由和 reopen-when）追加到 decisions/，把新的請求或顧慮加入對應的 stakeholders/ 檔案，把任何新的假設記入 hypotheses/。給每條記錄的事實標註來源：大多數會議發言在被獨立確認之前都是 [verbal]。把原始筆記儲存到 source/。

標準會議紀要模板

會議抬頭

會議：[會議名稱] 日期：[日期] 參會人：[姓名 / 角色] 記錄人：[姓名] 時長：[實際時長]

議程

• 議題 1
• 議題 2
• 議題 3

（討論過的勾選）

已做出的決定

清楚記錄決定：

決定：[決定了什麼] 背景：[為什麼這樣決定] 負責人：[誰負責執行] 截止日期：[如適用]

每個決定都用這個格式。

待辦事項

所有待辦事項應寫成：

• [待辦事項] - @負責人 - 截止：[日期]
• [待辦事項] - @負責人 - 截止：[日期]

格式要求：

• 清楚、具體的行動
• 單一負責人（不能是"團隊"）
• 明確的截止日期
• 用勾選框跟蹤

討論要點

按議題整理討論的關鍵點：

議題 1：[名稱]

• 關鍵觀點或討論重點
• 提出的重要背景或顧慮
• 分享的資料或資訊

議題 2：[名稱]

• 關鍵討論點
• 達成的決定或結論

待解決問題 / 跟進

沒能回答的問題：

• 問題：[我們需要知道什麼]
• 負責人：[誰去查清楚]
• 截止：[日期]

下一步

清楚總結接下來會發生什麼：

1. [緊接著的行動]
2. [如需要，跟進會議]
3. [需要啟動的更大流程]

最佳實踐

會議中：

• 關注決定和待辦，而不是對話本身
• 記錄具體的承諾，而不是泛泛的討論
• 重要決定上記錄反對意見
• 對含糊的承諾要求說清楚（"我去看看" → "我會分析資料，週五前分享結論"）

會議後：

• 趁記憶新鮮，2 小時內發出紀要
• @ 待辦事項的負責人
• 附上相關文件連結
• 跟進逾期的待辦

要記錄什麼： ✅ 已做出的決定 ✅ 有負責人和截止日期的待辦 ✅ 討論的關鍵點 ✅ 待解決問題 ✅ 下一步

不要記錄什麼： ❌ 逐字記錄 ❌ 跑題的內容 ❌ 做決定之前的初步討論 ❌ 重複的資訊

會議型別與調整

一對一會議

關注：

• 職業發展討論
• 反饋（雙向）
• 當前的挑戰
• 雙方的待辦

模板補充：

• 近期成績：進展順利的事
• 挑戰：不順利的事
• 職業討論：發展話題
• 反饋：給雙方

迭代規劃

關注：

• 故事的驗收標準
• 估算決定
• 識別依賴
• 迭代承諾

模板補充：

• 迭代目標：我們承諾什麼
• 故事點：容量和估算
• 依賴：外部阻礙
• 完成定義：驗收標準

產品評審

關注：

• 設計決定
• 討論的使用者反饋
• 提出的修改
• 上線準備度評估

模板補充：

• 設計決定：批准或否決了什麼
• 使用者反饋：討論的關鍵洞察
• 待定的設計問題：需要迭代的地方
• 上線標準：剩餘的要求

干係人同步

關注：

• 彙報的進展
• 提出的顧慮
• 給出的批准
• 需要升級的事項

模板補充：

• 進展概覽：整體進度
• 已獲批准：拿到的簽字確認
• 升級事項：提給干係人的問題
• 下次同步：時間和內容

會議紀要示例

# 產品路線圖評審：2026 年第一季度
**日期**：2026 年 1 月 20 日
**參會人**：Sarah（CPO）、Mike（技術負責人）、Jennifer（設計）、Tom（產品經理）
**記錄人**：Tom
**時長**：45 分鐘

## 議程
- [x] 評審第一季度計劃的功能
- [x] 討論資源限制
- [x] 優先順序討論
- [x] 時間線對齊

## 已做出的決定

**決定**：多渠道工作臺移到第二季度，第一季度優先改進移動端 App
**背景**：客戶反饋顯示移動端體驗嚴重影響留存（65% 的使用者主要使用移動端）。工程團隊本季度只能承擔一個重大專案。
**負責人**：Tom（產品經理）負責向干係人溝通
**截止日期**：1 月 22 日

**決定**：拿出 20% 的工程時間處理技術債
**背景**：累積的技術債正在拖慢功能開發。上季度團隊速率下降 30%。
**負責人**：Mike（技術負責人）建立技術債待辦列表
**截止日期**：1 月 27 日

**決定**：全量上線前先對 100 名使用者做移動端內測
**背景**：需要在不同裝置上驗證改進效果
**負責人**：Jennifer（設計）與測試團隊協調
**截止日期**：2 月 10 日

## 待辦事項
- [ ] **按新優先順序更新第一季度路線圖** - @Tom - 截止：1 月 22 日
- [ ] **與客服團隊約會議，溝通工作臺延期** - @Tom - 截止：1 月 24 日
- [ ] **制定技術債優先順序評分標準** - @Mike - 截止：1 月 27 日
- [ ] **對移動端設計做使用者測試** - @Jennifer - 截止：2 月 3 日
- [ ] **為高管寫清決策理由** - @Sarah - 截止：1 月 23 日
- [ ] **找到 100 名移動端內測使用者** - @Tom - 截止：2 月 1 日

## 討論要點

**第一季度功能優先順序**
- 客戶留存是本季度公司的第一優先順序
- 移動端 App 的 NPS 為 6.2（網頁端為 8.1）
- 移動端佔日活使用者的 65%
- 多渠道工作臺需要 8 個工程周
- 移動端改進估計需要 6 個工程周，回報更高
- 銷售有 3 個企業客戶訂單在等工作臺功能

**資源限制**
- 目前有 4 名工程師可用（上季度為 6 名，因人員流失減少）
- 設計團隊可以同時支援兩個專案，但產能下降
- 測試團隊需要 2 周對移動端做完整測試
- 一名工程師借調到安全團隊直到 2 月

**風險討論**
- 推遲工作臺可能影響企業銷售（3 個訂單在等）
- Sarah 指出："我們可以把移動端改進定位為企業功能的基礎"
- Mike 對移動端技術棧的穩定性表示擔憂，已透過技術債時間分配解決
- 需要就時間線變化與銷售清楚溝通

**移動端實施計劃**
- 第 1 到 2 周：根據使用者反饋細化設計
- 第 3 到 4 周：工程實現
- 第 5 周：內部測試
- 第 6 周：100 名使用者內測
- 第 7 周：全量上線

## 待解決問題
- **問題**：推遲工作臺對企業銷售管道有什麼影響？
  **負責人**：Sarah 向銷售負責人確認
  **截止**：1 月 23 日

- **問題**：能否為企業客戶做工作臺的有限內測？
  **負責人**：Tom 與 Mike 探討 MVP 範圍
  **截止**：1 月 25 日

- **問題**：如果移動端改進沒有達到目標指標，我們的計劃是什麼？
  **負責人**：Tom 制定應急方案
  **截止**：1 月 27 日

## 下一步
1. Tom 在週三（1 月 22 日）下班前把更新後的路線圖發給領導層
2. 團隊下週一（1 月 27 日）開始移動端改進的迭代規劃
3. 2 月 1 日開跟進會，檢查進展並驗證優先順序
4. Sarah 在 1 月 24 日向高管團隊彙報決策理由

---

**下次會議**：2026 年 2 月 1 日，進展檢查
**紀要發出時間**：2026 年 1 月 20 日 17:30

延伸材料

這個技能附帶支援檔案，可用時請使用：

• references/decisions-vs-discussion.md：區分決定與討論。在產出時應用它；它包含上面方法摘要壓縮掉的校準和判斷。
• templates/notes-skeleton.md：可填寫的成果模板，品質關卡寫在裡面。當使用者想自己完成文件而不是生成時提供。

評分量表（0 到 40）

交付前給這個技能的任何產出打分；32 分以上才算可以交付。

維度	0	5	10
待辦問責	待辦分給"團隊"或沒人負責，沒有日期	有負責人，但截止時間含糊（"下週"、"儘快"）或多人共擔	每個待辦都有且只有一個負責人和明確日期；共同的工作拆成分別負責的事項
決定可追溯	決定埋在討論裡，或記錄了卻沒有理由	列出決定和負責人，但理由單薄；分歧看不到	每個決定都有背景、負責人和截止日期；反對意見記錄在決定中並附重新討論的條件，而不是被抹平
提煉而非記錄	按順序逐字記錄誰說了什麼	按議題整理的精簡記錄，但仍是對話而不是提煉	討論被提煉為承重的要點；只有在影響決定時才引用原話
閉環	待解決問題、推遲的議題和升級被悄悄丟掉	列出了待辦，但沒有負責人或日期；推遲的事從下一步中消失	每個待解決問題都有負責人和截止時間；推遲的事帶日期出現在下一步中；紀要在 2 小時內發出

品質檢查

• 每個待辦都有一個具名負責人（不是"團隊"）
• 每個待辦都有明確截止日期
• 決定包含背景（為什麼這樣決定）
• 待解決問題有負責人和截止時間
• 沒有逐字記錄，只有提煉

反模式

• 不要把待辦分給"團隊"或"大家"：每個待辦必須有且只有一個具名負責人，否則不會完成
• 不要逐字記錄對話：會議紀要記錄的是決定和承諾，而不是達成它們的完整對話過程
• 不要省略決定的背景：六個月後有人問"我們為什麼這麼做"時，沒有理由的決定毫無用處
• 不要讓待解決問題沒有負責人和截止日期：沒人跟進的問題就是被卡住的決定
• 不要在會後超過 2 小時才發紀要：第二天才發，負責人就錯過了趁熱行動的視窗

紀要分發

郵件標題格式："[會議型別] 紀要 - [日期] - [關鍵議題]"

示例："產品路線圖評審紀要 - 1 月 20 日 - 第一季度優先順序"

收件人：

• 所有參會人
• 待辦中提到的任何人
• 任何要求收到紀要的人

跟進：

• 在待辦截止前 3 天發提醒
• 每週彙總所有未完成的待辦
• 把完成的待辦標記出來並同步進展

執行

供已連線 MCP 服務（Notion、Linear / Jira、Slack）的工具型智慧體使用。沒有工具許可權的執行環境忽略這一部分，只交付文件。參見 SKILLSPEC.md §5 和 connectors/mcp-pairings.md。

前提條件

• 上面的結構化紀要已經展示給使用者並得到明確批准，包括目的地（哪個 Notion 資料庫或頁面、哪個任務跟蹤專案）。
• MCP 服務已在智慧體的環境中連線並完成認證。
• 每個待辦都有具名負責人：沒有負責人的事項先與使用者確認，絕不憑猜測分配。

允許的操作

• 在批准的 Notion 資料庫（或同類文件工具）中建立一個頁面，內容為批准的紀要原文。
• 在批准的專案中為每個批准的待辦建立一個任務（標題、負責人、截止日期來自紀要）。
• 如果使用者指定了頻道，把頁面連結（只有連結和一句摘要）發到該頻道。
• 其他一律不做：不編輯已有頁面或任務，不邀請或通知指定頻道之外的人，不寫入日曆。

驗證

• 讀取建立的頁面和每個建立的任務；確認標題、負責人和日期與批准的紀要一致。
• 把所有建立的連結用一個列表報告給使用者。

回滾

• 撤銷 = 只在使用者明確指示時，歸檔或刪除剛建立的頁面和任務。
• 遇到以下情況，停下來問使用者：找不到目標資料庫或專案、任務建立中途失敗（報告已經建立了什麼）、待辦負責人在任務系統中不存在。

示例觸發語

• “幫我整理會議紀錄。”
• “把討論筆記整理一下。”
• “列出待辦事項。”
• “記錄這次會議的決議。”