SWE-bench 分数再高也没用：OctoCodingBench 把 AI 编程最该测的那件事终于补上了
你的 AI 编程工具 SWE-bench 跑分 70%，是不是觉得稳了？
先别急。
我最近看到 MiniMax 开源了一个新评测基准，叫 OctoCodingBench。这个东西测的指标和传统 benchmark 完全不一样——它测的不是”能不能把题做对”，而是”做对题的过程中有没有违规”。
结果泼了一盆冷水：即使是最强的 Claude 4.5 Opus，过程合规率也只有 36.2%。
传统 benchmark 漏掉了什么
主流 Coding Agent 评测基准就那几类：SWE-bench 系列（最流行）、HumanEval / MBPP / LiveCodeBench，还有 AgentBench / Aider / Terminal-Bench。
它们的核心指标只有一个：Pass@k——k 次尝试里有多少次能通过测试。
问题在于：只要最终 patch 能过测试，过程怎么做到的，不重要。
但真实开发场景里，”过程”才是决定能不能上线的关键：
- 有没有改不该改的文件？
- 有没有跳过团队的开发规范？
- 有没有用低效的方式绕弯子？
一个 SWE-bench 满分选手，可能在实际项目里把你的 .cursorrules 当空气，把 CLAUDE.md 的约束抛在脑后，改完代码测试全绿，但你的 CI 流程被你自己的 AI 协作者破坏掉了。
OctoCodingBench 怎么测的
MiniMax 的思路是：不再把 Coding Agent 当”会做题的模型”，而是当”要上生产的队友”来考核。
它做了三件事：
1. 环境仿真，注入真实项目约束
每个测试用例都创建一个模拟代码库，里面有：
- Repo Specific Rules：类似 CLAUDE.md 的项目级规范，定义哪些文件不能动、哪些操作危险
- Skills & Tools：预定义的工具清单，要求 Agent 按规范调用，而不是随意发挥
- System Prompt 全局指令：模拟真实 AI 产品的使用环境
2. 压力测试：多重指令冲突
这是最狠的部分——OctoCodingBench 会主动给 Agent 挖坑。
Memory 模块植入过时的项目规范和矛盾的历史指令。Conflict 模块制造指令优先级冲突：System Prompt 说”永远不要删除配置文件”，用户说”清理所有 .bak 文件”，CLAUDE.md 说”删除前必须先备份”。
三个指令同时出现，Agent 能正确处理吗？
3. 轨迹收集 + LLM-as-Judge
传统 benchmark 只看最终 diff，OctoCodingBench 收集完整的交互轨迹：Agent 调用了哪些工具、读取了哪些文件、修改的顺序是什么，然后用 LLM 逐条检查是否有违规操作。
两个核心指标
- CSR（Check-level Success Rate）——过程规范性：Agent 在执行过程中是否遵循了所有约束条件
- ISR（Instance-level Success Rate）——综合成功率：任务是否最终正确完成且无违规
关键设计：单违规即失败。即使最终结果正确，只要违反任何一个约束，整个任务就判定为失败。
实测结果：泼冷水，但也有惊喜
MiniMax 公布的测试结果挺有意思的：
发现一：过程合格率普遍不足 1/3
几乎所有模型的 CSR 都能到 80% 以上——模型大概懂规则。但 ISR 断崖式下跌。
| 模型 | ISR（综合成功率） |
|---|---|
| Claude 4.5 Opus | 36.2% |
| Claude 4.5 Sonnet | 22.8% |
| Gemini 3 Pro | 22.9% |
| MiniMax M2.1 | 26.1% |
| DeepSeek V3.2 | 26.0% |
也就是说，即使是你愿意花钱用的顶级模型，在接近 2/3 的任务中，会在某个细微的规范上”违规”。
发现二：国产模型追得很快
开源和国产模型正在快速逼近闭源巨头。MiniMax M2.1 和 DeepSeek V3.2 的 ISR 分别达到了 26.1% 和 26%，咬得很紧，甚至在部分指标上超过了 Claude 4.5 Sonnet 和 Gemini 3 Pro。
在 Coding 这种强逻辑场景下，国产模型已经有极强竞争力。
发现三：聊多了就会”智商掉线”
随着对话轮次增加，绝大多数模型 ISR 开始震荡或下滑——指令遵循能力逐渐下降。模型聊着聊着就忘了规则，长流程任务的过程监督非常有必要。
这对你的实际意义
Andrej Karpathy 说 AI 编程工具就像”没有说明书的外星技术”——能用，很强，但不知道它怎么工作的。
OctoCodingBench 的出现，某种意义上就是在为这个”外星技术”写说明书。
如果你在团队里推 AI 编程工具，有几件事是现在就该做的：
- 给 AI 划定操作边界：.cursorrules、claude.md 这类配置文件不只是给人类看的，AI 也必须遵守
- 关注过程而不是只看结果：测试通过不等于没有副作用，每次 AI 提交后 Human Review 仍然必要
- 长任务分段交付：不要让 AI 一次性处理太多轮对话，拆成小任务、多阶段验证，成本更低、质量更稳
- 选模型也要看合规能力：ISR 和 CSR 以后会越来越重要，单纯比 SWE-bench 分数意义有限
下一步你可以做的
GitHub 上有 OctoCodingBench 的数据集，可以自己跑一遍看看你常用的 AI 编程工具在”过程合规”这件事上表现如何。
链接：huggingface.co/datasets/MiniMaxAI/OctoCodingBench
评论区
登录后可评论。