未必。
ExeCRE 那篇论文出来的时候（arXiv 2608.04439，ASE 2026），我第一反应不是“这方法真巧”，而是“原来大家默认要修的东西，本身就是坏的”。
先说它干了什么。不靠测试用例，不靠 LLM 自己给反馈。喂一堆随机输入进去，看执行输出的一致性，再用 Dawid-Skene 那套从众数标签推断真值的统计模型，估计这段代码靠不靠谱。
这思路朴素到有点土。土得像是同行早想过，又觉得“这也算方法”，就没写。
但它戳的问题不土。
自校正这个方向，大家默认瓶颈是“代码错了能不能改对”。换句话说，默认错误代码是敌人。ExeCRE 给了个难堪的数字：LiveCodeBench 上用 GPT-5.2，一个代表性的自校正基线，会在本来正确的代码上平均产生 113.2 次误导性反馈。
一百多次。对着正确的代码。
所以很多时候不是模型改错了，是反馈先错了，改才错的。医生最大的失误不是治不好病，是把健康人治出病来。
这里值得停下来想想。
我们为什么默认反馈是对的？因为反馈来自模型，而模型“看过了代码”。这个默认很可疑。模型给的反馈，本质是它对代码的一次内部采样，不是对代码真值的一次测量。采样有噪声。自校正的流程把每次采样都当测量用——错了就修，修完再采。噪声被当成了信号。
随机输入加输出一致性，反而更像测量。同一份代码，喂一百个随机输入，输出乱成一团，这大概率不是巧合，是代码内部有不确定的东西在。输出高度一致，说明行为稳定。稳定性不等于正确性，但至少这个信号可重复观测，不像模型反馈那样每次重新掷骰子。
你可能反对说，输出一致也可能一致地错——一个系统性 bug，每个输入都触发同一个错。这个反问成立¹。但注意比较对象：模型反馈同样会对系统性 bug 一致地说“没问题”。两边都瞎的地方，一边便宜、可重复、不占用判断力，另一边贵、随机、还长得像判断力。选哪边不难。
真正让我在意的不是方法本身。是它暗示的分工变化。
反馈的质量问题，被一个统计模型而不是一个更大的模型解决了。这事如果推广开，形状会有点不一样：agent 流程里那些“让模型再检查一遍”的步骤，可能本来就不该由模型来做。执行一致性、不变量检查、行为稳定性——这些信号的来源在代码本身，不在模型。模型擅长生成，不擅长给自己生成的东西做质检。让作者审自己的稿，审得越多，稿子越像审稿人喜欢的样子。这话听着耳熟。
他们还把同一套策略搬到基于代码的数学推理上，也看到类似改进。这个细节比主实验更让我信。数学推理场景里“正确答案”更难定义，测试用例更难写，而执行一致性照样能用——说明这个信号抓的是代码的属性，不是任务的属性。可迁移的是信号，不是任务。
开头的说法可以收紧一点。不是“自校正这个方向错了”，是它一直把力气花在“怎么改”上，而更早的一环——“该不该改”——没有对应的机制。ExeCRE 补的就是这一环。113.2 降到 14.0，降的不是错误率，是把手术刀从健康人身上拿开的次数。
如果我对，接下来可以验证的推论是：agent 框架里会出现更多这种非 LLM 的守门信号——便宜、机械、可复算的检查，插在模型动作和真实修改之间。模型负责动，别让它负责决定动不动。
这个判断我也还没完全想清楚，但暂时这么认为。
¹ 系统性错误下输出一致但代码错误，这时 ExeCRE 会给高分。论文里 Dawid-Skene 推断的是潜在可靠性，一致性只是观测信号，理论上能压一部分，压不掉全部。这类边缘情况作者自己也承认存在，我不替他们藏。