官方技能 · 營運與行政

決策紀錄（決策日誌）

v1.0.0 · 2026 年 11 月 4 日 更新

把決策記成一則簡短的日誌：決策、背景、考慮過的選項、理由、決策者、日期、狀態，以及重新檢討的條件。

可在 Claude、ChatGPT 和程式設計代理中使用。使用 Team 和 Business 方案時，我們改進官方技能後，你 Pod 裡的這個技能會自動更新。

適用情境

• 團隊剛做出難以回頭或可能被質疑的決定
• 大家一直在問當初為什麼這樣選，但答案沒有寫下來

你要提供的內容

• 決定了什麼、由誰決定
• 日期
• 討論過的選項和落選的原因
• 討論串、會議紀錄或文件（選填）

你會得到的內容

一則有編號的 Markdown 決策紀錄，包含狀態、決策者、背景、選項、理由、影響和重新檢討的條件。

運作方式

1. 用一句主動語態的話寫出決策 Nygard 主張決策段落要「用完整的句子、主動語態」來寫，通常以「我們將」開頭。例如：「我們將從 3月1日起使用 Dealbook 作為 CRM。」
2. 用 2 到 4 句寫背景 迫使團隊做選擇的事實和壓力：期限、成本、某個客戶、某項限制。Nygard 說這一段「是價值中立的，只是在描述事實」。意見放在理由裡。
3. 列出考慮過的選項 每個選項一行，寫出它主要的取捨。Atlassian 的 DACI 做法會用一張表列出各選項的優點、缺點和成本。如果「維持現狀」是真的選項，也要列進去。只列真正討論過的選項。
4. 寫出理由 2 到 4 點，每點都要連回背景：為什麼這個選項勝過其他選項。接著列出影響，好的壞的都要寫。Nygard 說：「所有的影響都應該列在這裡，而不只是『正面的』那些。」
5. 寫出誰決定、徵詢了誰 一位決策者（Atlassian 的 DACI 做法稱為 Approver，「做出決定的那一個人（對：就一個！）」），以及被徵詢意見的人。英國政府的 ADR 框架也會記錄被徵詢的利害關係人。
6. 設定重新檢討的條件 一個會讓決策重新被討論的具體條件：日期、數字或事件（「業務超過 20 人時」、「價格漲到超出預算時」、「明年 3月1日檢討」）。本技能的預設：每則紀錄都要有；只有決策真的永久不變時才能寫「不需要」，而且要說明原因。
7. 設定狀態和編號 提議中、已採納或已取代。依序編號，編號絕不重複使用，和 Nygard 的格式一樣。如果這則取代了舊的決策，在舊紀錄標上「已由 #[n] 取代」並保留它；Nygard 的做法是把被推翻的決策「留著，但標成已取代」。

SKILL.md 檔案

完整檔案，就是你的 AI 讀到的內容。 下載檔案

---
name: decision-record
description: 把已經做出的決策記成一則簡短的決策紀錄：一句話寫出決策、背景、考慮過的選項、為什麼選這個、誰決定、日期、狀態，以及什麼情況下要重新檢討。依據架構決策紀錄（ADR）和決策日誌的做法，適用於任何商業決策。適用於團隊剛做出決定、有人要求記錄或整理某個決策，或大家一直在問「當初為什麼這樣做？」的時候。
---

# 決策紀錄

決策紀錄讓半年後的人不用去問當時在場的人，也能看懂決定了什麼、為什麼，以及什麼時候該重新討論。它記錄的是已經做出的決策，不是在為某個決策辯護。寫短一點：Michael Nygard 在 2011 年提出架構決策紀錄（ADR）格式的文章中說，整份文件應該是 1 到 2 頁，本技能的預設是半頁。

## 適用情境

- 團隊剛做出一個難以回頭、或之後會被質疑的決定：工具、供應商、價格、政策、招募計畫、流程。
- 有人說「把這個記下來」，或要求寫一則決策紀錄。
- 討論串裡一直有人問「當初為什麼選 X？」，而答案只存在某個人的腦袋裡。
- 不適用於做決策本身。要整理選項並讓建議獲得核准，先用決策備忘錄（decision memo），再把結果記在這裡。

## 需要準備

- 決定了什麼、由誰決定。如果不清楚是誰決定的，問一次；絕不用猜的。仍然不知道就寫「[決策者未確認]」。
- 做出決定的日期。如果沒有，用來源訊息的日期，並標上「[取自訊息日期]」。
- 當時有哪些選項，以及其他選項為什麼落選。如果只討論過一個選項，就照實寫；不要編造替代方案。
- 選填：討論的串、會議紀錄或文件，以及決策日誌上一則的編號。

## 步驟

1. **用一句主動語態的話寫出決策。** Nygard 主張決策段落要「用完整的句子、主動語態」來寫，通常以「我們將」開頭。例如：「我們將從 3月1日起使用 Dealbook 作為 CRM。」
2. **用 2 到 4 句寫背景。** 迫使團隊做選擇的事實和壓力：期限、成本、某個客戶、某項限制。Nygard 說這一段「是價值中立的，只是在描述事實」。意見放在理由裡。
3. **列出考慮過的選項。** 每個選項一行，寫出它主要的取捨。Atlassian 的 DACI 做法會用一張表列出各選項的優點、缺點和成本。如果「維持現狀」是真的選項，也要列進去。只列真正討論過的選項。
4. **寫出理由。** 2 到 4 點，每點都要連回背景：為什麼這個選項勝過其他選項。接著列出影響，好的壞的都要寫。Nygard 說：「所有的影響都應該列在這裡，而不只是『正面的』那些。」
5. **寫出誰決定、徵詢了誰。** 一位決策者（Atlassian 的 DACI 做法稱為 Approver，「做出決定的那一個人（對：就一個！）」），以及被徵詢意見的人。英國政府的 ADR 框架也會記錄被徵詢的利害關係人。
6. **設定重新檢討的條件。** 一個會讓決策重新被討論的具體條件：日期、數字或事件（「業務超過 20 人時」、「價格漲到超出預算時」、「明年 3月1日檢討」）。本技能的預設：每則紀錄都要有；只有決策真的永久不變時才能寫「不需要」，而且要說明原因。
7. **設定狀態和編號。** 提議中、已採納或已取代。依序編號，編號絕不重複使用，和 Nygard 的格式一樣。如果這則取代了舊的決策，在舊紀錄標上「已由 #[n] 取代」並保留它；Nygard 的做法是把被推翻的決策「留著，但標成已取代」。

## 輸出格式

```markdown
## #[編號] — [簡短的名詞片語標題]

**狀態：** [提議中／已採納／已由 #n 取代] · **日期：** [日期] · **決策者：** [一個人名]  
**徵詢對象：** [人名] · **來源：** [討論串、會議紀錄或文件的連結]

**決策：** 我們將[一句話]。

**背景：** [2–4 句事實。]

**考慮過的選項：**
- **[選項 A，採用]：** [主要取捨]
- **[選項 B]：** [主要取捨]
- **[維持現狀]：** [主要取捨，如果有考慮過]

**理由：**
- [連回背景的理由]

**影響：**
- [好的和壞的影響，對誰有什麼改變]

**重新檢討的條件：** [具體的日期、數字或事件]
```

## 範例

**輸入：** Slack 討論串摘要：「好，雅芳（營運長）2月3日拍板：我們用 Dealbook，不用 FunnelHQ。怡君和柏翰也有參與討論。以我們 6 個業務來算，FunnelHQ 的業務方案大約貴 3 倍，而且我們還沒用到行銷自動化。Dealbook 有我們需要的郵件同步。缺點是如果之後行銷想用 FunnelHQ，就得再搬一次資料。試算表快撐不住了，上個月漏掉 2 次追蹤聯繫。上一則紀錄是 #11。」

**輸出：**

```markdown
## #12 — 業務團隊的 CRM

**狀態：** 已採納 · **日期：** 2月3日 · **決策者：** 雅芳（營運長）  
**徵詢對象：** 怡君、柏翰 · **來源：** Slack 討論串，2月3日

**決策：** 我們將把業務團隊從共用試算表移到 Dealbook。

**背景：** 6 人的業務團隊用試算表追蹤商機，試算表已經快撐不住。上個月漏掉了 2 次追蹤聯繫。我們需要 CRM 能同步郵件。目前沒有使用行銷自動化。

**考慮過的選項：**
- **Dealbook，採用：** 有我們需要的郵件同步；沒有行銷自動化。
- **FunnelHQ 業務方案：** 包含行銷自動化，以 6 個業務計算，費用約為 Dealbook 的 3 倍。

**理由：**
- 能取代快撐不住的試算表，並且有我們需要的郵件同步。
- 以 6 個業務計算，FunnelHQ 業務方案的費用約為 3 倍，而我們還沒用到行銷自動化。

**影響：**
- 業務要把進行中的商機搬進 Dealbook，並停用試算表。
- 如果之後行銷需要 FunnelHQ，CRM 資料就要再搬第二次。

**重新檢討的條件：** 行銷想用 FunnelHQ，或開始使用行銷自動化時。
```

## 寄出前檢查

- [ ] 決策是一句主動語態、可以照著執行的話。
- [ ] 只寫出一位決策者，或寫「[決策者未確認]」。
- [ ] 列出的每個選項都真的討論過；沒有為了看起來周全而多加選項。
- [ ] 影響中至少有一項成本或缺點。
- [ ] 重新檢討的條件是具體的日期、數字或事件。
- [ ] 事實、人名、數字和日期全都來自來源。

## 常見錯誤

- 把一場討論記成決策。如果沒有具決定權的人說好，狀態就是「提議中」。
- 決策改變時去修改舊紀錄。要寫一則新的，並把舊的標成已取代；保留歷史正是重點。
- 背景段落在替決策辯護。支持這個選擇的論點放在「理由」。

分享給你的團隊

把它加入 AI Skill Pod，團隊每個人（外包人員也包括在內）都能從自己的 AI 使用同一個版本。 看看和團隊分享 AI 技能的最佳做法

加入我團隊的 Pod

更新紀錄

• v1.0.0 · 2026 年 11 月 4 日 · First release.