# 案例审核规范

创建人员：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. 旧任务输出的收口应一次检查内容合并、证据血缘和路径映射，不按文件拆分多轮审核。