很多人最近看 AI 编程圈的新闻已经有点恍惚了。今天这个模型在 SWE-Bench 上破纪录明天那个 Agent 在某个榜单上又刷新分数后天再来一篇“首次超越资深工程师”的传播稿。看多了你会产生一种错觉AI 编程这事是不是已经差不多成熟了剩下只是价格和速度问题。但偏偏这几周一个挺有意思的信号出来了连 OpenAI 自己都开始下场拆评测公开说一些热门 coding benchmark 里的任务本身就有缺陷噪声没有大家想的那么小。这个动作很说明问题。因为当一家本来最容易吃到“榜单红利”的公司反过来开始讲“别太迷信分数”基本就意味着行业已经被跑分叙事带偏了一段时间。我自己的判断很直接今天很多 AI 编程评测测出来的不是“谁最会干活”而是“谁最会参加这场考试”。这不是说 benchmark 没用而是它越来越像体育里的体测数据。能看重要但你不能拿 100 米成绩直接等同于整赛季表现。先说结论评测没有失效失效的是大家对评测的想象很多讨论一上来就走两个极端。一种人说benchmark 都是刷榜没意义。另一种人说既然榜单第一都出来了那说明模型能力已经足够替代大部分开发工作。这两种看法都太省事了。benchmark 当然有用。没有统一评测行业连最基本的横向比较都做不了。问题在于今天大家默认的那种“单一分数崇拜”已经越来越不适合 Agent 时代了。你测一个模型会不会解题和你测一个 Agent 能不能进项目、读代码、调工具、改完不炸、失败了还能回滚这根本不是一回事。模型能力像发动机真实交付更像整车。发动机马力大当然是好事但方向盘、刹车、底盘、轮胎、驾驶员和路况也都决定这车能不能真上路。这也是为什么 Anthropic 最近反复在讲一件事真正有效的 Agent往往不是靠特别花哨的框架而是靠简单、稳定、可验证的工作流。Lilian Weng 这周写 harness engineering也是在说同一件事。模型本身固然重要但模型外面那层流程、工具、状态管理、权限控制、验证机制已经开始和模型本体一样重要了。为什么今天的 AI 编程评测越来越容易“像表演”这个问题不是某一个榜单做得差而是整个赛道都天然会往那个方向滑。1. Benchmark 测的是封闭题真实开发做的是开放题SWE-Bench 这类评测本质上还是把复杂软件工程问题压缩成一个相对封闭的任务给你仓库、给你 issue、给你测试最后看过没过。这当然比早期那些算法题、LeetCode 风格评测强太多了但它依然有个边界它默认“问题定义”这件事是清楚的。现实里最费时间的部分恰恰不是改代码而是搞清楚到底该改什么。产品描述不完整需求口径在变历史包袱一层套一层相关模块不止一个 owner日志还不一定全。很多时候人类工程师最值钱的地方不是因为他能写出那十几行 patch而是他知道该先问谁、该先看哪段历史、该怎么把一个模糊问题收束成能执行的问题。这个能力benchmark 很难完整测出来。2. 评测天然奖励“最会过测试的人”只要评测目标是“通过测试”参赛系统就一定会朝“更擅长过测试”的方向优化。这听起来像废话但后果很大。因为“过测试”不总等于“改对了”。OpenAI 这次重审 SWE-Bench Pro核心就在这里。他们公开提到一批任务本身存在问题比如测试过严、描述不足、覆盖不完整、暗示性太强甚至会把不够合理的解法也算成通过。换句话说有些高分并不一定代表更强的工程能力只代表更懂这套题库的脾气。这件事放到任何考试制度里都成立。你给一群人固定题型、固定判分器、足够长的优化周期最后一定会出现“应试能力”强于“泛化能力”的系统。AI 也一样。3. 排行榜看起来在比模型实际上常常在比 harness这是今年最值得行业正视的变化。很多传播稿还在用一种老脑回路看 AIA 模型 64 分B 模型 58 分所以 A 比 B 强。实际情况已经没这么简单了。今天不少 Agent 系统的差异早就不只在模型参数而在外层那圈东西仓库检索怎么做、上下文怎么裁剪、失败后是否重试、工具调用顺序怎么排、是否有 verifier、是否有 reviewer、测试失败后会不会换路径、遇到歧义时是硬做还是先澄清。这些能力看起来不像“模型智商”却非常决定最后交付效果。说得再直白一点排行榜很多时候测出来的是“这家公司把 Agent 系统工程做到了什么程度”而不是“这个模型裸奔有多强”。所以你看到某些系统分数突然跳很大先别急着神化模型升级。更常见的情况是它把工具链、搜索策略、记忆裁剪、验证闭环这些脏活累活做顺了。4. 真正难的不是首轮命中而是连续稳定很多 demo 的迷惑性也在这里。一条很顺的 case录个屏确实很容易让人上头。尤其是 AI 编程这种东西只要它连续做对三四步人脑就会自动脑补后面也都能行。但工程现场的难点从来不是“它能不能秀一次”而是第 7 次还能不能稳仓库变大以后还能不能稳加上多人协作以后还能不能稳遇到历史屎山、隐式依赖、环境漂移以后还能不能稳这也是为什么我一直觉得单次任务成功率很重要但远远不够。更该看的是跨任务分布、失败类型、恢复能力以及在真实仓库里的波动范围。这些指标今天公开榜单大多还没讲清楚。为什么这件事跟普通团队也有关系很多人会觉得我又不做模型评测benchmark 失真跟我有啥关系关系其实非常大。因为你买工具、选模型、做工作流、向老板汇报、甚至决定要不要上 Agent参考的往往就是这些“看起来很硬”的分数和榜单。一旦你把榜单当成交付能力后面整个决策链都会偏。比如一个团队看到某个系统在榜单上暴涨就以为它适合马上接入生产。结果真正落地时发现代码 patch 写得不差但读仓库慢、上下文容易丢、工具调用不稳、review 机制也没有最后工程师花在兜底和返工上的时间可能比自己先写还多。再比如视觉工作流里也有同样的事。你看某个模型在“审美”“质感”“拟真”上特别能打不代表它就自动适合你的生产链。真到交付环节还要看它的稳定性、风格一致性、可控性、接口接入体验以及能不能和你现有工作流顺起来。像 iMini 这种聚合平台价值往往不是“替你宣布谁第一”而是让你在同一个入口里快速切模型、切任务再用自己的场景去验证谁更适合真正干活。这才是实战视角不是榜单视角。那我们现在到底该怎么看 AI 编程评测我的建议是别再问“哪个分最高”改问下面这四件事。第一看它测的是模型还是系统如果一篇文章只告诉你最终分数不告诉你有没有检索、有没有外部工具、有没有 reviewer、有没有多轮重试那这个分数的信息量其实很有限。因为你根本不知道自己在比较什么。你以为在比模型实际可能在比工作流工程。第二看它测的是单点能力还是完整交付链会改 bug、会补测试、会读 issue、会搜代码、会用终端、会回滚错误这些都重要。但把这些能力串成一条稳定链路更重要。单点很强不代表整链可用。第三看它有没有披露失败方式真正有参考价值的评测不只是告诉你赢了多少还得告诉你怎么输的。它是输在找不到文件输在误解需求输在只改表层没改根因还是输在测试过了但实现很脆没有失败画像的高分只能算宣传材料算不上工程材料。第四看它和你的任务分布像不像这是最容易被忽略的一条。你团队主要是前端、小程序、增长实验、数据脚本还是大型后端仓库、基础设施、SDK、CI/CD不同任务分布对 Agent 的要求差别巨大。一个系统在公开 benchmark 上表现优秀不代表它在你自己的任务篮子里同样优秀。真正靠谱的做法一直都是“公开榜单看方向私有样本做决策”。接下来会发生什么我觉得后面半年AI 编程这条线会越来越像自动驾驶而不是像跑分软件。大家会慢慢意识到真正决定可用性的不是某次榜单冲到多少分而是这套系统能不能在复杂环境里持续、低波动地完成任务。到那个阶段行业讨论重点也会跟着变从“谁分更高”转向“谁更稳”从“谁最聪明”转向“谁最可控”从“谁 demo 最惊艳”转向“谁真能进团队流程”这时候 benchmark 不会消失但它会回到一个更正常的位置它是仪表盘不是方向盘。最后一句如果你现在还在看 AI 编程工具当然可以看榜单但别把榜单当答案。更现实的做法是把它当筛选器先用 benchmark 排除明显不行的再用你自己的任务、仓库、协作链路去做二次验证。谁能在你的真实环境里少翻车、少返工、少让人盯着收尾谁才更接近“能用”。说到底软件工程不是考试生产环境也不是考场。AI 现在最缺的已经不只是更高的分数了而是更诚实的评测方式。
