案例审核规范

创建人员：Codex
文件职责：定义案例分析体系的审核范围、审核流程、设计审核、执行审核、证据链审核和问题阻断标准。
管理规范/模板：../../全局规范.md；../../体系说明.md；案例分析规范.md。
引用文件：案例审计报告模版.md；案例问题记录模版.md；案例总纲模版.md；案例分析设计模版.md；案例执行日志模版.md。
记录方式：案例审核规范；案例审核口径变化时更新。

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

1. 审核定位

案例审核检查案例分析是否真的按目标和设计完成。

审核重点是：

1. 设计是否能满足目标。
2. 执行是否按设计走。
3. 每个关键判断是否有证据。
4. 结果是否和过程、数据、图片一致。
5. 结论是否过读。

案例审核员还必须检查案例事项是否符合自身适用规范文档。适用范围包括 common 全局规范、全局项目规范、common 案例分析规范、项目本地案例分析规范，以及该案例直接声明采用的案例设计、存储、执行和审核规则。

如果案例设计或执行违反规范中的硬约束，例如跳过必要审核、未记录关键证据链、越权改写正式产物、候选选择与设计不一致、结论超出证据边界，必须反馈为审计问题。

如果只是命名、格式、表达方式等不影响案例目标、证据链、结论和后续使用的轻微差异，不应作为阻断问题。若规范之间冲突或规范本身不清楚，应标记为规范问题，不得强行按审核员个人理解加规则。

2. 设计审核

设计审核在正式执行前进行。

必须检查：

1. 案例总纲是否记录来源聊天和上游依据。
2. 案例目标是否清楚。
3. 案例选择口径是否能满足目标。
4. 全流程步骤是否覆盖从候选到结论。
5. 证据要求是否足够支撑复核。
6. 是否说明是否需要防未来函数或等价泄漏检查。
7. 验收方式是否明确。

设计审核不通过，不得进入正式执行。

如果案例事项使用项目本地案例流程，设计审核必须先判断本地流程是否满足 common 案例体系硬约束。新增流程重点检查输入输出、证据链和审核点；修改默认流程重点检查覆盖范围、替换原因、关键证据链和结论边界，且不得削弱来源追踪、案例选择口径、关键证据、审计闭环和不过读要求。

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

3. 执行审核

执行审核在案例执行后进行。

必须检查：

1. 执行是否按设计进行。
2. 候选来源和候选池是否对得上。
3. 具体案例是否来自设计约定范围。
4. 每个关键判断是否有数据或图片证据。
5. 如果有操作，操作触发条件是否真的成立。
6. 结果表、流水、图片、summary 是否互相一致。
7. 关键路径是否可读、无乱码、非临时伪正式产物。
8. 结论是否没有超过证据。

执行审核不通过，不得把案例事项标记为完成。

4. 交易 / 策略类案例审核

如果案例包含交易、买卖或收益结论，审核员必须额外检查：

1. 候选日是否正确。
2. 候选池是否按设计生成。
3. 入选原因是否有图或数据证据。
4. 买入点是否满足买入规则。
5. 卖出点是否满足卖出规则。
6. 账户流水是否能解释持仓和收益。
7. 如果目标是收益验证，是否存在未来函数或数据泄漏。

审核员不能只看 summary，应抽查或全查关键买卖点。

5. 不应阻断的问题

以下问题一般不阻断：

1. 图片样式一般但关键点可读。
2. 字段名不完全一致但映射清楚。
3. 不影响结论的备注缺失。
4. 非关键案例的轻微说明不足。
5. 后续工程化尚未开始。

6. 必须阻断的问题

以下问题必须阻断：

1. 设计目标和来源聊天不一致。
2. 执行没有按设计走，且未说明偏离。
3. 候选池和案例选择口径不一致。
4. 关键判断缺证据。
5. 图片或数据路径缺失导致无法复核。
6. 操作流水和结果不一致。
7. 使用未来信息支持实时决策或收益结论。
8. 结论明显过读。

7. 审核输出

审核结果写入 案例审计报告.md。

审核员发现的问题，主记录写入 案例审计报告.md。

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

案例分析开发中的临时草稿脚本可以不做独立代码审核；但只要代码用于生成正式案例结论、案例筛选、图表证据、账户流水、验收包、结果包、审计辅助报告或可复用工具，就必须纳入案例审核。审核重点不是把轻量脚本套成重型开发流程，而是确认案例证据可信：

1. 输入案例、样本范围、过滤条件是否和案例设计一致。
2. 输出图片、表格、流水、summary、manifest 或等价结果包是否能和案例执行日志对上。
3. 候选、入选、买入、卖出、退出、结论标签是否和案例规则一致。
4. 代码是否改写原始证据、污染正式数据或覆盖不可变结果。
5. 至少抽查关键案例，必要时人工复算 1-3 个操作点或关键行。
6. 是否需要防未来函数或数据泄漏必须按案例目标判断；涉及交易、买卖、收益验证、实时判断或自动动作时必须检查，后验理解、图形归纳、案例复盘、方法论总结类案例可以不作为实盘时点安全审核，但结论必须降读。

只有问题需要跨轮跟踪、跨案例汇总或由案例分析员长期处理时，才在 案例问题记录.md 中建立索引或关联，不重复全文。

审核报告至少包含：

1. 审核 ID。
2. 审核类型：设计审核 / 执行审核 / 复审。
3. 审核对象。
4. 审核依据。
5. 检查结果。
6. 问题清单。
7. 结论：通过 / 不通过 / 暂缓。
8. 是否允许进入下一阶段。

8. 审核边界

审核员可以运行只读检查脚本、打开图片、读取表格、人工计算关键触发点。

审核员可以维护项目本地 案例审核规范.md，仅限修正案例审核流程、审计口径和阻断标准；不得借此修改被审的案例分析规范、案例设计、执行日志、结果包或主产物。

审核员不得直接改被审计主产物来掩盖问题。

如确需修改案例分析执行规范，应创建规范维护事项，或额外授予案例体系维护 / 规范维护角色，并记录原因、影响范围和复审入口。

审核员应抓真问题，不把边角料升级成阻断。

9. 长期行业成果路径审核

1. 长期行业研究的正式人读成果应从 ana-data/cases/<行业>案例/当前成果索引.md 进入，并合并维护在 核心文档/；审核员不得反向要求其为每个任务或批次另建 <case_id>/outputs/。
2. 候选应位于 ana-data/tmp/<行业>案例/<task_id>/<run_id>/。审核通过前不得进入核心文档；审核通过后不得继续把任务目录当作第二个当前成果入口。
3. <case_id>/outputs/ 仅用于一次性专题、单公司或独立案例。判断路径是否合规时，先判断事项是“长期行业累计成果”还是“一次性独立案例”。
4. 旧任务输出的收口应一次检查内容合并、证据血缘和路径映射，不按文件拆分多轮审核。