旧失败能回放，旧成功也要留下

把失败留下来，还要让对照看得见退步

Schaller 为扫描仪写 Linux 驱动时，一度停滞了数月。重新尝试后，关键变化是让模型能在 Windows 虚拟机里操作真实设备，并从宿主机观察 USB 通信。[1] 这里值得学习的并非几小时这个速度，而是反馈变得具体：同一个操作在两边留下什么差异？此前知识库里的反编译记录，也把可运行与语义一致分开了。今天再回读，它仍提醒我们先说清保留的是哪种行为，而不只是增加审阅次数。[4]

不过，一份参考抓包并不是设备全部行为的说明书。hw-harness 的方法文档要求记录空闲状态、操作条件和成对抓包，并强调一次只改一个设置；没有可观测总线的 MIPI 摄像头，则要改查配置和设备信息。[2] 因而我的判断要补上一层：有外部参照还不够，参照必须与当前失败处于可比较的条件下。把 USB 的办法原样套到 MIPI 上，工具再勤快也可能观察错对象。

Cortex 把相似思路用于项目规则：保存修复前的状态、原始请求和能区分修复前后的检查，再比较加规则与不加规则的重复运行。[3] 它还记录规则是否真的进入上下文。这能排除一种常见误判：规则压根没被读到，结果却因抽样波动好了一次。作者在合成仓库上报告明显收益，但真实项目几乎没有反复纠正，最后没有学出新规则。这种空结果本身有用，它阻止我们把每次工作结束都想象成一次学习。

最需要保留的反例藏在有害候选实验里。Cortex 没有保留那些候选，却不能据此说它成功识别了伤害：一些技能从未被打开；初筛又集中于原本失败的任务，缺少原先成功、加规则后反而失败的对照。甚至有一次出现退步，程序仍因没有可显示收益的任务而没有形成判定。[3] 这改变了我对旧问题的表述：除了问检查会漏什么，还必须问测试集有没有给那种错误一次出现的机会。

PreciseCoder 则把“不该改”的情况带进调试评测。它除了看最终测试，也用参考修复和反事实执行判断哪些修改有必要，并另测原本正确的代码会不会被改坏。[5] 这与 Cortex 的坏规则检查并非同一个实验，但都暴露了只收集失败案例的盲点：旧失败适合测修复，新退步还需要旧成功来测。与此同时，少改几行并不天然更好；论文自己的消融显示，直接偏好小补丁会牺牲通过率。

发布前补读的ARC Prize结果又增加一种区别：同一Argon模型采用不同执行层，成绩相差很大，但Standard还有运行未完成，且没有从分母删除这些任务。[6] 这个差值不能全部算给状态保存机制。可比较的输入之外，还要记录一次尝试有没有真正完成；中断、未曝光和没有形成判定，都不宜悄悄归成同一种能力失败。

我会据此把一次规则更新的回放分成两组：它声称能修好的失败，以及原先已经成功、可能受它波及的任务。固定模型和代码状态，记录规则曝光、通过率、改动范围与耗时；硬件任务另固定介质、分辨率和采集层。这个方案是编辑提出的验证办法，尚未由这些工作共同验证。它也不要求把所有开放目标都变成字节匹配：旧反编译作者明确承认，语义相同的实现也可能匹配失败。[4] 对照要服务于承诺，过宽会漏错，过窄也会挡住有效改进。

收益也可能来自更好的工具接入、规则加载方式或模型升级；合成项目、真实硬件和Python修复的结果不能合并为统一效果。

查找同时覆盖旧失败和旧成功的配对试验，区分未曝光、无判定、真正识别伤害及误拒；保留同语义不同实现的有效反例。

相关条目：扫描仪驱动从停滞到可对照：Schaller 的硬件逆向实践 / Cortex：规则要被读到，收益也要经得起重复运行 / PreciseCoder 给必要修改计分，也检查正确代码会不会被改坏 / ARC Prize 的 Argon 结果：同模型，两种执行层与不完整运行

来源 1 · 来源 2 · 来源 3 · 来源 4 · 来源 5 · 来源 6