架構決策記錄 (Architecture Decision Records)
在編碼過程中即時捕捉架構決策。與其讓決策只存在於 Slack 討論串、PR 評論或某人的記憶中,此技能能產生命結構化的 ADR 文件,並與程式碼共存。
啟用時機
- 使用者明確表示「讓我們記錄這個決定」或「將此記錄為 ADR」
- 使用者在重要的替代方案之間做出選擇(框架、函式庫、模式、資料庫、API 設計)
- 使用者說「我們決定...」或「我們選擇 X 而非 Y 的原因是...」
- 使用者問「為什麼我們選擇 X?」(讀取現有 ADR)
- 在規劃階段討論架構權衡取捨時
ADR 格式
採用 Michael Nygard 提出的輕量級 ADR 格式,並針對 AI 輔助開發進行調整:
# ADR-NNNN:[決策標題]
**日期**:YYYY-MM-DD
**狀態**:proposed | accepted | deprecated | superseded by ADR-NNNN
**決策者**:[參與人員]
## 背景
是什麼問題促使我們做出這個決策或改變?
[2-5 句話描述情境、限制條件及影響因素]
## 決策
我們提議或正在進行的改變是什麼?
[1-3 句話清楚陳述決策]
## 考慮過的替代方案
### 替代方案 1:[名稱]
- **優點**:[好處]
- **缺點**:[壞處]
- **不選原因**:[拒絕該方案的具體原因]
### 替代方案 2:[名稱]
- **優點**:[好處]
- **缺點**:[壞處]
- **不選原因**:[拒絕該方案的具體原因]
## 後果
這個改變讓哪些事情變得更容易或更困難?
### 正面
- [好處 1]
- [好處 2]
### 負面
- [權衡 1]
- [權衡 2]
### 風險
- [風險與緩解措施]
工作流程
捕捉新的 ADR
偵測到決策時刻時:
- 初始化(僅限首次) — 如果
docs/adr/不存在,請在使用者確認後才建立該目錄、一個內含索引表格標頭的README.md,以及一份供手動使用的空白template.md。未經明確同意,不得建立檔案。 - 識別決策 — 提取正在進行的核心架構選擇
- 收集背景 — 是什麼問題促使了這個決策?存在哪些限制?
- 記錄替代方案 — 考慮過哪些其他選項?為什麼被拒絕?
- 陳述後果 — 有哪些權衡取捨?什麼變得更容易/更困難?
- 分配編號 — 掃描
docs/adr/中的現有 ADR 並遞增編號 - 確認並寫入 — 將 ADR 草稿呈現給使用者審查。只有在獲得明確批准後,才寫入
docs/adr/NNNN-decision-title.md。如果使用者拒絕,則丟棄草稿,不寫入任何檔案。 - 更新索引 — 附加到
docs/adr/README.md
讀取現有 ADR
當使用者問「為什麼我們選擇 X?」時:
- 檢查
docs/adr/是否存在 — 如果不存在,回應:「在此專案中找不到任何 ADR。您想開始記錄架構決策嗎?」 - 如果存在,掃描
docs/adr/README.md索引以尋找相關條目 - 讀取匹配的 ADR 檔案,並呈現背景與決策章節
- 如果找不到匹配項,回應:「找不到該決策的 ADR。您想現在記錄一個嗎?」
ADR 目錄結構
docs/
└── adr/
├── README.md ← 所有 ADR 的索引
├── 0001-use-nextjs.md
├── 0002-postgres-over-mongo.md
├── 0003-rest-over-graphql.md
└── template.md ← 供手動使用的空白範本
ADR 索引格式
# 架構決策記錄
| ADR | 標題 | 狀態 | 日期 |
|-----|------|------|------|
| [0001](0001-use-nextjs.md) | 使用 Next.js 作為前端框架 | accepted | 2026-01-15 |
| [0002](0002-postgres-over-mongo.md) | 使用 PostgreSQL 而非 MongoDB 作為主要資料儲存 | accepted | 2026-01-20 |
| [0003](0003-rest-over-graphql.md) | 使用 REST API 而非 GraphQL | accepted | 2026-02-01 |
決策偵測訊號
留意對話中表示架構決策的模式:
明確訊號
- 「我們用 X」
- 「我們應該用 X 而不是 Y」
- 「這個權衡取捨是值得的,因為...」
- 「將此記錄為 ADR」
隱含訊號(建議記錄 ADR — 未經使用者確認不要自動建立)
- 比較兩個框架或函式庫並得出結論
- 做出有明確理由的資料庫綱要設計選擇
- 選擇架構模式(單體 vs 微服務、REST vs GraphQL)
- 決定驗證/授權策略
- 在評估替代方案後選擇部署基礎設施
良好 ADR 的要素
應做
- 具體明確 — 使用「使用 Prisma ORM」,而非「使用 ORM」
- 記錄原因 — 理由比結果更重要
- 包含被拒絕的替代方案 — 未來開發者需要知道考慮過什麼
- 誠實陳述後果 — 每個決策都有權衡取捨
- 保持簡短 — ADR 應能在 2 分鐘內閱讀完畢
- 使用現在式 — 「我們使用 X」而非「我們將會使用 X」
不應做
- 記錄瑣碎決策 — 變數命名或格式化選擇不需要 ADR
- 寫成長篇大論 — 如果背景章節超過 10 行,就太長了
- 忽略替代方案 — 「我們就選了它」不是有效的理由
- 未標示就補記錄 — 如果記錄過去的決策,請註明原始日期
- 讓 ADR 過時 — 被取代的決策應參考其替代者
ADR 生命週期
proposed → accepted → [deprecated | superseded by ADR-NNNN]
- proposed:決策正在討論中,尚未確定
- accepted:決策已生效並正在遵循
- deprecated:決策已不再相關(例如功能已移除)
- superseded:較新的 ADR 取代了此決策(務必連結替代者)
值得記錄的決策類別
| 類別 | 範例 |
|---|---|
| 技術選擇 | 框架、語言、資料庫、雲端服務商 |
| 架構模式 | 單體 vs 微服務、事件驅動、CQRS |
| API 設計 | REST vs GraphQL、版本策略、驗證機制 |
| 資料建模 | 綱要設計、正規化決策、快取策略 |
| 基礎設施 | 部署模式、CI/CD 管線、監控堆疊 |
| 安全 | 驗證策略、加密方式、機密管理 |
| 測試 | 測試框架、覆蓋率目標、端對端 vs 整合測試的平衡 |
| 流程 | 分支策略、審查流程、發布節奏 |
與其他技能的整合
- 規劃代理:當規劃代理提出架構變更時,建議建立一個 ADR
- 程式碼審查代理:標記那些引入架構變更但沒有相應 ADR 的 PR