在 AI 輔助程式設計（AI Coding）普及前，工程師的產出差異常被歸因於打字速度、語法熟練度或搜尋 API 的速度。

但當強大的程式碼模型變得容易取得，開發者能快速產出大量語法正確的程式碼時，真正的差異轉向：誰能決定要做哪些工作、理解 Agent 做出的設計，並對最後結果負責。

當人把「決定哪些子任務要做」也交給 Agent 時，局部可行的輸出可能累積成缺少關鍵情境的系統；這正是本文接下來要拆解的責任落點。

@jowaywang 把這種工作方式稱為「盡職程式設計（Due Diligent Programming）」。原文的重點不是魔法提示詞：AI 可以完成許多子任務，但未必能決定為了「把事做成」究竟需要哪些子任務，以及哪些取捨不能漏掉。作者也主張用架構圖或面向產品經理的文件理解 Agent 的設計，而非只把生成結果當作黑盒子接受。

本文的工程化拆解：四個責任節點

為什麼調用同一個模型，產出會有天壤之別？關鍵在於工作流程中四個不可替代的責任節點：

盡職工程實踐鏈 (Due Diligent Pipeline)

從精準需求到生產級交付的四個專業責任卡點

  1. 01Scope & Invariants

    需求契約化

    拆解任務前置與後置條件，明確標註 Non-goals，防止 Agent 自作主張擴展功能邊界。

    Gate不可變條件 (Invariants) 鎖定
  2. 02JIT Context

    上下文治理

    提供高訊號、低噪音的專案知識，包含最小重現測試、明確型別與介面合約。

    Gate去除冗餘與無效日誌
  3. 03Deep Modules

    架構接縫把關

    評估 AI 產出架構的演進成本，優先選擇深模組隱藏複雜度，維持單向依賴。

    Gate防止淺模組與膠水代碼
  4. 04Independent Gate

    機械式驗收

    拒絕盲目 LGTM；透過獨立 Reviewer、靜態分析與自動化測試驗證邊界與併發安全。

    GateCI 測試與覆蓋率硬指標
維度依賴型開發者（草率模式）盡職工程師（Due Diligent 模式）
需求輸入丟一句模糊需求（如「幫我做一個金流處理」）拆解 Pre/Post-conditions，明確標註 Non-goals 與不可破壞條件
上下文管理直接貼入 500 行錯誤日誌或整個龐大專案目錄提取最小可重現範例（MRE）、精準型別定義與關鍵介面
架構審視只要程式能跑就按 Accept，不管抽象是否洩漏檢視模組深度（Deep vs. Shallow Modules），確保接縫清晰
審查與驗收讓同一個 AI 自我保證「程式碼完全正確」由獨立 Reviewer 與自動化測試套件（CI）進行機械式硬驗收

1. 需求契約化：防止任務在執行中「悄悄改義」

AI Agent 最常見的失敗不是「語法錯誤」，而是「語意漂移」——在實作過程中擅自調整了邊界條件，最後解決了一個看似相關但不是你真正需要的子問題。

盡職工程師在呼叫 AI 前，會先建立最小任務契約：

  • 明確的不可變條件（Invariants）：例如「在任何併發情境下，帳戶餘額不得為負數」。
  • 清楚的非目標（Non-goals）：明確告知「本次變更不包含快取機制重構，請勿更動現有 Redis 模組」。
  • 具體驗收證據：指定需通過的測試清單或 API 響應結構。

2. 架構接縫與「深模組」把關

AI 天生傾向「局部最優解」。當你要求它增加功能時，它往往會選擇最快速、最直覺的侵入式修改：在既有函式加兩個 if-else，或者在全域狀態多塞一個變數。

若缺乏架構自律，系統很快會退化為充滿膠水代碼（Glue Code）的「淺模組」集合。

盡職工程師懂得評估 AI 提出的設計：

  • 這個模組的表面積是否過大？（Interface 簡單，內部邏輯深厚才是好設計）
  • 這個改動是否打破了既有的單向依賴？
  • 未來的維護者（包括 AI 自己）是否容易理解這個接縫？

3. 獨立審查：拒絕「盲目 LGTM」

當 AI 寫出的代碼看似優雅、註解完整時，人類大腦很容易產生「認知惰性」，順手按下合併。然而，AI 極度容易在以下領域產生致命盲點：

  • 併發與競態條件（Race Conditions）；
  • 邊界溢位與時區／精度截斷；
  • 錯誤復原路徑中的資源洩漏；
  • 安全漏洞（如授權繞過或不安全的序列化）。

盡職工程師堅持**「程式碼作者與審查者分離」**原則：不讓生成程式碼的模型自行打分數，而是透過靜態分析、模糊測試（Fuzz Testing）與人工批判性走查，驗證關鍵路徑與邊界條件。

結語：AI 時代的工程師護城河

AI 沒有消除軟體工程的基本功，而是將其價值推到了最前線。

當編寫語法（How）變得極度廉價，定義問題（What）、判斷架構合理性（Why）與確保系統可靠度（Verification）就成了工程師最核心的護城河。「盡職」不再只是工作態度，而是決定個人產出能否在 AI 時代形成十倍複利競爭力的技術分水嶺。