claim-verify

主张验证循环

对结果草稿进行逐条主张的对抗性验证。验证对象是草稿；反馈信号是未验证主张的数量——尚未核查，或虽已核查但尚未通过压力测试的主张。你要将其降至零：每条主张最终都应得到验证（能够复现并经受明显威胁），或得到恰当限定（加上保留措辞、缩小适用范围，或说明理由后撤回）。

这项纪律是：仅仅能够复现的数字并不可信——大多数错误发现也能顺利复现。只有在经受住最可能推翻它的威胁后，主张才算得到验证：离群值、混杂因素、样本量小到毫无意义的子组，或经分层后符号反转的结果。此循环是对现有草稿的把关流程，而不是生成新发现的工具。

适用场景

当你已有一份草稿（或一组主张），这些内容源自某个数据集，并希望在发布前对每条主张进行红队审查时，使用此流程。默认验证草稿中的每条独立主张；如果用户指出了几条高风险主张，就优先处理这些主张，但仍要检查其余内容。此流程不适用于开放式地探索新发现（那是 data-analysis 循环的用途），也不适用于诊断某个已知异常。

设置

以交互方式确定绑定项。如果工作目录中存在 loop.run.yaml，就加载它，用一行确认各项值，然后直接进入循环。否则：在 Claude Code 中（可使用 AskUserQuestion 工具），推断每个绑定项的可能值，并将其作为建议选项呈现；在其他宿主环境中，则分别以引用的纯文本提示询问。然后写入 loop.run.yaml（格式见：examples/run.example.yaml），并在创建任何其他文件前确认各项值。

绑定项	含义	默认值	推断方法
<draft>	待验证的结果/主张文档（markdown/text）	—	扫描工作目录，查找结果或报告文件
<dataset>	主张所依据的数据；只读的事实依据	—	扫描工作目录，查找数据文件
<analysis_cmd>	在用户环境中运行检查代码片段的解释器	python3	检查工作目录中的 pyproject.toml/.venv/uv
<report>	此循环生成的已验证/修订草稿	<sandbox_root>/verified.md	—
<sandbox_root>	检查代码片段和台账的存放位置	./sandbox	—
<budget>	最大迭代次数	10	—

检查代码片段通过 <analysis_cmd> 在用户的环境中运行，因此可以使用用户已安装的任何内容。辅助代码应优先使用标准库（csv、statistics）：如果代码片段需要 pandas/numpy，则通过 try/except ImportError 探测，并降级到标准库实现；或者在获得同意后提供 uv pip install "pandas==<ver>" 命令——绝不假定该软件包已安装。

循环

复制此检查清单，并逐项勾选：

• 迭代 0 — 从 <draft> 中提取可单独核验的主张；不将任何内容记为已验证。
• 选取一项未经验证的主张。
• 从 <dataset> 中复现其确切数值；若无法复现 → refuted。
• 针对最可能推翻该主张的威胁进行压力测试；分类为 verified / fragile。
• 修订 <report>：保留已验证的主张；对脆弱的主张加以限定、收窄范围或撤回；纠正被推翻的主张。
• 追加一行账目记录；该主张随即移出未验证集合。当没有未验证主张时，或达到 <budget> 时，停止。

迭代 0 — 提取主张。 阅读 <draft>，列出其中可单独核验的主张，并为每项标明其断言的数值／效应及其主张类型（组间差异、相关性、因果／政策主张、亚组结果、比率）。这些构成当前未验证集合。如果草稿是叙述性文字，首先要做的就是将其拆分为可单独核验的主张。

然后，持续执行，直到停止（所有主张均已处理，或达到预算）：

1. 选取一项未经验证的主张。

2. 复现——第一道关卡。 编写 <sandbox_root>/iter<N>/check.py，从 <dataset> 重新计算该主张所述的确切统计量。使用 <analysis_cmd> 运行，并将输出重定向到 <sandbox_root>/iter<N>/out.txt（不要让输出淹没上下文）。如果数值无法复现 → 标记为 refuted（数值有误）；跳到第 4 步。

3. 压力测试——第二道关卡。 针对最可能推翻该主张的一到两个威胁进行测试，威胁类型取决于主张的类型：

   • 异常值敏感性 — 去掉极端点／使用稳健统计量重新计算。效应是否依然存在，还是由少数几行数据驱动？
   • 混杂因素与辛普森反转 — 按明显的混杂因素分层；效应在各层内是否成立，还是发生反转？如果因果／政策主张在亚组内反转，则不受数据支持。
   • 亚组规模与多重比较 — 亚组有多大？该结果是否来自众多比较之一？n=5 时引人注目的比率只是噪声。
   • 替代设定 — 采用站得住脚的不同切分方式（不同分箱、控制协变量）。方向／大小是否保持不变？

   分类为：verified（能够复现且经受住测试）或 fragile（能够复现，但在合理的压力测试下消失或反转）。如果某项主张的数值能够复现，但其暗示的解读并无数据支持——例如把描述性差距包装成因果结论（“治疗有效”）、把极小样本的比率说成“更优”，或把单点相关性称为“早期预警信号”——则应标记为 fragile，而不是已验证：统计量没有问题，从中得出的结论却站不住脚。

4. 修订草稿。 更新 <report>：

   • verified → 保留该主张，并说明它通过了哪项稳健性检验。
   • fragile → 弱化、限定范围或降低权重，使其符合数据支持的程度（例如：“描述性结果较高，但层内比较出现反转——这并不能证明治疗导致了康复”），或撤回。绝不要让脆弱的主张维持原样。
   • refuted → 用正确数值纠正，或将其删除。 记录判定结果和证据。

5. 记录一行账目，然后继续；该主张随即移出未验证集合。

账目

<sandbox_root>/ledger.tsv，使用制表符分隔，文本中不得出现逗号。表头：

iter	claim	verdict	threat	resolution

verdict ∈ {extract, verified, fragile, refuted}。示例：

iter	claim	verdict	threat	resolution
0	claims extracted	extract	-	7 claims listed
1	treatment recovery rate > control (70.6 vs 55.0)	verified	reproduced; holds	kept
2	treatment causes higher recovery (+16pp)	fragile	Simpson: control >= treatment within both age groups	rescoped to descriptive; causal claim retracted
3	biomarker correlates with recovery_days (r=0.16)	fragile	one outlier drives it (r=0.16 -> 0.02 without it)	retracted
5	pilot site 100% recovery (superior)	fragile	n=5 subgroup	hedged: too small to conclude

报告结果：<report> 的路径、每项主张的判定结果，以及摘要——已验证、弱化或撤回的主张各有多少项，以及发现的最重要的一项脆弱性。

约束

• 既要复现，也要进行压力测试。 仅能复现的说法未经验证；它必须经受住最可能推翻它的威胁。跳过压力测试，正是此循环旨在防止的失败模式。
• 每个判定都必须有 <report> 中记录的重新运行作为依据； 不得凭直觉放过或否定任何说法。
• 脆弱的说法必须修改，不能原样保留——将其限定在数据支持的范围内，或撤回，因为照原样保留正是未经验证的草稿最终发布的原因。
• 区分描述与因果关系——“治疗组恢复得更多”可能属实，而“治疗导致恢复”却可能被混杂因素推翻；应准确说明数据支持什么。
• 只能读取 <dataset>——绝不修改它，因为它是核验每个说法所依据的真实基准。沙盒完全自包含（无法通过 ../ 越界）。
• 每次迭代只处理一个说法，以便将每个判定归因于特定说法。
• 不要暂停循环询问是否继续；持续运行，直至所有说法均已解决或达到 <budget>。

停止条件

• 已解决——不再有未经验证或尚未解决的脆弱说法。
• 预算——已达到 <budget> 次迭代。