AI 編碼代理的「精準度困境」：新研究揭露，找到檔案卻錯失關鍵程式碼的隱藏弱點

人工智慧（AI）編碼代理（coding agents）在軟體開發領域的應用日益廣泛，然而，一項由上海交通大學團隊參與的國際研究揭示了這些 AI 代理一個長期被忽視的關鍵弱點：它們雖然能找到問題所在的「正確檔案」，卻往往錯失了程式碼中真正重要的「關鍵行」。這項發現挑戰了傳統上僅以「是否修復錯誤」來評估 AI 編碼能力的單一指標，並指出了一個影響其效率與可靠性的深層問題。

傳統評估盲點：只看結果，不問過程

過去，AI 編碼代理的表現主要透過其能否成功修復錯誤來判斷。然而，這種單一指標掩蓋了許多潛在的問題：代理程式可能從未讀取相關程式碼，或者即使找到了正確的檔案，卻仍寫出了錯誤的修補程式。無論哪種情況，最終結果看起來都一樣，導致開發者難以理解 AI 失敗的真正原因。

為了解決這個盲點，上海交通大學團隊開發了一套名為 SWE-Explore 的新基準測試。這套測試專注於評估 AI 編碼過程的「第一階段」，也就是代理程式在收到錯誤描述和軟體專案後，如何返回一份它認為相關的程式碼區塊排名列表。透過隔離這個上游的搜尋階段，SWE-Explore 能更精確地揭露 AI 代理在定位關鍵程式碼時的真實能力。

SWE-Explore 如何定義「關鍵程式碼」？

要手動判斷哪些程式碼區塊真正重要幾乎是不可能的任務。因此，研究團隊採取了創新的方法：他們從資料集中 848 個問題的至少兩個成功解決方案中提取參考。這些成功方案來自於 GPT-5.4、Gemini 3 Pro、Claude Sonnet 4.6 或 Kimi K2.6 等強大模型。

研究人員追蹤這些 AI 模型在修復錯誤之前實際檢查了哪些檔案和程式碼行。那些多個獨立解決方案路徑都匯聚的程式碼段，被視為有用上下文的強烈訊號。隨後，透過單獨的驗證步驟填補個別關鍵段落，並由團隊手動再次審查每個區域，確保參考的準確性。這種方法避免了手動定義必要位置的困難，而是從成功解決方案的「閱讀軌跡」中推導出參考基準。

該資料集涵蓋了 10 種程式語言的 203 個開源專案，其中 Python 任務佔了 547 個，其次是 Go、JavaScript 和 Rust。

AI 代理的「精準度斷崖」：檔案級別佳，行級別差

研究團隊將傳統的關鍵字搜尋方法與五種通用編碼代理（包括 Claude Code、Codex 和 OpenHands）以及四種專為程式碼搜尋設計的研究系統進行了比較。結果顯示：

關鍵字搜尋表現不佳：傳統的關鍵字搜尋效果幾乎只比隨機猜測好一點。例如，一個像「RuntimeWarning on Overflow」這樣的錯誤描述，其關鍵字在專案的模板和文件中出現的頻率，遠高於實際的原始碼。AI 代理則表現更佳，因為它們能逐步搜尋專案，而非一次性篩選所有結果。
檔案級別表現良好，行級別卻斷崖式下跌：在檔案層級，AI 代理的表現尚可，它們能找到正確的原始碼檔案，並將其排在靠前的位置。然而，一旦測試聚焦到單一程式碼行時，系統的表現便急劇惡化。通用編碼代理僅能覆蓋實際關鍵程式碼行的 14% 到 19%。

研究指出，通用編碼代理在檔案層級的命中率尚可，但一旦深入到程式碼行層級，其對關鍵行的覆蓋率便急劇下降，僅能達到 14% 至 19%。

更令人意外的是，即使採用更強大的大型語言模型（LLM）也無法解決這個問題。研究團隊使用 OpenAI、Anthropic、Google、Moonshot 和 Zhipu 的六種不同模型運行相同的代理程式，結果顯示 GPT 系列雖然領先，但檔案命中率始終高於實際的行覆蓋率，這種模式依然存在。此外，Claude Code、Codex、OpenHands、Mini-SWE-Agent 和 AweAgent 等不同的代理架構，在各項指標上的得分也驚人地接近。

值得注意的是，研究系統 CoSIL 是一個例外。它將程式碼視為相互連接的構建模塊網路進行掃描，從而實現了更高的行覆蓋率。在專門的定位系統中，AutoCodeRover 雖然精確但偏於保守，而 OrcaLoca 產生的雜訊較少，卻也錯過了許多相關的關鍵點。

修復成功率的「上下文門檻」：讀太少比讀太多更糟

在一項受控的消融實驗（ablation experiment）中，研究團隊人為地改變了提供給修復模型的上下文（context）。修復模型僅能看到 0%、25%、50%、75% 或 100% 的核心區域，有時還會混入不相關的非核心程式碼。結果顯示，對於資料集中較簡單的任務，存在一個明顯的「門檻效應」：

只要可見的核心區域少於一半，修復任務幾乎都會失敗。
成功率僅在覆蓋率達到 50% 到 75% 之間時才顯著提升。這表明修復並非逐漸改善，而是需要達到最低限度的線索後才能「豁然開朗」。
對於較困難的任務，這種效應的範圍則窄得多。如果問題本身已經超出模型的能力範圍，即使提供更好的上下文也幫助不大。

研究發現，修復成功率只有在超過一半的必要關鍵點可見時才會顯著提升。上下文不足的傷害，遠大於額外不相關程式碼的影響。

一旦關鍵點到位，額外不相關的程式碼幾乎不會造成阻礙。一個讀取太少的代理程式，其表現會比讀取太多的代理程式更差。這項研究為未來的改進提供了明確的啟示：「篩選更少，讀取更多」（Filter less, read more）。相關程式碼和數據已在 GitHub 和 Hugging Face 上公開。

為什麼這很重要？

大約兩年前，另一個研究團隊創建了 SWE-bench，一個針對真實 GitHub 問題報告測試 AI 編碼代理的基準測試。這催生了一系列涵蓋更多語言、更清晰數據和更專業任務的變體。然而，近年來，其底層的成功指標受到了多方壓力。研究組織 METR 的一項研究發現，專案經理會拒絕約一半由自動審查員接受的解決方案，其中許多是因為基本的程式功能錯誤。SWE-Explore 的出現，正是為了填補這一評估盲區，促使 AI 編碼代理不僅能「解決問題」，更能「理解問題」，從而提升其在真實世界軟體開發中的實用性和可靠性。