principle-prove-it-works

证明它有效

直接检查实际结果，验证每项任务的输出。不要根据代理指标、自我报告或“能编译”来推断。

**原因：**未经验证的工作，正确性无从得知。间接验证（文件修改时间、输出是否为最新、Agent 自我报告、缓存的屏幕截图）看似成本更低，但基于错误推断采取行动，代价远高于检查源头。

检查实际对象，而非代理指标：

• 直接检查进程是否存活，不要通过派生状态间接判断
• 读取实际值，不要读取缓存或派生表示
• 验证失败时，先怀疑观察方法，再怀疑系统

核对已接受的范围

根据最初接受的要求进行检查。计划、摘要或委派不能悄然缩小范围。将每项要求关联到证据，或在现有任务记录中明确标出差距。任何未满足的要求都意味着不能声称任务已全部完成。保留任何 backstop 或 judgment 标签，并单独记录经授权的范围变更。如已有运行记录，请复用。

如果工作包含威胁模型或安全审查，请将每项已声明威胁与受威胁边界上的缓解证据逐一对应。声称已缓解不等于证据。记录已授权责任人承担的已接受风险、附有责任人和证据的已转移责任，或尚未解决的差距。未解决的威胁必须在完成判定中保持可见。

将证据与结果关联

记录每项检查所针对的工件、适用时的修订版本，以及相关环境。合并变更后，针对集成后的结果重新运行受影响路径的检查。各分支分别通过，并不能证明合并后的结果也通过。

如果任务或项目要求运行指定的验收辅助工具，就运行它。如果无法运行，请报告这一差距。在将替代方案视为等效方案之前，须根据相同的验收标准说明其合理性。

尽可能将检查脚本化

最有力的证据是能重复运行相同比较的确定性脚本，而不是一次性的目测检查。编写并运行脚本，将其输出保留为工件，供审查者重新运行，而不是让他们相信你的说法。

让人工审查者能看到该工件。使用 show-me-your-work 技能处理记录留存和证据保留规则。