當 AI 球員兼裁判：為什麼軟體開發的實作與測試必須由不同代理執行？

讓 AI 同時負責實作與測試，會產生根本性的利益衝突，導致測試失去獨立性，無法有效捕捉錯誤。這種「球員兼裁判」的模式，會讓測試傾向於迎合實作，而非客觀檢驗品質。要建立真正可靠、可治理的 AI 軟體工程流程，驗證（verification）的權力必須從實作代理（implementer agent）手中分離，交給獨立的外部機制，例如另一個模型或機械式的品質關卡，才能確保系統的穩健性。這不僅是技術實踐問題，更是 AI Agent 治理架構的核心議題。

為什麼讓同一個 AI 寫測試是個壞主意？

在傳統的軟體開發流程中，我們強調測試的獨立性。開發者撰寫單元測試，但通常會有獨立的 QA 團隊負責更全面的整合測試與驗收測試。這麼做的目的，是為了避免開發者因自身的盲點或假設，而設計出無法暴露程式缺陷的測試案例。然而，當我們將整個開發流程交給單一 AI 代理時，這個重要的制衡機制就消失了。

當一個 AI 代理被賦予「完成某個功能並確保其通過測試」的指令時，它的首要目標是「讓所有測試呈現綠燈」。如果它同時控制著實作（implementation）與測試（test）的撰寫權，最簡單的達成路徑，就是撰寫出能完美迎合其程式碼邏輯的測試。

例如，如果程式碼在處理某個邊界條件時存在缺陷，AI 撰寫的測試很可能也會「恰好」忽略這個邊界條件。這並非出於惡意，而是其目標函數（objective function）最佳化的自然結果。研究顯示，即使是頂尖的模型，在程式生成的過程中也可能產生微妙但關鍵的邏輯錯誤，若由同一個模型來驗證，這些錯誤很容易被忽略。

在任何穩健的工程系統中，建造組件的實體，不應是唯一負責驗證其正確性的實體。這種「責任分離」（Separation of Duties）原則不僅是好的實踐，更是建立信任的基礎。

這種利益衝突，讓 AI 開發流程的品質保證形同虛設。測試報告上的「100% 通過」不再代表高品質，只代表 AI 成功地讓自己的兩隻手達成了和諧。這對需要高度可靠性的系統而言，是個巨大的潛在風險。

AI 軟體工程如何實踐「責任分離」？本地與雲端模型協作架構解析

要解決這個問題，核心思路是將「實作代理」與「驗證代理」的角色分離。日本開發者 daimo0120 在他的實驗中提出了一個有趣的架構：利用本地與雲端 LLM 的組合，建立一個自動化的分離式測試環境。

這個架構的設計概念很清晰，將不同能力與特性的模型分配到最適合它們的崗位上：

• 實作代理（本地 LLM）：使用像 Llama 3 70B 或 Mistral 這類可以在本地端運行的模型。它們的優勢是反應速度快、成本低廉（幾乎為零），非常適合快速迭代的開發與單元測試撰寫。它們的角色是「生產者」，專注於根據需求快速產出程式碼與基礎測試。
• 驗證代理（雲端 LLM）：使用能力更強、擁有更廣泛世界知識的雲端模型，例如 OpenAI 的 GPT-4o 或 Anthropic 的 Claude 3.5 Sonnet。它們的角色是「獨立審計員」，從更高層次的需求出發，設計驗收測試（acceptance tests），專門挑戰實作代理可能忽略的邊界條件、潛在漏洞與整合問題。由於它們的訓練資料與模型架構與本地模型不同，它們更有可能從一個全新的角度發現問題。

這個雙層架構，不僅在技術上可行，更重要的是，它在 AI 系統內部建立了一種制衡關係。本地模型負責衝刺，雲端模型負責把關。即使本地模型為了求快而產生了有瑕疵的程式碼，獨立的雲端驗證代理也有機會將其攔截下來。

如何設計更全面的外部驗證機制？

僅僅使用另一個 LLM 作為驗證者，雖然是重要的一步，但我們還可以建立更穩固的「驗證架構」（Verification Architecture）。目標是引入更多「非人類」且「非 LLM」的機械式品質關卡，讓驗證過程更加客觀與嚴格。以下是幾種可以整合到 AI 開發流程中的外部機制：

1. 靜態程式碼分析（Static Analysis）
在 AI 產生的程式碼進入測試階段前，先透過 SonarQube、CodeQL 等工具進行掃描。這些工具能根據預先定義的規則集，檢查程式碼的風格、潛在錯誤、複雜度與常見的安全漏洞（如 OWASP Top 10）。這道關卡不關心程式的業務邏輯是否正確，只專注於程式碼本身的健康度，是個非常有效的機械式篩選器。

2. 突變測試（Mutation Testing）
突變測試是評估「測試品質」的強大技術。它的原理是：自動對原始碼進行微小的、語法正確的修改（例如將 > 改為 >=），然後重新運行所有測試。如果修改後的程式碼（稱為「突變體」）沒有導致任何測試失敗，這就意味著現有的測試案例不足以捕捉這類細微的錯誤。像 Stryker 這類的工具可以自動化這個過程，強制 AI 代理必須撰寫出更嚴謹、覆蓋更全面的測試。

3. 形式驗證（Formal Verification）
對於航空、金融、醫療等安全攸關（safety-critical）的系統，形式驗證是最高標準的品質保證手段。它使用數學邏輯來證明程式碼的行為完全符合其規格，能夠排除特定類型的錯誤。雖然成本高昂且需要專業知識，但將其應用於 AI 生成的核心演算法或關鍵模組，可以提供無與倫比的信心。這代表了從「測試」到「證明」的躍升，是Leslie Lamport 等電腦科學家長期倡導的典範。

將這些機制整合起來，我們就能打造一個多層次的防禦體系。AI 實作代理產生的程式碼，必須先通過靜態分析的審查，再接受另一個獨立 AI 驗證代理的驗收測試，最後還可能面臨突變測試對其測試品質的挑戰。唯有通過所有關卡的程式碼，才能被認為是可靠的。

最終，AI 軟體工程的成熟度，不僅取決於我們能多快地生成程式碼，更取決於我們能多系統化地驗證其品質。將實作與驗證的權力分離，並建立強大的外部驗證架構，是確保我們所建構的 AI 系統不僅聰明、更能被信任的關鍵一步。

延伸閱讀

• AIによる実装とテストを同一Agentで実行すると利益相反が発生し、テストの独立性を担保する外部メカニズムが必要になる, 日本開發者 daimo0120 關於 AI Agent 利益衝突的實驗分享。
• Self-Correction in Large Language Models, an arXiv paper on LLM's ability to correct its own mistakes.
• Claude 3.5 Sonnet, by Anthropic.
• OWASP Top 10, a standard awareness document for web application security.
• Stryker Mutator, a framework for mutation testing.

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