AI 寫程式的盲點：為何「看起來完成」不等於「已被驗證」？

AI 程式助手在開發流程中日益普及，但我們發現一個核心問題：它們的「完成」判斷往往基於「看起來像做完了」的表面相似性，而非實際驗證。這種「殘留課題」的產生，並非模型能力不足，而是源於其完成判定的機制缺陷，缺乏「執行紀律」。要解決這個盲點，我們必須將驗證步驟顯式化，從而確保 AI Agent 交付的成果不僅是表面的完成，更是經過驗證、真正可用的解決方案。本文將深入探討此問題的根源，並提出具體的實踐方法。

AI 為什麼會陷入「看起來像完成」的陷阱？

在使用像 Claude 這樣的 AI 進行開發時，你是否也曾遇過這種情況：你請它實作一個功能，它回傳了結構完整的程式碼，包含了函式、註解、甚至還有模組引入。然而，仔細一看，最核心的商業邏輯區塊卻是一行 // TODO: Implement the core logic here 的註解，或是在 CLAUDE.md 這類輸出檔案中被標記為「殘留課題」。

這並非偶發錯誤，而是 AI 系統設計的內在特性。Anthropic 的官方文件坦白指出：「Claude stops when the work looks done.」（當工作看起來完成時，Claude 就會停止）。這句話揭示了問題的本質：AI 的「完成」判斷，是一種基於視覺與結構模式匹配的行為。它評估的是程式碼的「外觀」是否符合已完成檔案的特徵，而非透過執行、測試或任何形式的驗證來確認功能的正確性與完整性。

換句話說，當我們給予一個模糊的指令時，AI 會盡力產出一個「看起來最像答案」的結果。如果一個包含待辦註解的程式碼骨架，在統計上比一個功能完整但結構不尋常的程式碼更「像是」人類工程師會寫出的中間產物，那麼模型就可能會選擇前者。它交付的不是一個經過驗證的解決方案，而是一個關於解決方案的、最為逼真的「素描」。

為什麼 AI 會滿足於表面的完成度？

這個問題可以從三個層次來理解：模型行為、指令設計，以及任務的請求方式。這三者共同導致了 AI Agent 容易將「看起來像完成」誤當成「已被證明完成」。

首先是模型的根本行為。大型語言模型（LLM）的核心是個「下一個詞預測器」（next-token predictor），其目標是生成統計上最可能接續的文本序列，而非達成某個具體的外部目標。它沒有真正的意圖或對「功能正確性」的理解。正如史丹佛大學的 HELM (Holistic Evaluation of Language Models) 框架所揭示的，評估一個模型的能力需要從多個面向進行，而單純的程式碼生成能力，與解決實際問題的能力之間存在巨大鴻溝。

其次是指令設計的模糊性。如果我們的提示語（prompt）只是「實作使用者登入功能」，卻沒有定義何謂「完成」。例如，是否包含密碼加密？是否有錯誤處理機制？是否需要通過特定的單元測試？在缺乏這些明確的驗收條件下，AI 只能自行猜測「完成」的定義，而最安全的猜測，就是提供一個看起來面面俱到的程式碼框架。

最後是任務請求的複雜度。當面對一個龐大而複雜的任務時，AI 如同人類一樣，會傾向於採用「化整為零」的策略。但它的做法不是真正地去拆解並依序完成，而是先產出一個高階的結構，然後將複雜的細節標記為「待辦事項」。這是一種認知卸載（cognitive offloading），也是它在單一回合互動中處理複雜性的極限。

AI Agent 的工作完成度，取決於我們定義「完成」的精確度。如果我們自己都無法將驗證條件顯式化，就不能期望一個基於模式匹配的系統能讀懂我們心中那把隱形的尺。

如何導入「執行紀律」來確保真正完成？

要解決這個問題，我們需要從根本上改變與 AI 協作的模式。重點不再只是「下指令」，而是轉移到「設計可驗證的工作流程」。這就是執行紀律的核心精神：確保每一步的產出都有明確的驗證標準，從而讓 AI Agent 真正交付可用成果。

具體來說，可以從以下三個方面著手建立這種執行紀律：

• 定義明確的驗收條件（Acceptance Criteria）：在發出指令前，先用自然語言或程式碼範例寫下「完成」的標準。這就像敏捷開發中的使用者故事一樣，例如：「撰寫一個 Python 函式，它必須接受一個 JSON 字串，驗證 'email' 欄位格式正確且 'age' 欄位大於 18，並回傳一個字典。函式必須包含三個 `pytest` 單元測試，分別涵蓋成功、email 格式錯誤和年齡不符的情境。」
• 在工作流中嵌入驗證（Embed Verification in the Workflow）：不要只要求 AI 產出程式碼，而是要求它產出一個包含「程式碼＋驗證步驟」的完整流程。例如，採用測試驅動開發（TDD）的方法，先讓 AI 寫出測試案例，再讓它寫出能通過這些測試的程式碼。這種模式強迫 AI 必須先「思考」何謂正確，才能動手「實作」。這也類似於ReAct (Reason, Act) 框架所提倡的，讓模型在行動之間進行推理與反思。
• 善用工具與外部回饋（Leverage Tools and External Feedback）：真正的完成，需要與外部世界互動來驗證。透過Tool Use 或 Function Calling 等機制，讓 AI Agent 能夠呼叫 linter、編譯器、測試框架，並根據這些工具的回饋來修正自己的程式碼。這才是閉環的、有回饋的開發。現實世界中的軟體工程問題遠比單純生成程式碼複雜，這也解釋了為何在 SWE-bench 這種模擬真實 GitHub issue 的基準測試上，即便是 Claude 3 Opus 這樣的頂尖模型，其解決率也僅在 14% 左右徘徊。這巨大的差距，正是有待執行紀律與外部驗證來彌補的。

總結來說，AI coding agent 的盲點不在於能力，而在於缺乏驗證的自覺。當我們從單純的程式碼生成器，轉而將其視為一個需要被嚴格管理的「執行者」（executor）時，我們才能真正發揮其潛力。未來的關鍵，不在於寫出更華麗的提示語，而在於設計出更嚴謹、更能自我驗證的自動化工作流程。

延伸閱讀

• Anthropic: How Claude decides to stop
• HELM: Holistic Evaluation of Language Models
• ReAct: Synergizing Reasoning and Acting in Language Models
• SWE-bench: A Real-World Benchmark for Software Engineering with AI

我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。