From e87cfdcb76a359d217130b33ffb4ed917b64d230 Mon Sep 17 00:00:00 2001 From: 1 <wentingyear@gmail.com> Date: Thu, 25 Jun 2026 20:56:54 +0800 Subject: [PATCH] fix: rebuild project-info system documents --- exp-doc/实验审计规范.md | 457 +++------------------------------------------------------ 1 files changed, 24 insertions(+), 433 deletions(-) diff --git "a/exp-doc/\345\256\236\351\252\214\345\256\241\350\256\241\350\247\204\350\214\203.md" "b/exp-doc/\345\256\236\351\252\214\345\256\241\350\256\241\350\247\204\350\214\203.md" index f783d76..f035545 100644 --- "a/exp-doc/\345\256\236\351\252\214\345\256\241\350\256\241\350\247\204\350\214\203.md" +++ "b/exp-doc/\345\256\236\351\252\214\345\256\241\350\256\241\350\247\204\350\214\203.md" @@ -1,444 +1,35 @@ -# 实验审核规范 +# 实验审计规范 -创建人员：Codex -文件职责：定义实验设计审核、实验执行审核、复审、问题归因、通过标准和审计报告记录规则。 -管理规范/模板：common/exp-doc/实验规范.md；本文件是实验审核专用规范。 -引用文件：../../管理系统说明.md；实验规范.md；实验总纲模版.md；实验设计模版.md； +创建人员：management.admin +文件职责：记录 `project-info` 项目实验审核员必须遵守的本地实验审计规范。本文件引用 common 实验审核规范，不得削弱 common 硬约束。 +管理规范/模板：../../common/exp-doc/实验审核规范.md；../../common/exp-doc/实验环境创建指南.md。 +引用文件：实验规范.md；实验总纲.md；实验设计.md；实验执行日志.md；实验审计报告.md；实验问题记录.md；../项目配置清单.md。 +记录方式：项目本地审核规范；审核口径变化时更新。 -统一依赖：本规范必须同时遵守 `../../全局规范.md` 和 `../project-doc/项目规范.md`；项目本地实验审核规范可补充流程，但不得违反全局规范、全局项目规范和本体系硬约束。 +## 1. 基本口径 -## 1. 定位 +本项目所有实验审核员必须同时遵守 `../../common/exp-doc/实验审核规范.md` 和本文件。`laoshen` 是本项目实验审核员，同时兼任实验开发审核员；实验开发相关审核结论统一写入 `exp-doc/实验审计报告.md`。 -实验审核是实验事项的质量关口。 +## 2. 审核范围 -它不负责替执行者重新做实验，也不负责无边界地增加要求。 +审核员至少检查： -它只回答： +1. 设计是否明确实验目标、样本、数据源、步骤、产物和 PASS / FAIL / HELD 标准。 +2. 执行是否严格按设计进行，偏离是否记录并解释。 +3. 结果包、manifest、summary、readout 是否可复核。 +4. 结论是否降读，是否避免策略、收益或预测过读。 +5. 是否存在凭据泄漏、大量原始输出进入窗口、或把 tmp 当正式证据。 -1. 实验目标是否清楚。 -2. 实验设计是否能满足目标。 -3. 实验是否按设计执行。 -4. 关键数据、代码、案例、产物是否对得上。 -5. 是否存在会影响结论的真 bug、样本污染、口径替换或结论过读。 -6. 如果实验目标要求时点安全，是否存在未来函数。 -7. 当前结论能不能成立，最多能读到什么程度。 +## 3. 审计记录位置 -## 1A. 全局审核规范和项目本地审核规范 - -`common/exp-doc/实验审核规范.md` 是全局通用审核规范。 - -所有项目的审核员都必须遵守本文件。每个项目创建实验环境时都必须创建项目本地 `exp-doc/实验审计规范.md`。项目本地审计规范默认可以很短，只引用本文件并声明必须遵守；如果补充项目特化规则，不能违反本文件的硬约束。具体审核流程可以按 1A.1 设计本地版本。 - -实验审核员可以维护项目本地 `exp-doc/实验审计规范.md`，仅限修正实验审核流程、审计口径和阻断标准；不得借此修改被审的 `实验规范.md`、实验总纲、实验设计、执行日志、结果包或主产物。如确需修改实验执行规范，应创建规范维护事项，或额外授予实验体系维护 / 规范维护角色。 - -项目本地审核规范允许补充： - -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`。 - -实验开发中的临时草稿脚本可以不做独立代码审核；但只要代码用于生成正式实验结果、候选池、收益统计、图表、验收包、结果包、结论 readout 或可复用工具，就必须纳入实验审核。审核重点不是把轻量脚本套成重型开发流程，而是确认结果可信： - -1. 输入数据、样本范围、过滤条件是否和实验设计一致。 -2. 输出表、图片、summary、manifest 或等价结果包是否能和执行日志对上。 -3. 抽样、baseline、分组、统计口径、买卖规则或候选规则是否和实验目标一致。 -4. 代码是否改写原始证据、污染正式数据或覆盖不可变结果。 -5. 至少抽查关键样本，必要时人工复算 1-3 个样本或关键行。 -6. 是否需要防未来函数必须按实验目标判断，具体按 2.5“未来函数按目标判断”执行。 - -以下内容默认不作为阻断问题： - -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、图表是否存在且对得上 | -| 案例 | 关键样本是否能人工复核 | -| 偏差 | 是否按目标处理未来函数、样本污染、时点错位 | -| 结论 | 是否存在过读 | +| 初始化审计 | `实验审计报告.md` | +| 设计审核 | `实验审计报告.md` | +| 执行审核 | `实验审计报告.md` | +| 审计发现问题 | `实验审计报告.md` 为主，`实验问题记录.md` 只做跨轮索引 | +| 非审计来源问题 | `实验问题记录.md` | -## 7. 问题分类 +## 4. 审核结论 -审核发现问题时，必须明确问题类型。 - -允许类型： - -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. 必要时运行证据链上的只读脚本或检查脚本，但不得用审计脚本替代执行方正式产物。 +审核结论使用：`通过`、`有条件通过`、`不通过`、`HELD`。结论必须包含证据入口、阻断项、需要修复的文档或结果包路径。 -- Gitblit v1.9.3