AI Coding Agent 怎麼做真實倉庫評測：任務集、通過率、成本與迴歸基線

美國區過去完整週中，“AI coding” 在本輪五個對比詞裏熱度最高，爲 27。

公開榜單適合瞭解模型能力，但不能回答某個 Agent 是否適合你的倉庫。

先定義你真正購買的結果

有人需要快速修小 bug。

有人需要跨服務重構。

有人更在意隱私、成本和可審計性。

把這些目標寫成權重，避免最後只比較“看起來聰明”。

從歷史工單抽取任務

選擇已經解決、答案可驗證的工單。

覆蓋四類難度：

單文件明確修復。
跨文件行爲修改。
需要運行項目才能定位的問題。
需求含歧義、必須先提問的任務。

不要只選模型訓練資料裏可能出現的公開熱門 issue。

每個任務創建固定起點

保存倉庫 commit、依賴鎖文件和測試數據版本。

使用獨立 Git worktree。

1

git worktree add ../eval-task-01 <base-commit>

容器鏡像用 digest，而不是浮動 latest。

外部 API 用錄製響應或測試環境。

寫機器可判定的通過條件

單元測試通過只是第一層。

還要檢查原有測試、類型檢查、lint 和構建。

數據庫任務檢查 schema 與數據兼容。

前端任務加入截圖或無障礙斷言。

安全任務加入負面測試。

防止 Agent 修改裁判

隱藏測試不放在可寫工作樹。

測試運行器掛載爲只讀。

檢查 Agent 是否刪除、跳過或弱化現有測試。

比較測試數量與覆蓋率變化。

禁止通過硬編碼測試輸入“修復”問題。

記錄完整運行軌跡

至少保存：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


agent_version
model
task_id
base_commit
prompt_version
wall_time
input_tokens
output_tokens
tool_calls
human_interventions
final_cost

沒有版本字段的結果無法用於以後迴歸。

敏感日誌先脫敏再歸檔。

成功率分成三檔

一次通過：無需人工修改，所有驗收通過。

協助通過：人提供澄清或小改後通過。

失敗：未完成、破壞其他行爲或結論不可信。

不要把“生成了很多代碼”計作成功。

也不要把 Agent 自述的“已修復”當測試結果。

成本按成功任務計算

平均每次請求成本會掩蓋失敗重試。

更有用的是：

1

每个一次通过任务成本 = 总成本 / 一次通过任务数

同時記錄工程師審覈時間。

便宜模型若需要更久人工審查，總成本未必更低。

時間指標拆成三段

首個有效動作時間。

Agent 完成時間。

人工審覈到合併時間。

並行 Agent 可能縮短第二段，卻增加第三段衝突成本。

因此只看模型響應速度沒有意義。

重複運行衡量穩定性

同一任務至少運行三次。

固定模型版本、溫度和環境。

三次中只有一次通過，不能當成可靠自動化。

記錄失敗類型是否一致。

穩定地提出正確澄清問題，也是一種可用能力。

建立失敗分類

沒找到相關文件。
理解錯需求。
工具或環境失敗。
補丁正確但測試不完整。
修改超出範圍。
僞造驗證結果。
成本或時間超限。

分類後才能決定改模型、提示、工具還是環境。

升級前運行迴歸

保留 15 到 30 個代表性任務作爲基線。

Agent、模型、工具權限或系統提示變化都觸發迴歸。

新版本至少不能讓高風險任務退步。

結果用同一評分腳本生成。

不要在看到結果後臨時改變權重。

一張實用結果表

Agent	一次通過率	人工分鐘/任務	成本/成功任務	越界次數
A	由測試填寫	由記錄填寫	由賬單填寫	由審計填寫
B	由測試填寫	由記錄填寫	由賬單填寫	由審計填寫

保留原始任務級數據，不只發佈彙總平均值。

結論怎麼寫纔可信

說明倉庫語言、任務類型、模型日期和權限配置。

說明樣本量與置信限制。

區分事實數據與主觀體驗。

不要把一個倉庫的贏家宣傳成所有場景的贏家。

真正有價值的評測，是下一次升級時可以原樣重跑的工程資產。

評測數據來源

任務清單使用版本化 YAML

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


id: api-017
base_commit: 8c18d4a
category: cross-file-bug
time_limit_minutes: 30
allowed_paths:
  - src/api/
  - tests/api/
required_checks:
  - python -m pytest tests/api
  - ruff check src/api tests/api
forbidden_changes:
  - tests/fixtures/golden.json

任務描述與隱藏測試分開保存。YAML 進入評測倉庫，隱藏測試放在 Agent 無權讀取的執行環境。

區分環境失敗與能力失敗

依賴源不可用、容器拉取失敗或測試基礎設施故障不應直接計爲模型失敗。先由固定的預檢腳本確認環境健康。

環境正常後才啓動計時。Agent 自己破壞依賴或配置導致的失敗則屬於任務結果，不能標記爲基礎設施問題。

人工干預如何計分

把干預分成需求澄清、環境幫助、技術提示和直接給出答案。每類分別計數與計時。

Agent 主動提出必要澄清，與人主動透露關鍵文件位置不同。前者可能是良好行爲，後者說明獨立完成能力不足。

檢查補丁範圍

1
2
3


git diff --name-only <base-commit>...HEAD
git diff --numstat <base-commit>...HEAD
git diff --check <base-commit>...HEAD

統計修改文件數、淨增刪行和任務允許範圍外的文件。大補丁不自動扣分，但無關修改應單獨標記。

對抗“測試通過但行爲錯誤”

隱藏測試覆蓋邊界輸入、錯誤處理和舊行爲兼容。人工審查測試是否被跳過、mock 是否過度，以及實現是否硬編碼樣例。

前端任務錄製關鍵交互，API 任務比較狀態碼與錯誤結構，性能任務使用固定數據集和預熱規則。

評測成本包含基礎設施

除模型 token 費用，還記錄容器時間、瀏覽器運行、數據庫實例和日誌存儲。企業環境再加入人工審覈成本。

同一 Agent 併發運行時，按任務分攤共享服務成本。不要把免費試用額度當長期單位成本。

結果變化的顯著性

二十個任務中多通過一個，可能只是隨機波動。查看任務級配對結果：哪些舊任務退步，哪些新任務改善。

對關鍵類別設置最低通過率，而不是隻看總平均。安全修復退步不能被文檔任務提升抵消。

保存失敗產物

失敗運行保留最終 diff、最後測試輸出、工具錯誤與停止原因。去除憑據後存入按任務和運行 ID 命名的目錄。

覆盤時先比較失敗類型，再閱讀長對話。很多問題可以直接從重複工具調用、錯誤工作目錄或測試未執行看出。

防止基準被訓練記憶污染

內部任務不要公開完整描述與答案。定期從新近已解決工單補充題目，並淘汰已經泄露的任務。

保留一組長期錨點用於趨勢比較，同時用滾動任務衡量當前真實工作。兩組結果分別報告。

發佈結果時附上未通過任務清單和停止原因，避免彙總分數掩蓋模型在關鍵場景中的穩定失敗。

原始數據保留足夠精度，展示時再統一四捨五入。