原帖把这份成绩单的骨架搭得挺准，但 83% 那把尺子我拆开看了一遍，有几处对不上。
一、83% 的尺子握在发卷人手里
原帖已经点出「判定标准握在发布方手里」，这句不是空的，它有一个数。METR 2026 年 3 月 10 日的报告：4 位来自 scikit-learn、Sphinx、pytest 的在职维护者，盲评 296 个通过了 SWE-bench Verified 自动判定的 AI 补丁，接受率比自动判定低 24.2 个百分点（标准误 2.7）。他们还做了一组对照，把 47 个人类写的、已经合并进主干的 PR 混进去 —— 这批「黄金补丁」自己也只有 68% 被接受，说明审查本身就有主观成分，不是说 AI 一定差。
另一条口径更贴近这次的题目形态：MSR 2026 那篇分析 33,596 个 agent 提交的 GitHub PR，实际合并 24,014 个，71.48%。
所以「可合并」和「已合并」中间那段距离，行业里已经量过了 —— 大约二十几个百分点。它没写进这份成绩单而已。
二、「隔离官方补丁」清的是仓库，清不掉权重
这是我最想问的一条。York 大学那篇 SWE-Bench+（arXiv 2410.06992）把每一个被判定「成功」的补丁手工翻了一遍：32.67% 是答案直接写在 issue 正文或评论里，模型是在抄自己提示词里的剧透；另外 31.08% 是因为测试太弱、错的补丁也能蒙绿。把这两类剔干净、再换到知识截止之后的新题上，同一套系统从 12.47% → 3.97% → 0.55%。
背景数据：SWE-bench 里 94% 以上的题目创建时间早于当时主流模型的知识截止。2026 年 2 月 23 日，OpenAI 宣布停报 SWE-bench Verified，理由之一就是前沿模型能几乎逐字背出人类写的 gold patch。
Luanti 是公开仓库，修复补丁在公开的 git 历史里。把补丁从本地工作区剔掉，剔不掉它在权重里的那一份。所以真正需要交代的是这 1000 个 Issue 的时间分布，以及做没做过时间切分或仓库级去污染。官方口径里一个字都没有。
再补一层选择偏差：Luanti 的 issue 跟踪器现在挂着 1,511 个 open issue（我今天用 GitHub API 拉的）。这份考卷的准入条件是「有官方补丁可剔」，也就是说能进卷的都是已经被人类解决过的问题。「还开着」的那一整类难题，从一开始就不在卷面上。
三、原帖那组仓库数字对不上
我今天直接拉了 luanti-org/luanti 的真实数据：
| 指标 | 原帖 | GitHub API 实测 |
|---|---|---|
| 默认分支可达提交 | 18,726 | 13,754 |
| 贡献者 | 1,441 | 1,256（含匿名邮箱） |
| 仓库创建 | 2010-11 起算 | 2011-08-07 |
| 2025-03 ~ 2026-03 提交 | 1,254 | 835 |
git shortlog 的 name-email 去重、含 merge 提交，这些口径能差出这个量级，而且 1,441 > GitHub 的 1,256 恰好符合「用 shortlog 数邮件对」的特征。但口径必须写出来，否则读者会把它当 GitHub 官方计数读。四、100 人年算得对，但它是最保守的一档
自己算一遍。COCOMO 81 基本模型 organic 档：E = 2.4 × KLOC^1.05。378.373 KLOC 代进去，378.373^1.05 = 509.0，乘 2.4 得 1,221.6 人月 ≈ 102 人年。原帖的「约 100 人年」对得上。
换个档位就散了：semi-detached（3.0 × KLOC^1.12）是 193 人年，embedded（3.6 × KLOC^1.20）是 372 人年。同一个仓库、同一份代码，差 3.6 倍。
还有一层原帖没交代：Luanti 树内 vendored 了 Irrlicht（irr/）和 Lua（lib/）。这两个目录算不算进 378,373 行，直接决定 COCOMO 的结果。仓库体积 141 MB，显然不只有自研代码。
五、官方自己公布的抗污染基准上，它并不领先
Seed 官方项目页给 Seed-2.1-Pro 自报的数：SWE-Pro 57.5（Claude Opus 4.7 = 64.3，GPT-5.5 = 58.6）；Terminal Bench 2.1 = 71.0（Opus 4.7 = 71.7，GPT-5.5 = 73.8）。
一边是自家判定的 83%，一边是自家公布的公开基准 57.5。两个数不矛盾，但它们是两把尺子，不能叠着读 —— 也不该拿来跟 SWE-bench Verified 上那批 95%+ 的分数比。
六、原帖落下的一组案例更说明问题
官方同一批材料里还有一组更贴「长程」这两个字的：Tiny NPU Tile 的 RTL 设计（16×16 PE），连续跑了近 18 小时、9 轮迭代，交出 6 个核心模块、1303 行 RTL，跑通仿真、测试、综合检查完整流程。官方说同等工作量通常要 3–5 名资深工程师做数周。另外还有 3D 城市：500+ 子 Agent、100+ 栋建筑。
比 ERP 那组更能说明「长程」到底长在哪 —— 因为 RTL 有综合和仿真当硬判定，比「页面能跑」可验证得多。
七、几处出处要分清
「13 个业务模块」「3 个移动端页面约 2000 行」「约 2 小时」「正确率提升 31%」这四处，我在火山引擎官方公告正文里都没找到，只在二级日报里出现。官方原文写的是「1000 个真实历史 Issue」「近 36 小时」「83% 达到可合并标准」「28 万行 Java ERP」。
不是说日报写错了，是说这几个数目前只有一个来源。引用的时候最好带上这一层。
下一根钉子
三件事，按能验证的顺序排：
① 这 1000 个 Issue 的时间分布。只要有一批落在 Seed-2.1-Pro 的知识截止之前，83% 就得打折读。这是唯一能一刀切干净的检查。
② 那 17% 的失败分布。官方说覆盖渲染、网络、物理等 13 个模块，但没说失败集中在哪。如果失败全挤在物理机制这类需要跑仿真的模块，那结论就变成「能验证的修得好，要跑起来才知道的修不了」。
③ 有没有人把这 1000 题做成可复现的公开集合。没有它，83% 永远是单向成绩单，不是基准。原帖最后那句话我完全同意：只有成功率的成绩单，和一份带失败样本的复盘，价值差一个量级。
#AIAgent #软件工程 #基准评测