案例分析规范

创建人员：Codex
文件职责：定义案例分析体系的定位、核心流程、证据链要求、文档职责、审计闭环和问题处理边界。
管理规范/模板：../../全局规范.md；../../体系说明.md；../../体系创建流程.md。
引用文件：案例分析环境创建指南.md；案例存储体系创建指南.md；案例总纲模版.md；案例分析设计模版.md；案例执行日志模版.md；案例审核规范.md；案例审计报告模版.md；案例问题记录模版.md。
记录方式：全局案例分析规范；案例分析流程或审计口径变化时更新。

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

1. 定位

案例分析体系用于管理一类“对具体案例做全流程分析、复盘、解释和校验”的事项。

案例可以来自：

1. 方法论或笔记。
2. 交易、需求、用户、工程、业务流程。
3. 样本数据。
4. 人工标注。
5. AI 发现的异常或候选。

案例分析不是代码实现，也不是单纯写总结。它要把“为什么选这个案例、怎么分析、每一步依据是什么、最后结果是什么、是否符合原始方法论”都留下证据链。

2. 核心目标

案例分析体系要达成：

1. 能追踪案例起因和原始要求。
2. 能复核案例为什么被选中。
3. 能复核每一步判断或操作是否按规则发生。
4. 能看到中间关键节点的数据、图片或文本证据。
5. 能判断最终结论有没有过读。
6. 能让审核员和人类读者快速理解案例前因后果。

3. 核心流程

默认流程：

来源聊天记录 / 上游方法论 / 样本来源
-> 案例总纲记录背景、目标、边界、当前结论
-> 案例分析设计记录案例选择口径、分析步骤、证据要求、验收方式
-> 设计审核
-> 执行案例分析
-> 案例执行日志记录候选、过程、关键数据、图片、结果
-> 结果包 / 证据包归档
-> 执行审核
-> 审计报告记录审计问题 / 问题记录承接非审计问题或审计索引
-> 修复 / 复审
-> 结论回写到案例总纲和案例设计

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

执行审核未通过，不得把案例标记为完成或可交付。

3.0 本地案例分析流程优先级

common 案例分析规范规定案例体系底线和默认流程，项目本地 ana-doc/案例分析规范.md 可以设计更适合本项目的案例分析流程。

本地案例流程设计必须满足案例体系硬约束：来源聊天和上游依据可追踪、目标和边界清楚、案例选择口径冻结、关键判断有证据、设计和执行有审核闭环、结论不过读。

本地流程可以做两类调整：

1. 新增流程：例如新增逐图验收流程、人工回填流程、交易案例复盘流程。
2. 修改默认流程：例如把案例设计、执行、验收、复盘步骤拆分、合并或替换为项目内更合适的步骤。

如果只是新增流程，只要不违反案例体系硬约束即可放行。
如果是修改默认流程，必须在本地 案例分析规范.md、案例分析设计.md 或对应案例事项中写清楚覆盖范围、替换原因、输入输出、关键证据链和审核点。

本地案例流程一旦设计完成并通过审核，执行时以本地流程为准；案例审核员也应按已通过的本地流程审计执行结果。只有发现本地流程违反案例体系硬约束时，才回到 common 案例分析规范要求整改。

3.1 案例分析设计流程

设计流程负责回答“为什么分析、分析什么、怎么分析、怎么验收”。

设计流程至少包括：

1. 记录来源聊天、上游方法论、样本来源和事项背景。
2. 在案例总纲中登记案例分析目标、边界、当前状态和预期结论形式。
3. 在案例分析设计中冻结案例选择口径、分析步骤、证据要求、图片要求、数据输出和验收方式。
4. 明确是否需要防未来函数、是否需要人工复核关键触发点、是否需要逐图验收。
5. 提交设计审核。

设计审核通过后，执行员应按冻结设计执行；如执行中发现设计不合理，应记录偏离原因，并回到设计修订和复审，不得直接换口径继续跑。

3.2 案例分析执行流程

执行流程负责回答“实际怎么跑、每一步证据在哪里、结果如何复核”。

执行流程必须按逐案例证据链留痕：

读取已审核通过的案例分析设计
-> 生成或读取候选池
-> 记录候选池来源、筛选条件和筛选结果
-> 选择具体案例并记录入选理由
-> 为每个案例记录背景数据和背景图片
-> 按设计逐步执行关键判断或操作
-> 每一步记录规则、触发条件、数据路径、图片路径和结论
-> 记录最终结果、异常、偏离和复盘结论
-> 生成结果包 / 证据包
-> 回写案例执行日志、案例总纲和案例分析设计
-> 提交执行审核

执行流程的重点是证明“确实按设计做了”，不是只输出最终 summary。对交易、图形、流程操作类案例，关键判断点应尽量有图片或可视化支撑；没有图片时，必须有可复核的数据路径和计算说明。

4. 全流程留痕原则

案例分析必须尽量做到“人能沿着证据链重走一遍”。

关键留痕点：

1. 起因：为什么要分析这批案例。
2. 方法论来源：使用了哪个笔记、规则、文档或上游结论。
3. 候选池：候选案例从哪里来，怎么筛出来。
4. 具体案例：每个案例的 ID、主体、日期/阶段、背景。
5. 关键判断：每一步判断对应什么规则。
6. 关键证据：每一步判断对应的数据、图片、文本或表格路径。
7. 操作过程：如果案例包含操作，必须记录操作时间、触发条件、数量或动作。
8. 结果：最终收益、成败、分类、误判、异常或复盘结论。
9. 审计：审核员如何复核，发现什么问题。

5. 图片和可视化原则

案例分析如果涉及图形、时间序列、交易、过程状态或行为路径，应优先提供图片或可视化证据。

图片不是装饰，而是帮助人快速复核。

图片应尽量标注：

1. 案例 ID。
2. 关键日期或时间。
3. 触发规则。
4. 买入、卖出、开始、结束、异常点等关键动作。
5. 对照基准或背景。

如果没有图片，也必须说明用什么数据证据替代。

6. 交易 / 策略类案例的特殊要求

如果案例是交易或策略类，必须至少记录：

1. 候选日。
2. 候选池。
3. 入选原因。
4. 买入触发条件。
5. 买入时间和价格。
6. 卖出触发条件。
7. 卖出时间和价格。
8. 持仓变化。
9. 单案例账户或等价流水。
10. 最终收益和风险。

审核员不能只看结果表，应按规则人工复核关键买点和卖点是否真的触发。

是否需要防未来函数，按案例目标判断。如果案例目标是理解历史形态，可以不要求实盘级防未来；如果案例目标是验证可交易收益或实时决策，必须检查未来函数。

7. 文档职责

案例总纲：

记录所有案例分析事项的背景、目标、方法论来源、状态和当前结论。

案例分析设计：

记录案例选择口径、分析流程、证据要求、执行步骤和验收方式。

案例执行日志：

记录每个案例的实际分析过程、关键节点、数据路径、图片路径、结果和偏离。

案例审计报告：

记录设计审核、执行审核、复审结果，以及审核员发现的问题、证据、影响、修复建议和复审要求。

案例问题记录：

记录非审计来源的案例选择、数据、证据链、判断、结论问题；对需要跨轮跟踪的审计问题只记录索引或关联。

案例存储体系：

记录案例数据、图片、结果包、账户表、过程表、索引表如何存放和读取。

8. 不应过度加码

以下内容通常不应阻断：

1. 图片样式不够漂亮，但关键点可读。
2. 字段命名不完全一致，但映射清楚。
3. 非核心备注缺失。
4. 不影响结论的格式问题。
5. 案例暂时未工程化。

以下内容应阻断：

1. 案例目标和来源聊天记录不一致。
2. 候选池口径和实际执行不一致。
3. 关键买点、卖点、判断点没有证据。
4. 结果和流水对不上。
5. 用未来条件支持实时决策结论。
6. 图片或数据路径缺失，导致无法复核关键结论。
7. 结论超过案例证据。

9. 完成标准

一个案例分析事项完成，至少满足：

1. 案例总纲有背景、目标、来源和当前结论。
2. 案例分析设计通过审核。
3. 案例执行日志记录关键过程。
4. 结果包或证据包有入口。
5. 关键数据和图片可读。
6. 审计报告通过。
7. 如有非审计问题，问题记录已关闭或明确暂缓；如有审计问题，审计报告已有复审结论或明确暂缓原因。

10. 一句话

案例分析体系的核心是：让 AI 像分析员一样把一件事按规则跑完整，并把每一步为什么这么做、证据在哪里、结果怎么来的都留下来。