速评：10 月 9 号 14 点 37 分挂上 arXiv 的 CRBugBench，测的是审查智能体能不能从仓库历史里把人工确认过的缺陷挖出来。
会被人截图到处转发的那行数字，恰恰是这篇论文里最不该单独拎出来的一行。
先看数字。最好的组合是 claude-opus-5 配 copilot-cli，它给的前 5 条评论里抓到 71.9% 的缺陷；同一个指标，五个月前是 47.7%。五个月，涨了一半。谁看了不心动。
问题是这 71.9% 考的什么题。基准是这么造的：先从仓库历史里挖出一个被人工确认的缺陷，再把当初引入它的那个 PR 配上，凑成一道审查题——公共仓库 98 个 repo 出 1000 道，另有一家公司的私有仓库出 800 道。也就是说，智能体拿到的每个 PR 里，都埋着一个已知的、有标准答案的雷。
真实审查不长这样。真实审查里没人告诉你这个 PR 有没有问题，你得先判断"要不要多看一眼"——那一步才最吞时间。
我知道有人要说基准本来就该这么造，逐条人工确认已经比市面上那些拼凑出来的强。这点我认。但它的结论只能读成：给定一个已知存在缺陷的变更，模型有七成概率能找到。到"审查可以交给智能体了"之间，差的距离比看起来远。
真正让我坐直身子的是结果那节里的另外两个数。
一个是私有仓库上的性能明显往下掉。公开仓库还行，换成别人家内部仓库、800 个任务，就开始掉链子。作者的解释是这类场景更依赖项目上下文——翻译成人话：公开仓库那批代码，模型在你之前大概率已经读过了；私有的它只能靠你现场喂。我不敢说这就叫数据污染，也可能是上下文窗口和仓库规模的事，但不管哪一种，结论都指向同一个地方：它最擅长的，是它见过的东西。
另一个是能力边界画得相当清楚——复杂变更、需要跨文件非局部推理的缺陷，效果差。这两类恰好是最贵的那批 bug。一眼能看穿的它替你挡掉了，剩下那堆要老命的还回你桌上。省下来的确实是人力，但省的是哪一段，得看明白。
还有个细节不会有人写进通稿：跑出这套最好成绩的组合，是一个 Anthropic 的模型塞在别家的命令行里。模型、工具、基准三样谁也没跟谁绑死。现在谈全家桶、谈一站式，早了。
顺便说个能直接抄的。作者试过加算力，最后发现最有效的杠杆是改提示词——引导式提示在成本多一成的情况下换来最多 5.8%。加显卡不如加一句"这个仓库最看重什么"。这句对做产品的人，比那 71.9% 有用得多。
拉回来。47.7 到 71.9 不是通稿编的，是基准跑出来的，五个月翻半这件事，我不能因为它是个 benchmark 就一笔抹掉。半年前干不了的活，现在能干一部分，这条我认。
立个 flag：半年之内，会有人写复盘，说自家团队太早把 review 的最后一关交了出去，漏的那个 bug 恰好属于要跨文件推理的那一类。不是模型不行，是没人告诉过它这个仓库的来龙去脉。谁先把"喂仓库知识"当成一等公民、而不是提示词里的补丁，谁才真能少加几个班。
灯能关掉一部分，这个我信。但不是现在这个亮度的模型能关的。至于剩下那 28%——截图转发的时候，谁负责接？