與其追求更強的模型，不如設計更好的「人類干預點」：我如何打造可信任的 AI 編碼自動化

Coding Agent 的可靠性瓶頸不在模型強度，而在人機介面的設計：把人類確認收斂成少數明確的「意圖承認點」，其餘環節用機械驗證取代目視比對。實務上這能讓系統每週 312 件任務自動篩選、270 件自動處理，只有 10 件高風險變更需要我手動核可，整體仍可長期穩定運行。

為何單純升級模型無法解決信任問題？

在 AI Agent 的實踐中，我們很快會遇到一個天花板：即使是目前最強大的模型，如 OpenAI 的 GPT-4o 或 Anthropic 的 Claude 3.5 Sonnet，在沒有明確框架下執行任務時，其行為仍然存在不可預測性。這種「黑盒子」特性是信任的最大敵人。當一個 Agent 嘗試修改程式碼、更新設定檔或執行指令時，我們很難百分之百確定它的每一步操作都符合我們的隱性期望。

追求「更聰明的模型」試圖用模型的推理能力來彌補這種不確定性，但這是一條充滿挑戰的路。模型的「智慧」往往體現在處理複雜、開放式問題的能力，但在高度結構化、要求零失誤的自動化工作流中，我們需要的不是創意，而是絕對的可靠性。模型的行為漂移（behavior drift）與幻覺（hallucination）問題，在需要精確執行的場景下，可能會導致災難性後果。研究也指出，大型語言模型的評估本身就是一個複雜的挑戰，單純的分數提升不等於在特定任務上的可靠性提升（可參考 Challenges in Evaluating Large Language Models）。

與其寄望一個永遠不會犯錯的 AI，不如設計一個讓 AI「想犯錯也很難」的系統。

這就帶出了核心觀點：與其不斷更換模型來祈禱更好的結果，不如將心力投入在設計一個穩固的「人機協作框架」。這個框架的核心，我稱之為「意圖承認層」（Intention Confirmation Layer）。

如何設計有效的「意圖承認層」？

「意圖承認層」的設計理念很簡單：並非所有 AI 的操作都具有相同的風險。我們需要建立一套機制，根據操作的潛在影響，決定是直接放行，還是暫停並請求人類批准。這不是要審查 AI 的每一步思考，而是要驗證其最終的「行動意圖」。

如何區分 AI 操作的風險等級？

在我的實踐中，我將 Agent 的所有可能操作分為四個明確的類別，並設定不同的處理流程：

• 第一類：唯讀操作 (Read-only)
  例如讀取檔案、抓取網頁內容、分析程式碼結構。這類操作風險極低，應完全自動化，不需任何干預。
• 第二類：冪等且低風險的寫入 (Idempotent & Low-risk Writes)
  例如程式碼格式化、產生文件、更新無關緊要的註解。這些操作即使重複執行，結果也相同，且不會破壞系統核心功能。這類操作也可以高度自動化。（關於「冪等性」的定義，可參考 AWS 官方文件。）
• 第三類：有狀態或高風險的寫入 (Stateful or High-risk Writes)
  這是我設定的關鍵「人類干預點」。例如修改設定檔、變更核心業務邏輯、升級重要的套件依賴。我的系統會將這類變更打包，生成一份清晰的變更摘要（diff），然後暫停執行，等待我一個點擊批准。
• 第四類：破壞性操作 (Destructive Actions)
  例如刪除檔案、清空資料庫。這類操作在我的系統中預設是完全禁止的，除非有極其特殊的授權流程。

這種精確的分類法，成功將模糊的「信任」問題，轉化為具體的工程挑戰。它讓我們能有策略地分配人類的注意力，只在真正關鍵的時刻介入。

以我過去三個月的經驗為例，我使用的 Claude Code Agent 就是在這個框架下運作。每週約 312 件由 RSS feed 觸發的內容更新任務，其中約 270 件屬於第一、二類，被系統自動處理。剩下的 42 件中，有 32 件被系統的自動化測試或 linter 否決，最終只有 10 件需要我手動介入，進行「意圖承認」。整個過程，我需要做的只是一次性的審查與批准，而不是逐一檢查 312 個任務，大幅提升了工作效率與系統可靠性。

如何將人工目視轉化為機械化驗證？

一個常被忽略的環節是：人類批准之後呢？傳統的 Human-in-the-Loop (HITL) 系統設計，往往在人類點下「同意」後就結束了（可參考 A Survey on Human-in-the-Loop for Machine Learning）。然而，如何有效設計這些人機協作系統，確保其在批准後仍能可靠運作，是關鍵挑戰（可參考 卡內基美隆大學關於 Agent-Based HITL 系統設計的研究）。這種設計上的疏漏，往往留下了風險缺口：我們如何確保被批准的操作，在執行後確實達到了預期效果？

答案是將驗證過程也機械化。在我的工作流中，當我批准了那 10 件高風險變更後，系統並非直接部署上線，而是會先在一個隔離的暫存環境（staging environment）中應用變更，然後自動執行一系列預先定義好的測試，包括單元測試、整合測試與程式碼品質檢查。只有當所有自動化檢查都通過後，變更才會被合併到主分支。

這種「批准後自動驗證」的閉環設計，徹底取代了不可靠的人工目視檢查。它建立了一個信任鏈：我信任我的測試套件，而測試套件的通過證明了 AI 操作的正確性。這使得整個自動化系統不僅高效，而且極為穩固。這也符合現代軟體工程中持續整合／持續部署（CI/CD）的最佳實踐（可參考 Google Cloud 的 CI/CD 說明）。

總結來說，打造可信任的 AI 自動化系統，其核心挑戰並非來自模型本身的能力不足，而是我們如何設計人與機器的互動介面與協作框架。與其等待一個完美的、無需監督的「超級智慧」，不如從今天起，就開始設計更聰明的「人類干預點」與「機械化驗證」流程。這不僅是技術上的選擇，更是一種務實、可擴展且能立即帶來價值的系統設計哲學。

延伸閱讀

• AI コーディングエージェントの信頼性は「意図確認レイヤー」の設計で解決した (本文參考的原始實踐案例)

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