我的知識庫

方法論支柱：可操作的工程紀律

閱讀時間約 9 分鐘

把 AI 生成程式碼的品質問題說清楚很容易；把解法系統化成可操作的工程紀律才有價值。以下八個支柱，不是理論原則，而是各自有明確時機、輸入輸出、和判斷準則的實踐——把它們串接起來，就是一套 AI 輔助工程的完整閉環（見 AI 編碼工程閉環：從意圖到沉澱）。

支柱一：Problem Framing（問題框定）

時機：一切開始之前。輸入：模糊的需求或想法。輸出：一個值得解的問題陳述句。

在 AI 時代，Problem Framing 的重要性更高，不更低。原因：AI 執行的速度比人快得多，一旦方向錯了，它把錯誤放大的速度也更快。花 30 分鐘確認「我們在解決什麼問題」，遠比 AI 快速生成了一個錯誤方向的完整實作，再花幾天砍掉重練，成本低得多。

核心工具：5 Whys（根因分析）、HMW（How Might We，重構問題陳述）、JTBD（Jobs-to-be-Done，確認真正的用戶需求）。

詳見 Problem Framing：定義正確問題。

支柱二：Spec-Driven Development（規格先行）

時機：Problem Framing 之後、任何實作之前。輸入：確認過的問題陳述和意圖。輸出：一份結構化的 spec 文件。

Spec 的作用是雙重的：它是人類團隊的共識文件，也是 AI agent 的執行 prompt。一份好的 spec 讓 AI 知道「做什麼、為什麼、成功是什麼樣子」，同時讓人知道「假設是什麼、邊界在哪、不做什麼」。

Thoughtworks（2025 Technology Radar）把 Spec-Driven Development 列為 AI 輔助工程的關鍵新實踐；Microsoft 稱之為 AI-native engineering 的規格先行方法。

Spec 的六大核心：Objective（可測試的驗收標準）、Commands（可執行指令）、Project Structure（結構）、Code Style（風格）、Testing Strategy（測試策略）、Boundaries（邊界清單）。

詳見 Spec-Driven Development：規格先行。

支柱三：Planning & Incremental Implementation（計畫與小步交付）

時機：Spec 完成並審核後，實作開始前。輸入：審核過的 spec。輸出：有依賴順序、有驗收標準的任務清單。

把 spec 拆成垂直切片（每個切片完成後系統是可運作的），每個任務改動不超過五個檔案。這個原則在 AI 輔助開發裡特別重要：小步意味著每個 AI 生成物的範疇可控，review 成本低，出問題時回頭容易。

「一次 AI 把整個功能全生成出來」看起來快，但一旦有問題（而根據 AI 生成程式碼的失敗模式，問題是大概率事件），整體 debug 的成本遠超過分步驟的 review 成本。

支柱四：Test-Driven Development（測試先行）

時機：每個任務開始實作時。輸入：任務的驗收標準。輸出：一個先寫失敗測試（red）、然後讓 AI 生成讓它通過（green）的流程。

TDD 在 AI 輔助編碼裡的作用特別強：把驗收標準化為可執行的機器檢查，讓 AI 生成的程式碼必須通過一個定義清楚的考關。

一個有良好測試覆蓋的 codebase，是 AI agent 最好的工作環境；一個沒有測試的 codebase，是 AI agent 的地雷場——它無法知道修改一個地方會不會在另一個地方製造問題。

TDD 也解決了 似是而非的正確性 這個失敗模式：「看起來對」的程式碼必須通過具體的測試才能被接受。

支柱五：Code Review（代碼審查）

時機：每個 AI 生成物完成後、整合進 main branch 前。輸入：AI 生成的程式碼 diff。輸出：核准（或要求修改）。

AI 生成的程式碼的 code review，比人寫的 code 的 review 更不能省略。原因：AI 的靜默失敗模式（隱性假設、似是而非的正確性、幻覺）需要有領域知識的人主動檢查，不能只靠測試。

Code review 的五個維度：正確性（是否做到 spec 說的事）、可讀性（能否被下一個人理解）、架構（是否符合整個系統的設計脈絡）、安全性（是否引入漏洞）、效能（是否有明顯的反模式）。

不要因為「是 AI 寫的速度快，所以 review 也要快」。生成速度和審查嚴謹度是不相關的兩件事。

支柱六：Doubt-Driven Development（對抗式審查）

時機：任何「非顯然」的決策點；任何「我確定這沒問題」的時刻。輸入：一個決策或主張。輸出：這個決策被主動試圖推翻後，仍然成立的確信。

Doubt-Driven 不是 code review 的重複。Code review 是對已完成 artifact 的評估；Doubt-Driven 是在決策當下，主動生成一個偏向「反對這個決策」的審查視角。

特別適用場景：

  • 任何影響資料結構的決策（落 production 後很難回頭）
  • 任何跨模組邊界的決策
  • 任何 AI 提出的「我確定這樣做更好」的建議

支柱七：Documentation & ADR（文件與架構決策紀錄）

時機：任何重要架構決策時；任何「這裡為什麼這樣設計」的時刻。輸出：ADR（Architecture Decision Record）。

ADR 格式：情境（為什麼有這個決策的需要）→ 決策（我們決定做什麼）→ 考慮過的替代方案 → 後果（這個決策的 trade-off）。

在 AI 輔助開發裡，ADR 特別重要：AI 在每個新 session 都從零開始，它沒有上一次決策的記憶。把決策的理由固化在 ADR 裡，讓 AI（和人）在未來的 session 裡能理解「我們為什麼這樣設計」，而不是重蹈已被否決的路。

支柱八：Evals & Observability（評估與可觀測性）

時機：系統上線後持續進行；AI 功能的 prompt 或模型有任何變動時。輸入：已上線系統的輸出。輸出：量測到的品質數據。

在 Agentic 系統裡，evals 是「生產環境是否仍然正確工作」的持續確認機制。prompt 的變動、模型的更新、資料的漂移——任何一個都可能讓一個之前「能跑」的系統悄悄變差，而你不會立刻知道。

工具：PromptFoo（CI-native，YAML 定義 test case，整合 GitHub Actions）、Braintrust（端到端 eval + production monitoring + human review）、LLM-as-Judge（用另一個模型評估目標模型的輸出品質）。

詳見 幻覺、Evals 與品質保證。

八個支柱的時間軸

─────────────────────────────────────────────────────────────── 時間 ▶

[Problem     [Spec-Driven] [Planning &   [TDD]   [Code   [Evals &
 Framing]                  Incremental]           Review]  Obs.]
                           Implementation                        ↑
    │              │              │           │      │       持續
  意圖            規格          拆解         驗     審
  確認            固化          執行        收     查
                                             標
    ←── 每個非顯然決策：Doubt-Driven Development ──────────────────→
    ←── 每個架構決策：ADR ───────────────────────────────────────→

沒有一個支柱能替代另一個。它們各有時機，缺任何一個都會讓整個流程產生對應的盲點。

延伸

反向連結