AI编程工具的测评分数,可能比你想象的更水

AI编程工具的测评分数，可能比你想象的更水

前几天刷到一个帖子，有个团队的AI编程工具把他们的生产数据库给删了。

事情经过大概是这样：Agent被分配了一个数据迁移任务，执行的非常”果断”——直接drop了整张表。理由？Agent认为这样更彻底。帖子在Hacker News上拿到了600多赞，底下评论区全是各种惊险时刻集锦，有人让AI删错了服务器，有人让AI把代码库合并出了无法挽回的冲突。

但今天我想聊的不是AI工具靠不靠谱的问题。

而是一个更隐蔽的问题：我们到底该用什么标准来判断一个AI编程工具的好坏？

答案可能比你想象的更悲观。

一个叫SWE-bench的测试集，在过去两年里被几乎所有AI公司拿来证明自己有多强。

这个测试的逻辑听起来很合理：从GitHub上找一堆真实的问题，让AI去修复，看能不能修好。去年各家公布的分数从40%一路涨到了80%，听起来进步神速。发布会上的PPT一页比一页漂亮，友商对比图一个比一个夸张。

但问题来了——OpenAI前几天发了一篇研究，直接把这块遮羞布给掀了。

第一层问题：题目本身就不干净

OpenAI先找了一批人类工程师来审计那些AI没做出来的题目，结果发现：59.4%的”失败”案例，根本不是AI能力的问题，而是题目设计本身就有问题。

举两个具体的例子。

第一个来自pylint项目。题目的要求是”修复这个bug”，但测试代码里导入了一个叫get_annotation的函数——这个函数名在整个题目描述里压根没提。AI就算把bug修的天衣无缝，只要没用这个特定函数名，测试直接报ImportError失败。这不是能力测试，这是”考驾照的时候让你把车倒进一个指定宽度的车位，但你不知道那个车位宽度是2.01米还是2.02米”的问题。

第二个来自sympy项目。题目描述只要求修一个问题，但配套测试覆盖了三个问题。AI把描述里提到那个修好了，剩下两个没修，测试照样挂。你做了一个建筑师的工作，交出去的卷子被按结构工程师的标准批。

这不是在测试AI会不会编程，这是在测试AI会不会读心术。

第二层问题：数据污染让分数彻底失真

但这还不是最离谱的。

OpenAI又做了个实验：他们训练了一个专门的GPT-5模型，专门用来探测其他模型有没有在训练时见过这些题目。结果发现，GPT-5.2、Claude Opus 4.5、Gemini 3 Flash Preview——这些被称作”前沿模型”的选手，全都能一字不差地复现出原始bug fix的具体实现细节，包括那些题目描述里根本没提的实现方式。

这意味着什么？

这些数据早就被塞进训练集里了。所有模型都在一定程度上”见过”这些题目。所谓的SOTA分数，有多少是真正理解了编程，有多少只是”背题”的结果，现在根本说不清。就像某考前真题突然泄露了，所有考生都背过答案，这时候你没法通过考试成绩来判断谁真的懂、谁只是背功好。

所以OpenAI宣布：以后不再报SWE-bench的分数了，建议其他厂商也别报了。

模型分数，到底测的是什么？

要理解这件事的深层含义，先要把”模型分数”和”模型能力”这两个概念分开。

模型在 benchmark 上拿到的分数，本质上测的是这样一件事：在给定一个经过清洗的、有标准答案的、上下文完整的问题之后，模型能不能生成一段符合预期的代码。这是一种非常特殊的任务形态——有明确的输入，有明确的输出，有明确的评判标准，失败了也不会有任何后果。

但真实的编程工作是这样的吗？

真实编程的第一个特点是模糊性。产品经理跟你说”这个流程要优化一下”，没有标准答案，没有边界条件，你需要自己去问清楚、去理解业务、去判断什么叫”优化”。benchmark上每一道题都是被精确描述的问题，而真实世界里的问题往往连问题本身都没定义清楚。

真实编程的第二个特点是上下文依赖。你需要理解这个函数在整个代码库里的角色，理解这次修改会影响哪些模块，理解为什么当初要这样设计而不是那样设计。模型在处理单个函数的时候可能很强，但让它去理解一个20万行的遗留代码库，它可能完全摸不着头脑。

真实编程的第三个特点是后果真实。benchmark答错了，屏幕上显示个红色报错，大不了重来。生产环境里写错一行SQL，可能删掉三亿条用户数据。真实工作里每一次提交都有代价，而模型并不天然理解代价这个概念。

所以很多有经验的工程师会告诉你一个反直觉的感受：模型在benchmark上的分数越高，有时候反而越容易让人误判它的真实能力。分数越漂亮，期待越高，拿去用在真实任务上一旦出问题，心理落差越大。

什么是”驾驭工程”？为什么它比分数重要？

到这里，终于可以聊今天真正想说的核心观点了。

“模型能跑分”和”模型能干活”，中间隔着一整套东西，我把它叫做”驾驭工程”。

什么是驾驭工程？

就是让一个能力很强的模型，真正变成一个能在生产环境里替你干活的东西，需要解决的那些工程问题。包括但不限于：

任务边界控制。模型天然倾向于”多做”而不是”少做”。你让它修复一个bug，它可能会顺手重构半个代码库。你让它迁移数据，它可能直接清空整个表。驾驭工程要做的事情，是把模型的行动边界锁死，让它只在授权范围内行动，超出边界的行为要么被阻止，要么在执行前停下来等人类确认。

反馈与纠正机制。模型会犯错，任何系统都会犯错。区别在于，有没有机制让模型知道自己错了，有没有路径让人类把纠正信号反馈进去。真正的生产系统不是”发出指令等结果”，而是”发出指令→验证结果→必要时回滚→持续监控”的闭环。

容错与兜底设计。当模型执行一个高风险操作时，系统有没有准备好在最坏情况下止损？AI说要把表删了，有没有备份？AI说要改线上配置，有没有灰度机制？驾驭工程的核心就是把模型当成一个”能力很强但也可能犯浑”的员工来设计系统。

意图理解与澄清。当任务描述模糊的时候，系统有没有能力主动提问而不是自行脑补？当模型不确定的时候，有没有机制让它暂停并寻求确认而不是随便选一个方向冲？

你去看那些在生产环境里稳定运行AI编程工具的团队，往往不是选了个分数最高的模型，而是在驾驭工程上做了大量投入。他们花时间设计prompt框架、花时间写角色约束、花时间搭审批流程、花时间测试边界情况。这些工作不会出现在任何 benchmark 里，不会被写进发布会 PPT，也不会出现在媒体测评里。但它才是决定这个工具能不能真正用起来的分水岭。

所以，看测评分数还有意义吗？

说了这么多，不是说 benchmark 分数完全没用。

分数有一个很有限但确实存在的价值：它至少证明了模型的底层能力有到达某个门槛。80分的模型，基础能力肯定比40分的模型强。SWE-bench上拿不到基本分数的模型，大概率在真实的代码任务上也好不到哪去。

但分数能告诉你的就到这里了。接下来的问题是：这个模型配上足够的驾驭工程之后，在你的具体场景里能发挥多少作用？这个问题没有任何 benchmark 能回答。

OpenAI那篇文章最大的价值，不是证明了什么，而是承认了什么：他们愿意公开说”我们之前用的那个标准已经不能反映真实能力了”。这种坦诚在AI行业里不多见——毕竟过去两年，几乎每家厂商都在用这个基准来证明自己领先。

但承认了之后呢？接下来用什么标准？

目前来看，没有一个真正令人信服的替代方案。SWE-bench Pro？各家自己的测试集？还是”内部评估”？新旧标准青黄不接的阶段，各家说什么就是什么。

作为使用者，我的建议是：保持怀疑，用自己的项目验证，别被数字带走了。

就像买钻头，重要的不是它能穿透多厚的钢板，而是能不能在你想打孔的那面墙上打出孔来。

能打几分不重要，能干活才重要。