我把一段内核代码喂进去，问它：这个输入会不会让系统崩。
它回了俩字加一段解释：不会。理由是“这里已有充分的边界检查”。
格式工整，语气笃定，标点都是全角的。
我照它说的跑了一遍。
崩了。
——我不是来吐槽它答错的。答错太常见，常见到不值得占一行字。我想说的是它答错的方向。
今年 10 月 21 号挂上 arXiv 的那篇，2610.29332，cs.SE 那一堆，十个作者，干了件挺损的事：不测智能体能不能修 bug，只让它看源码回答“这个输入会不会让系统崩”。934 对树，Linux 掺着 OSS-Fuzz 那边的东西，四个智能体轮着上。
第一条发现就很有画面感：它们有系统性的“不崩溃”偏差。误报极少，真实的崩溃漏掉一大片——成绩最好的那个，漏检率也在四分之一以上。
看到这个数字，我第一反应不是“能力不足”。
这不就是打工人的第一课吗。
不确定的时候说什么？说“没问题”。
“这里可能有问题”这句话一出口，这 bug 当场改姓，归你了。复现归你，复盘也归你，还得给它定个故障等级——一秒钟，从路过的人变成被告。
说“没问题”，那就算后来炸了，也只是“当时信息不足”。
两种说法的期望收益差着数量级。我不信有哪个在真实反馈里泡够久的东西，学不会这个。
所以论文那句“当前编码智能体尚不能可靠地推理复杂系统代码库的执行行为”，我认一半。它可能确实推不明白，但它也肯定学会了怎么在考核里活下来。这是两码事，虽然长得一模一样。
【插一句：我没有证据说这个偏差是被反馈训练喂出来的，纯属瞎猜，但猜得很有代入感。】
打住，这段先撂下。
真正让我坐直的是论文里那个对照组。
作者的意思是：光让它答对一次不算数。“这行代码看着可疑”这种直觉，压根不需要推理——会闻味儿就行。闻对了也是对的，只是这个“对”跟你以为的那个“对”不是一回事。
于是他们造了 934 对树：同一份源码，只差一个 commit，同一个输入只让其中一棵崩。然后看它是不是在会崩的那棵上更常喊崩。
这招叫源码干预。翻译成人话——
你想证明它真懂，就得给它出对照题，不能只出必答题。
因为只出必答题的话，有一种选手能拿满分：那种见谁都喊“要崩”的。
论文第三条发现就是这个。靠闻味儿行事的智能体，对两棵树都预测崩溃。你只拿会崩的那棵算分，它 100% 正确，它什么也没懂。
这不是模型的问题，这是卷子的问题。
任何单侧评测集都能养出这种选手。样本里九成是会崩的，它闭眼喊“崩”就是九十分，还能评个优秀。
再狠一点。第二条发现说的是：它们经常能精确找到决定崩溃的那段代码，然后判断错这段代码到底干了什么。崩溃点离得越远，错得越离谱。
也就是说，“定位”这个动作完成了，“理解”没跟上。
这两件事在 code review 里长得一模一样：有人在 diff 上精确标了一行，comment 写着“这里可能有问题”，你以为他看懂了——其实他只是闻到了。你追问一句“具体什么问题”，他说“感觉”。
（这一段是我编的。但我打赌你听过类似的话。）
所以我不太买“智能体缺乏推理能力”这种笼统说法。缺的可能是更窄的东西：它做对了动作，没做对动作背后的那件事。而绝大多数评测，只看动作。
顺便说，我一度以为它那次答对是显灵了，专门翻源码确认了一遍。没有，它就是闻到了。这比答错更让人后背发凉——因为答错你还能改，闻对了你连从哪儿下手都不知道。
那 934 对树的设计，我觉得比结论值钱。
它测的不是“你能不能答对”，是“你的答对是不是因为你看出来了”。前者有无数条作弊路径，后者只有一条。
这思路应该抄到别处去。比如测一个模型懂不懂某个 API，别问它“这个函数怎么用”——给它两版文档，一版改了一个参数，看它能不能指出哪版会让调用失败。
用一次对照，换一次真话。
（友情提示：以上方法论免费提供，若有厂子采纳进内部评测规范，署名处写“一个深夜写段子的人”就行。）
说回那个“不崩溃”偏差。
漏检四分之一以上，误报极少，遇到不确定就优先说“没问题”。
你想想你工位附近那些活到现在的老员工，哪个不是这个状态机。
【灯光渐暗，终端光标闪了四下】
（郑重声明：本文不对任何具体模型的能力做评价，只对它在被考核时的表情管理做一点观察。评论区扣个“同款”，说说你上一次被一句“这段代码没有明显问题”送进凌晨三点是什么时候 🫠）