打开 Snorkel AI 新发布的 Senior SWE-Bench 网站，点开第一道任务，看到的不是"修一个 bug"这种熟悉的 SWE-bench 题型，而是一份完整的 GitHub 需求文档：给开源图书数据库 Open Library 的 BookWorm 导入系统，加一个 Google Books 作为元数据兜底来源。要求跨 5 个文件改动、新增至少 4 个函数接口，还得自己想清楚"同一个 ISBN 查出多个结果该怎么办"这种需求里没写明的边界情况。
这不是记者随手摘的示例，这就是该基准 100 道真实任务里的一道。它想说明的问题很直接：能通过传统 SWE-bench 的 AI，未必真的会当资深工程师。而目前，还没有任何一家模型厂商公布过在这套题上的分数——这才是最值得盯的悬念。
一道题里藏着的"资深"标准
传统 SWE-bench 的题目大多是：给一个已知的 GitHub issue，改一个文件，跑一个现成的测试用例，过了就算通过。BookWorm 这道题不一样：需求原文只说"元数据缺失或不完整"，具体要拆成哪些字段、哪些接口、哪种降级逻辑，全靠工程师自己判断。
更关键的是防御性编码那一条——如果 Google Books 对同一个 ISBN 返回多个匹配结果，正确做法不是硬导入，而是记录警告并跳过。这种"知道什么时候不该动手"的克制，恰恰是传统基准从来没考过的东西。
打分看的不是"过没过"，是"像不像老手写的"
Senior SWE-Bench 的 100 道任务里，50 道是私有集，用来降低训练数据污染的风险；题目全部来自 12 个开源项目的真实 PR。评分机制引入了一个"验证代理"，按专家写好的 recipe 生成行为测试，专门针对被测方案量身定制，而不是套用现成用例。
核心指标叫"tasteful solve"，不只看代码跑没跑通，还看写法是否符合代码库的既有惯例——说白了就是有没有"代码品味"。这一层判断依赖人工复核，官方目前没有公布评审员之间的一致性数据，这是个空白。
历史教训：更难的题，不等于更难刷
SWE-bench 系列走到今天已经有 Full、Lite、Verified 等好几个版本，头部模型的分数一路刷新，业界开始怀疑这套题是不是已经被"刷题式"攻克了。Senior SWE-Bench 想解决的正是这个信任危机，但它自己也绕不开一个老问题：评测方法本身能不能左右分数。
2024 年 8 月 OpenAI 发布 SWE-bench Verified 时，GPT-4o 拿到 33.2% 的分数，几乎是它在原始 SWE-bench Full 上约 16% 分数的两倍。同一个模型，翻倍的成绩几乎全部来自更优的 agent 脚手架，而不是模型本身变强了。
更难的题，考验的可能是脚手架的工程能力，未必是模型本身的智能。
Senior SWE-Bench 目前没有公开排行榜分数，也就没法验证它是否对"脚手架套利"做了约束。如果没有，历史大概率会重演。
谁在等这份考卷开分
对 agent 厂商来说，这道题是个证明自己不只会"刷传统基准"的机会，但没人愿意第一个交出可能难看的成绩单。企业买家更关心这套评测能不能真正反映生产环境里的表现，决定要不要拿它调整采购和试点标准。开源项目维护者的处境则有点尴尬——BookWorm 所属的 Open Library 项目，其真实 PR 被直接拿来当考题，代码库变成了别人的模拟考场。
- 风险.taste 评分依赖专家主观判断，官方尚未披露评审员之间的一致性数据，评分本身的可信度还没被验证过。
- 结论.现在唯一确定的事，是还没有一份公开成绩单——这段空白期，恰恰是判断这套基准是否真的更难被刷高的观察窗口。
接下来最该盯的信号是：第一批公开跑分什么时候出现、私有的 50 道题会不会像老 SWE-bench 一样在几个月内被攻克、以及厂商们会不会为了刷这套新题，又造出一套新的脚手架。