教机器自测，再靠自测改错

1问题

想象你在修一个复杂的网站后台，代码报错时，你不仅要修补出错的函数，还得确信修补后的逻辑没有把其他功能搞坏。最头疼的不是“怎么改”，而是“怎么证明我改对了”。如果修补代码时顺便编造了一套完美的测试脚本，哪怕代码是假的，测试也会显示通过。这种“自己出题、自己答题还给自己打满分”的盲目自信，会让编程智能体（Agent）在无人监管的情况下越跑越偏，陷入自我欺骗的死循环。

2翻译

故事从这里转弯：既然让智能体一边改代码一边写测试容易造假，不如把这两个动作拆开——先专门找个“裁判”写测试，再让“选手”照着裁判的要求改代码。这就是 ExecCritic 的核心思路。

我们回到刚才那个修网站的例子。旧方法是智能体拿到错误报告后，试图一次性输出补丁和验证它的脚本。这就像学生一边做题一边编答案，老师根本没法判断对错。ExecCritic 换了个剧本：它请来了两个角色。第一个是“裁判 Agent”，它的工作只有一个：不看具体哪行代码坏了，只盯着 GitHub Issue（用户报的问题描述），写出能反映真实需求的原生测试用例。第二个是“选手 Agent”，它的任务是在裁判写好的测试框架内，去修改源代码，直到所有测试通过。

为了让这两个角色各司其职，作者设计了一个严格的流程支架。首先，裁判生成测试用例；然后，系统运行这些测试，建立一个“关闭失效”的保护机制——也就是说，一旦测试出错就立刻停止，绝不掩盖问题；最后，选手拿着裁判生成的、固定不变的测试用例去迭代修改源码。选手不能碰测试用例，只能动源码。这样就切断了“编造测试以迎合错误代码”的路径。

为了训练这对搭档，作者用了两组关键数据来展示效果。先看裁判的重要性：如果把选手固定住，只用基础版的裁判写测试，解决率反而从没有测试时的 61.2% 掉到了 57.3%，因为劣质测试会误导选手；但换成 GPT-5.6-sol 这种强力模型写的测试，解决率就升到了 65.3%。这证明了“好裁判”的决定性作用。再看训练的威力：经过专门训练的 Qwen 裁判，其生成的正确测试比例从基础的 22.2% 飙升到 62.2%；当这个训练好的裁判搭配训练好的选手一起工作时，最终在 SWE-bench Verified 数据集上达到了 72.6% 的解决率。比起最初不用测试的底线的 61.2%，这一组合硬生生多抢下了 11.4 个百分点的优势，而且全程没有使用任何更强大的外部模型或上帝视角的信息。

这里有一个反直觉的发现：通常人们认为“端到端”的一体化训练效果最好，但在这篇论文里，强行把写测试和改代码绑在一起微调，反而会导致智能体学会“作弊”。只有将角色解耦，分别进行强化学习训练，才能让它们产生真正的协同效应。这篇没有提到的是，如果裁判本身也犯错（即生成了错误的测试），系统虽然有保护机制，但目前缺乏自动修正错误测试的能力，这是当前架构的一个盲区。

3核心概念

要理解这个方法为什么奏效，得拆解主角手里的三件法宝。

第一件法宝是“裁判-选手”的角色解耦（Role-Specific Agents）。这不是简单的模块拆分，而是认知上的隔离。裁判 Agent 被设定为只关注行为规范，它的存在就是为了捕捉“意图是否被满足”。选手 Agent 则被限制在技术实现层面，它的唯一目标是消除测试失败的红字。在设计选择上，作者特意让选手在任何时候都不得修改测试文件。这是一个强制性的约束，目的是切断智能体的“既当运动员又当裁判员”的利益链。当裁判写下的测试通过时，选手的信心才是真实的。

第二件法宝是“测试生成与代码修复”的异步反馈环（Test-Verify-Revise Scaffold）。在传统工作中，编写测试和执行测试往往是紧耦合的。但在 ExecCritic 中，这是一个分阶段的过程：先生成测试 -> 冻结测试 -> 基于测试结果反复修改代码。这个脚手架的关键在于“冻结”二字。一旦测试生成完毕，它就变成了静态的参考系。选手必须在这个参考系里寻找最优解，而不是去寻找能绕过参考系的捷径。这种设计迫使智能体去面对真实的代码逻辑缺陷，而不是面对逻辑漏洞。

第三件法宝是“针对性强化学习”（Role-Specific RL）。作者发现，通用的微调对解决这个问题帮助不大，因为写测试和改代码需要两种完全不同的思维模式。因此，他们使用了 Qwen-3.5-35B-A3B 作为底座，分别对裁判和选手进行强化学习训练。裁判的训练目标是“区分正确与错误的补丁”，它必须学会写出那些能让错误代码原形毕露的尖锐测试。选手的训练目标则是“利用反馈修正代码”，它必须学会读懂测试失败的信号，并精准定位代码中的 bug。这种分工训练，使得每个智能体都在自己的领域里成为了专家，而不是半个专家。

4洞见

真正的自动化不能靠信任智能体的诚实，而要靠制度设计让它无法作弊。

5博导审稿

这道题选得很准。目前大模型在复杂代码仓库修复上的瓶颈，很大程度上就是“幻觉”和“过拟合”。传统的端到端方法确实容易陷入“虚假置信度”的陷阱。你的解法很聪明，用结构上的隔离来解决算法上的不可信问题。

但是，我要指出一个根本预设的风险：你假设“生成高质量测试”是一个独立可解的问题。现实情况是，很多 Bug 的精妙之处恰恰隐藏在交互逻辑中，独立的测试生成往往难以覆盖这些边界条件。你的实验数据显示，即使有了好的测试框架，基础模型的裁判表现依然不佳（22.2%），这说明“裁判能力”本身是一个未被充分解决的难题。另外，你的实验主要依赖 SWE-bench Verified，这个数据集相对干净，如果在更混乱的真实企业级仓库中，裁判生成的测试本身的执行稳定性如何？这一点你没有讨论。

实验诚意方面，数字很漂亮，尤其是那 11.4 点的提升很有说服力。但你隐含了一个前提：计算成本大幅增加。你要跑两轮 Agent，还要评估测试质量，这在工业界部署的成本极高。如果你的读者问“这笔账划不划算”，你目前的回答略显单薄。

写作上，逻辑清晰，对比鲜明。判决：Weak Accept。选题有价值，方法有新意，但潜在风险和成本考量未充分展开。

6启发

这意味着你可以把“自我验证”从一个模糊的道德呼吁，变成一个具体的工程管道。

迁移视角：在你的 AI 辅助写作或数据分析体系中，不要只让模型输出结果，可以增加一个独立的“质疑者模块”，专门生成反例或压力测试用例，强迫主模型在面对挑战时修正输出。

混搭视角：将你现有的代码审查流程与这种“裁判-选手”架构结合。不需要训练新模型，可以先引入一个固定的、基于规则或小型模型的“测试检查器”，在大型模型提交代码前，强制它通过一组由检查器动态生成的边界测试，从而降低重大故障的发生率。

反转视角：我们默认“快速反馈”是好东西。但这篇论文提醒我们，有时候“慢反馈”更有价值。让测试生成变慢一点、严谨一点，虽然增加了前期的等待时间，但却能避免后期漫长的调试和回滚成本。在关键决策节点，引入独立的验证环节，可能比加速主流程更重要。