实验设计模版

创建人员：<填写创建人员或 AI>
文件职责：记录项目内所有实验的设计、步骤、依赖、产物、判定标准、设计审核和执行结果回填；对应管理系统里的事项计划账本。
管理规范/模板：common/exp-doc/实验规范.md；本文件由 common/exp-doc/实验设计模版.md 实例化。
引用文件：<填写实验总纲、实验执行日志、实验审计报告、实验存储体系、来源聊天记录或上游文档>

0. 当前设计总览

本节用于快速查看当前正在推进的实验设计，可以随最新进展更新；详细设计记录仍必须追加到文件末尾。

• 当前最新设计：<设计 ID / 实验事项 ID / 状态>
• 当前可执行设计：<设计 ID 列表；必须已通过设计审核>
• 当前阻断设计：<设计 ID / 阻断原因>
• 当前下一步：<设计修订/等待审核/进入执行/暂停>

0A. 文档定位和证据索引职责

• 本文件是项目内具体实验设计与证据索引主入口。
• 它负责回答：每个实验想解决什么问题、怎么验证、当前状态是什么、关键证据和结果包在哪里。
• 实验总纲回答“为什么做和最后怎么读”；实验设计回答“具体怎么做、证据在哪里、结果包是什么”。
• 后续新增实验、修订实验边界、回填执行结果，都应追加到本文件末尾，不得覆盖历史设计。

1. 固定设计口径

• 维护方式：append-only；新设计、新修订、新执行回填追加到文件末尾，最新内容在最后。
• 旧设计处理：不得删除；若失效，追加“失效/降读/被替代”说明。
• 设计与计划合并：本文件同时记录“要怎么验证”和“按什么步骤执行”。
• 设计审核要求：设计审核通过后才能执行；未通过则追加修订块，不覆盖旧设计。
• 路径规则：项目内文件默认使用相对路径。

2. 实验设计追加区

从这里开始按时间顺序追加。结构尽量像可执行计划，不要写成厚重需求文档。
每个实验设计块必须能回答：为什么这样跑、用什么数据、怎么判定、产物在哪里、审核状态是什么。

<设计 ID>：<实验名称>

• 所属实验事项：<实验事项 ID / 名称>
• 创建人员：<填写>
• 创建时间：<YYYY-MM-DD HH:mm:ss>
• 当前状态：<设计中/待设计审核/设计审核通过/执行中/完成/暂停/取消>
• 当前结论：<当前阶段结论>
• 来源聊天记录：<引用实验总纲中的关键聊天记录；如无说明原因>

当前约定

• 本轮要验证：<核心问题>
• 本轮不验证：<排除范围>
• 与来源聊天要求的一致性：<逐条说明如何承接用户要求>
• 前置依赖：<前序实验、数据、文档、人工反馈>

实验方法和样本

• 核心假设：<填写>
• 数据源：<数据路径、表、接口、版本>
• 样本范围：<时间、对象、过滤条件>
• 实验组：<如何构造>
• 对照组：<如何构造；如不需要，说明原因>
• 边界样本：<容易误判或需要专门观察的样本>
• 防偏差要求：<样本污染、源数据切换、口径替换等>
• 是否需要防未来函数：<是/否/不适用>
• 判断理由：<根据实验目标说明为什么需要或不需要>

执行顺序

1. <步骤 ID>：<步骤名称；输入；输出；判定>
2. <步骤 ID>：<步骤名称；输入；输出；判定>
3. <步骤 ID>：<步骤名称；输入；输出；判定>

字段、指标和状态

输出产物

• 结果包目录：<路径>
• 核心输出表：<路径/文件名>
• 核心图表：<路径/文件名>
• summary/readout：<路径/文件名>
• manifest/输入快照：<路径/文件名>
• 执行日志：实验执行日志.md 中 <run_id / 小节标题>

判定标准

• PASS：<什么结果算通过>
• FAIL：<什么结果算失败>
• HELD：<什么情况下只能暂挂，不能判断>
• 降读规则：<结果不充分时如何降读>
• 停止或转向条件：<什么情况下不继续跑，改为补数据/改设计/暂停>

风险和不做事项

• 关键风险：<样本不足、口径不稳、源数据缺失、计算成本高、人工审核未回收等>
• 阻断项：<没有这些就不能继续的前置条件>
• 可接受缺口：<不影响本轮目标的小缺口>
• 本轮不做：<明确不做的事情>

设计审核

• 设计审核状态：<待审核/通过/未通过>
• 审核人：<填写>
• 审核时间：<YYYY-MM-DD HH:mm:ss>
• 审核结论：<填写>
• 未通过问题：<如无填写无>
• 复审记录：<路径或摘要>

执行结果回填

• run_id：<填写；未执行则待补>
• 结果包：<路径；未执行则待补>
• 关键结果：<摘要>
• 当前读法：<PASS/FAIL/HELD/降读/失效>
• 是否纳入实验总纲结论：<是/否；说明>