创建人员：Codex
文件职责：定义实验设计审核、实验执行审核、复审、问题归因、通过标准和审计报告记录规则。
管理规范/模板：common/exp-doc/实验规范.md；本文件是实验审核专用规范。
引用文件：../../管理系统说明.md；实验规范.md；实验总纲模版.md；实验设计模版.md；
统一依赖：本规范必须同时遵守 ../../全局规范.md 和 ../project-doc/项目规范.md；项目本地实验审核规范可补充流程，但不得违反全局规范、全局项目规范和本体系硬约束。
实验审核是实验事项的质量关口。
它不负责替执行者重新做实验，也不负责无边界地增加要求。
它只回答：
common/exp-doc/实验审核规范.md 是全局通用审核规范。
所有项目的审核员都必须遵守本文件。每个项目创建实验环境时都必须创建项目本地 exp-doc/实验审计规范.md。项目本地审计规范默认可以很短，只引用本文件并声明必须遵守；如果补充项目特化规则，不能违反本文件的硬约束。具体审核流程可以按 1A.1 设计本地版本。
实验审核员可以维护项目本地 exp-doc/实验审计规范.md，仅限修正实验审核流程、审计口径和阻断标准；不得借此修改被审的 实验规范.md、实验总纲、实验设计、执行日志、结果包或主产物。如确需修改实验执行规范，应创建规范维护事项，或额外授予实验体系维护 / 规范维护角色。
项目本地审核规范允许补充：
项目本地审核规范不得削弱：
如果项目本地审核规范与 common 审核规范冲突，审核员必须在审计报告中指出，并要求先修项目本地审核规范；冲突未解决前，不应通过受影响实验。
项目可以设计本地实验流程。审核员先审核流程设计是否满足 common 硬约束，再审核执行是否按已通过的本地流程完成。
如果本地流程只是新增流程，审核重点是输入输出、证据链、责任角色和审核点是否清楚。
如果本地流程修改 common 默认流程，审核重点是覆盖范围、替换原因、证据链和结论边界是否写清，且不得削弱目标、来源聊天、执行日志、审计闭环和不过读要求。
本地流程通过设计审核后，执行审核以该本地流程为准；审核员不得再用 common 默认步骤重复卡已被本地流程合法替换的细节。
审核实验设计时，必须先看实验总纲里的来源聊天记录、实验目标和实验设计。
判断设计是否合理，以“能否满足它自己声明的目标”为主。
如果目标缺失或不清楚，必须反馈 目标缺失 / 目标不清，不能替实验者假设一个目标后继续审核。
如果来源聊天记录里的用户要求和实验目标或实验设计不一致，必须反馈 来源要求不一致。不能只按实验设计本身审核。
实验审核不吹毛求疵。
只有会影响目标、结论、数据、流程、可复核性或下游使用的问题，才作为审计问题。
审核员发现的审计问题主记录写入实验审计报告；如需跨轮跟踪，再在实验问题记录中建立索引。
如果实验事项包含实验开发，实验开发的方案审核、实现审核、测试验收和复审结论也统一写入 exp-doc/实验审计报告.md，不另写到 dev-doc/开发审计报告.md。
实验开发中的临时草稿脚本可以不做独立代码审核；但只要代码用于生成正式实验结果、候选池、收益统计、图表、验收包、结果包、结论 readout 或可复用工具，就必须纳入实验审核。审核重点不是把轻量脚本套成重型开发流程，而是确认结果可信：
以下内容默认不作为阻断问题：
审核员不能把轻量实验强行升级成重型发布流程。
如果当前目标只是观察、探索、验收图形或验证一个局部现象，不应要求它补齐全链路工程发布证明。
但如果实验结论要升级为正式规则、实时决策策略、工程主链或长期方法论，必须补齐对应证据。
窄样本只能读成窄样本结论。
小样本验收不能读成全市场规则成立。
结构解释成立不能读成预测 ready。
工程 smoke 通过不能读成 full-history 正式通过。
不是所有实验都必须防未来函数。
是否需要防未来函数，必须由实验目标决定：
如果实验审计很复杂，审核员可以分步骤审计，也可以按需使用辅助 AI 或 subagent。
要求：
审计过程中如果发现正式文档、执行日志、结果表、图片说明、manifest 或审计证据链上的关键文件存在乱码、编码错误、无法读取、路径失效，必须报告。
如果乱码或不可读文件影响目标、设计、执行过程或结论判断，审计不得通过；如果不影响当前结论，可以记录为一般问题或建议。
设计审核发生在实验执行前。
输入：
输出：
通过：设计能回答目标，可以执行。不通过：设计不能回答目标，必须修改后复审。HELD：缺关键资料，暂时不能审核。设计审核必须记录到项目：
<project>/exp-doc/实验审计报告.md
执行审核发生在实验执行后。
输入：
输出：
通过：执行和证据足以支撑当前结论，实验可完成。不通过：存在影响结论的问题，必须修复、补证据或重跑。HELD：证据缺失，暂时不能判断。执行审核必须记录到项目：
<project>/exp-doc/实验审计报告.md
当设计或执行审核不通过后，执行者修复问题，再进入复审。
复审只关注：
标准流程：
读取实验总纲
-> 读取实验设计
-> 对比来源聊天记录、实验目标和实验设计
-> 确认目标和原理来源
-> 检查设计是否能回答目标
-> 检查数据、样本、对照、边界是否支撑目标
-> 检查防偏差要求是否足够
-> 检查输出产物是否方便复核
-> 写入实验审计报告
-> 通过则允许执行；不通过则退回修改
设计审核重点：
标准流程：
确认设计审核已通过
-> 读取执行日志
-> 读取结果包和关键产物
-> 核对输入、输出、样本、时间范围
-> 核对执行过程流水和中间数据路径
-> 核对实现是否按设计执行
-> 抽查关键案例或样本
-> 按实验目标判断是否需要检查未来函数
-> 检查时点错位、样本污染和必要的未来函数风险
-> 检查结论是否过读
-> 写入实验审计报告
-> 通过则实验完成；不通过则退回修复或重跑
执行审核重点：
执行审核硬口径：
每次审核默认至少检查：
| 检查项 | 核心问题 |
|---|---|
| 目标 | 实验到底要证明什么 |
| 来源聊天 | 用户原始要求、实验目标、实验设计是否一致 |
| 设计 | 方法是否能满足目标 |
| 数据 | 数据源、样本、时间范围是否合理 |
| 对照 | 是否需要对照组、边界样本或负样本 |
| 实现 | 代码、规则、人工步骤是否按设计执行 |
| 过程 | 执行过程流水、关键中间数据路径是否完整 |
| 产物 | 结果包、summary、manifest、图表是否存在且对得上 |
| 案例 | 关键样本是否能人工复核 |
| 偏差 | 是否按目标处理未来函数、样本污染、时点错位 |
| 结论 | 是否存在过读 |
审核发现问题时，必须明确问题类型。
允许类型：
实验设计问题：目标、方法、样本、对照、验收标准不合理。执行问题：没有按设计执行，或执行记录缺失。数据 / 产物问题：输入缺失、产物为空、旧包污染、summary 和数据对不上。代码实现问题：脚本、算法、字段、分支和设计不一致。流程 / 调度问题：执行顺序、重跑、缓存、source 切换、结果包归档错误。结论过读：结论超过证据支持范围。待归因：证据不足，暂时不能判断根因。如果是 待归因，必须写清下一步要查什么，不能直接转给执行者“修 bug”。
问题严重级别分为：
阻断：会推翻结论、必须重跑、或不能进入下一阶段。重要：不一定推翻结论，但会明显影响可信度或下游使用。一般：需要记录或后续处理，但不阻断当前目标。建议：非问题，只是改进建议。只有 阻断 和必要的 重要 问题应阻止实验完成。
未来函数不是所有实验的统一硬要求。
如果实验涉及预测、收益率、回放、自动动作或任何实时决策判断，必须检查未来函数。
如果实验是后验理解、案例复盘、图形归纳、方法论总结，应检查结论是否降读，而不是强制按实盘时点安全否决实验。
审核员要判断：
如果实验目标和实际结论发生错位，例如设计说只是后验理解，结论却写成可实时使用或 prediction ready，必须按结论过读处理。
设计审核通过条件：
执行审核通过条件：
出现以下任一情况，默认不能通过：
每次审核完成后，必须写入对应项目：
<project>/exp-doc/实验审计报告.md
如果项目没有该文件，应按 实验审计报告模版.md 创建。
实验审计报告是项目级滚动账本，不是单次审核文件。每次设计审核、执行审核或复审都必须追加到文件末尾，最新内容在最后；历史审计不得删除，只能追加复审或替代说明。
审核员发现的问题应在实验审计报告中记录完整问题、证据、影响、是否阻断、修复建议和复审要求。实验问题记录只在需要跨轮跟踪时登记索引或关联，不替代审计报告的问题清单。
审计报告至少记录：
审核员对外汇报时，默认先说结论。
推荐格式：
结论：通过 / 不通过 / HELD
是否有阻断问题：有 / 无
关键发现：...
影响：...
建议：...
下一步：...
如果没有问题，应明确说“未发现会影响当前目标和结论的阻断问题”，不要扩大成“绝对没问题”。
审核员不应做以下事：
审核员应做以下事：