經過兩年的AI輔助編碼，我實現了真正提升品質的那項工作的自動化：AI結對程式設計。

經過近兩年的AI輔助開發——從ChatGPT 3.5到Claude Code——我總是遇到同一個問題：每個模型都會犯一些它自己無法發現的錯誤。受結對程式設計和Ralph循環的啟發，我建構了一個雙智能體工作流程，其中一個智能體負責編寫，另一個負責審核。上週，一個完全由這兩個智能體編寫的PR在經過三輪維護者反饋後，被合併到了一個擁有1.5萬顆星的開源Electron專案中。我並不編寫TypeScript程式碼。

我不斷發現的問題

我從事人工智慧輔助程式已經快兩年了。最初使用 ChatGPT 3.5 產生程式碼片段，後來又嘗試了 Claude、Cursor、TRAE，最終愛上了 Claude Code。

從一開始，我就注意到每個模型和每個代理人都有其自身特有的問題。不是隨機的錯誤，而是持續存在的故障模式：

當上下文過長時，Claude Code 會省略錯誤處理。它的架構設計非常出色，但在後續的防禦性程式碼編寫上卻顯得粗糙。

Codex 的抽象設計過於複雜，但卻能捕捉到 Claude 忽略的邊緣情況。

Gemini在處理複雜的多檔案變更時會遇到困難。

遊標存在上下文依賴性問題——在小範圍內運作良好，但在不同檔案之間會變得混亂。

嚴重程度不一，但模式相同：單一代理無法可靠地發現自身的錯誤。它既編寫程式碼，又判斷程式碼的好壞——就像給自己批改考卷一樣。

每個開發者都知道這個問題有個名字，它叫做「我們為什麼要進行程式碼審查」。

結對編程，但與人工智慧合作

結對程式設計由 Kent Beck 於 20 世紀 90 年代末期正式提出，是極限編程 (XP) 的一部分——也是敏捷運動中最具影響力的實踐之一。其核心概念很簡單：兩名開發人員共用一台工作站，一人負責引導，一人負責協調。協調者即時發現錯誤，質疑設計決策，並確保專案始終處於全局之中。研究始終表明，儘管這種模式看似「浪費」了一半的開發人員，但它卻能減少缺陷，並帶來更好的設計。

同樣的原理也適用於人工智慧代理。如果一個代理程式編寫程式碼，另一個代理程式進行監視，就能發現更多漏洞。

所以我開始手動操作。很久以前我用Claude（聊天版，Claude Code出現之前的版本）的時候，我會把Claude的輸出貼到ChatGPT裡，讓ChatGPT審核，然後再把回饋結果帶回來。雖然很原始，但比單獨依賴其中任何一個都有效。

Claude Code 和 Codex CLI 的出現，讓工作流程變得更規範。 Claude Code 編寫程式碼，我將差異複製到 Codex，Codex 進行程式碼審查並標記問題，我將回饋帶回 Claude Code。如此反覆。

這種人工跨部門協調的方式確實有效，但速度慢、重複性高，而且非常耗費精力。最糟糕的是：疲憊的時候很容易跳過這一步。你會告訴自己「這個改動看起來沒問題，我可以跳過審核步驟」——而這往往就是讓你吃虧的改變。

循環自動化

後來我發現了拉爾夫循環（Geoffrey Huntley 提出）——將編碼代理程式封裝在外部循環中，使其不斷迭代。這個想法非常強大，它促使我實現了雙代理工作流程的自動化。

但 Ralph Loop 團隊也坦誠地指出了它的一些限制。它非常適合有明確完成標準的全新專案。但對於遺留程式碼庫、複雜的重構或需要沿途設定檢查點的多步驟任務來說，它就顯得力不從心了。

這與我的經驗相符。我並非從零開始建立新專案，而是對一個現有的大型 Electron 應用進行分支和深度修改。我需要一個能夠處理模糊性、維護者回饋以及逐步達成共識的工具。

所以我建構了一個結構化的循環：一位代理人（Claude Code）負責編寫，另一位代理人（Codex）負責審核，他們輪流進行，只有雙方都同意才能繼續前進。我身為技術負責人，負責統籌全局——確定專案範圍、制定架構方案，並在出現分歧時做出最終決定。

效率立刻提升。這並非因為員工變得更聰明，而是因為審核流程變成了自動化，不再需要我凌晨兩點的意志力來維持。

真正的考驗：我的第一個開源 PR

我之前一直用這套工作流程將 AionUI（一個大約 1.5 萬粉絲的 Electron + React 應用）fork 成公司內部的 AI 助理。總共提交了 30 次，沒有編寫任何手動程式碼。包括完整的品牌重塑、核心引擎重寫、資料庫遷移、CI/CD 重建——所有這些都透過雙代理循環完成。

在進行這項工作期間，客服人員發現了一個真正的上游漏洞：使用 ACP 客服終止對話後，會有一些孤立的 CLI 進程殘留。我已經向 AionUI 提交了一個 PR。

維修人員審核後提出了 3 個問題：

雙重 super.kill()競態條件－需要冪等保護

吞掉的錯誤－.catch(() => {}) 應該記錄警告

treeKill 有差異－PR 描述與上游實際實作不符。

我把維護者的回饋交給了兩個代理，讓他們開始工作。作者代理分析了問題，編寫了修復程序，並執行了測試（133/133 個測試全部通過）。審核代理審核了差異，驗證了正確性，並確認了類型定義清晰。他們來回溝通了幾輪。我在一旁觀察，但沒有寫程式碼。

已合併。 “LGTM——所有三項評審回饋意見均已妥善處理。”

這是我第一次提交 PR 並合併到別人的專案中。我是一名擁有 30 年經驗的軟體工程師，但過去 25 年我一直從事產品和業務方面的工作，而不是寫程式碼。我不會寫 TypeScript。人工智慧工具讓我重新回到了開發領域，而這個雙代理循環讓我能夠為一個真實的專案貢獻真正的修復。

獨立收斂

在我發布這篇文章後，另一位開發者（Hwee-Boon Yar，獨立開發者，同樣擁有30年經驗）分享了一種類似的方法——一種會向第二個審核員付費的技能，循環往復直到審核員沒有需要標記的內容為止。這種方法比我的更輕量級，可以在一次會話中完成。雖然權衡取捨不同，但核心理念是一樣的。

多人獨立得出此結論：僅靠一個人是不夠的。你需要第二雙眼睛。

限制

這並非萬全之策。以下幾點行不通：

代理程式崩潰後沒有自動恢復功能。當代理程式在會話期間崩潰時，循環會停止。您需要手動重新啟動代理程式。目前尚無自我修復功能。

浪費了好幾輪時間。有時候，修復程序會像打乒乓球一樣來回切換——一次修復引入了新問題，審查發現了問題，下一次修復又引入了另一個問題。這時，你必須介入並重新調整修復範圍。

上下文視窗——但略有不同。長時間會話會導致品質下降，當智能體壓縮其上下文時，資訊就會遺失。但雙智能體架構恰好解決了這個問題：當一個智能體的上下文被壓縮並失去細節時，另一個智能體仍然會記住這些資訊。它們不共享同一個上下文窗口，因此不會同時丟失相同的資訊。這是一個意想不到的架構優勢。我正在考慮在未來的版本中建立跨智慧體的共享記憶體管理機制——這樣它們就可以明確地共享彼此遺忘的資訊。

兩個人工智慧系統可以欣然認同糟糕的設計。如果沒有人類的領域判斷，這只不過是兩個系統互相認可而已。人類仲裁者的作用不可或缺。

這並非自主開發，而是結構化的AI輔助開發。二者的差異至關重要。