將計算力投入正確性

對於完全擁抱AI代理的開發者而言，生產力已不再是瓶頸。代理生成代碼的速度遠超人類，且往往質量更優。真正的瓶頸在於正確性：代碼是否真正解決問題？架構能否承載不斷增長的功能集？實現是否編碼了正確的先決條件？實踐上的轉變是，應將相當一部分代理計算力投入驗證（測試、審查、範圍檢查），而非生成更多代碼。

一年前，推崇代理編程的理由是吞吐量：代理讓你用更少的時間交付更多代碼。這一點如今已毫無爭議。藉助當前一代模型（如Claude Code、Codex等）構建的代理框架，一名開發者監督一個代理，其產出便能媲美一支小型手寫團隊。對於完全融入這種工作流程的人而言，問題不再是“如何產出更多？”，而是“如何確保產出是正確的？”。

正確性可能在三個層面失敗。首先是產品層：代碼是否符合用户需求？這仍需要人類判斷。實際用户必須審視運行中的產品，確認其是否真正滿足需求。沒有代理計算能替代這一點。你能做的最高效工作是讓這位人類的工作變得輕鬆：快速部署到真實環境，使用真實數據，以便用户能直接交互並反饋。

其次是架構層：代碼結構是否合理？這是最難的一層，也是當前代理最薄弱的環節。經驗豐富的軟件工程師的許多工作是架構判斷：如何組織代碼以適應未來特性，而不預知具體需求；知道哪些特性不應實現；識別特性集何時超出原始架構的容量，需要在添加更多代碼前重構代碼庫。代理在這些方面均不擅長——它們會愉快地按你的要求添加功能，卻往往放在最不合適的位置，採用使後續三個功能更難實現的抽象。它們會實現你所要求的可配置性，而不會質疑你是否應該需要它。它們會不斷擴展已超出假設的結構，因為每個單獨的差異在孤立審視時仍然合理。這一層的補救措施是人類主導的架構審查，並由一個明確負責對照事實源文檔檢查每個差異的代理輔助。

第三是實現層：代碼是否如其聲稱般運行？這種失敗模式最容易被忽略：代碼看起來正確，測試通過，但實際上卻是錯誤的。其編碼的前提稍有偏差；中間存在測試恰好未覆蓋的變通方案；一個聲稱“處理邊緣情況”的輔助函數實際上吞沒了應傳播的錯誤。這是編寫代理自身無法察覺的失敗模式，因為它繼承了自己早期推理中的前提。它需要另一雙眼睛（審查代理、新上下文子代理或完全不同的代理類型）來讀取差異，而不帶編寫者的假設。

補救措施説起來簡單，但更難堅持：將相當一部分代理預算用於驗證。運行編碼代理團隊的目的不再是更快地生成更多代碼，而是提高代碼正確的概率。在實踐中，驗證包括多項內容：測試（包括昂貴的端到端測試、Playwright瀏覽器測試、代表性數據運行）；持續代碼審查，而不僅限於PR階段——在上下文中包含架構文檔和任務列表的審查代理會讀取每個差異；以及對照事實源文檔的範圍重檢——差異是否偏離了原始要求？代理是否悄悄擴大了範圍？是否實現了事實源明確禁止的內容？

錯誤在於將驗證視為對生產力的税收。事實並非如此。一個經過驗證的編碼代理的產出，其價值遠超兩個未經驗證的編碼代理的產出之和。

有幾種投入驗證計算力的模式，它們並不互斥：同一代理內的代碼審查子代理（Claude Code和Codex均內置了強大的代碼審查子代理，編寫者可在任務中途生成它，獲得本地反饋並應用，捕獲bug、缺失邊緣情況和風格違規）；用不同代理類型審查編寫者（讓Claude Code生成Codex進行審查，反之亦然，不同訓練和先驗能捕獲略有不同的問題）；以及持久化專業審查代理——每個重要任務配備兩個代理，一個程序員一個審查員，它們持久存在、共享任務列表，並在每個TDD週期後交流。作者認為最後一種模式最有用，是上下文最豐富、成本最高但最具價值的驗證計算形式。

轉變在於：早期推崇代理編程的理由是每小時注意力能產生更多代碼——這依然正確且有用。但對於已置身此種工作流程的人而言，更重要的理由是：如果你將計算力投入正確性，每小時注意力能產生更多正確的代碼。瓶頸已經轉移，預算也應隨之而動。