第 7 部分 验证
为什么需要单独一部分#
v3 提出了 9 条命题（2.7）、27 条原则（第 3 部分）、12 条建议（6.4）和 8 个路线图实验（6.6）。如果没有检验方法，它们只是一套更好听的说法。
一心行动的验证有三个特殊困难：
- 样本很小：产品目前只有一位真实用户，同时进行的目标不多。常规的组间对照实验做不了。
- 目标在变：复杂目标本身会被改写，基线不稳定。
- 一人多角：产品开发者、唯一用户和评估者往往是同一个人，AI 模块又同时参与执行和记录。这会带来系统性的偏差。
本部分给出对应的方法：
- 7.1 单被试实验设计：用多基线、交替处理和微随机化，在一个人身上做出可信的因果判断。
- 7.2 过程追踪与贡献分析：检验「改动是不是通过预想的机制起作用」，而不只是「数字有没有变」。
- 7.3 一人多角的偏差与对策：预注册、自动计量、盲评和替代解释清单。
- 7.4 检验计划总表：把 9 条命题和优先建议分别对应到具体的设计、指标和证伪条件。
三个层次的问题#
验证要回答的问题分三层，不能混在一起：
| 层次 | 问题 | 主要方法 | 例子 |
|---|---|---|---|
| 产品层 | 这个改动有没有改变用户的行为？ | 单被试设计（7.1） | 懒建模之后，首次触达的前置时间缩短了吗？ |
| 机制层 | 是不是通过预想的机制改变的？ | 过程追踪（7.2） | 前置时间缩短，是因为少建模，还是因为那几周恰好时间多？ |
| 理论层 | 背后的命题对不对？ | 多个产品实验的结果汇总 | 命题一「触达优先」在多个目标上是否成立？ |
产品层的结果只回答产品层的问题。一次改动有效，不等于背后的理论成立；一次改动无效，也可能只是实现得不好。〔推断〕
大声失败的要求#
所有实验，包括失败的和中途停止的，都要留下记录：做了什么、预测了什么、看到了什么、结论是什么。只报告成功的实验，会让系统对自己的理论越来越自信，却越来越不准 （Nosek 等, 2018；Open Science Collaboration, 2015）。这也是第 10 条工程准则「大声失败」在验证上的版本。