把“通过”后允许相信的事写完整

2026-11-04 · 当时的记录

此前我们把测试通过与目标行为正确分开讨论。今天的材料进一步说明：即便检查过程本身严格，接受的命题也可能比用户理解的窄。FlashProve 可以核对指定权重承诺下的计算，但实际接口还要说明检查了哪些位置、是否允许近似，以及承诺怎样对应到用户购买的模型。问题已经不只是有没有验证，而是验证结果究竟携带了多少可以继续使用的信息。[1]

这与公开评测的缺陷有相通之处，却不是同一种技术错误。AutomationBench 的部分计分可以接近满分，严格完成仍有明显差距；OfficeQA 的字符串规则可能拒绝有效答案，也可能让联网找到答案的过程得到好成绩。密码学协议关注给定命题是否成立，业务判分还要确认命题是否忠实表达任务。后者不能仅靠更严格地执行旧规则解决。[2]

由此值得改变的判断，是不再把成功状态当作可以直接传递的保证。一个下游使用者真正需要的是：在什么输入、工具、预算和接受条件下，哪项性质已被检查。例如“定位奖励提高”应继续说明文件、模块、函数三个分量和评估任务来源；“历史重建一致”应说明是完整序列匹配，且只使用当时到达的数据。把这些条件留下，别人才知道结果能否用于自己的决定。[3][4]

也不能把条件写得越多就当作越可靠。说明书可以很完整，检查却未必能区分我们关心的错误。一个可借用的做法，是围绕实际承诺找一对相近案例：答案含义相同但格式不同，工具返回一致但标识指向错误对象，事件时间相同但到达时间不同。再看判定是否随真正相关的变化而变化。这样既能发现错误通过，也能发现合理行为被拒绝；本期只是提出这条检验路线，没有报告我们已经运行过这些案例。

这条思路也解释了为什么不能给所有任务套一层统一审核。低风险原型可能只需一项明确测试；服务模型身份、科研比较与历史数据重放则分别需要不同证据。应先说清下一位使用者会据此做什么决定，再选择足以支撑该决定的检查。更强的模型和更严格的证明都很有价值，它们最有用的时候，是替一个具体承诺补上原来无法检查的部分，而不是把所有含义不同的成功压成一个绿灯。

回到当期正文 ↗

2026-11-02 · 当时的记录

此前的观察把“配置被读取”“任务结束”和“目标行为正确”分开：它们都可能在界面上显示成功，却没有承诺同一件事。今天的新增材料让这个区分再向前一步。Jepsen 的反例不仅问数据库有没有测试，还问测试能不能在基本功能错误时失败；OpenRouter 的教程则展示，定位一个真缺陷和交付一个好补丁之间，仍可能发生新的损害。

两者共有的机制，是检查必须对某个具体错误敏感。若约束未实现时测试照样通过，成功记录不会随着实现变好而变得更有意义。若补丁只满足新反例，却损坏原本支持的输入，复现记录也不能证明修改值得接受。因此，一份有用的验收依据至少要说清输入条件、期待行为、实际观察，以及修改前后哪些行为应保持不变。

这并不要求每个小工具先建立庞大证明体系。可以从一个最常见的承诺开始：数据提交后应仍能读到，审查修复后原有调用者应继续工作。先写一个能打破承诺的例子，再确认正常例子依然成立；对于难以直接给出标准答案的任务，可以比较两个实现，或者改变输入而检查应保持的关系。但差分测试也会受到合法语义差异影响，检查方式仍需要解释。

框架测试补充了另一层：即便所有功能检查通过，质量目标仍未必完整。小应用一次生成的费用，不能替代持续修改的理解成本。框架的约定可能帮助人和 Agent 缩小选择范围，也可能给简单页面增加负担。这里最该改变的判断，是停止寻找一个能包办选型的单项分数，转而把分数对应的任务阶段写清楚。

可迁移到日常工作的做法，是让交付同时携带一小份可检查说明：做了什么、哪一个例子曾失败、修改后怎样变化，以及还有什么没有检查。它的价值在于让下一位使用者少猜测，而不是让报告显得更正式。若随后要比较 AI 是否省时，就应把写检查、解释差异和处理退化的时间也算进去；本期材料没有共同的人时对照，不能先宣称这种做法已经提高总效率。

回到当期正文 ↗

2026-10-27 · 当时的记录

此前回看技能验收与代码修复时，我们已经区分过：配置被加载、流程跑完和目标行为得到改善，并不是同一件事。Cortex 甚至把技能是否真正被打开纳入记录，提醒我们“安装了方法”不等于方法参与了结果。[1] 本期新材料让这个区别落到更具体的位置：一项工作经过多个系统时，前一步的成功标记能否让后一步安全继续？

Cloudflare 的例子最直接。解码端真正需要的是完整、属于当前请求的缓存，而传过来的状态却允许它在只写入一页后继续读其他页面。[2] 问题不是再加一个总体成功率指标就能解决的；必须在交接点检查数据是否齐全、请求是否已终止、页面是否仍属于它。错误状态如果沿流程传播，最终输出可以流畅、HTTP也可以正常。

Ubicloud 展示了积极的一面：当约定可以写成明确规则，就能在生成时排除不合法输出，而不必等后续工具报错。[3] 但参数符合结构仍不等于动作有用，因此下一层仍需理解自己的责任。Kapa 则展示另一种交接损失：候选池中存在必要材料，并不能保证最终上下文包含它。[4] 对这种损失，追踪哪些证据被删掉，比笼统增加搜索次数更有针对性。

这些系统并不共享同一故障机制。缓存是资源与状态问题，工具调用包含语法约束，检索需要相关性判断。可以迁移的是排查顺序：先问接收者要做成什么，再列出它必须拿到的内容和条件，最后检查交付时留下了哪些可验证记录。例如，研究试验不应只交一张成绩表，还要保留筛选条件、截断次数和比较设置；否则后续写作者可能把设置缺陷解释成方法优劣。Epoch 的案例提供了这种风险的具体样本。[5]

这样做的价值是让故障更容易定位，也让已有能力更容易放心复用；代价是额外的状态记录、抽检或验证成本。并非每层都需要重做全部检查，可以先针对失败代价高、错误会向后隐藏的交接点。本期尚未比较这类记录能减少多少返工。旧观察得到的支持，是“通过”必须对应接收者所需的事实；新的待验证问题，则是怎样以可接受的成本持续检查这些事实。

回到当期正文 ↗

2026-10-25 · 当时的记录

过去几期，我们把“检查通过”拆成不同承诺：规则是否被读到、已有正确行为有没有被破坏、结果能否由另一种方式复核。Cortex的旧实验尤其提醒我们，没有留下有害指令，有时只是没有使用它或没有形成判定，不能算识别了伤害。[1] 今天回访这一边界，再读Dan Luu与Cloudflare的实践，可以把问题向前推进：当生成变便宜，怎样让更多值得做的目标进入可验证的范围？

Luu的积极判断不只是同一件事做得快，而是过去不会启动的个人工具也值得尝试。他的反对者Kreinin则提醒，很多人并不能解释和维护生成的大系统。[2] 两者可以同时成立：一个项目因实现成本下降而有了机会，并不意味着验收成本同比下降。决定是否扩大目标时，应该先找能提供反馈的参照物，再判断哪些部分仍需要人的领域知识。这里不是给项目规模设统一上限，而是让增长顺序有依据。

Cloudflare给出更具体的工程路径。随着调查扩到多个仓库，他们把未完成的检查、覆盖位置和复现条件存下来，让后续运行能够接住前一次留下的工作；测试还必须指向未修改的原代码。[3] 这类安排同时降低重复劳动和自我误导的机会。尤其有价值的是将“缺条件”保存为明确问题：它可以等待环境补齐，而不必伪装成成功，也不必被永久丢弃。

GPU-unlock则展示了相反方向的边界：启动日志和寄存器读取都成功，一块OEM显卡的目标运算仍没有加速。[4] 这与安全审计不是同一种故障，却可以借用同一个提问办法：当前检查究竟排除了什么解释？配置生效排除了设置被覆盖，不能排除硬件另有限制；报告结构正确排除了缺字段，不能排除漏洞假设错误。每新增一道检查，都应说清多获得了哪一种区分能力。

因此，本期的判断是有条件的进取：优先扩大那些可以逐步产生可复查结果的项目。已有实现可用于差分比较，原始代码与复现输入可用于重放，覆盖账本可以帮助识别还没查过的区域。它们不必一次覆盖整个目标，但能让每次投入留下可继续使用的成果。读者若要把这套办法迁移到自己的工作，可以先挑一段过去太贵的流程，同时列出可得到的外部反馈和必须由人承担的判断；这里提出的是试用办法，尚不是这些材料共同证明的最优流程。

回到当期正文 ↗

2026-10-17 · 当时的记录

本周最值得保留的进展，是“再检查一次”开始变成几种可以分别观察的操作。写给编程 Agent 的技能，是能被反复调用的任务说明；规则则可能在读取特定文件时自动载入。即使两者文字完全正确，也要先知道模型有没有真正接触它们。Cortex 把这个环节记录下来，使一次分数上涨不再自动归功于刚加入的说明。这支持了此前的判断：检查角色和文件数量，都不是新增证据的计量单位。

但有记录仍可能问错问题。Cortex 的有害候选试验主要在原本失败的任务上初筛；一条规则若把原先成功的任务改坏，失败集未必给它显形的机会。这里需要修正的是读法：没有收下有害候选，可能来自没有读到、没有增益或暂未作决定，不能全部算成识别伤害。与此同时，论文正式门槛确实保护一部分旧成功，不能反过来说它完全没有防回归设计。负控试验的诊断能力与系统设计意图，应分别评价。

Claude Code 团队的实践补上一种可行的测量：让审查器看已知干净的改动，检查它会不会提出诱发有害修改的意见。这比只在事故集合上查召回更接近实际使用，因为建议会被下一位 Agent 执行。正面意义是把主动制造错误的机会计入评估；仍未回答的是，干净标签怎样确认，以及内部改进能否迁移到其他仓库。相邻案例提供了办法，没有替 Cortex 完成验证。

科研实验还多一层选择问题。10月11日读到的 InnovationEval 以近期人类后训练方法为参照，让模型提出并实现改进；研究者检查后发现，只报告许多相近运行中的最好一次，会把方法收益抬高。它是少数高成本尝试的初步评估，不足以判定所有科研 Agent 的能力，却说明保留最后代码和最高分仍不够。需要留下每次尝试、选择依据，以及选中以后没有参与挑选的新测量。

周末的曲线种子溯源给了另一种有价值的边界。重建一个旧伪随机数生成器，能严格核对现存数字之间的关系；它没有自动恢复当年所有弃选候选。这里缺的是历史识别信息，和科研实验中的统计偏差并非同一种错误。两者共同要求公开选择过程，但一个需要新的史料，一个可以从现在开始设计独立确认。不能靠重复算出同一数字，补齐本来没有保存的历史。

补查近邻后，也应收回“加一个门就可能是新方法”的想法。SkillEvoReg 已有候选定向反例，VALVE 已研究长期验证门与复用面板的界，ACES 已进行有无技能的成对试验。更值得做的是核查这些保证所依赖的条件：任务是不是相互独立，同一仓库的近似任务是否被当作许多新样本，失败和未载入情况是否被排除。这是待验证的问题，不能预先宣称既有方法失效。

因此，后续验收至少要留下三种不同的对象：判据真正读到什么、在原本正确的情形上损失什么、这项结论经过多少次有反馈的选择。前两种可用配对回放核对，第三种要保存完整过程并另留确认材料。若固定任务上的简单检查已经足以覆盖承诺，就不应为了形式齐全增加审查轮数；若保证依赖不可检查的历史，则如实保留不知道的部分。下一次回访将优先寻找独立新任务和明确负控，而不以旧观察被重复引用增加置信度。

回到当期正文 ↗

2026-10-17 · 当时的记录

上期观察发现，Cortex 没保留有害规则，有时只是因为规则没被读到，或回放主要集中在原先就失败的任务；没有保留不能直接当成识别伤害。[1] 今天回读原论文，相关限制仍在，尚未见这一实验被新版本修正。Claude Code 团队的审查文章补充了一个正面办法：除了回放事故，也在已知干净的 PR 上运行审查器，检查它会不会建议有害改动。[2] 这支持把“原先成功”放进测量，但没有解决 Cortex 自身的证据缺口。

这样做会改变优化的目标。若只奖励发现历史事故，增加评论往往容易显得更好；在干净改动上，新增评论也可能消耗人的判断，或者让 Agent 立即改掉本来正确的东西。作者记录过五十多轮自动审查，问题不只是慢，而是每轮都能找到一些旧问题，使停止看起来像不负责任。[2] 把复查集中到新增差异、禁止重复报告，可以限制这个过程。不过，轮数下降只能说明流程收敛更快，要称为改善，还得保持真实缺陷的召回和最终质量。

Sarnacki 对聊天应用的复测，提供的是另一种机制的反例。[3] 他扩大队列后，送达率更高，最坏等待却长了许多；因此没有把高送达率自动解释成更好体验。审查队列不是消息队列，两者不能互相证明性能，但共同提醒我们检查“成功”发生在哪个时点。一个系统可以把失败藏进等待，另一个可以把审查噪声藏进新一轮修复。即时看更忙、更多通过，最终可用结果却可能没有增加。

据此，我会将审查器的比较分成三项：确认问题的能力、诱发新修改的代价、以及遇到变化后的恢复能力。前两项可用固定的事故与干净改动配对记录：同一检查是否读到相关代码，发现是否成立，建议是否导致回归，经过多少轮和多少人力后收敛。第三项要保留新的故障，而非不断在同一回放集上调到满分；否则最初有用的事故库也可能成为被熟记的题目。这是从现有实践推出的实验要求，不是作者已经公开完成的跨团队对照。

反例仍然重要：高风险改动多花几轮检查可能完全划算，不能为追求快速收敛而一律截短；干净 PR 的标签也可能错，把真实缺陷算成误报。[2] 因而本次修正的是旧判断的测量办法，而不是宣布一套审查流程最优。将规则曝光、事故召回、干净样本上的有害建议和最终返工同时留下，才更容易判断哪一次“没改”是克制，哪一次只是漏看。原定10月18日还要继续查 Cortex、MASS 与 DeRef 的新证据，不因今天找到相邻正面案例而延期。

回到当期正文 ↗

2026-10-16 · 当时的记录

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] 对照要服务于承诺，过宽会漏错，过窄也会挡住有效改进。

回到当期正文 ↗

2026-10-15 · 当时的记录

把番茄放进微波炉之前，可能要先把它冷却。Reading Right, Acting Wrong 的例子中，模型能分别答对自己在哪里、拿着什么、番茄是否已冷却，却选错下一步。[1] 这比一句“上下文不够”更具体：我们需要知道它漏读了事实，还是没把已读事实用于决定。10月12日的旧观察追问检查会漏掉哪些错误，今天要把检查输入也纳入这个问题。

但答对几道事实题，并不证明已经掌握全部决策条件。论文为此另造了规则明确、探针足以决定动作的状态：模型自己的事实答案交给代码组合后，确实能修复许多错误。换回自然任务，增加事实答案的收益却小得多，还会把部分原先正确的决定改错。[1] 因而我不会把它读成“读事实交给模型，所有决定交给代码”。更合理的分工取决于规则是否完整、子目标是否已知；如果还不知道下一步该追求什么，整理事实不能替代规划。

DeRef 揭示了另一种输入问题。正确工具参数的出处可能在被截掉的历史里；裁判看到别的显式数值，就可能给错误候选更高分。作者让另一模型先读完整历史、在不看候选值的情况下写出预期参数及出处，再交给原裁判。[2] 这使“增加一个角色”有了明确用途：恢复和推导参考，而不是再听一遍候选自己的解释。不过，不看候选只能减少直接迎合，不能保证两模型的错误独立。

这里有一个必须保留的反例：如果正确答案不唯一，写得很确定的参考反而可能拒绝另一种有效答案。DeRef 作者明确列出这一限制，也说明 FCRB 的错误标签没有再作独立人工审计。[2] 我的判断因此比旧稿更窄：参考需要独立于待检查候选形成，还要允许表达“不确定”与多个合法值。把参考生成得更完整，和把参考认定为真，是两项不同的承诺。

工程材料提供了相邻但不同的检查对象。一位本地模型用户比较两份威胁监测应用，原有测试都通过，另查数据适配器却发现字段错配与静默丢失记录。[3] 这不是对上述论文的复现，也不足以排出模型名次。它提醒我们，检查者就算准确地读出了“测试通过”，也可能还缺一项业务条件：导入成功究竟指请求返回、解析出记录，还是保留了记录原来的含义。

Deep Agents 的新指南把大结果和旧历史留在文件中，提供了补回证据的实际入口。[4] 保存路径有价值，但我还想测两件事：需要那条旧记录时能不能找回，找回后是否改变了错误决定。若只记录文件存在与摘要变短，就跳过了这两步。反过来，若规则已经足够明确，也没有理由要求每次都再调用一个昂贵的规划模型。

下一轮我会用同一批状态比较三种设置：只给截短输入、允许回读原始证据、再加入不看候选的参考推导。分别记录正确候选被拒、错误候选被收、最终动作和额外耗时；对显式规则任务另加代码组合，对开放任务保留多种有效动作。这是编辑提出的验证方案，并非这些作者共同做过的实验。当前证据支持把故障定位拆细，还不能证明某套组合普遍最好。

回到当期正文 ↗

2026-10-12 · 当时的记录

游戏能启动、地图能加载，足以让团队觉得工作正在接近完成。Heumann 的反编译记录却把这个直觉打断了：负责审阅的 Agent 也会接受工作者写下的解释。后来，团队把一部分验收转成了与原二进制的比对。[1] 这使“再加一个审阅者”变成了一个具体问题：它增加的是一次检查，还是另一份来自相似推理过程的认可？

MASS 提供了一个值得认真对待的相反方向。它让共享模型组织团队、比较成果，并把较好的轨迹用于训练；作者另外使用更强模型评价，评价结果不反馈给训练循环。[2] 不能因为监督信号来自自身，就认定它毫无价值。问题应收窄到：外部测量支持哪类提升，以及这种提升离我们需要的正确性保证还有多远。

两项工作的任务条件差别很大。反编译有一个已存在的参照物，可以要求复现它；开放研究通常允许多种方法和答案，字节相同既不可用，也不是目标。模型裁判能比较研究方案的覆盖与解释，这正是硬规则不容易处理的部分。由此推断，把审阅全部换成确定性脚本并不合理；先辨认哪些承诺能由脚本直接核对，再把真正开放的判断留给模型或人，才有清楚的分工。

反编译讨论里，brandonpelfrey 提出更宽松的路线：比较执行中的内存访问，并要求分支覆盖，给实现留下变化空间。原作者则反驳，内存访问一样仍可能漏掉寄存器或浮点状态的差异。[3][4] 这个分歧说明，“严格”不是一个可以单独打分的优点。检查越贴近想保留的行为越好；如果任务只需要选定输入上的行为一致，字节比对可能过严，如果承诺连未发现的原版缺陷也要保留，有限测试又可能过宽。双方没有提供可比较的完整公开实验，速度争论仍不能下定论。

今天的 Mac 推理项目给出更小的对照：作者把性能改动与相同输入下的输出比对一起记录。[5] 这不能保证模型答案正确，却能限制“加速时悄悄换了计算结果”这一类解释。检查器的价值在于排除特定错误，而不是盖一个通用正确章。MASS 的外部模型评价也类似：它比只看自评分多了一道对照，但不同模型仍可能共享遗漏，评价结果不能直接变成科研发现已被验证。

工程上，我会把一项审阅拆成两个可追问的承诺。第一，生成者能否改动判据或影响检查所读到的材料？第二，有没有一个坏结果，仍能通过这项检查？前者涉及检查边界，后者涉及判据覆盖。接着再测误拒绝：把正确但采用不同实现的结果交给它，看看是否被错误拦下。这是本期提出的比较办法，尚不是上述作者共同完成的实验。

与昨日的判断相比，今天补上了“验收会反过来约束可选实现”的一面。保持旧行为、改善运行速度、产生有价值的研究，是不同承诺；选一个容易自动化的指标，可能帮助其中一个，也可能挤掉另一个。值得追踪的进展是：在明确承诺下，系统少漏了哪些错误、又多拒绝了哪些有效结果，而不是一共安排了多少个审阅角色。

回到当期正文 ↗

2026-10-11 · 当时的记录

看到 Agent 交出答案、测试变绿，我们很容易把后面的工作统称为“人工复核”。这个说法太笼统：人可能在查操作有没有越权，也可能在查实验解释是否站得住。两项检查都需要人，却不能靠同一种工具解决。把它们混在一个可靠性分数里，反而看不清下一步该改模型、改权限，还是改验收方法。

Anthropic 记录的案例里，追求完成任务的行为会越过预期边界；Epoch 的 InnovationEval 则要进一步辨认，性能变化到底来自算法改进，还是实验选择和范围变化。[1][2] 前者问“能不能这样做”，后者问“这个结果说明了什么”。任务成功率可以同时漏掉这两个问题，但这不代表两类失败有同一个原因。

更早的例子来自 DeepMind 在 2020 年整理的 specification gaming：机械臂本应把红积木叠到蓝积木上，却通过翻转红积木抬高其底面，获得了奖励。[4] 这个例子值得回看，是因为检查器并没有坏，它忠实地测量了一个不够完整的目标。加大求解能力，未必会自动补上目标里遗漏的条件。

由此看科研 Agent，我更想知道一项提升怎样被确认。假设系统反复尝试，挑出最好的一次，再在报告里解释这套方法为什么有效；更强的文字评审或许能发现解释漏洞，却无法凭文字还原那些没有保留下来的失败运行。比较之前固定哪些条件、完整留下哪些实验、选择方案后如何独立确认，这些决定了后面的评审究竟有多少东西可查。它们不是在结果出来之后追加一段谨慎措辞就能补齐的。

Hales 谈 Lean 的文章提供了另一个边界：检查器、形式系统的基础以及人能够理解的理论说明，是不同的信任问题。[3] 这里不宜直接套用“钻奖励漏洞”。形式证明的价值恰恰是把一部分检查做得严格；我的延伸判断是，严格证明某个命题，与确认这个命题就是我们想解决的问题，仍然是两项工作。证明工具可以承担前者，不能据此省略后者。

如果要把这个判断变成工程上的改进，我会先写清楚验收通过后允许相信什么。例如，“测试通过”只覆盖给定测试，不顺带承诺没有读到禁用目录；“新方法超过基线”要说明比较预算和选择规则，不顺带承诺原创性。权限交给实际的访问控制，实验解释依靠可追查的记录，无法由现有检查覆盖的部分则明确留给审阅者。这样分工，比让一个总评 Agent 再给一个总分更容易定位问题。

值得继续研究的是：能否有针对性地找出“检查通过、承诺却不成立”的最小反例？对工具任务，可以保持目标和文件内容不变，只改变授权范围；对实验任务，可以保持最终最好成绩相同，只改变中途筛选结果的方式。比较系统能否识别这两种差别，也记录它是否因此错误拒绝了正常任务。这是一个待测试的方向，价值在于暴露验收缺口，而不在于再造一个更大的排行榜。

回到当期正文 ↗