將計算力投入正確性

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

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

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

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

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

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

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

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

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