從透鏡到框架 — 一個人如何用 AI 建出 12 套開發決策系統 - Ward
用 AI 寫了 300 個 session 的 code 之後，我把反覆踩的坑變成了 AI 會自動問我的決策系統。這篇記錄從 checklist 到三態裁決框架的演化過程。
用 AI 寫了 300 個 session 的 code，我發現自己一直在問同樣的問題。
「這段該不該拆？」「改了會不會炸到別的地方？」「這個方向對嗎？」每次都是我自己問自己，每次都是憑感覺回答。
我的開發環境很單純：一個人加上 Claude Code。沒有 team，沒有 code review，沒有 PM。這種設定的好處是速度快、沒有溝通成本。壞處是——沒有人會幫你踩煞車。
當你一個人開發，品質的最後防線就是你自己的判斷力。但人的判斷力會疲勞、會遺漏、會因為趕進度而放水。我需要一個機制，讓那些「我應該問但忘了問」的問題，在正確的時間點自動出現。
這篇文章記錄我怎麼從零開始，把這些重複的問題變成 12 套 AI 會自動觸發的決策系統。
Phase 1 — 透鏡：把直覺變成 checklist
四月的時候，我開始覺得不對勁。
每次要寫計畫書，總是漏掉同樣的角度。寫完覺得完整了，回頭看才發現沒考慮回滾方案、沒想過邊界條件、沒評估對既有模組的影響。這些不是什麼高深的問題，就是「早該問的但沒問」。
我決定回頭翻自己的對話紀錄。用腳本掃了 10 個 session、4352 段對話，把每一次「回頭修正」「踩坑後的補救」「中途改方向」的原因撈出來。結果整理出 183 個反覆出現的問題。
這些問題有明顯的結構。我把它們歸納成三層樹：
- 8 個元規則：最上層的思考原則，像是「根因優先」「閉環驗證」「單一職責」
- 25 個檢查項：每個元規則展開成具體的檢查維度
- 80+ 提問句：每個檢查項對應的實際問題
展開來長這樣：
舉個例子。元規則 A1 是「根因優先」，底下有一條檢查項是「重複修補偵測」，對應的提問句是：「這個問題你已經修了 2 次還沒好，是不是該停下來找根因？」
這不是什麼原創的概念。Toyota 的 5 Whys 問的是同一件事，Gary Klein 的 Pre-mortem 也是在逼你提前想失敗。FMEA 更是整套失效模式分析。但差別在於——這些方法論在業界是「人自己去翻手冊」，在我的環境裡是「AI 在你動手前自動問你」。
我把這套東西叫做「透鏡」（Lens）。一組透鏡就是一組特定角度的問題，套上去看，就能看到原本忽略的盲點。
| 我的做法 | 業界對標 | 共同核心 |
|---|---|---|
| 根因優先提問 | 5 Whys (Toyota) | 逼到底層，不修表面 |
| 預先失敗想像 | Pre-mortem (Gary Klein) | 假設已經失敗，倒推原因 |
| 失效模式分析 | FMEA | 系統性列舉可能出錯的地方 |
| 差別：綁在 AI 工作流 | 差別：人去翻手冊 | — |
Phase 2 — 從 12 組到兩套體系
透鏡做下去，自然分成了兩套。
第一套是工具透鏡，12 組（A 到 L）。 用戶丟一個關鍵字或場景描述，AI 把對應的透鏡組拉出來，像 checklist 一樣逐項掃過。這是廣度防漏——確保你沒有遺漏重要的角度。
第二套是思考透鏡，16 支。 這些不是被動等你觸發的，而是 AI 偵測到對話中的語意線索後，主動建議「要不要套這個透鏡看看？」。比如你說「A 跟 B 選哪個」，它會建議套 trade-off 矩陣透鏡；你說「這東西穩定了，不太需要改」，它會建議套不變量透鏡。
兩套搭配使用的邏輯是：工具透鏡負責廣度掃描，確保不漏；思考透鏡負責縱深挖掘，確保想透。先廣後深，或者交叉使用。
這些透鏡背後的思維模型也不是我發明的。它們有清楚的業界血統：
| 透鏡概念 | 業界對標 | 差異 |
|---|---|---|
| 閉環四元件（感測→判斷→行動→回饋） | PDCA / OODA Loop | 更強調「感測」環節，不只是 Plan |
| Trade-off 矩陣 | Architecture Decision Record (ADR) | 即時觸發 vs 事後記錄 |
| 不變量透鏡 | Design by Contract (Meyer) | 從合約推回「什麼不能動」 |
| 層級透鏡 | 關注點分離 (Dijkstra) | 加入「誰該在哪一層做決定」 |
轉折：透鏡不夠
透鏡用了兩個月，效果很明顯——漏想的東西少了很多。但新的問題出現了。
透鏡能幫你問對問題，但問完之後呢？它沒有裁決機制。
具體的場景是這樣的：我要改一段跨模組的 code，透鏡掃完告訴我「有三個模組會受影響」「需要考慮回滾方案」「測試覆蓋率不足」。好，我都知道了。然後呢？是要硬上、還是先補測試、還是根本不該改？
Checklist 告訴你「有風險」，但 GO 還是 KILL，它不管。
這個領悟很關鍵：checklist 是必要條件，不是充分條件。 你需要一個閘門——一個能根據掃描結果做出明確裁決的機制。
Phase 3 — 框架：三態裁決
六月底，我做了一個叫 EFG（Execution Feasibility Gate）的東西。核心概念很簡單：每個決策點不是只有「做」或「不做」，而是三個狀態——GO / DEFER / KILL。
- GO：條件都滿足，直接開工
- DEFER：條件不完整但不致命，先補再來
- KILL：根本不該做，或現在做代價太高
結構是四步：靜態閘門（前置條件檢查）→ dry-run（小範圍試跑）→ 三態裁決 → 閉迴路收尾（做完驗證結果）。
EFG 誕生之後，七月的前兩週發生了一個我沒預期到的事：領域專用框架像長出來一樣，兩週內冒出了 12 個。
因為 EFG 提供了一個通用的裁決骨架，每個特定領域只需要填入自己的閘門條件和判斷標準就行。逆向分析有 RE 框架，修補判定有 CP 框架，程式碼品質有 ACQF 框架，資安弱掃有 SecScan 框架——每一個都是三態裁決，但各自的 GO/DEFER/KILL 條件完全不同。
整段演化用時間線畫出來：
這些框架的設計也不是從天上掉下來的。它們有清楚的業界血統：
| 框架概念 | 業界對標 | 核心思路 |
|---|---|---|
| 三態裁決 GO/DEFER/KILL | OPA allow / warn / deny | 不是二元的，中間態最重要 |
| 信任階梯（品質分級） | SRE Error Budget (Google) | 信任要量化，不是感覺 |
| 外科手術式修改 | Karpathy LLM pitfalls + Fowler refactoring | 只動該動的，不順手改隔壁 |
| Deep Modules 反向檢查 | Ousterhout Philosophy of Software Design | 拆完介面比原本更窄才算成功 |
| 遙測回報（FTP） | OpenTelemetry 精神 | fail 才回報，pass 靜默不打擾 |
其中遙測回報（Framework Telemetry Protocol）值得多說一句。12 個框架同時運作，如果每個框架每次判定都跳出來告訴你「我檢查過了，沒問題」，你會被訊息淹死。所以規則很簡單：pass 靜默，fail 才回報。 這跟 SRE 的 alerting 哲學一樣——你不需要知道一切正常，你只需要知道哪裡出了問題。
活的系統 vs 死的文件
寫到這裡，有人可能會問：這跟在 Notion 裡寫一份 SOP 有什麼差別？
差別在於：這些框架不是文件，是行為。
實作上，我用 Hook 機制讓 AI 偵測對話中的語意線索。當你說「改這段」，Claude Code 會自動載入修補判定框架（CP）；當你說「可行嗎」，會載入執行可行性閘門（EFG）；當你說「畫個圖表」，會載入視覺化框架（Dataviz）。
你不需要記得有哪些框架，也不需要手動呼叫。AI 聽到關鍵語意就會問你：「要不要跑一下這個框架？」你說好，它就照著框架的結構做掃描和裁決。
這跟業界方法論的根本差異在最後一哩路。PDCA、FMEA、5 Whys，這些方法論本身沒問題，問題是落地方式。它們被寫成培訓教材、被做成海報貼在牆上、被放進 wiki 裡，然後——沒有人在忙的時候會去翻。
方法論的最後一哩路不是寫下來，是讓它自己跑起來。
核仁
這 12 套框架沒有一個是我坐下來「設計」出來的。每一個都是從反覆踩坑裡長出來的——先有 LESSON，再有規則，最後才有框架。
業界方法論是骨架，你自己的 LESSON 是肉。骨架可以借，肉不能借。
如果你也在用 AI 做開發，不需要一次建 12 個框架。從你最常問自己的 3 個問題開始。把它們寫下來，放進你跟 AI 的工作流裡，讓 AI 在你忘記的時候替你問出來。
那 3 個問題就是你的第一組透鏡。