我的知識庫

AI 編碼工程閉環：從意圖到沉澱

閱讀時間約 8 分鐘

八個方法論支柱（方法論支柱：可操作的工程紀律）串在一起，形成一條完整的 AI 輔助工程閉環。這條流程的設計目標不是「讓 AI 更快生成程式碼」，而是「讓 AI 生成的程式碼能可靠地進入 production 並且可以長期維護」。

完整閉環

┌─────────────────────────────────────────────────────────────────────┐
│                  AI 編碼工程閉環                                     │
│                                                                     │
│  ① 意圖/Spec       ② 生成         ③ 驗證         ④ 審查          │
│  ─────────────     ─────────────  ─────────────   ─────────────    │
│  Problem Framing → AI generates → TDD red/green → Code Review      │
│  + Spec-Driven     (per task,     + run tests    + Doubt-Driven     │
│  + Planning        small scope)   + check spec   (non-obvious       │
│  + Task Breakdown                 acceptance     decisions)          │
│                                   criteria                          │
│       ↓                 ↓               ↓               ↓          │
│  ⑤ 整合            ⑥ 沉澱                                          │
│  ─────────────     ─────────────                                    │
│  Merge to main  →  ADR + docs   ←──── 更新認知、回饋下一輪 ──────┘  │
│  + Observability   update                                           │
│  + Evals           + Spec update                                    │
└─────────────────────────────────────────────────────────────────────┘

第一節點：意圖/Spec

工作：把模糊的需求轉化成可執行的規格。

這個節點的輸出決定後面所有節點的品質。一個模糊的 spec 讓 AI 在生成時填補假設（見 AI 生成程式碼的失敗模式——隱性假設失敗模式），而你不會知道它填補了什麼。

  • Problem Framing：確認「我們在解決什麼問題」，用 5 Whys / HMW 萃取問題陳述句
  • Spec：六大核心（目標、指令、結構、風格、測試策略、邊界）
  • Planning：把 spec 拆成垂直切片的任務清單，每個任務有明確驗收標準
  • 閘門：Spec 必須有人工審核確認，才能進入下一節點

输入：模糊需求。輸出：任務清單（每個任務：驗收標準、範疇限制、依賴順序）。

第二節點：生成

工作：AI 根據一個 task（非整個 spec）生成程式碼。

關鍵原則：每次讓 AI 處理的範疇必須可審查。「一個任務，一個 AI 生成，一個 review」是節奏，不是「一個功能，一次全生成，最後 review」。

為什麼要小範疇？

  • 小範疇的 review 成本低，大範疇的 review 成本高（而且人往往因為太大而省略真正的審查）
  • 小範疇的 AI 生成物，脈絡清楚，錯誤率相對低
  • 發現問題時，回頭成本低

輸入：一個 task（含驗收標準）。輸出：一個可驗證的 diff。

第三節點：驗證

工作：確認 AI 生成物符合 spec 的驗收標準。

  • TDD 紅燈→綠燈：先寫失敗測試（確認 spec 驗收標準化成了機器可執行形式），讓 AI 生成讓測試通過的程式碼
  • 執行 test suite：確認沒有讓既有測試失敗（regression）
  • 對照 spec：手動確認 AI 生成物是否符合 spec 的 Boundaries（特別是「Never do」清單）

驗證的目標是把「看起來對」轉換成「機器確認對」。自動化越多，越能在高速生成時保持品質。

輸入：AI 生成物 + spec 驗收標準。輸出：測試結果報告（通過或不通過，不通過則回到生成節點）。

第四節點：審查

工作：有領域知識的人審查 diff。

這個節點做自動化無法做的事：識別似是而非的正確性、隱性假設、架構不一致、安全隱患。

  • Code Review：五個維度（正確性、可讀性、架構、安全性、效能）
  • Doubt-Driven：對任何非顯然的決策，主動生成對抗性審查
  • 閘門：不通過 review，不進入整合節點

最容易被省略的節點，也是最重要的節點。「AI 很快生成、我也快速過一下」——這是在系統性跳過最值錢的那部分工程判斷。

輸入：驗證通過的 diff。輸出：核准合併（或退回修改）。

第五節點：整合

工作：把通過審查的改動整合進主線，並設立可觀測性。

  • Merge：通過 CI/CD pipeline
  • Observability：確認這個改動在 production 中的行為可以被觀測（logs、metrics、traces）
  • Evals（AI 功能）：如果這個改動影響 AI 功能的 prompt 或行為，更新 eval 測試集

沒有可觀測性的整合是盲目的整合——你不知道上線之後是否正確工作。

第六節點：沉澱

工作：把這個閉環獲得的知識固化，讓下一個閉環更好。

  • ADR：任何重要的架構決策，寫成 Architecture Decision Record（情境、決策、替代方案、後果）
  • Spec 更新：如果實作過程中發現 spec 有需要修正的地方，回去更新
  • CLAUDE.md / 工程慣例：如果發現了一個值得固化的模式，寫進 project 的工程慣例文件

沉澱節點的作用是讓每個閉環結束時，下一個閉環的起點比這個高一點。沒有沉澱，每次都從同樣的基準點開始；有了沉澱，知識積累，閉環品質逐漸提升。

閉環的節奏

一個健康的 AI 輔助開發節奏，不是「把所有工作一次全交給 AI 然後等結果」，而是：

Task → [生成] → [驗證] → [審查] → Merge
  ↓
Task → [生成] → [驗證] → [審查] → Merge
  ↓
...（每個 task 完成前，人工確認通過 review）
  ↓
Sprint 結束 → [沉澱]（ADR、文件、慣例更新）

這個節奏比「一次全交給 AI 再收成」更慢，但產出的程式碼是可審查的、可維護的、有測試覆蓋的——也就是說，它是真正的工程交付，不只是「能跑的程式碼」。

與其他專欄的關係

延伸

關係圖譜

反向連結