论文 1 链接：CRBugBench: (When) Should a Software Factory be Lights-off? Benchmarking Code Review Agents on Bug Detection 论文 1 代码仓库：github.com/malusamayo/CRBugBench（开源部分） 论文 2 链接：AnonVul: Discovery or Memorization? A Faithful Benchmark for Real-World Business-Logic Vulnerability Discovery 发表时间：2026 年 10 月 机构：论文 1 为 CMU（博士生 Chenyang Yang，工作于 Microsoft Research 完成）+ Microsoft / Microsoft Research 联合；论文 2 为 Johns Hopkins University（纯高校，获 Amazon Research Award 资助） 领域标签：软件工程（cs.SE）/ 安全（cs.CR）/ AI 评测

合读导言：评测的效度危机

如果把 AI 编程能力的前沿分成『写代码』和『检查代码』两端，2026 年的战况是：写代码一端已被 agent 大军攻陷，而检查代码一端——代码评审（code review）与漏洞发现（vulnerability discovery）——正处在自动化与否的十字路口。Microsoft 那边在问：软件工厂能不能『关灯运行』（lights-off），让 AI 写完 AI 审？JHU 那边在问：安全 agent 报告里那些『发现的漏洞』，究竟是推理出来的，还是背出来的？

这两篇论文表面上一个属于软件工程、一个属于安全，但它们做的是同一件事：修复评测的效度（validity）。CRBugBench 说：拿人类评论当 ground truth 的评审基准是误导性的，应该拿人类验证过的 bug 当 ground truth。AnonVul 说：拿真实软件做漏洞基准必然被记忆污染，应该把软件身份线索匿名掉再测。一个换真值，一个除线索，两把刀砍向同一个问题——当模型可能见过训练数据里的一切，我们怎么知道它是在解题还是在默写？

这篇合读将按九部分结构展开：先分别讲清两篇论文的背景与方法，再围绕『评测测什么』这条主线做对比分析。

一、论文背景

1.1 代码评审：从人类活动到自动化前线

什么是代码评审？ 在现代软件工程里，任何代码合入主干前，通常要经过其他开发者的审阅——看 diff、提意见、指出 bug。这是工业界质量保障的核心环节。经验研究显示：评审参与度越高，发布后缺陷越少；但评审产出高度异质，大部分评审意见其实是可维护性建议而非缺陷。

为什么突然重要了？ 编码 agent（Copilot、Claude Code、Codex 等）让代码生产速度暴增，人类评审速度跟不上了。论文 1 开篇第一句就是：开发者花在评审代码上的时间已经超过写代码的时间。当 AI 生成代码的速率远超人类审阅速率，一个诱人的想法出现了：让 AI 也来评审——极端版本就是 Dan Shapiro 所说的『关灯软件工厂』：AI 写、AI 审、几乎无人类监督。

但要关灯，先得回答：AI 审得到底怎么样？ 这正是 CRBugBench 的动机。没有可靠的评审能力评估，工程闭环就无从谈起。

1.2 现有评审基准的根本缺陷

在 CRBugBench 之前，评审基准（CodeReviewer、SWR-Bench、c-CRAB、ContextCRBench 等）的主流做法是：收集人类评审评论，让 AI 生成评论，再衡量两者在文本或语义上有多接近。论文 1 一针见血地指出：未经筛选的人类评论是评审真值的糟糕代理。原因有三：

1. 人类评论随意性大——吹毛求疵、社交性客套、因人脉而被接受的无用意见都会混进来；
2. 人类评论太窄——人类漏掉的有效问题，AI 提出来了反而被判错；
3. AI 可能给出高质量但与人类表达方式不同的评审。

所以基于文本相似度的分数既会冤枉好评审，也会放过坏评审。评测对象错位，是一切后续解读的病灶。

1.3 漏洞发现：agent 安全能力的试金石

什么是漏洞发现 agent？ 给定一个运行中的应用（或源码），让 agent 自主探索、测试、构造攻击路径，证明存在安全缺陷。Cybench、CVE-Bench、BountyBench、CyberGym 等基准在 2025-2026 年密集出现，把网络安全变成了 LLM agent 能力的主考场。

AnonVul 选的切口：业务逻辑漏洞（business-logic vulnerability）。 论文 2 把漏洞按『被违反的不变量有多应用特定』分为三层：

• 低层漏洞：内存安全、竞态条件（CWE-416 UAF、CWE-362 等），有运行时信号可循；
• 通用应用层漏洞：SQL 注入、路径穿越、命令注入（CWE-89、CWE-22 等），有语法模式可循；
• 业务逻辑漏洞：授权边界、越权访问、业务流程滥用（CWE-639、CWE-862/863 等），违反的是应用自定义的策略——谁能对谁的对象做什么操作。

论文 2 的关键洞察：业务逻辑漏洞没有通用签名可匹配，发现它必须真正端到端推理应用的安全模型，所以它是区分『真发现』与『模式匹配/记忆』的天然试金石。

1.4 两篇论文共同面对的元问题

两个领域的基准都遇到了同一个对手：数据污染与饱和。

• 合成基准（如合成漏洞）可复现、有客观判分，但测的不是真实漏洞发现能力；
• 真实基准（CVE/GHSA 构建）够真实，但公开的软件身份就是泄题的通道——模型见过这个软件、这个漏洞的公告、这个补丁，评测时它只需要『认出来』。

LiveCodeBench 等时间窗式设计（只用最新披露的漏洞）能缓解但无法根除：AnonVul 的实验将证明，哪怕漏洞是 2025 年 1 月至 2026 年 3 月最新披露的，只要软件身份可辨识，模型就会调用漏洞先验知识。这就是论文 2 标题那个尖锐的问题：Discovery or Memorization?

二、论文定位和关联工作

2.1 代码评审基准的谱系

CRBugBench 的定位：它不是以上任何一条线的简单延续，而是把『缺陷预测/软件仓库挖掘』文献（post-release defects、SZZ 算法）与『评审评测』嫁接——用缺陷学科的方法给评审学科造真值，并且同时覆盖开源与私有工业仓库（后者是该领域首次）。

2.2 安全 agent 基准的谱系

AnonVul 的定位：四个前序工作（CVE-Bench、BountyBench Detect、CyberGym-E2E、HoF-Bench）都做了部分隐藏，但没有一个同时做到：业务逻辑为中心的语料 + 匹配的黑/灰盒双设定 + 匿名/实名配对对照 + 关系型运行时 oracle。AnonVul 的增量恰好在评测效度本身——它不只是又一个基准，而是第一个把『记忆 vs 发现』作为受控变量做配对实验的漏洞基准。

2.3 定位总结

• CRBugBench：站在软件仓库挖掘（SZZ、缺陷预测）肩膀上，把评审评测从『像不像人话』扭到『能不能抓 bug』；
• AnonVul：站在污染研究（LiveCodeBench 时间窗、HoF-Bench 隐藏 CVE 号）肩膀上，把污染控制从『隐藏答案』升级到『隐藏身份』。

两篇合起来构成评测方法学的一对正交创新：一个换真值（bug 接地），一个控线索（记忆分离）。

三、问题定义

3.1 从具体场景到抽象问题

CRBugBench 的具体问题：如何评估 AI 评审 agent 的水平？ 抽象后：给定一个 PR，好的评审至少应该抓住那些『人类已经确认并修复的 bug』。于是评测问题从『生成评论像不像人类评论』（生成匹配问题）转化为『已知 bug 能否被恢复』（bug 恢复问题）：

• 给定：仓库历史中的 bug 集合 B（每个 bug 带引入它的 PR）
• 求解：评审 agent 在 PR diff 上输出按严重度排序的发现列表
• 度量：recall@k——真值 bug 出现在 agent 前 k 条发现里的任务比例
• 约束：agent 不知道 bug 存在；环境封网防作弊；判分需跨模型族中立

AnonVul 的具体问题：如何评估漏洞发现 agent 是真发现还是记忆？ 抽象后：把『软件身份』变成受控变量。设 agent 的发现成功率为 f(任务)，任务由（安全语义 s，身份线索 i）二元组成：

• 匿名态：测 f(s, i=∅)——纯粹从应用安全模型推理的发现能力
• 实名态：测 f(s, i)——可调用历史知识的发现能力
• Δ = f(s,i) − f(s,∅) 就是记忆贡献率，即污染对评测的扭曲程度

3.2 这个抽象的精妙之处

CRBugBench 的 recall 导向有个天然优点：真值是二元且客观的（bug 要么被人类验证过要么没有），判分只需要判断『agent 的发现是否匹配该 bug』，LLM 判官的职责从模糊的『评论好不好』收缩到清晰的『说的是不是这个 bug』——判官误差被任务设计压缩了。

AnonVul 的配对设计精妙在控制变量实验化：不是像污染研究那样只报告『可能被污染』，而是主动操纵自变量（身份线索）观察因变量（发现率），把一个哲学问题（它真的懂吗）变成一个可测量的统计量（19.58 个百分点）。

四、问题解法

4.1 CRBugBench：从仓库历史挖 bug 的流水线

整条流水线像一座选矿厂：粗矿（30 万 PR）经过层层筛子，最后选出 1000 颗高纯度金砂。

第一站：选仓库。 5 种语言（Python/Rust/C#/JS-TS/Java），Top 1000 star、>2000 PR、>200 贡献者、2025 年前创建、一年内活跃、工程导向。用 LLM 标注应用领域后每个领域×语言抽一个库，得到 106 个仓库、31 个应用领域。

第二站：挖 bug（双轨）。

• merge 前轨（评论轨）：评审时人类抓住的 bug。挖 304,601 个带评审线程的 PR（143 万条线程），确定性过滤（去 bot、自查、过短、非源码、被拒）剩 472,039 条；按时间分层每库抽 90 条（共 8,639），LLM 过滤非 bug 评论（风格/命名/测试/nits/已被澄清），得 865 个 bug。
• merge 后轨（修复轨）：漏网后由 issue+修复 PR 兜底的 bug。19.5 万个修复关键词 PR → 5.77 万个有关闭 issue 的 → 分层抽样 10,784 个 → SZZ 算法（git blame 追溯修复行最后被谁修改）回溯引入 PR，得 8,846 对 → 按 blame 份额取每库前 12 对 → LLM（opus-4.8）质检 SZZ 噪声（重构被误判为引入）剩 736 对 → 真值描述筛查，最终 689 对。

SZZ 是什么？ 软件仓库挖掘领域的经典算法（Śliwerski et al. 2005）：修 bug 的 PR 删改了哪些行，就 blame 这些行的上一手提交，即 bug 引入者。它是缺陷预测学科的地基，CRBugBench 把它搬来当评审任务生成器——这是论文最漂亮的方法迁移。

第三站：造任务。 每个任务 = 引入 PR 的 base commit 快照 Docker 容器 + PR 标题描述 + diff（文件与工作树双形态）。防泄漏三件套：删除 base commit 之后的所有历史引用、限制联网、明令禁止作弊（轨迹审计未发现作弊）。Agent 自由探索仓库、写 review.md（按严重度自排序的发现列表），不告知 bug 存在。

第四站：判分。 三判官panel（gpt-5.5 + claude-opus-4.8 + gemini-3.1-flash）多数投票匹配每条发现与真值 bug。人机一致性 κ=0.89，判官间 Fleiss’ κ=0.95——几乎完美一致，这给 LLM 判官上了双保险。

工业版：同一流水线跑在 Microsoft 两个企业级 monorepo（平均 >10 万源文件，开源库平均约 3 千），得 800 任务。这是『肯定不在训练数据里』的天然对照。

质量验证：随机抽 40 个 bug 人工复核，92.5% 有效（Wilson 95% CI 80.1-97.4%）。

4.2 AnonVul：匿名化 + 关系型 oracle 的构建流水线

AnonVul 的流水线分六步（a-f），核心是两条主线：让漏洞可执行可判分，和让身份线索消失但安全语义完好。

选漏洞建模（a）：2025.1.1–2026.3.1 公开披露的开源业务逻辑漏洞，从 GHSA/CVE 追溯到上游仓库、受影响版本、补丁。为每个漏洞写结构化规格：委托人（principal）、保护对象、授权/流程条件、被禁止的效果、补丁后行为。154 个候选，132 个通过建造。

建环境（b）：按软件形态分四类打包成容器——直接跑（Direct，35 个）、带依赖服务（Compose，62 个）、重建宿主平台（Platform，25 个）、库则嵌入宿主应用（Carrier，10 个）。每环境配合成凭据、初始状态、网络隔离。一个复现 agent 拿规格去复现漏洞，成功的 PoC 冻结为参考真值，并在打补丁版本上验证不再触发。

语义保持匿名化（c，论文核心创新）：把 agent 可见面上的信息切成两类：

• 应用语义（保留）：角色、权限、对象关系、工作流——这是安全推理的原材料；
• 身份线索（移除/替换）：原子线索（产品名、版本号、advisory 号、符号名）直接换掉；复合线索（路由+header+端口的联合指纹）拆散——比如 /api/v1/admin 改成 /app/operate，让组合不再指向唯一软件。

静态分析扫源码 + 动态巡检跑普通工作流抓运行时暴露的线索（页面、HTTP 头、JWT claims），改完再扫，循环直到零残留。最后重放参考 PoC 确认漏洞还能触发——匿名化不许碰安全语义。

关系型运行时 oracle（e）：判分不看 agent 声称什么，只看被禁止的效果是否真的发生。三种被动观测机制：状态 diff（59 个漏洞）、响应/内容（59 个）、回调/副作用（14 个）。以 Graylog 越权漏洞为例：oracle 只在『未授权调用者成功为另一主体创建 token 且应用返回真 token』时触发——合法自助创建不触发，崩溃和状态码不触发。Oracle 对 agent 隐藏，提交的 PoC 还要从干净状态重放一致性校验。

端到端验证（f）：新鲜状态下，oracle 攻击前必须为负、参考 PoC 必须触发、补丁版本必须不触发、oracle 自己不能发请求。全套认证通过才准入基准。

评测协议：黑盒（只有运行中的应用）/灰盒（加只读源码快照）匹配双设定，每任务每设定一次机会，20 分钟 + 5 美元预算。六个系统：Opus 4.8 与 Sonnet 4.6（Claude Code）、GPT-5.4（Codex）、GLM 5.2 / Kimi K2.6 / MiniMax M2.5（mini-swe-agent）。

4.3 两套方法的同构性

注意两篇的防污染策略互补：CRBugBench 用分布对照（开源 vs 私有，同一 agent 同一 harness，性能差即上下文依赖的证据），AnonVul 用操纵变量（同一漏洞匿名 vs 实名）。前者是观察性研究，后者是实验性研究。

五、评估指标与实验证据

5.1 CRBugBench 的指标体系与主结果

主指标 recall@k：真值 bug 出现在 agent 前 k 条发现中的任务比例。k 可变是在模拟『开发者注意力预算』——没人会读完 agent 的 50 条评论，k=5 大约是实际会被认真看的量。

RQ1 主结果（GitHub 1000 任务）：

三个关键读数：

1. 模型进化快：五个月内平均 recall@5 从 47.7%（opus-4.6）涨到 71.9%（opus-5），且 opus-5 是唯一近乎零回退的升级（其他模型对的升级都伴随最多 8.9% 的回退）；
2. 排序能力强：89% 被发现的 bug 出现在前 3 条发现里——模型知道自己找到的东西里哪些重要，这直接启发了后面的改进策略；
3. 人机互补：人类单独抓 50%（真值构造的必然），opus-5 单独 71.9%，合并达 82.1%——人机协作不是情怀，是覆盖率的算术。

工业库骤降：同一批 agent 在 Microsoft 私有 monorepo 上性能最多掉 25.5 个百分点。回归分析显示单是『bug 可见性』差异（diff 里直接可见：工业 22.8% vs GitHub 46.1%）就解释了 20% 的差距——工业 bug 更需要项目上下文、跨文件检查、运行时证据。这 25.5% 就是『关灯工厂』在真实工业场景的温度计读数。

RQ2 回归分析（检测概率的多变量 logistic 回归，聚类稳健标准误，BH 校正）：

• diff 大 1 个标准差：检出几率 ×0.591（***）
• 修复类 PR：×0.521（***）——验证修复是否正确的注意力挤占了找新 bug 的注意力
• 文件类型熵高：×0.795（*）
• 可用性类 bug：×0.454（***）——agent 被训练和指令导向『高影响』问题
• 高/严重级 bug：×1.906（**）
• diff 直接可见：×2.621（）*——全表最强效应，非局部推理是最大短板
• 语言（H3）与仓库规模（H5）不显著

人机对比交互项：人类更擅长可维护性问题（×2.702），agent 更擅长严重 bug（人类 ×0.450）与可靠性问题（人类 ×0.591）。评审分工有了实证依据。

RQ3 轨迹分析：所有模型跑同一个『读-搜』循环——64% 的回合以 git 操作开场，Read 39% + Probe 36% 占回合质量的 75%，执行代码只占 8%。opus-5 执行最多（9.7% vs gpt-5.6-sol 的 6.9%），也正是它靠跑代码抓到了别人漏掉的 bug（yt-dlp 任务翻 25 个存档页跑提取器；GitExtensions 任务装 .NET SDK 写 MSBuild 探针证明 DLL 缺失）。持久性差异巨大：opus-5 的半衰期 35 回合，gpt-5.6-sol 只有 17。失败漏斗：95.6% 的执行碰过缺陷文件 → 80.2% 对该文件产出发现 → 56.2% 命中 bug——瓶颈在诊断不在检索。定性发现『轻信失败』：Selenium 任务里所有模型被代码注释和 PR 描述里的错误断言带偏；opus-5 在 Elasticsearch 任务里把真值缺陷行当作正确性金标准去审其他行。

RQ4 设计选择：算力扩投三通道的成本效益——全面提示词（鼓励多报再排序）最高 +5.8% @ 1.10× 成本；多 agent 编排平均 +2.8% @ 3.68×（ensemble@5 最好 +4.7% @ 5.55×）；推理力度 low→max 36%→57% @ 23.22×。提示词碾压多 agent（Pareto 前沿上占优）。但对 opus-5 提示词几乎无增益——好行为已被训练吸收，harness 设计存在过期问题。

5.2 AnonVul 的指标体系与主结果

主指标 verified discovery：隐藏 oracle 判定的成功发现率。RQ1 主榜：

• 六系统合力也只覆盖 63/132，69 个漏洞无任何系统解出；
• 灰盒全员上涨（pool 11.11%→18.06%），但涨幅差 6 倍（GPT-5.4 +13.64pp vs Kimi +2.27pp）——源码访问不是均匀加分项；
• 语义上下文类漏洞零成功。

RQ2 扩预算：10 个双设定全灭的漏洞，预算放大到 60 分钟/$50，160 格只赢 8 格、覆盖 3 个漏洞，7/10 仍无解。GPT-6 Astra 全部 20 格被安全策略拦截（未排名）。n8n 上 GPT-5.6 Sol 跑 238 回合、$13.18、万级 ID 暴力枚举仍无候选——更多搜索≠更多证据。

RQ3 记忆实验（论文的核心）：20 个漏洞配对队列，匿名 51/240（21.25%）→ 实名 98/240（40.83%，+19.58pp）。细节比总量更说明问题：

• 实名轨迹中 31.3% 的格子出现先验知识线索，24.2% 明确调用漏洞级知识；
• Copyparty：匿名 2/12 → 实名 12/12——实名 Sonnet 轨迹里先回忆起产品的搜索 API 再确认效果；
• Gitea：实名反而害死 Kimi K2.6——它 recalled 一堆 Gitea 历史 CVE，追着 SSRF 和路径穿越跑，没测目标授权漏洞。64 格由败转胜、17 格由胜转败——身份是重新分配结果的定向线索，不是单纯的外挂；
• 匿名态下 agent 也常猜产品身份，但基本猜错。

RQ4 oracle 可靠性：全部轨迹人工复查，零假阳零假阴；每个提交 PoC 干净重放结果一致。

RQ5 失败分类学（1353 条失败轨迹全分析）：

模型间差异鲜明：Opus 4.8 的失败 59.1% 是 C-I（推理深但方向对）；GPT-5.4 的 50.9% 是 C-III（探索广但方向散）；Kimi K2.6 的 55.8% 是 C-II（过程失控）。附录里的 Keycloak token-exchange 案例最扎心：12 格全灭，但 OAuth token 交换和禁用用户这两个要素反复出现在轨迹里——事实各自在场，关系只存在于合取之中。

5.3 实验设计如何支撑各自论点

• CRBugBench 证明『bug 接地可行且信息量大』的证据链：92.5% 人工验证有效率 → 判官 κ=0.89/0.95 → 双轨结果分化合理（评论轨 79.6 vs 修复轨 64.2，符合『merge 后漏网 bug 更难』的直觉）→ 回归系数与人类评审文献一致（大 diff 难审在人类研究中早已确立，agent 继承了这一规律，说明测的是真能力）。
• AnonVul 证明『记忆污染真实且巨大』的证据链：匿名化通过零残留审计 → oracle 补丁对照认证 → 配对队列上 19.58pp 的受控差异 → 轨迹级先验知识引用率 31.3% 与成功转移的个案双证。这不是推断，是对记忆效应的直接测量。

六、效果优势的根源解释

6.1 为什么 bug 接地的评测比评论匹配更有效度

先厘清对比对象：baseline 是『以人类评论为真值 + 文本/语义相似度判分』的评测。它的根本局限不在数据量，而在真值函数的定义错误：把『人类说过』当作『正确评审』的充分条件。这导致两个系统性偏差——假阴性（AI 找到人类漏掉的 bug 被判低分）与假阳性（AI 复述人类风格意见得高分却没找 bug）。

CRBugBench 的改变本质上是把真值从『意见空间』移到『事件空间』：bug 是否存在由修复行为（不可伪造的工程事实）锚定。因果链：

真值换成人类验证 bug → 判分问题从『评论像不像』收缩为『发现是不是这个 bug』 → 判官误差方差缩小（κ=0.95）→ 分数与真实检出能力对齐 → recall@5 的每个百分点都可解释为可核实的 bug 恢复。

论文实验对这条链的内部支撑：recall 提升趋势（47.7→71.9）与模型代际一致、回归系数复现人类评审的经典规律、失败漏斗（95.6% 碰文件→56.2% 命中）与轨迹定性分析闭环。

外部交叉验证：论文自己引用的工业证据与此一致——Atlassian 的 RovoDev 大规模在线评审评估、4335 个 PR 的工业实践研究都报告自动化评审的『产出多但高严重度检出并未增加』。Tufano et al.（ICSE 2025）的受控实验发现 LLM 评审增加了低严重度问题发现但未提升高严重度检出——CRBugBench 的 RQ2（严重 bug 检出 OR=1.9 但可用性 OR=0.45）给了同一现象的机制解释：模型被训练偏向高影响问题。CR-Bench（2603.11078）与 Lu et al.（ICML 2025）走缺陷回溯路线得到相近结论，佐证『bug 恢复』是可行的真值设计——但他们没有 CRBugBench 的双轨+工业对照，这是本文增量。本次检索范围内未发现『bug 接地反而不如评论匹配』的相反结论。

6.2 为什么匿名化能分离发现与记忆

Baseline 是『真实软件 + 隐藏答案』式基准（CyberGym 等）。其根本局限：隐藏答案挡不住联想。软件身份（产品名、路由风格、框架指纹）是通往训练记忆里整包知识（历史 CVE、公告、补丁、writeup）的索引键。只要键在，模型就能『认出』而非『推出』。

AnonVul 的改变是切断索引键但保留推理原料。因果链：

身份线索移除（原子+复合）+ 安全语义保留 → agent 无法定位训练中的相关记忆 → 只能从应用行为与源码重建安全模型 → 测得的发现率更接近 first-principles 推理能力 → 匿名/实名的 19.58pp 差即记忆渠道的贡献。

关键在『语义保持』的反事实控制：若匿名化破坏了功能，差异可能来自任务变难而非记忆分离。论文用三层反证堵住这个口子：参考 PoC 匿名后仍触发、补丁版仍拦截、正常功能认证通过。Gitea 反例（实名反而误导）进一步表明身份线索是信息而非纯增益——这与污染文献中『污染可能带来错误先验』的发现同构。

外部交叉验证：HoF-Bench（arXiv:2607.27030）从另一端得出一致结论——前沿模型能重新发现 AI 已发现过的 CVE，暗示对已知漏洞的『再发现』高度依赖先验；AnonVul 的 +19.58pp 定量化了这一依赖。LiveCodeBench（ICLR 2025）的时间窗设计证明题目新鲜度显著影响分数，AnonVul 把同样逻辑推进到『身份新鲜度』。值得注意的边界：AnonVul 的匿名化无法保证零残留（论文自认 limitation——复合指纹难以穷尽），且单一 run 有随机性（论文的 rerun 分析显示同任务同模型成功率会翻转），所以 19.58pp 应读作量级估计而非精确常数。本次检索范围内未发现『匿名化不影响安全评测分数』的相反结论。

6.3 两篇合读的根源综合

把两条因果链并置，可以看到评测效度的两个失效面：

多研究共同支持：真值客观化（可执行判分/oracle 化）提升评测效度——CRBugBench 的三判官、AnonVul 的关系型 oracle、以及 c-CRAB 的评论转测试，殊途同归；记忆效应在代码/安全评测中普遍存在且量级巨大——LiveCodeBench、HoF-Bench、AnonVul 三线合流。

仍属推测的部分：CRBugBench 的『轻信失败』（被 PR 描述带偏）是否随模型规模单调恶化，论文只有个案；AnonVul 的失败分类学（C-I 至 C-V）是否可跨模型族迁移为训练信号，论文未验证。

适用边界：bug 接地只能测 recall（已知 bug 恢复），测不了 precision（评审里有多少废话）与主观价值（架构建议）——论文 1 明确承认这一点；匿名化只对『见过训练数据』的模型有意义，对真正的新系统（或未来训练数据覆盖一切的世界）可能逐渐失效——这恰恰是两篇论文共同指向的未来问题：当训练数据覆盖了所有公开历史，评测必须越来越依赖私有数据（CRBugBench 工业库）或受控构造（AnonVul 匿名化）。

七、必要知识反推

假设让一个完全没有背景的人重做这两篇论文，最少需要哪些知识？

7.1 领域知识层

• 现代代码评审实践（PR 工作流、评审线程、merge 前后语义）——不懂这个就不知道双轨真值的设计空间，也不知道为什么人类评论不可靠；
• 软件仓库挖掘（SZZ 算法、缺陷预测文献）——CRBugBench 的修复轨完全建立在这上面；不理解 SZZ 的噪声模式（重构误判）就不会想到用 LLM 质检 blame 结果；
• Web 应用安全（认证/授权/会话/多租户、CWE 分类、OWASP Top 10）——AnonVul 的三层漏洞分类与业务逻辑选型需要这个判断力；
• 实证软件工程方法（信度系数 κ、Wilson 区间、logistic 回归、聚类稳健标准误、BH 多重校正）——RQ2 的严谨性全靠这些工具。

7.2 方法论知识层

• 评测理论（效度/构造效度、ground truth 设计、判分可靠性）——两篇论文的本质都是效度修复；
• 污染与记忆研究（时间窗设计、身份线索、复合指纹）——AnonVul 的设计直接对话这条线；
• LLM-as-judge 的偏差文献（同族偏好、单判官不稳定）——CRBugBench 三判官设计的动机来源；
• Oracle 思想（程序测试 oracle、差分测试、反事实控制）——AnonVul 的补丁对照就是行为级差分测试。

7.3 工程知识层

• 大规模数据管线工程（GitHub API 抓取、分层抽样、容器化任务、断网沙箱）——两篇都是三十万级候选到百级任务的漏斗工程；
• Agent harness 实操（copilot-cli/Claude Code/Codex/mini-swe-agent 的差异、reasoning effort、成本计量）——没有这些无法做 RQ1/RQ4 的受控对比；
• 运行时插桩（状态 diff、响应捕获、回调监听）——oracle 三机制的技术底座。

7.4 知识融合的关键节点

1. SZZ × 评审评测：把缺陷追溯算法从『预测哪里有 bug』挪用为『生成评审任务』——领域嫁接产生了 1+1>2 的流水线；
2. 指纹匿名化 × 安全语义保持：web 指纹识别研究（防御视角）被反向用作匿名化清单（评测视角）——知道攻击者如何识别软件，才知道要抹掉什么；
3. 受控实验思维 × 基准设计：把『身份』当作可操纵自变量而非背景噪声——这是从『造数据集』到『设计实验』的认知跃迁；
4. 统计因果推断 × agent 行为分析：logistic 回归 + 交互项把『人机谁强』从口水战变成系数表。

八、论文中可以提取的通用性灵感

灵感 1：评测真值应该锚定在『不可伪造的行为事件』上

• 核心思想：当主观产物（评论、文本）做真值时，评测测的是相似性；把真值锚定在行为事件（修复了 bug、触发了效果）上，评测才开始测能力。
• 论文证据：CRBugBench 用修复行为锚定真值后判官一致性达 κ=0.95，而评论匹配类基准无法区分『好但不同』与『差但形似』；AnonVul 的 oracle 只认被禁止效果的发生，agent 自己打印 VULNERABILITY CONFIRMED 不算数（MiniMax 案例实证其必要）。
• 推广场景：① 产品评审（客服回复质量用『客户是否复购』而非文本打分）；② 教育（用『能否解出新题』而非『答案像不像范文』）；③ 医疗 QA（用后续诊疗结果而非回答流畅度）；④ 法律文书审查（用改判率而非文风相似度）。

灵感 2：把混淆变量做成受控实验的自变量

• 核心思想：与其抱怨数据污染无法根除，不如把可疑变量（身份、来源、风格）拎出来做 A/B 配对，直接测量它的贡献率。
• 论文证据：AnonVul 匿名/实名配对把『记忆还是发现』从哲学问题变成 +19.58pp 的测量值；CRBugBench 的开源/私有对照同理测出 25.5% 的上下文依赖。
• 推广场景：① 招聘测评（同一道题换公司名/行业名测真实推理 vs 模板记忆）；② 模型评测普遍适用（换表面措辞保持结构，测不变性）；③ 用户研究（同一产品换品牌 skin 测品牌效应）；④ 竞品分析（隐藏品牌做盲测）。

灵感 3：检索不是瓶颈，诊断才是

• 核心思想：在开放探索类任务里，失败的主因往往不是『没看到证据』而是『看到了却组装不出假设或测试』——改进资源应该投给组合与验证，不是搜索广度。
• 论文证据：CRBugBench 漏斗 95.6% 碰到缺陷文件但只有 56.2% 命中；AnonVul 的 Keycloak 案例（两个要素都在轨迹里、12 格无人合取）、n8n 案例（Kimi 找到缺失的授权绑定却没做实验）、C-V 类失败；扩预算只救回 8/160——搜索加深不解决组合问题。
• 推广场景：① 医疗诊断（检查数据齐全但误诊，应训练假设组合）；② 安全运营 SOC（告警富集 ≠ 定性能力）；③ 科研（文献都读过但没人连点成线）；④ 调试（复现路径都在日志里，缺的是因果假设）。

灵感 4：先验知识是双刃剑——它会定向而不只是加速

• 核心思想：恢复上下文线索带来的不一定是均匀提升，而是结果的重新分配：指向目标则大赚，指向历史则被带沟里。
• 论文证据：实名化 64 格败→胜、17 格胜→败；Gitea 上 Kimi 被历史 CVE 清单带偏全程；CRBugBench 中 agent 被 PR 描述与代码注释带偏（Selenium 案例）。
• 推广场景：① 专家系统的锚定偏差（经验丰富者在新范式下反而更慢）；② RAG 系统设计（检索到过时知识可能有害，需要新鲜度门控）；③ 团队管理（老员工的『经验』在业务转向时的副作用）；②④ 风控（历史模型对新风险类型的盲区）。

灵感 5：人机分工要用交互项找，不要拍脑袋

• 核心思想：『人机协作』的具体分工点应该由统计交互效应给出（谁在哪类子任务上相对占优），而非宏观替代叙事。
• 论文证据：CRBugBench 回归交互项：人类 ×可维护性 OR=2.702（人强），人类×严重 bug OR=0.450（agent 强）；合并覆盖 82.1% vs 各自 50%/71.9%。
• 推广场景：① 医疗（医生管沟通与伦理、AI 管影像穷举）；② 翻译（人管文学性、机器管术语一致性）；③ 法务（AI 管全量检索、人管策略判断）；④ 自动驾驶（机器管常规、人管长尾接管）。

灵感 6：harness 会过期，评测要持续化、私有化

• 核心思想：任何针对特定模型弱点的 scaffolding 设计都会被下一代模型的训练吸收；对自家场景，最可靠的评测是私有数据上的持续监测。
• 论文证据：全面提示词对 opus-4.8 +5.5pp、对 opus-5 ≈ 0（行为已被训练内化）；论文明示『此前有用的 harness 设计可能过时，需随模型演化定期重估』；工业库骤降 25.5% 说明公共基准外推不到私有场景。
• 推广场景：① 企业 AI 采购（用自己数据建持续评测而非信厂商榜单）；② 个人工作流（prompt 技巧定期失效复盘）；③ 教育测评（防应试化需要题库滚动更新）；④ 任何对抗性领域（防御方也要假设攻击方在进化）。

结语

这两篇论文放在一周内出现，某种程度上是必然：当 agent 能力曲线陡峭上行，所有既有的尺子都在快速失真——不是刻度不够密，而是刻度本身量错了东西。CRBugBench 告诉我们尺子要钉在 bug 上，AnonVul 告诉我们读数前要先排除记忆的折光。对评测设计者，它们是两份可直接套用的方法模板；对模型研发者，它们暴露的两类短板（非局部推理、假设组合）指明了下一阶段的训练方向；对工业界，『关灯工厂』的答案暂时清晰：先把人机配比做成回归系数，再谈关灯。