更好的工具反而讓Copilot程式碼審查變得更糟，我們是這樣改進的

給代理更好的工具，它應該做得更好——這是直覺。然而，當GitHub團隊將Copilot程式碼審查的底層程式碼探索工具替換為共享的Unix風格工具（grep、glob和view）時，他們發現審查成本上升了，發現的問題卻減少了。問題並不在於新工具本身，而在於代理使用這些工具的指令。原始指令是為通用編碼助手設計的，導致代理像瀏覽整個倉庫一樣去探索程式碼，而不是從拉取請求（PR）的差異出發進行有針對性的審查。這種“瀏覽模式”使代理積累了過多無關上下文，增加了成本並稀釋了注意力。

團隊透過重寫工具指令來糾正這一行為。新的指令模擬了人類審查者的工作流程：從PR差異開始，形成具體的審查問題；使用grep和glob快速發現候選檔案和符號，但推遲讀取；僅在確定位置後才使用view讀取精確的程式碼範圍。這種“先縮小範圍，再精確讀取”的模式顯著提高了效率。例如，當審查一個授權輔助函式的變更時，代理不再搜尋所有呼叫該函式的檔案，而是透過grep查詢呼叫者，再用glob定位相關路由檔案，最後用view讀取關鍵呼叫點。

此外，指令還改進了錯誤恢復策略。如果grep失敗，代理會嘗試更簡單的轉義搜尋；如果路徑錯誤，則轉向glob而不是猜測相鄰路徑。這些調整避免了小錯誤引發更大的探索迴圈。內部基準測試在此過程中發揮了關鍵作用，它們不僅顯示最終評分，還展示了代理的完整工具呼叫軌跡，使團隊能夠視覺化代理行為並迭代指令。

最佳化後的結果令人滿意：生產環境中平均審查成本降低了約20%，且審查質量保持不變。這一改進的啟示在於，工具本身是通用的，但指令必須針對特定任務進行最佳化。同樣的工具在不同產品中需要不同的指令——Copilot CLI處理的是互動式編碼任務，而Copilot程式碼審查專注於從差異出發的評估。團隊的經驗表明，共享工具與定製化指令、嚴格基準測試相結合，才能實現真正的效率提升。