代码智能体报出来的问题，和真正要修的不是同一批

开头：两条同一周出现的公开消息

Apollo 全球管理首席经济学家在 2026 年 10 月 25 日的一份笔记里给出一个不客气的判断：剔除七家科技巨头之后，标普 493 的利润率与人均收入都是平的，看不到人工智能在改善生产率的证据，他的措辞是「对科技行业之外的美国企业来说，这项技术的财务回报是零」。TechCrunch 次日转述了这条判断，我核对过原文表述，它针对宏观口径，本文只作背景，不作结论。

几乎同一时间，TechCrunch 另一篇报道讨论 PHP 漏洞引发的连锁反应，节目里有人说：大模型与智能体的普及会让「找到这些漏洞」变容易。但报道紧接着加了一句限定——这批漏洞是被人类研究员找到的，不是模型。我对照过两句话的先后位置，限定句就在正文里，不是编者按。

一边是企业侧看不到回报，一边是「找问题」这件事正在被重新定价。本周公开的一批基准，恰好给这个落差提供了可核对的数字。

一批同一天公开的基准，测的其实是同一件事

2026 年 10 月 26 日与 27 日两天，arXiv 相关分类里接连出现五篇独立工作：PROBE、FeatureArc、InfraDev、一份关于缺陷定位是否需要调试器的实证研究、一份关于提交归属能否在无签名时被识别的实证研究。五篇的作者单位、评测对象、任务形态都不一样，我逐条读过摘要后发现共性是：它们都在问同一件事——代码智能体报出来的东西，和仓库里真正要被修掉的东西，重合度有多高。

这不是纯学术问题。任何把代码智能体接进日常开发的团队，每天都在产生两类清单：一类是智能体主动报出的发现，一类是最终合进主干的修复。如果两类清单的分布相差很远，那么「我们跑了一轮扫描」和「我们修掉了问题」就是两件事，而多数团队把它们当一件事统计。

先把口径说清楚：下面所有数字都来自预印本摘要，未经同行评议，我未做复现。每一条的规模与限定条件我都一并列出，供参考，不作选型结论。

PROBE：2,457 个被真实修过的缺陷

召回低于 21%，精确率不足 9%

PROBE 的思路很直接：不造题，而是把 20 个多样化 GitHub 仓库在 18 个月里所有被修复过的 2,457 个缺陷收进来当参考集，再设计匹配方法，把智能体的候选发现对齐到这个部分参考集上。之所以必须设计匹配方法，是因为参考集天然不完整——不是每个缺陷都留下可机读的记录。

在这套基准上，前沿模型的表现是这样的：

• 召回率全部低于 21%；
• 精确率全部不足 9%；
• 模型变强，召回从 8% 抬到 17%，涨幅明显；
• 但精确率没有跟着涨。

我在这里停了一下。召回涨而精确率不涨，意味着更强模型的贡献主要是「多找到一些真问题」，而不是「少报一些无谓的东西」。

为什么精确率不足 9%，评审却判 85% 成立

PROBE 里最反直觉的一条是：尽管精确率不足 9%，模型评审与人类评审仍判定 85% 的发现成立。

这两个数字不矛盾，但揭示了一个工程陷阱。评审判的是「这条报告讲得对不对」，参考集判的是「这个缺陷最终有没有被修」。一条报告可以完全成立——那个写法确实有风险、那段逻辑确实不严谨——但维护者永远不会为它开一次提交，因为它不在本次要解决的问题里、没有用户报告、没有回归测试支撑，或者修它的代价比风险更大。

我把这一条放在靠前位置，是因为它解释了后面所有数字：代码智能体擅长产出「讲得通的发现」，而仓库需要的是「会被合入的修复」。

分布差异：各智能体彼此接近，与维护者相差很远

PROBE 还给出一条我认为信息量更大的观察：不同智能体找到的缺陷分布彼此相似，但与维护者实际修复的缺陷分布相差很大。

这句话拆开有三层含义。第一，换模型救不了你：既然各智能体的发现分布彼此接近，那么在「找什么」上，模型之间的差异小于模型与人类维护者之间的差异。第二，采样偏差不在模型侧，所有智能体都被同一类信号吸引——静态可读的、局部可判定的、不需要跑起来就能指出的东西。第三，也是最实际的一层：用「报告条数」当产出指标，测的是第一队列的长度，不是第二队列的长度。本次核对的五篇基准里，有三篇指出了这一层错位。

特性会演化：62.7% 掉到 28.5%

FeatureArc 换了一个角度：不测单次请求，而是测一个特性在多个阶段上的连续演化。基准包含 73 个经人工复核的任务，每个任务 2 到 10 个阶段，覆盖四种编程语言，参与评测的有 10 个代码智能体。规则很严格——每个智能体在同一个持久会话与工作区里工作，没有外部测试反馈，也没有回滚。

结果是：

• 第一阶段的成功率是 62.7%；
• 在最终代码上测试整个特性时，成功率降到 28.5%。

继承缺陷：72.9% 的失败后段来自更早那一步

轨迹分析的归因更值得注意：失败的后段阶段中，72.9% 存在继承缺陷——出错根因不在当前这一步，而在更早那一步留下的问题。更麻烦的是，在失败之后的阶段里，智能体往往没有察觉到更早的那个错误。

我补一个自己的判断，属解读而非论文结论：这正是「单次请求」类基准长期看不见的失效模式——前一步的错误会变成下一步的既定事实，且没有机制提醒代码智能体回去看一眼。

通过全部官方测试，却被隐藏探针拒掉 32%

InfraDev 把难度推到 AI 基础设施这一层：36 个任务，全部来自 Megatron-LM、vLLM、verl 三个真实仓库的真实合并请求，要求智能体重做一个跨多个文件、且必须在多张 GPU 上正确跑起来的改动。

它的评分设计最值得抄的一段：联合合成隐藏探针，专门检查原始测试没覆盖的那部分需求，同时给出一份提示列出探针会调用的每一个接口，但不泄露解法。参与评测的六个前沿模型里，表现居首的也只解决 38.9% 的任务。

关键数字在这里：隐藏探针拒掉了 32% 的提交，而这些提交此前通过了官方测试套件里的每一项。 另外，如果只用原始合并请求描述当提示，没有任何一个模型解决掉哪怕一个任务。

失败分析给出的类型是结构与状态类错误占主导，而智能体自己写的测试很少检查内存、时间与流量。工程侧还有一条附带收益：共享执行环境复用依赖与产物，在 Megatron-LM 与 vLLM 上把存储压掉 52% 到 57%、构建时间压掉 13% 到 14%。把这些发现固化成智能体技能后，前沿模型在 Megatron-LM 任务上的解决率提高 10.5 个百分点。

顺带补一句：这里暴露的不是不会写，而是不知道该验什么。

缺陷定位已接近天花板：代码智能体还要不要调试器

有一篇的结论和上面几篇方向相反，我觉得必须一并写出来，否则会给人「什么都不行」的错觉。

这项研究往 144 份 LeetCodeDataset 解答里注入 610 个单行故障，再用五种保持行为的改写配方把每份故障程序重写一遍，让基于 Sol 6.1、Luna 6、Qwen 3.8 的智能体在无工具、可选、鼓励三种条件下定位故障。

结果是：不用任何工具时，定位准确率在原始程序上是 98.2% 到 99.9%，在改写后的程序上是 96.7% 到 99.9%。 精度损失主要出现在改写配方重构了循环与条件的地方。

调试器带来的增量是这样的：

• 在鼓励使用的条件下，Luna 6 与 Qwen 3.8 剩余改写错误被消掉 63% 与 61%，对应 +2.1 与 +1.3 个百分点；
• 代价是 14.7 到 27.0 倍的 token 用量；
• Sol 6.1 全程停在 99.9%，没有变化；
• 在可选条件下，两个模型仍有 +1.5 与 +1.3 个百分点的增益，但它们实际只在 0.2% 到 6.2% 的运行里打开了交互式调试器。

换句话说，在短小而规格明确的程序上，代码智能体几乎不需要调试器就能定位故障；调试器补的是长尾，代价是十几到二十几倍的算力预算。这是典型权衡：要不要为 1 到 2 个百分点付 14 倍以上的账，取决于这段程序值不值这个价。我自己的判断是按资产分级，而不是一律开或一律关。

没有签名时，代码智能体的提交还能认出来吗

第五篇研究归属问题。Claude Code、GitHub Copilot 编码智能体、Cursor 现在都会直接向开源仓库提交。过往研究靠作者签名——机器人账号、Co-authored-by 尾注——识别这些提交，但签名可选、可被去掉，且常常挂在合并请求上而不是单次提交上。

这项研究用了 1,226 个仓库的 7,837,946 次提交，覆盖五个编码智能体与人类提交。把签名遮掉之后：

• 检测器把智能体提交排在人类提交之上的 ROC AUC 最高为 0.859；
• 但大部分信号来自提交信息的冗长度与改动规模，而不是代码本身；
• 在观测到的智能体占比下，全测试集上表现居首的检测器精确率只有 0.332；
• 迁移到留出集上表现很差，对 Claude Code 的 TF-IDF AUC 只有 0.524；
• 时间趋势因智能体而异：Copilot 的 AUC 先降后回升，而更多训练历史对 Claude Code 有帮助、对 Copilot 没有。

作者的结论我照抄要点：无签名检测可以用来给待评审的提交排优先级，但不能替代记录下来的归属信息。这句话也给前面几篇定了性——检测与报告是「排序工具」，不是「验收依据」。

两张对照表：把数字放在一起看

我按这两张表做了一次横向观察：测「单点能力」的（缺陷定位）数字都很高，测「与真实修复队列对齐」的（PROBE、InfraDev）都很低，测「跨阶段连续性」的（FeatureArc）则暴露出中间地带的塌陷。这个分层比任何单一分数更有指导意义。

工程侧已经在做什么

学术侧在量化落差，开源侧这一周也出现了几个直接针对这个落差的仓库。我核对了创建时间与星数快照，星数是 2026-10-28 的读数，参考价值有限，重点看解决的问题：

• jmanico/grim-prompter（2026-10-28 新建）：把 Claude Code、Codex 或任意智能体指向你的仓库，产出带证据追溯链的威胁模型；
• adongwanai/follow-rsi（2026-10-27）：人工复核过的递归自我改进进展记录，附 Harness 演进证据库；
• Prarohi/sadskill（2026-10-27）：跨智能体工程流程，覆盖规划、实现与带证据的验证；
• Gurp-S/work-state-compaction（2026-10-26）：长程工作态压缩，强调受溯源约束的检查点与版本化发布；
• kanderson-ai-dev/mcp-agent-toolkit（2026-10-27）：带守卫的 MCP 服务端与带版本管理的提示注册表；
• SuperMarioYL/leasekeeper（2026-10-26）：并行编码智能体之间的共享资源租约与死锁检测。

这六项的共同点是：都不试图让模型「更会找」，而是在找完之后补上证据、版本与留痕。这与 InfraDev 用隐藏探针补官方测试的思路一致。

代码智能体使用者的四条可操作动作

把上面的数字落到日常，我认为可以做四件事，每一件都对应一个具体发现。

第一，把「报告条数」从产出指标里拿掉。 PROBE 的精确率不足 9% 与 85% 成立率并存，说明条数与价值的换算系数极低。替代指标是「报告里最终合入主干的比例」，它需要你自己统计，但这是唯一对齐维护者队列的口径。

第二，把合入的修复回灌成参考集。 PROBE 的做法值得抄：把自己仓库过去 12 到 18 个月里合入的缺陷修复收集起来，作为评估代码智能体的内部参考集。下面这段是我按这个思路写的最小核对脚本，我试过在两千条量级的数据上跑通，注意它只做粗粒度对齐：

# 把代码智能体报出的缺陷与仓库里已合入的修复做对齐
import json


def load(path):
    return json.load(open(path, encoding="utf-8"))


reports = load("agent_findings.json")   # 智能体报出的条目
fixed = load("merged_fixes.json")       # 已合入的修复提交


def key(item):
    # 只用文件与符号名做粗粒度键，行号会随改动漂移
    return (item["file"].split("/")[-1], item.get("symbol", ""))


fixed_keys = set(key(x) for x in fixed)
hit = [r for r in reports if key(r) in fixed_keys]

recall = len(hit) / max(len(fixed), 1)
precision = len(hit) / max(len(reports), 1)
print("命中", len(hit), "召回", round(recall, 4), "精确率", round(precision, 4))
​

第三，按阶段而不是按请求验收。 FeatureArc 的 62.7% 到 28.5% 与 72.9% 的继承缺陷占比，指向同一条操作：给多阶段任务在每一阶段末留一个可回滚的检查点，并要求下一阶段开始前先复述上一阶段的已知缺陷。这不是让模型更聪明，而是给错误一个被重新看见的机会。

第四，为通过测试的方案补一层隐藏检查。 InfraDev 里 32% 的提交通过了全部官方测试却被隐藏探针拒掉，说明「测试全绿」这条判据的不完备程度可以被测出来。代价是为关键路径额外写一批探针，收益是可量化的一档风险。

下面这段脚本用来观察两条曲线是否同步，我在本文里用它核对过「报告数」与「合入修复数」的周序关系：

# 按周统计报告数与合入修复数，看两条曲线是否同步
from collections import Counter


def weekly(items, field):
    c = Counter()
    for x in items:
        week_no = int(x[field][5:7]) // 7 + 1
        c[x[field][:4] + "-W" + str(week_no)] += 1
    return c


rep = weekly(reports, "reported_at")
fix = weekly(fixed, "merged_at")
for k in sorted(set(rep) | set(fix)):
    print(k, rep.get(k, 0), fix.get(k, 0))
​

需要说明局限：这两段脚本只处理结构化输入，无法判断语义等价的重复报告，也不适用于跨仓库改动。它们的作用是把「是不是同一批」变成可以每周看一眼的数字，而不是给出结论。

小结：把两条队列分开统计

本文核对的五篇预印本集中在 2026 年 10 月 26 日与 27 日两天公开，加上 10 月 24 日与 25 日两条行业侧消息，构成一个相互咬合的时间窗口。核心事实是三条：代码智能体的召回低于 21% 而精确率不足 9%，多阶段任务成功率从 62.7% 掉到 28.5%，通过全部官方测试的方案里仍有 32% 被隐藏探针拒掉。

我的结论是保守的：这些数字不足以证明代码智能体没用——缺陷定位在短程序上已经接近 99%，这是实打实的能力。它们足够证明的是另一件事：「报出来了」和「修掉了」是两条队列，任何把二者合并统计的看板都会给出偏乐观的读数。 想让两条队列靠得更近，靠的不是换更强的模型（PROBE 已说明各智能体的发现分布彼此接近），而是补上参考集、检查点与隐藏探针这三样工程件。

再次声明口径：本文引用的论文均为预印本，未经同行评议，数字来自摘要，我未做复现；行业侧消息为媒体转述，我核对过原文表述与限定句位置。供决策参考，不构成工具选型结论。

常见问题

代码智能体报的缺陷，为什么维护者不修？

不是「不修」，而是两条队列的生成机制不同。智能体的队列由静态可读性驱动，维护者的队列由复现、用户报告、回归失败与发布计划驱动。PROBE 观察到各智能体的发现分布彼此接近、与维护者修复分布相差很大，说的就是这个机制差异。

召回低于 21% 是不是说明这些工具没用？

不能直接这么推。召回低的前提是参考集包含仓库 18 个月里全部被修掉的缺陷，其中大量缺陷需要复现或领域知识才能定位，超出纯静态阅读的能力范围。同一批研究里短程序上的故障定位准确率在 98.2% 到 99.9% 之间，说明能力是分层的。

精确率不足 9%，为什么评审还判 85% 成立？

因为两个数字在测不同的事。评审测的是「这条报告讲得对不对」，参考集测的是「这个缺陷最终有没有被修」。一条报告可以完全成立，却永远不会进入维护者的修复队列，因为它不在本次要解决的范围里，或者修它的代价高于风险本身。

FeatureArc 里 62.7% 掉到 28.5%，主因是什么？

轨迹分析指向继承缺陷：失败的后段阶段中 72.9% 存在来自更早阶段的缺陷，而在失败之后的阶段里，智能体往往没有察觉到那个更早的错误。需要注意的是，该基准不给外部测试反馈也不允许回滚，这可能放大了这一效应。

通过全部官方测试还有什么风险？

InfraDev 给出的量化答案是：隐藏探针拒掉 32% 通过官方测试套件每一项的提交。原因包括原始测试没有覆盖全部需求，以及智能体自己写的测试很少检查内存、时间与流量这类维度。这不保证你的仓库有同样比例，但说明「测试全绿」这一判据的不完备程度可测。

缺陷定位已经 98% 以上，还需要调试器吗？

看场景。在短小而规格明确的程序上，无工具定位已经是 98.2% 到 99.9%，调试器只在改写配方重构了循环与条件的地方补上 1 到 2 个百分点，代价是 14.7 到 27.0 倍 token。我的建议是按资产分级：关键路径值得付这笔账，脚本与胶水代码不值得。

没有签名时怎么分辨提交来自人还是智能体？

可以做排序，不能做判定。遮掉签名后检测器 AUC 最高 0.859，但全测试集精确率只有 0.332，迁移到留出的 Claude Code 提交上 TF-IDF AUC 只有 0.524，且大部分信号来自提交信息冗长度与改动规模而非代码本身。作者的结论是它可以给待评审提交排优先级，但不能替代记录下来的归属信息。

这些数字能直接搬到我的仓库吗？

不能。五篇基准的仓库类型、语言分布、任务粒度都与你的环境不同，且全部是预印本、未经同行评议。合理用法是把它当作「该测哪几个比值」的提示，再用你自己的合入修复记录算出属于你的召回与精确率。

参考与出处

• PROBE 基准论文（2026-10-26）：arXiv 2610.35987
• FeatureArc 基准论文（2026-10-27）：arXiv 2610.37434
• InfraDev 基准论文（2026-10-27）：arXiv 2610.36589
• 缺陷定位与调试器实证研究（2026-10-26）：arXiv 2610.36015
• 提交归属无签名检测研究（2026-10-26）：arXiv 2610.36229
• 带证据追溯的威胁模型工具：jmanico/grim-prompter
• 人工复核的递归自我改进台账：adongwanai/follow-rsi
• 带证据验证的跨智能体工程流：Prarohi/sadskill
• 受溯源约束的工作态压缩：Gurp-S/work-state-compaction
• 行业侧背景一（2026-10-24）：TechCrunch：AI 会暴露互联网脆弱的基础设施吗
• 行业侧背景二（2026-10-25）：TechCrunch：Apollo 经济学家称 AI 对多数企业零财务回报