解決 PR 瓶頸：Haystack 如何對 AI 生成的程式碼進行分流處理

隨著精密的編碼代理（coding agents）崛起——例如 Opus 4.5 等模型展現出的能力飛躍——軟體開發的速度已發生根本性的轉變。雖然工程師現在能以空前的速度產生 Pull Requests (PRs)，但人類審查這些程式碼的能力並未按比例擴展。當單一團隊成員每天能產出超過 20 個 PRs 時，傳統逐行比對（diff）的審查方式會變成資訊的「消防栓」，讓人感到認知疲勞且往往收效甚微。

這正是 Haystack 旨在解決的核心問題。Haystack 並非將每個 PR 都視為需要人工審查的同等候選對象，而是引入了一個分流層（triage layer），根據風險、證據和意圖來過濾並路由 PRs，確保人類的注意力能花在能對結果產生實質影響的地方。

Moving from "What Changed?" to "Does it Work?"

從「變動了什麼？」轉向「它是否有效？」

傳統的程式碼審查專注於 diff：哪些行被新增或刪除了？ 在 AI 增強的工作流程中，這種方法效率低下。Haystack 將審查者的焦點轉向目標與驗證證據。審查者不再從程式碼開始，而是會看到：

• The Goal: PR 的預期目的。
• Design Decisions: 實作背後的原理，由工程師與編碼代理之間的對話提供資訊。
• Verification Evidence: 作者如何驗證變動的紀錄（例如：執行腳本、前端檢查或端到端測試）。

透過將審查重心放在行為與證據而非語法上，這個過程變成了對意圖的驗證，而非對每個字元變動的手動審計。

The Triage System: Three Buckets of Review

分流系統：審查的三個分類桶

Haystack 取代了標準的 GitHub PR 列表，改用一個分流隊列，將 PRs 分成三個不同的分類桶：

1. Safe to Merge

1. 可安全合併

這些是具有充足證據顯示可以在無需人工干預的情況下合併的 PRs。範例包括：

• 伴隨最終狀態截圖的小型 UI 文字變動。
• 後端變動，且作者已提供在真實環境中測試關鍵路徑的明確證據。

2. Needs Fixes

2. 需要修正

這些 PRs 會被標記出來，讓作者在到達人工審查者之前先進行修正。這可以防止審查者在明顯的錯誤或違反政策的情況下浪費時間，例如：

• Logic Failures: 一個代理被要求實作分頁功能，但卻是載入所有結果並在 UI 中模擬分頁。
• Rule Violations: 一個 PR 悄悄地吞掉了錯誤，違反了團隊的「不允許靜默吞掉錯誤」政策。

3. Needs Human Review

3. 需要人工審查

這個分類桶保留給高風險變動或缺乏充足驗證的變動。這包括：

• Sensitive Areas: 對關鍵邏輯的變動，例如計費系統。
• Insufficient Verification: 高影響力的面向使用者變動（例如註冊流程），作者僅執行了單元測試但未能進行手動端到端驗證。

The Philosophical Shift in AI Review

AI 審查中的哲學轉變

Haystack 的引入引發了關於 AI 在開發生命週期中角色的一場必要對話。一些懷疑論者問，讓 AI 審查 AI 寫的程式碼是否是一種循環論證。然而，其價值主張並非完全自動化，而是「增強」（augmentation）。

正如一位社群成員所言，理想的未來是 AI 作為一個支援系統——類似於電影《Limitless》中的概念——增強人類的能力而非完全取代人類。透過扮演一個過濾器，說「檢查這些特定部分，因為它們值得注意」，AI 讓人類能繼續擔任品質與架構的最終仲裁者，同時消除瑣碎驗證的枯燥工作。

Conclusion

結論

隨著編碼速度持續加速，軟體開發生命週期的瓶頸正從「編寫」程式碼轉向「審查」它。透過將人類注意力視為稀缺且昂貴的資源，Haystack 提出了一個「分流先於審查」的系統，確保最關鍵的邏輯能獲得最多的審查，而瑣碎的部分則交由自動化處理。