此前的观察把“配置被读取”“任务结束”和“目标行为正确”分开：它们都可能在界面上显示成功，却没有承诺同一件事。今天的新增材料让这个区分再向前一步。Jepsen 的反例不仅问数据库有没有测试，还问测试能不能在基本功能错误时失败；OpenRouter 的教程则展示，定位一个真缺陷和交付一个好补丁之间，仍可能发生新的损害。
两者共有的机制，是检查必须对某个具体错误敏感。若约束未实现时测试照样通过，成功记录不会随着实现变好而变得更有意义。若补丁只满足新反例，却损坏原本支持的输入，复现记录也不能证明修改值得接受。因此，一份有用的验收依据至少要说清输入条件、期待行为、实际观察，以及修改前后哪些行为应保持不变。
这并不要求每个小工具先建立庞大证明体系。可以从一个最常见的承诺开始：数据提交后应仍能读到，审查修复后原有调用者应继续工作。先写一个能打破承诺的例子，再确认正常例子依然成立；对于难以直接给出标准答案的任务，可以比较两个实现，或者改变输入而检查应保持的关系。但差分测试也会受到合法语义差异影响，检查方式仍需要解释。
框架测试补充了另一层：即便所有功能检查通过，质量目标仍未必完整。小应用一次生成的费用，不能替代持续修改的理解成本。框架的约定可能帮助人和 Agent 缩小选择范围，也可能给简单页面增加负担。这里最该改变的判断，是停止寻找一个能包办选型的单项分数，转而把分数对应的任务阶段写清楚。
可迁移到日常工作的做法，是让交付同时携带一小份可检查说明：做了什么、哪一个例子曾失败、修改后怎样变化，以及还有什么没有检查。它的价值在于让下一位使用者少猜测，而不是让报告显得更正式。若随后要比较 AI 是否省时，就应把写检查、解释差异和处理退化的时间也算进去；本期材料没有共同的人时对照，不能先宣称这种做法已经提高总效率。
另一种解释
同一次通过也可能来自较简单任务、较窄输入或更多人工准备；没有匹配条件，不能把收益全部归因于模型或检查设计。
接下来观察什么
跟踪可公开复跑的失败用例、补丁后保真检查和接手成本，尤其关注检查能否在故意破坏功能时报警。