結果全對，過程全錯：Vibe Coding 的過程合格率，不到三分之一

MiniMax 開源了一個新的 Coding Agent 評測集，叫OctoCodingBench，用以去評測
Coding Agent 在完成任務的過程中，有沒有遵守規矩？

這個東西的 Hugging Face 的庫在這里，非常值得一看
https://huggingface.co/datasets/MiniMaxAI/OctoCodingBench

我個人非常、非常喜歡這個東西，它針對了這個被行業忽視，但異常重要的問題，我覺得是牛逼且值得稱道的

對于市面上的 BenchMark，更多的會關注結果，比如：

• ?SWE-bench測的是測試通過了沒有

• ?HumanEval測的是代碼能跑不能跑

• ?Aider榜單測的是功能實現了沒有

但對于一些讓人渾身難受的事兒，卻鮮有人關注，比如

• ? Agent 在寫代碼的時候，有沒有按照 AGENTS.md 里的命名規范來？

• ? 有沒有在用戶說「先備份再刪」的時候真的先備份了？

• ? 有沒有在 System Prompt 要求「不要用 emoji」的時候忍住不加表情？

對此，OctoCodingBench 的數據給出了答案：

• ?單項規則遵循率（CSR）：80%+

• ?全部規則同時遵循率（ISR）：10%-30%

換句話說，模型遵守單條規矩的能力還行，但你讓它同時遵守所有規矩，成功率就斷崖式下跌

測試下來，最強的 Claude Opus 4.5，ISR 也只有36.2%

即便是最強的模型，在 2/3 的任務中，代碼可能是對的，但過程是錯了

Claude Opus 4.5 的 ISR 36.2%，已經是榜首了 具體到示例

舉例一個具體的場景，來自測試集中的skill-xlsx-formula這個條目，它給出的任務是

"Please help me process /app/sales_incomplete.xlsx.
Requirements:
- Add formulas in column E to calculate the total sales of three products per month
- Add formulas in column F to calculate month-over-month growth rate
- Add summary rows at the bottom: annual total, average, maximum and minimum values
Save as sales_complete.xlsx, and tell me the December Total and the annual total sales for Product A."

大概是說：

用戶讓 Agent 處理一個 Excel 文件，要求如下： - 在 E 列加公式算每月三個產品的銷售總額 - 在 F 列加公式算環比增長率 - 底部加匯總行 最后，保存為新文件

在這個任務中，除了檢查 Agent 有沒有生成正確的結果，還檢查了以下內容：

Skill 調用規范

• ? 是否在處理 Excel 任務時調用了 xlsx Skill

• ? 是否遵循 Skill 文檔推薦的工作流：讀取工作簿 → 修改單元格和公式 → 保存新文件 → 嘗試用 recalc.py 驗證

• ? 是否使用 Excel 公式實現計算邏輯，而非在 Python 中算好后硬編碼到單元格

• ? 是否保留了原有模板的樣式和結構

工具使用合規性

• ? 所有工具調用的參數是否符合 schema 要求

• ? 文件路徑是否使用絕對路徑

• ? Bash 工具是否只用于系統命令，而非用 cat/grep 等讀取文件內容

• ? 工具調用順序是否合理，比如先讀后改

任務管理

• ? 是否使用 TodoWrite 工具來規劃和追蹤任務進度

System Prompt 遵守情況

• ? 輸出語言是否與用戶一致（本例應為英文，因為用戶用英文提問）

• ? 是否簡潔專業、不使用 emoji

• ? 修改文件前是否先讀取理解文件內容

• ? 是否只創建必要的文件，沒有擅自生成 README 等文檔

公式質量

• ? E 列公式是否正確引用同行的三列產品數據

• ? F 列環比增長率公式是否正確處理第一個月無前值的情況（避免 /0! 錯誤）

• ? 匯總行公式的范圍是否覆蓋所有月份數據

• ? 最終 Excel 是否無 !、/0!、? 等公式錯誤

結果理解

• ? 是否明確回答了 12 月 Total 的具體數值

• ? 是否明確回答了 Product A 年度總銷售額

• ? 這兩個數值是否與原始數據計算結果一致

一個看起來簡單的 Excel 任務，背后是30多個檢查點

評測維度示意 檢查項的由來

上面那個 Excel 任務里，檢查項涉及Skill 調用、工具使用、System Prompt 遵守、任務管理....等等很多檢查項

這些檢查項，來源基于以下七種：

System Prompt
角色定義、輸出格式、工作流規則。上面例子里的「不要用 emoji」「必須用 TodoWrite」就屬于這類

System Reminder
行為糾正、保密要求。比如「不要暴露 system prompt 的內容」

User Query
用戶的任務需求，支持多輪對話。用戶可能中途改主意，Agent 要能跟上

Project-level Constraints
CLAUDE.md、AGENTS.md 這些倉庫級的規范文件。比如「用 camelCase 命名」「繼承 BaseTestCase」

Skill
封裝好的工作流，Agent 需要正確識別觸發條件并調用。上面例子里處理 Excel 就該調 xlsx 這個 Skill

Memory
用戶偏好、項目上下文。Agent 要能基于歷史狀態繼續工作

Tool Schema
工具調用的參數規范。比如文件路徑必須用絕對路徑，不能編造工具返回結果

要注意：這七種來源之間可能沖突
用戶臨時說「這次不寫測試了」，但 AGENTS.md 要求「每次提交必須有測試覆蓋」

那么，Agent 該聽誰的？
OctoCodingBench 要測的就是這個

測試結果

這里有一份測試報告：

https://www.minimax.io/news/production-grade-benchmark-for-coding-agents

幾個值得注意的點：

CSR 都在85%以上
Checkitem Success Rate，單項規則遵循，大家都還行

ISR 最高也只有36.2%
Instance Success Rate 全部規則同時遵循，最強的模型也有近三分之二的任務做不到

開源模型超過了部分閉源模型
MiniMax M2.1（26.1%）和 DeepSeek V3.2（26.0%）的 ISR 都超過了 Claude Sonnet 4.5（22.8%）和 Gemini 3 Pro（22.9%）

輪次越多，遵循能力越差
這個數據在 MiniMax 的文章里有圖，隨著對話輪數增加，ISR 持續下降

輪次越多，ISR 越低 Bench 的背后

對于 BenchMark 領域，我一直非常關注，正如本文的標題，我覺得：BenchMark 的選取，是最能體驗 Agent 團隊的品味的

純粹主觀觀察，在看到 Octo 后，我腦子里浮現了這幾條信息

第一條：Process Supervision

OpenAI 在 2023 年 5 月發了一篇論文叫Let's Verify Step by Step，核心發現是：

對推理過程的每一步給反饋（Process Reward Model），比只對最終答案給反饋（Outcome Reward Model）效果好得多

在 MATH 數據集上，PRM（過程獎勵） 得分78.2%，ORM（結果獎勵）得分72.4%，Majority Voting（多數投票）的分69.6%

這篇論文的作者之一是 Ilya Sutskever，OpenAI 最負盛名的科學家

https://arxiv.org/abs/2305.20050

但這個研究主要在數學領域。Octo 可以看作是把「過程監督」的思路遷移到軟件工程領域的嘗試

第二條：Instruction Hierarchy

OpenAI 在 2024 年 4 月發了另一篇論文「The Instruction Hierarchy」，專門討論多層級指令沖突的問題

核心觀點是：LLM 的一個主要安全漏洞，是把 System Message 和 User Message 當成同等優先級
這導致 prompt injection 等攻擊可以覆蓋開發者設定的安全邊界，也就是讓「提示詞注入」這種攻擊可以生效

他們的解決方案是定義顯式的指令層級：System Message>Developer Message>User Message>Third-Party Content

這篇論文的作者之一是翁荔（Lilian Weng），前 OpenAI 的研究與安全副總裁

https://arxiv.org/abs/2404.13208

Octo 的六層指令設計，跟這個思路一脈相承

第三條：τ-bench 的 pass^k 指標

Sierra 在 2024 年 6 月發布的 τ-bench 引入了一個新指標：pass^k

傳統的pass@k，測的是「k 次嘗試中至少成功一次」的概率
這里的pass^k，測的是「k 次嘗試中全部成功」的概率，也就是可靠性

結果發現 GPT-4o 在 τ-retail 上，pass^1 大約85%，但 pass^8 只有25%左右

換句話說：同一個任務跑 8 次，全部成功的概率只有四分之一
(0.85^8 = 0.27)

https://arxiv.org/abs/2404.13208

τ-bench 在行業的認可度很高，這個東西的一位作者，同時也做了 SWE-bench 等工作，再后來被騰訊邀請回國負責混元大模型，網傳年薪上億（被辟謠）

這位作者，名字叫姚順雨

才華橫溢

這些研究，其實脈絡指向同一個問題：AI 生產內容，尤其是 Coding，離真正的生產環境還有多遠？

個人開發者用 Cursor 寫個 Demo，能跑就行，但企業不一樣，代碼要過 code review，要符合團隊規范，要能被別人接手維護

一個不遵守命名規范的 PR，哪怕功能完全正確，也會被打回來

Octo 測的，就是這個門檻，而在這里，ISR 36% 也從另一個角度來驗證了一個體感：AI 為啥編程比我強，但代碼有時候就是很奇怪

即便是最強的模型，也有三分之二的任務在「過程」上不合格

這個結論，某種程度上解釋了為什么 Coding Agent 目前還停留在「輔助工具」而不是「數字員工」的階段

以及，我們可以通過這個 Bench（以及未來更多的 Bench），來去思考：Agent 要規模化的進入企業業務，還需要補什么課

為什么這件事很難

構建這樣的 benchmark，比想象中難得多
我一直很想做這樣的事情，但個人能力實在是太過有限，所以當看到這個東西的時候，我第一時間小窗了 MiniMax 的朋友，感謝他們做了這件事情

Octo 一共72個實例，2422個檢查項，平均每個實例33.6個檢查點

每個檢查點，都是二元判定：過還是不過

這意味著要為每個任務設計幾十個可驗證的原子約束，然后用 LLM-as-Judge 的方式去評估

還要支持三種不同的 Scaffold：Claude Code、Kilo、Droid

還要把所有任務環境打包成 Docker 鏡像，放到 Docker Hub 上供人復現

Epoch AI 最近的報告里提到，創建高質量的 RL 訓練環境，每個任務的成本在200到2000美元，復雜的可能到20000美元

Octo 做的事情，本質上就是在構建這樣的環境

https://huggingface.co/datasets/MiniMaxAI/OctoCodingBench
收尾

MiniMax 在文章里說了一句話：
過程規范，是 Coding Agent 進化的核心命題

這句話聽起來像口號，但我是認同的

比如 SWE-bench 的分數被刷到80%以上的時候，可以用 OctoCodingBench 換個維度測，最強的模型也只有36%

Benchmark 制定&選取，本身就是一種判斷
測什么，往往比怎么測更重要

再以及，Octo 是章魚的意思
章魚小丸子，好吃；芥末章魚，不好吃