代理式程式碼生成改變了工作的基本單位。以往由一位人類作者撰寫並審查一個小型 PR；現在，代理可以一次產生數十種候選實作、跨服務架構樣板，以及自動化遷移程式。結果是產量與程式碼多樣性同步增加，讓審查範圍大幅擴張。團隊同時面臨兩種壓力——交付量（持續推出功能）與安全性（避免回歸問題或供應鏈風險）。本節將說明自動化如何擴大審查範圍、審查者為何成為瓶頸，以及哪些職務受影響最大：發布工程師、安全團隊與關鍵函式庫的維護者。

測試會驗證所選情境中的預期行為，最適合預防與測試案例相符的回歸問題。靜態分析與 lint 工具能在程式執行前找出型別錯誤、記憶體問題及許多 API 誤用。AI 程式碼審查有助於大規模分流可讀性問題、可能的邏輯錯誤與風格回歸，但可能漏掉細微的語意錯誤，或把幻覺產生的邏輯當成問題。相較之下，只要提供精確規格，形式化驗證就能證明所有輸入都符合特定性質。實務上，測試用於行為涵蓋，靜態工具用於結構問題，AI 審查用於初步分流，而證明則用來確認不變條件、並行性或密碼學保證——這些內容無法靠有限測試案例窮盡驗證。

形式化方法功能強大，但並非萬用。它需要精確規格——而撰寫規格本身就是不簡單的設計工作——程式碼通常也必須採用適合證明的子集，或加上契約註記。若是 UI 版面問題、效能調校，或取決於模糊現實輸入的行為預期，形式化方法就不那麼有用。若團隊試圖形式化驗證大型且快速變動的程式碼庫，過度使用證明也可能造成瓶頸。本節將整理常見陷阱：規格與實作逐漸偏離、證明維護成本、與 CI 整合時的摩擦，以及證明所依據的假設有誤卻仍讓人過度安心的風險。

採用分層流程：1）規格優先生成——請代理實作前，先撰寫精確的 API 契約、型別與屬性測試；2）沙箱合成——在隔離的 CI 執行器中運行代理，並對生成的模組進行檢測與模糊測試；3）自動化閘門——人工審查前，必須通過單元測試、整合測試、屬性測試及 GitHub AI Scan 安全檢查；4）指定範圍的形式化證明——針對關鍵不變條件（共識、密碼學、授權）或影響範圍極大的模組採用證明；5）人工驗證——讓審查者專注於設計、規格遵循情況與對抗性思考，而非逐行確認程式碼是否正確。整合工具時，應確保每個步驟不會阻塞流程，並能在 PR 儀表板中清楚呈現。

從小規模開始：先在一項關鍵服務試行形式化證明，建立指標以衡量缺陷暴露時間與審查時間，並訓練 SRE／安全工程師撰寫規格與證明測試架構。可設立新職務或輪值角色，例如證明工程師或驗證推動者，協助將產品需求轉化為機器可檢查的契約。長期而言，程式碼的驗證方式將逐漸分流：大部分程式碼由快速的機率式工具與人工審查者驗證；少部分高價值模組則以形式化證明加固。這種組合既能維持開發速度，也能在最關鍵之處大幅降低系統性風險。