Senior SWE-Bench：最强模型也只干完四分之一的活
最强的那个模型，也只能干完四分之一的活。
我说的是 Claude Opus 4.8，开到 max 档，在一个刚放出来的新基准上，解题率 24.0%。第二名 Sonnet 5，19.4%。GPT-5.5 开到 xhigh，16.0%。再往下 GLM-5.2 12.5%、Kimi K2.6 8.2%，Gemini 3.5 Flash 最惨，3.0%。
这榜单叫 Senior SWE-Bench，Snorkel AI 上周放出来的。我盯着那张排行榜看了好一会儿，脑子里就一个念头，怎么忽然全都这么低了。
要知道在老的 SWE-Bench 那套题上，各家模型早就卷到七八十分了，天天有人发推「又刷新了 SOTA」。结果换一套题，直接从八十几掉到二十几。同一批模型，同一个礼拜，分数腰斩再腰斩。
不是模型退步了。是这套题，第一次开始按「高级工程师」的标准来考它们。
坦率讲，这件事戳到我了。因为我平时干的活，就是给这些模型搭能真正干活的那层工程，agent 的工具链、评测、调度、上下文管理，行话叫 harness，说人话就是给大模型搭脚手架，让它别光会聊天、能真的把事办完。天天看这些 agent 在生产环境里怎么跑怎么翻车，所以我对「评测」这两个字特别敏感。一个评测题出得好不好，直接决定了你对这玩意的能力判断是不是幻觉。
而 Senior SWE-Bench 提的那个问题，恰好是我一直觉得别扭、但没人正面戳破的一件事。
我们早就把 AI 当高级工程师用了，却一直在拿初级工程师的卷子考它。
你想想看现在大家是怎么用 agent 的。Slack 里甩一句「帮我把导入那块加个 Google Books 兜底」，GitHub issue 底下 @一下 Claude，命令行敲半句话就让它去跑。没有需求文档，没有验收标准，没有一二三四五。我们默认它像个资深同事，能自己领会意图、自己做技术设计、自己去把犄角旮旯的运行时 bug 刨出来，然后交出一份能直接 merge 的活。这就是高级工程师的日常。
可你去翻现有的那些代码基准，全反过来。指令写得密不透风，恨不得把每个函数签名、每个边界条件、每个要改的文件都列给你。为啥？因为它得配一套预先写死的测试来判对错，指令越具体，测试越好写。于是模型拿到的题，长得根本不像你半夜在 Slack 上随手扔的那句话，倒像一份甲方爸爸给的三十页 PRD。
Senior SWE-Bench 官方那句吐槽我觉得特别准，我们把 agent 当高级工程师，为什么却像考初级工程师一样评它。
它到底换了什么考法
先说题从哪来。这批题全部取自 2026 年 2 月之后、真实合并进主干的 PR，开源仓库里捞的。为什么卡在 2 月之后，防污染，别让题目早就躺在模型训练数据里。而且大部分题背后那个 PR，作者都是在该仓库提交过 100 次以上的人，很多干脆就是 maintainer 本人。也就是说，出卷子的是这个项目里最懂行的那几个老炮，不是随便找的水题。首发 100 道，其中 50 道藏起来不公开，专门防刷榜。这套设计 Snorkel 在 how-it-works 那篇博客里写得很细，感兴趣可以去啃。
题分两大类，名字起得挺实在。一类叫 Design-and-Build，设计并实现，考的是在需求不完整的情况下你自己把一个 feature 长出来。另一类叫 Investigate-and-Fix，排查并修复，考的是从一份模糊的行为报告出发，自己启服务、看日志、翻 profiling，把一个藏得很深的运行时 bug 揪出来。
我特意去看了道样例题。是给一个叫 BookWorm 的图书元数据项目加个 Google Books 兜底源，原来只有 Amazon 和 ISBNdb，遇到只有 ISBN-13 的书就抓瞎。这题的指令长啥样？它不是「请在 imports.py 的第 47 行的 STAGED_SOURCES 里加上 google_books 字符串」，那才是喂饭。它给的是一段像产品同事写的东西，讲清楚现在的痛点是导入质量差、占位条目多，讲清楚为什么值得做、成功长什么样，然后一句「去把它实现了」。至于要动哪些文件、注册到哪个框架、怎么处理找不到和找到多个的情况，自己领会去。
这就对了。这才是资深工程师每天收到的东西。
官方给了组数字我觉得挺能说明问题。Senior SWE-Bench 题目的指令长度中位数，只有 SWE-Bench Pro 的 31%。指令短了三分之二，但活一点没变少，一道 feature 任务平均要动 11 个文件，横跨好几个服务层，最强的 agent 也得几百步才能磨完。信息给得更少，要走的路更长。这一下就把「照着说明书填空」和「自己想清楚该干嘛」这两种能力分开了。
最有意思的是它怎么判分
这块我觉得是整个基准最有点子牛逼的地方。
老办法判对错就靠预先写死的测试脚本，pytest 跑一遍，绿了就算过。但问题来了，你指令都故意写得不具体了，模型交上来的方案可能千奇百怪，你预先写的那套测试根本框不住。人家换了个函数名、挪了个接口，你的测试直接报错，可人家的实现明明是对的。
Senior SWE-Bench 塞了四种打分机制进去，我一个个说。
第一种就是老朋友，预写 verifier，提前写好的行为测试，管那些接口不会变的部分。
第二种叫 validation agent，我觉得这个设计是真骚。它是一个专门的 agent，等你把方案交上来之后，它现场读你的代码，然后照着专家设计好的一套配方，临时写出一批能适配你这个具体实现的行为测试来。你接口改了？它跟着你的接口来测。这就绕开了「指令要真实 vs 判分要可靠」那个老矛盾，既让题目可以像真人说话那样含糊，又能在运行时真刀真枪验代码。
第三种是 rubric judge，任务级的评分细则，交给 LLM 当裁判打。那些没法在运行时跑出来的要求，比如跟某个外部服务集成，就走这条。
第四种是我最想聊的，taste judge，品味裁判。一个全局的代码质量评审 agent，专门看你写的代码「有没有品」。
为什么要单独搞个品味裁判？这里得请出 METR 那篇让不少人破防的文章，《很多能过 SWE-bench 的 PR，根本不会被 merge 进主干》。标题就是结论。测试全绿，不代表这段代码你敢往生产上合。可能它硬编码了一堆魔法值，可能它绕过了整个项目都在用的鉴权框架自己另起炉灶，可能它写得又臭又长，测试是过了，但任何一个 reviewer 看一眼都得打回来。
我干这行天天看这个。一段代码能不能跑，和一段代码你愿不愿意让它进你的 codebase，是两码事。前者是及格线，后者才是资深和新手的分水岭。
Cognition 也注意到了这事，他们前阵子出的 FrontierCode 就是让仓库 maintainer 亲手为每道题写详细的质量评分细则。Senior SWE-Bench 走了条更省力的路，用一个全局的品味裁判，靠观察和对比来给代码质量打分，牺牲一点单题的精细度，换一个能套到任何题上的通用机制。
品味这件事，它拆得比我想的细
我原本以为「品味」这种东西太玄，没法量化。看完它怎么切我服了。
它把「一段代码该不该这么写」分成了三档，判分时区别对待。
第一档叫 load-bearing practice，承重实践。就是这个 codebase 里又强又一致、直接影响功能的模式。比方说你加一个新的 API 端点，这个项目所有端点都注册在同一个鉴权框架下，你不接进去就是错，这种没商量。这一档是硬要求，测试里必须过。
第二档叫 general best practice，通用最佳实践。任何一个资深工程师看了都觉得该这么做、且没有别的合理选择。经典例子，一个会返回无界集合的列表接口，你必须做分页或者封顶，不然迟早被人拖库拖崩。这也是硬的。
第三档叫 preference，偏好。就是那种「这么写也行那么写也行」的风格问题。这一档它特意不设成一票否决，走 rubric 打分，扣点分但不判你死刑。
我特别欣赏这个分层。因为现实里最容易吵架的就是这个边界，到底哪些是「你必须这么做」，哪些只是「我个人喜欢这么做」。很多 code review 撕起来没完，就是因为 reviewer 把自己的 preference 当成了 load-bearing 的铁律硬压。Senior SWE-Bench 把这条线画出来，还专门去分析 agent 的解题轨迹，看有没有出现「判分不公」，就是那种其实是偏好、却被当成硬要求卡掉的情况，发现了就回去改题。这份克制，比那个分数本身更让我觉得靠谱。
说真的，这套东西设计到这个份上，已经不只是在考模型了。它其实是在逼着我们把「什么才叫资深工程师的活」这个一直模模糊糊的东西，一条一条写清楚。
所以那个 24% 到底意味着什么
绕回到开头那张榜。
我一开始的反应是「怎么这么低」，后来越想越觉得，这个低，反而让我踏实。
这半年你听了多少「程序员要被取代了」的论调。数据也确实唬人，各家都在秀 AI 写代码的比例又涨了多少倍。可那些数字大多建立在初级卷子上，需求给全、只测对错、跑绿就算赢。在那套标准下，模型确实像个能顶半个团队的超人。
Senior SWE-Bench 把卷子换成资深工程师每天真实收到的活，超人当场现原形。最强的 Opus 4.8 全力开到 max，也只能体面地干完四分之一。剩下四分之三，卡在哪了？卡在没人把需求喂到嘴边的时候不知道自己该干嘛，卡在 bug 藏在运行时得自己一层层扒开的时候扒不动，卡在代码能跑但一看就不像出自一个有品味的人之手。
这三样，恰好是我们平时嘴上最爱说、心里最看重的资深能力。也恰好是模型现在最露怯的地方。
我不觉得这是给 AI 泼冷水，我觉得这是把标尺终于摆正了。当榜单从 80 分掉回 24 分，那 76 分的差距不是坏消息，那是还没被自动化掉的、属于人的那部分手艺，被诚实地量出来了。
我一个做脚手架的，天天想的就是怎么把模型这最后几十分的能力一点点撑起来。以前撑得有点心虚，因为不知道差在哪，评测告诉你 80 分了你还较什么劲。现在好了，Senior SWE-Bench 把「差在哪」摆得明明白白，就仨词，需求理解、运行时排查、代码品味。这三个词，就是接下来我们这些搭脚手架的人要死磕的方向。
有个数字我一直记着。这批题里，一半的仓库是最近五年才起的项目，官方说这是故意的，为了逮住那些迭代更快、技术栈更新的真实场景。你看，连出题的人都在追着当下跑，生怕题目离真实工程太远。
评测这东西，说到底是一面镜子。镜子照不出你想看的样子没关系，可怕的是镜子本身是哈哈镜，把你照得又高又胖，你还美滋滋。过去那些刷到八十分的榜，多少有点哈哈镜的意思。Senior SWE-Bench 至少是块平的。
24% 不好看。但我宁可要一个照得难看的真镜子。
毕竟，是谁来自山川湖海，却囿于昼夜厨房与爱。我们造的这些 agent，眼下也一样，能上天入地聊遍古今，真让它安安静静把一个没写清楚的活漂亮地做完，它还差得远。
差得远，才有得搞。挺好。