架構決策記錄 ADR 怎麼寫提示詞（背景、可選方案、決定、後果，一頁說清為什麼這樣選）
團隊做了一個重要技術決定（換數據庫、引入消息隊列、選前端框架），想留下「當時為什麼這樣選」的記錄時用：把討論過程整理成標準的 ADR 文檔，寫清約束、被否決的方案和需要承擔的代價，半年後的新人也能看懂。
通用大模型 對話模型通用
請把下面的討論整理成一份架構決策記錄（Architecture Decision Record，ADR）。 - 決策主題：[決策主題]（例：訂單服務從 MySQL 遷到 PostgreSQL） - 編號：[如 ADR-0012] - 當前狀態：[當前狀態]（可選：提議中/已接受/已廢棄/被某某 ADR 取代） - 討論材料（會議紀要、聊天記錄、方案文檔都可以，原樣粘貼）： [粘貼討論材料] - 參與決策的角色：[如後端組、DBA、架構師] 文檔結構（總長度控制在一到兩頁）： 1. 標題：用一句話寫出決定本身，例如「訂單服務使用 PostgreSQL 作為主數據庫」。 2. 狀態與日期。 3. 背景：現在面臨什麼問題、有哪些硬約束（性能、成本、團隊技能、合規、時間），為什麼現在必須做決定。只寫事實，不寫結論。 4. 考慮過的方案：每個方案寫優點、缺點和關鍵風險；至少包括「保持現狀」這個選項。可以用對比表。 5. 決定：選了哪個方案，用一段話說明決定性的理由，與背景中的約束對應起來。 6. 後果： - 好處； - 需要接受的代價和新增的風險； - 需要後續跟進的事項（遷移步驟、要補的監控、要更新的文檔）。 7. 什麼情況下應該重新審視這個決定（例如數據量超過某個規模、某個依賴停止維護）。 要求： - 材料中沒有給出的數據（性能對比數字、成本）不要編造，標「待補充」； - 如果討論材料中存在明顯沒有達成一致的分歧，在文末單獨列出「未決問題」； - 使用 Markdown，標題層級清晰，適合直接放進代碼倉庫的 docs/adr 目錄。
高亮處換成你自己的內容：[決策主題]、[如 ADR-0012]、[當前狀態]、[粘貼討論材料]、[如後端組、DBA、架構師]
ChatGPT Plus 充值
已被複製 0 次
使用說明
怎麼填變量：[討論材料] 越原始越好，AI 擅長從混亂的聊天記錄裏提煉出約束和分歧。[當前狀態] 如果是「提議中」，這份文檔就可以拿去評審；已經做完決定的，可以補寫成「已接受」。
常見坑：
- 只寫選了什麼，不寫為什麼沒選別的。ADR 最大的價值恰恰是「被否決的方案和理由」，否則新人會反覆提出同樣的方案。
- 把背景寫成了推銷結論（「因為 PostgreSQL 更好」）。背景只寫問題和約束，判斷留到「決定」一節。
- ADR 寫好就不再改。正確做法是保留舊記錄，新決定寫一份新的 ADR，並把舊的狀態改為「被取代」。
追問技巧：追問「站在當時反對這個方案的人的角度，這份文檔有哪些地方寫得不公平或遺漏了他的理由」，讓記錄更客觀。
示例輸出
示例，僅供參考（節選）
markdown
# ADR-0012：訂單服務使用 PostgreSQL 作為主數據庫
狀態：已接受 日期：2026-10-07
## 背景
訂單表需要按 JSON 擴展字段做複雜查詢，當前方案依賴應用層過濾，高峰期接口耗時超過 2 秒。
約束：遷移須在 Q4 大促前完成；團隊中 2 人有 PostgreSQL 運維經驗；不增加新的託管服務供應商。
## 考慮過的方案
| 方案 | 優點 | 缺點 |
|---|---|---|
| 保持 MySQL，優化應用層 | 無遷移成本 | 無法解決 JSON 查詢性能，只能緩解 |
| 遷移到 PostgreSQL | JSONB 索引支持此類查詢 | 遷移與雙寫期風險，需要培訓 |
## 後果
- 代價：遷移期間需要雙寫，預計持續 3 周（待補充具體排期）
- 重新審視的條件：訂單表超過 5 億行時評估分庫分表方案同款作品
用這條提示詞做出來的作品；原作者會因此獲得積分
還沒有同款，來做第一個。
0 條評論
還沒有評論，來搶沙發～