一句话

把一句断言改写成可证伪的形式，同环境各抓一份 baseline 和 treatment 原始产物对比，只回 VERIFIED、NOT VERIFIED 或 INCONCLUSIVE 三种结论。

何时用

• 适合：「verify this」「修好了吗」「给我看证据」；bug 修复要前后复现；UI、CLI、API、性能、内存断言要测量。
• 不适合：「代码是不是更干净了」这类不可测量的说法，先让用户给出可测断言。

怎么用

验证一下：这个修复让列表页首屏渲染从 2 秒降到 500ms 以内

1. 把断言写成可证伪形式：条件、指标、阈值。
2. 选最小的能推翻它的本地面：单测或复现脚本、ctk-control-cli 终端 transcript、ctk-control-ui 截图、HTTP 响应 diff、同机计时、heap snapshot。
3. 从 merge base 或父提交抓 baseline，用同命令、同数据、同预热抓 treatment。
4. 对比原始产物，按判定规则给唯一结论。

产出

• 固定格式的结论块：verdict、claim、各项指标的 baseline/treatment/delta/threshold、一段点名证据和混杂因素的推理；产物可放 /tmp/verify-this/<claim-slug>/。

要点与坑

• INCONCLUSIVE 也是有效结论：拿不到有效 baseline、信号噪、测量失败、环境不一致都算。
• 产物可能含敏感代码、截图、heap 时只保留最小内联证据，除非用户同意落盘。
• 不许软化负面结果，一个清楚的 NOT VERIFIED 很有用。

关联

• 上游：ctk-control-cli、ctk-control-ui · 同类：ctk-run-smoke-tests
• 所属：00-ctk-概览 · 工作流：W1-快修、W6-高风险加固层