过去几期，我们把“检查通过”拆成不同承诺：规则是否被读到、已有正确行为有没有被破坏、结果能否由另一种方式复核。Cortex的旧实验尤其提醒我们，没有留下有害指令，有时只是没有使用它或没有形成判定，不能算识别了伤害。[1] 今天回访这一边界，再读Dan Luu与Cloudflare的实践，可以把问题向前推进：当生成变便宜，怎样让更多值得做的目标进入可验证的范围？
Luu的积极判断不只是同一件事做得快，而是过去不会启动的个人工具也值得尝试。他的反对者Kreinin则提醒，很多人并不能解释和维护生成的大系统。[2] 两者可以同时成立：一个项目因实现成本下降而有了机会，并不意味着验收成本同比下降。决定是否扩大目标时，应该先找能提供反馈的参照物，再判断哪些部分仍需要人的领域知识。这里不是给项目规模设统一上限，而是让增长顺序有依据。
Cloudflare给出更具体的工程路径。随着调查扩到多个仓库，他们把未完成的检查、覆盖位置和复现条件存下来，让后续运行能够接住前一次留下的工作；测试还必须指向未修改的原代码。[3] 这类安排同时降低重复劳动和自我误导的机会。尤其有价值的是将“缺条件”保存为明确问题：它可以等待环境补齐，而不必伪装成成功，也不必被永久丢弃。
GPU-unlock则展示了相反方向的边界：启动日志和寄存器读取都成功，一块OEM显卡的目标运算仍没有加速。[4] 这与安全审计不是同一种故障，却可以借用同一个提问办法：当前检查究竟排除了什么解释？配置生效排除了设置被覆盖，不能排除硬件另有限制；报告结构正确排除了缺字段，不能排除漏洞假设错误。每新增一道检查，都应说清多获得了哪一种区分能力。
因此，本期的判断是有条件的进取：优先扩大那些可以逐步产生可复查结果的项目。已有实现可用于差分比较，原始代码与复现输入可用于重放，覆盖账本可以帮助识别还没查过的区域。它们不必一次覆盖整个目标，但能让每次投入留下可继续使用的成果。读者若要把这套办法迁移到自己的工作，可以先挑一段过去太贵的流程，同时列出可得到的外部反馈和必须由人承担的判断；这里提出的是试用办法，尚不是这些材料共同证明的最优流程。