架構與設計決策

你將學到什麼

• 如何使用 Claude 以清晰的框架系統性地評估相互競爭的架構選項
• 如何撰寫不只記錄決策而且記錄推理的架構決策記錄（ADR）
• 如何將 Claude 作為複雜設計取捨的技術諮詢板

使用情境

架構決策是軟體開發中最高風險的選擇之一。與一個錯誤不同，你可以在一個下午修復它，錯誤的架構選擇可能多年來限制你的系統——創造效能上限、使某些功能不可能實現、積累每增加一個新功能都會複利的技術債。

挑戰在於架構決策通常是在不確定的條件下做出的。你在選擇你還沒有完全構建的選項之間做選擇，預測你的系統將如何增長，以及衡量每個選項都有真實成本的取捨。這正是 Claude 增加最多價值的結構化不確定性推理類型。Claude 可以幫助你系統性地思考選項、浮現你沒有考慮過的取捨、對你的假設進行壓力測試，以及記錄推理，讓你的未來自己（和團隊成員）理解為什麼做出了決策。

常見場景：在新產品的微服務和單體架構之間選擇；決定是否使用事件驅動的訊息系統；評估資料庫選擇（Postgres vs. MongoDB vs. 圖形資料庫）；確定如何構造快取層；規劃從一個系統到另一個系統的遷移策略；設計 API 版本控制方案。

逐步指南

第一步：框架決策，而不只是問題

在與 Claude 交流之前，你能做的最有價值的事情是清晰地表達你的決策。一個框架良好的決策有三個部分：

1. 背景資訊 — 系統是什麼？你目前的限制條件是什麼（團隊規模、現有基礎設施、流量規模、預算）？
2. 選項 — 你正在考慮什麼具體的替代方案？（如果你還不知道，請 Claude 幫助列舉它們。）
3. 標準 — 你最關心什麼？（開發者速度？操作簡單性？查詢效能？規模成本？數據一致性？）

沒有明確的標準，架構評估就變成了對偏好的爭論。有了標準，它們就變成了結構化的取捨分析。

第二步：請求選項分析，而不是建議

當你在決策的早期階段時，不要急於請 Claude 立即推薦一個選項。而是請求對每個選項的誠實分析。這有兩個目的：它浮現你可能沒有的資訊，並防止你過早錨定在 Claude 的第一個答案上。

提示模式：「對於每個選項，分析：(1) 它與我們的限制條件的契合程度，(2) 它的優勢所在，(3) 它的不足之處，(4) 我們需要投資什麼才能使它工作，以及 (5) 我們在 2 年後選擇它會後悔什麼。」

第三步：對你的假設進行壓力測試

在形成初步偏好後，使用 Claude 挑戰它。呈現你的暫定結論和背後的推理，然後問：

「我傾向於 [選項]。我做了什麼可能不成立的假設？如果這是錯誤的選擇，需要什麼是真的？我所否定的替代方案最強的論點是什麼？」

這種對抗性方法浮現盲點。你可能確認你的選擇是正確的——現在更有信心。或者你可能發現一個你沒有正確加權的關鍵因素。

第四步：撰寫架構決策記錄（ADR）

一旦做出決策，將其記錄為 ADR。ADR 是捕捉單一架構決策、其背景、考慮的選項和理由的短文件。對於入門、重訪過去的決策和避免兩次同樣的爭論，它們是非常有價值的。

Claude 非常擅長從決策對話中起草 ADR。分享你的分析並告訴 Claude：「使用標準格式起草這個決策的 ADR：標題、狀態、背景資訊、決策、後果、考慮的替代方案。」

第五步：使用 Claude 進行增量設計審查

架構不只是高層次的系統設計。它也是模組設計、介面設計和數據模型設計。對於這些較小規模的決策，將 Claude 作為審查夥伴：描述你正在考慮的設計、你的限制條件，並問：「這個設計的缺陷是什麼？隨著需求改變，這在哪裡會崩潰？你會改變什麼？」

提示範本

對於選項分析：

我正在為 [系統的簡短描述] 做一個架構決策。

背景資訊：
- 系統：[它做什麼、當前規模、流量、數據量]
- 團隊：[規模、專業知識、頻寬]
- 限制條件：[預算、時程、現有基礎設施]
- 增長預期：[12-18 個月後的預期規模]

決策：[清楚說明你在決定什麼]

我正在考慮的選項：
1. [選項 A]
2. [選項 B]
3. [選項 C——或請 Claude 列舉更多]

評估標準（按優先順序）：
1. [最重要的標準]
2. [第二個標準]
3. [第三個標準]

對於每個選項，請分析：
- 對我們的標準和限制條件的契合度
- 在我們具體背景中的關鍵優勢
- 關鍵弱點或風險
- 操作複雜性
- 2 年後我們會後悔的事情

現在還不要推薦一個選項——只是給我對每個選項的誠實分析。

對於 ADR：

請為以下決策撰寫一個架構決策記錄。

決策：[決定了什麼]
背景資訊：[使這個決策必要的情況]
考慮的選項：[簡要列出評估了什麼]
理由：[為什麼選擇這個選項]
預期後果：[因此發生了什麼變化、我們接受了什麼取捨]

格式化為標準的 ADR，包含以下章節：標題、狀態、背景資訊、決策、後果、考慮的替代方案。

技巧與最佳實踐

1. 預先說明你的非談判條件 — 每個架構決策都有硬性限制條件，無論其他優點如何都會排除某些選項。先說明這些：「我們不能使用任何需要對專有數據格式進行供應商鎖定的服務」或「我們必須留在現有的 AWS 帳戶中，不添加新的受管服務。」 這防止 Claude 在從未可行的選項上浪費分析。

2. 請求失敗模式，而不只是取捨 — 取捨是抽象的。失敗模式是具體的。不要問「這個選項的弱點是什麼」，而是問：「描述一個 18 個月後我們選擇了這個選項並深感後悔的現實情景。出了什麼問題？」 這使不利面變得生動且與決策相關。

3. 請求遷移路徑，而不只是設計 — 好的架構決策包括到達那裡的計劃。添加：「假設我們選擇這個選項，分階段的遷移是什麼樣的？我們在第一週 vs. 第一季 vs. 年底可以做什麼？」 這測試選項是否真正可實現。

4. 使用 Claude 綜合對立的觀點 — 當你的團隊分裂時，公平地呈現兩個陣營：「我們一半的團隊因為 [原因] 想要選項 A。另一半因為 [原因] 想要選項 B。幫助我們了解是否有辦法獲得兩者的最佳，或者這是一個我們需要承諾的真正的非此即彼選擇。」

5. 為你的 ADR 加日期並定期回顧 — 隨著背景改變，架構決策會衰退。請 Claude 在每個 ADR 中添加「回顧日期」欄位：「哪些條件會讓我們重訪這個決策？添加一個『何時應重新審視』部分，列出應該觸發重新評估的觸發因素。」 隨著系統演進，這讓你的 ADR 庫保持有用。

動手試試

識別一個你正在面對或最近做出的真實架構決策。寫出：你的系統背景資訊、你正在權衡的兩到三個選項，以及你的前三個評估標準。然後問 Claude：

「根據我的標準分析這三個選項。對每個的弱點要誠實——我想了解風險，而不只是好處。分析後，幫助我起草一份一頁的 ADR，記錄我選擇的任何選項。」

在你的下一次架構討論中使用 Claude 的分析。看看它浮現了哪些你的團隊沒有完全說清楚的取捨。