# 实验审核规范

创建人员：Codex  
文件职责：定义实验设计审核、实验执行审核、复审、问题归因、通过标准和审计报告记录规则。  
管理规范/模板：common/exp-doc/实验规范.md；本文件是实验审核专用规范。  
引用文件：../../管理系统说明.md；实验规范.md；实验总纲模版.md；实验设计模版.md；

统一依赖：本规范必须同时遵守 `../../全局规范.md` 和 `../project-doc/项目规范.md`；项目本地实验审核规范可补充流程，但不得违反全局规范、全局项目规范和本体系硬约束。

## 1. 定位

实验审核是实验事项的质量关口。

它不负责替执行者重新做实验，也不负责无边界地增加要求。

它只回答：

1. 实验目标是否清楚。
2. 实验设计是否能满足目标。
3. 实验是否按设计执行。
4. 关键数据、代码、案例、产物是否对得上。
5. 是否存在会影响结论的真 bug、样本污染、口径替换或结论过读。
6. 如果实验目标要求时点安全，是否存在未来函数。
7. 当前结论能不能成立，最多能读到什么程度。

## 1A. 全局审核规范和项目本地审核规范

`common/exp-doc/实验审核规范.md` 是全局通用审核规范。

所有项目的审核员都必须遵守本文件。每个项目创建实验环境时都必须创建项目本地 `exp-doc/实验审计规范.md`。项目本地审计规范默认可以很短，只引用本文件并声明必须遵守；如果补充项目特化规则，不能违反本文件的硬约束。具体审核流程可以按 1A.1 设计本地版本。

项目本地审核规范允许补充：

1. 项目专用审核样本口径。
2. 项目专用结果包检查项。
3. 项目专用数据源、图表、案例的复核方式。
4. 项目专用问题分级细则。
5. 项目专用审核记录位置。

项目本地审核规范不得削弱：

1. 审核必须先看目标和来源聊天记录。
2. 审核必须检查实验设计能否满足目标。
3. 审核必须检查执行是否按设计走。
4. 审核必须检查结论是否过读。
5. 审核必须抓真问题，不得吹毛求疵或层层加码。

如果项目本地审核规范与 common 审核规范冲突，审核员必须在审计报告中指出，并要求先修项目本地审核规范；冲突未解决前，不应通过受影响实验。

### 1A.1 本地实验流程审核口径

项目可以设计本地实验流程。审核员先审核流程设计是否满足 common 硬约束，再审核执行是否按已通过的本地流程完成。

如果本地流程只是新增流程，审核重点是输入输出、证据链、责任角色和审核点是否清楚。  
如果本地流程修改 common 默认流程，审核重点是覆盖范围、替换原因、证据链和结论边界是否写清，且不得削弱目标、来源聊天、执行日志、审计闭环和不过读要求。

本地流程通过设计审核后，执行审核以该本地流程为准；审核员不得再用 common 默认步骤重复卡已被本地流程合法替换的细节。

## 2. 审核原则

### 2.1 目标优先

审核实验设计时，必须先看实验总纲里的来源聊天记录、实验目标和实验设计。

判断设计是否合理，以“能否满足它自己声明的目标”为主。

如果目标缺失或不清楚，必须反馈 `目标缺失 / 目标不清`，不能替实验者假设一个目标后继续审核。

如果来源聊天记录里的用户要求和实验目标或实验设计不一致，必须反馈 `来源要求不一致`。不能只按实验设计本身审核。

### 2.2 只抓真问题

实验审核不吹毛求疵。

只有会影响目标、结论、数据、流程、可复核性或下游使用的问题，才作为审计问题。
审核员发现的审计问题主记录写入实验审计报告；如需跨轮跟踪，再在实验问题记录中建立索引。

如果实验事项包含实验开发，实验开发的方案审核、实现审核、测试验收和复审结论也统一写入 `exp-doc/实验审计报告.md`，不另写到 `dev-doc/开发审计报告.md`。

以下内容默认不作为阻断问题：

1. 文案不漂亮。
2. 命名风格不统一但不影响读法。
3. 可选优化项。
4. 与目标无关的边角料。
5. 审核员个人偏好的额外实验。

### 2.3 不层层加码

审核员不能把轻量实验强行升级成重型发布流程。

如果当前目标只是观察、探索、验收图形或验证一个局部现象，不应要求它补齐全链路工程发布证明。

但如果实验结论要升级为正式规则、实时决策策略、工程主链或长期方法论，必须补齐对应证据。

### 2.4 结论范围必须和证据范围一致

窄样本只能读成窄样本结论。

小样本验收不能读成全市场规则成立。

结构解释成立不能读成预测 ready。

工程 smoke 通过不能读成 full-history 正式通过。

### 2.5 未来函数按目标判断

不是所有实验都必须防未来函数。

是否需要防未来函数，必须由实验目标决定：

1. 涉及时序决策、收益率、预测、实时筛选、回放、自动动作的实验，必须防未来函数。
2. 后验理解、图形归纳、案例复盘、方法论总结类实验，可以不按实盘时点安全审核，但结论必须降读。
3. 如果实验设计没有说明是否需要防未来函数，设计审核应要求补清楚。

### 2.6 复杂审核可以拆分，但必须可追踪

如果实验审计很复杂，审核员可以分步骤审计，也可以按需使用辅助 AI 或 subagent。

要求：

1. 审核员必须在实验审计报告中记录本次审计拆分了哪些检查步骤。
2. 辅助 AI 或 subagent 的发现必须由主审核员复核后再写入最终结论。
3. 不得直接转发未经复核的碎片结论。
4. 拆分审计不能变成额外加码，只能用于降低复杂审计的漏查风险。

### 2.7 乱码和文件可读性

审计过程中如果发现正式文档、执行日志、结果表、图片说明、manifest 或审计证据链上的关键文件存在乱码、编码错误、无法读取、路径失效，必须报告。

如果乱码或不可读文件影响目标、设计、执行过程或结论判断，审计不得通过；如果不影响当前结论，可以记录为一般问题或建议。

## 3. 审核类型

### 3.1 设计审核

设计审核发生在实验执行前。

输入：

1. 实验总纲。
2. 实验设计。
3. 实验总纲中的关键来源聊天记录。
4. 原理来源文档。
5. 必要的前序实验或数据说明。

输出：

1. `通过`：设计能回答目标，可以执行。
2. `不通过`：设计不能回答目标，必须修改后复审。
3. `HELD`：缺关键资料，暂时不能审核。

设计审核必须记录到项目：

```text
<project>/exp-doc/实验审计报告.md
```

### 3.2 执行审核

执行审核发生在实验执行后。

输入：

1. 已审核通过的实验设计。
2. 执行日志。
3. 结果包入口。
4. 关键数据、图表、summary、manifest 或等价产物。
5. 必要的脚本、代码、配置和样本案例。

输出：

1. `通过`：执行和证据足以支撑当前结论，实验可完成。
2. `不通过`：存在影响结论的问题，必须修复、补证据或重跑。
3. `HELD`：证据缺失，暂时不能判断。

执行审核必须记录到项目：

```text
<project>/exp-doc/实验审计报告.md
```

### 3.3 复审

当设计或执行审核不通过后，执行者修复问题，再进入复审。

复审只关注：

1. 原问题是否已修复。
2. 修复是否引入新问题。
3. 是否需要重跑或补充结果包。
4. 结论是否需要降读。

## 4. 设计审核流程

标准流程：

```text
读取实验总纲
-> 读取实验设计
-> 对比来源聊天记录、实验目标和实验设计
-> 确认目标和原理来源
-> 检查设计是否能回答目标
-> 检查数据、样本、对照、边界是否支撑目标
-> 检查防偏差要求是否足够
-> 检查输出产物是否方便复核
-> 写入实验审计报告
-> 通过则允许执行；不通过则退回修改
```

设计审核重点：

1. 目标是否清楚。
2. 原理来源是否写清。
3. 来源聊天记录、实验目标、实验设计是否一致。
4. 方法是否能回答目标。
5. 样本和对照是否合理。
6. 关键边界是否写清。
7. 是否需要防未来函数的判断是否合理。
8. 样本污染、source 切换等风险是否被处理。
9. 输出产物是否足够让人复核。
10. PASS / FAIL / HELD 标准是否能机械判断。

## 5. 执行审核流程

标准流程：

```text
确认设计审核已通过
-> 读取执行日志
-> 读取结果包和关键产物
-> 核对输入、输出、样本、时间范围
-> 核对执行过程流水和中间数据路径
-> 核对实现是否按设计执行
-> 抽查关键案例或样本
-> 按实验目标判断是否需要检查未来函数
-> 检查时点错位、样本污染和必要的未来函数风险
-> 检查结论是否过读
-> 写入实验审计报告
-> 通过则实验完成；不通过则退回修复或重跑
```

执行审核重点：

1. 是否按已审核设计执行。
2. 结果包是否真实存在，关键产物是否可读。
3. 执行日志是否记录关键中间过程，不只是开始和结束。
4. 需要复核的中间数据是否落盘，并能从执行日志追到路径。
5. summary、日志、结果表、图表是否互相对得上。
6. source snapshot、样本池、时间范围是否和设计一致。
7. 关键代码或规则是否和设计一致。
8. 关键样例、冻结案例、人工验收样本是否对得上。
9. 是否按实验目标处理未来函数要求。
10. 如果目标要求时点安全，是否有未来函数、PIT 泄漏、时点错位。
11. 是否有样本污染、对照缺失、proxy 冒充真实目标。
12. 结论是否超过证据支持范围。

执行审核硬口径：

1. 如果实验执行日志缺少关键节点流水，导致审核员无法从输入追到中间处理、再追到最终结果，执行审核不得通过。
2. 如果关键节点产生了会影响结论的中间数据，但没有落盘或没有在执行日志中给出可追踪路径，执行审核不得通过。
3. 如果结果包只有 summary/readout，缺少支撑结论的关键中间表、结果表、图表、manifest 或等价证据，执行审核不得通过。
4. 如果某个中间节点确实没有独立数据产物，执行日志必须说明原因；审核员确认该说明不影响复核后，才允许通过。
5. 审核员不能只看执行者口头结论或最终 summary，必须检查关键节点日志和关键数据是否能串成审计链。

## 6. 默认检查清单

每次审核默认至少检查：

| 检查项 | 核心问题 |
|---|---|
| 目标 | 实验到底要证明什么 |
| 来源聊天 | 用户原始要求、实验目标、实验设计是否一致 |
| 设计 | 方法是否能满足目标 |
| 数据 | 数据源、样本、时间范围是否合理 |
| 对照 | 是否需要对照组、边界样本或负样本 |
| 实现 | 代码、规则、人工步骤是否按设计执行 |
| 过程 | 执行过程流水、关键中间数据路径是否完整 |
| 产物 | 结果包、summary、manifest、图表是否存在且对得上 |
| 案例 | 关键样本是否能人工复核 |
| 偏差 | 是否按目标处理未来函数、样本污染、时点错位 |
| 结论 | 是否存在过读 |

## 7. 问题分类

审核发现问题时，必须明确问题类型。

允许类型：

1. `实验设计问题`：目标、方法、样本、对照、验收标准不合理。
2. `执行问题`：没有按设计执行，或执行记录缺失。
3. `数据 / 产物问题`：输入缺失、产物为空、旧包污染、summary 和数据对不上。
4. `代码实现问题`：脚本、算法、字段、分支和设计不一致。
5. `流程 / 调度问题`：执行顺序、重跑、缓存、source 切换、结果包归档错误。
6. `结论过读`：结论超过证据支持范围。
7. `待归因`：证据不足，暂时不能判断根因。

如果是 `待归因`，必须写清下一步要查什么，不能直接转给执行者“修 bug”。

## 8. 严重级别

问题严重级别分为：

1. `阻断`：会推翻结论、必须重跑、或不能进入下一阶段。
2. `重要`：不一定推翻结论，但会明显影响可信度或下游使用。
3. `一般`：需要记录或后续处理，但不阻断当前目标。
4. `建议`：非问题，只是改进建议。

只有 `阻断` 和必要的 `重要` 问题应阻止实验完成。

## 9. 未来函数和时点审核

未来函数不是所有实验的统一硬要求。

如果实验涉及预测、收益率、回放、自动动作或任何实时决策判断，必须检查未来函数。

如果实验是后验理解、案例复盘、图形归纳、方法论总结，应检查结论是否降读，而不是强制按实盘时点安全否决实验。

审核员要判断：

1. 触发条件在决策时点是否已经可见。
2. 买卖点、候选池、过滤条件是否用了当天收盘后或未来数据。
3. 指标窗口是否包含了当前还不可见的数据。
4. 人工案例是否按当时可见信息执行。
5. 结果解释是否把后验确认当成实时触发。

如果实验目标和实际结论发生错位，例如设计说只是后验理解，结论却写成可实时使用或 prediction ready，必须按结论过读处理。

## 10. 通过条件

设计审核通过条件：

1. 目标清楚。
2. 来源聊天记录、实验目标、实验设计一致；如不一致，已明确处理。
3. 设计能回答目标。
4. 数据和样本能支撑目标。
5. 是否需要防未来函数的判断清楚。
6. 输出产物和验收标准清楚。
7. 没有会明显污染结论的设计缺陷。

执行审核通过条件：

1. 已按设计执行。
2. 关键产物存在并可复核。
3. 关键计数、样本、图表、日志对得上。
4. 未发现会推翻结论的真 bug。
5. 如果目标要求时点安全，未发现会影响结论的未来函数。
6. 未发现会影响结论的样本污染。
7. 结论边界写清，没有过读。

## 11. 不能通过的情况

出现以下任一情况，默认不能通过：

1. 目标不清。
2. 来源聊天记录、实验目标、实验设计不一致且未处理。
3. 设计不能回答目标。
4. 代码能跑但和设计不一致。
5. 结果包缺关键产物。
6. summary 和底层数据对不上。
7. 样本或 source 被替换但没有记录。
8. 在需要时点安全的实验中，存在未来函数且影响结论。
9. 结论从窄样本过读成广泛成立。
10. 问题根因还没定位清楚。

## 12. 实验审计报告记录规则

每次审核完成后，必须写入对应项目：

```text
<project>/exp-doc/实验审计报告.md
```

如果项目没有该文件，应按 `实验审计报告模版.md` 创建。

实验审计报告是项目级滚动账本，不是单次审核文件。每次设计审核、执行审核或复审都必须追加到文件末尾，最新内容在最后；历史审计不得删除，只能追加复审或替代说明。

审核员发现的问题应在实验审计报告中记录完整问题、证据、影响、是否阻断、修复建议和复审要求。实验问题记录只在需要跨轮跟踪时登记索引或关联，不替代审计报告的问题清单。

审计报告至少记录：

1. 审计 ID。
2. 审计类型：设计审核、执行审核或复审。
3. 实验事项 ID 和实验名称。
4. 审核人。
5. 审核时间，精确到秒。
6. 审核结论：通过、不通过或 HELD。
7. 审核依据文件。
8. 关键发现。
9. 问题清单和严重级别。
10. 是否允许进入下一阶段。
11. 结论边界。
12. 来源聊天记录、实验目标、实验设计一致性判断。
13. 是否需要防未来函数，以及判断理由。
14. 需要回写到总纲、设计、方法论、需求或下一轮实验的内容。

## 13. 审核输出口径

审核员对外汇报时，默认先说结论。

推荐格式：

```text
结论：通过 / 不通过 / HELD
是否有阻断问题：有 / 无
关键发现：...
影响：...
建议：...
下一步：...
```

如果没有问题，应明确说“未发现会影响当前目标和结论的阻断问题”，不要扩大成“绝对没问题”。

## 14. 审核边界

审核员不应做以下事：

1. 为了严谨而无限加实验。
2. 把低价值格式问题升成阻断。
3. 把探索实验强行按发布实验审核。
4. 把自己没查到的数据问题转嫁给人工。
5. 只看执行方 summary，不追关键证据。
6. 明知目标缺失还替实验者脑补目标。
7. 直接改写被审计实验主产物、主表或正式结果包。

审核员应做以下事：

1. 抓住影响结论的关键问题。
2. 明确问题类型和严重级别。
3. 给出可执行修复建议。
4. 让人能快速追到证据。
5. 审核通过前，确保设计或执行已经满足当前实验目标。
6. 必要时运行证据链上的只读脚本或检查脚本，但不得用审计脚本替代执行方正式产物。