| | |
|---|
| | | # 案例分析规范 |
|---|
| | | |
|---|
| | | 创建人员：Codex |
|---|
| | | 文件职责：定义案例分析体系的定位、核心流程、证据链要求、文档职责、审计闭环和问题处理边界。 |
|---|
| | | 管理规范/模板：../../全局规范.md；../../体系说明.md；../../体系创建流程.md。 |
|---|
| | | 引用文件：案例分析环境创建指南.md；案例存储体系创建指南.md；案例总纲模版.md；案例分析设计模版.md；案例执行日志模版.md；案例审核规范.md；案例审计报告模版.md；案例问题记录模版.md。 |
|---|
| | | 记录方式：全局案例分析规范；案例分析流程或审计口径变化时更新。 |
|---|
| | | 创建人员：management.admin |
|---|
| | | 文件职责：记录 `project-info` 项目案例分析员必须遵守的本地规范。本文件引用 common 案例分析规范，不得削弱 common 硬约束。 |
|---|
| | | 管理规范/模板：../../common/ana-doc/案例分析规范.md；../../common/ana-doc/案例分析环境创建指南.md。 |
|---|
| | | 引用文件：目录导读.md；案例总纲.md；案例分析设计.md；案例执行日志.md；案例存储体系.md；../项目配置清单.md。 |
|---|
| | | 记录方式：项目本地规范；本项目案例分析口径发生变化时更新，并同步项目变更记录。 |
|---|
| | | |
|---|
| | | 统一依赖：本规范必须同时遵守 `../../全局规范.md` 和 `../project-doc/项目规范.md`；项目本地案例分析规范可补充流程，但不得违反全局规范、全局项目规范和本体系硬约束。 |
|---|
| | | ## 1. 基本口径 |
|---|
| | | |
|---|
| | | ## 1. 定位 |
|---|
| | | 本项目所有案例分析员必须同时遵守 `../../common/ana-doc/案例分析规范.md` 和本文件。本文件只做 `project-info` 的项目化补充；如果与 common 规范冲突，以 common 硬约束为准，并先修复本文件。 |
|---|
| | | |
|---|
| | | 案例分析体系用于管理一类“对具体案例做全流程分析、复盘、解释和校验”的事项。 |
|---|
| | | ## 2. 项目分析范围 |
|---|
| | | |
|---|
| | | 案例可以来自： |
|---|
| | | 本项目案例分析范围限定为股市信息研究相关案例，包括： |
|---|
| | | |
|---|
| | | 1. 方法论或笔记。 |
|---|
| | | 2. 交易、需求、用户、工程、业务流程。 |
|---|
| | | 3. 样本数据。 |
|---|
| | | 4. 人工标注。 |
|---|
| | | 5. AI 发现的异常或候选。 |
|---|
| | | 1. 研报、公告、新闻、公开网络信息形成的信息事件链。 |
|---|
| | | 2. K 线、成交量、市场广度、行业表现等市场显影证据。 |
|---|
| | | 3. 暗线 / 信息拓扑分析中的意图、目标、证据链和替代解释。 |
|---|
| | | 4. 后续可交给实验体系验证的假设和观察窗口。 |
|---|
| | | |
|---|
| | | 案例分析不是代码实现，也不是单纯写总结。它要把“为什么选这个案例、怎么分析、每一步依据是什么、最后结果是什么、是否符合原始方法论”都留下证据链。 |
|---|
| | | 本项目案例分析不得直接输出交易指令、收益承诺或未经验证的因果结论。 |
|---|
| | | |
|---|
| | | ## 2. 核心目标 |
|---|
| | | ## 3. 核心文档作用 |
|---|
| | | |
|---|
| | | 案例分析体系要达成： |
|---|
| | | | 文档 | 作用 | |
|---|
| | | |---|---| |
|---|
| | | | `案例总纲.md` | 记录本项目所有案例事项的来源、目标、边界、状态和结论 | |
|---|
| | | | `案例分析设计.md` | 记录案例选择口径、证据链设计、执行步骤、产物和判定标准 | |
|---|
| | | | `案例执行日志.md` | 记录执行过程、证据入口、关键中间结果、异常和自检 | |
|---|
| | | | `案例存储体系.md` | 说明案例数据、图片、结果包、临时文件和证据包的存储规则 | |
|---|
| | | | `案例审计报告.md` | 记录设计审核、执行审核、初始化审核和复审结论 | |
|---|
| | | | `案例问题记录.md` | 记录非审计来源问题；审计问题主记录留在审计报告 | |
|---|
| | | |
|---|
| | | 1. 能追踪案例起因和原始要求。 |
|---|
| | | 2. 能复核案例为什么被选中。 |
|---|
| | | 3. 能复核每一步判断或操作是否按规则发生。 |
|---|
| | | 4. 能看到中间关键节点的数据、图片或文本证据。 |
|---|
| | | 5. 能判断最终结论有没有过读。 |
|---|
| | | 6. 能让审核员和人类读者快速理解案例前因后果。 |
|---|
| | | ## 4. 最小案例链路 |
|---|
| | | |
|---|
| | | ## 3. 核心流程 |
|---|
| | | 每个正式案例至少具备： |
|---|
| | | |
|---|
| | | 默认流程： |
|---|
| | | 1. 案例 ID、来源、目标、边界和状态。 |
|---|
| | | 2. 设计记录，说明要分析的信息叶子、证据来源、K 线/市场显影检查口径和替代解释。 |
|---|
| | | 3. 执行日志，说明实际读取的文档、数据、证据路径和输出包。 |
|---|
| | | 4. 审计记录，说明设计或执行是否通过。 |
|---|
| | | 5. 结果包或明确的 `HELD` 状态；不能用口头结论替代证据入口。 |
|---|
| | | |
|---|
| | | ```text |
|---|
| | | 来源聊天记录 / 上游方法论 / 样本来源 |
|---|
| | | -> 案例总纲记录背景、目标、边界、当前结论 |
|---|
| | | -> 案例分析设计记录案例选择口径、分析步骤、证据要求、验收方式 |
|---|
| | | -> 设计审核 |
|---|
| | | -> 执行案例分析 |
|---|
| | | -> 案例执行日志记录候选、过程、关键数据、图片、结果 |
|---|
| | | -> 结果包 / 证据包归档 |
|---|
| | | -> 执行审核 |
|---|
| | | -> 审计报告记录审计问题 / 问题记录承接非审计问题或审计索引 |
|---|
| | | -> 修复 / 复审 |
|---|
| | | -> 结论回写到案例总纲和案例设计 |
|---|
| | | ``` |
|---|
| | | ## 5. darkline 使用口径 |
|---|
| | | |
|---|
| | | 设计审核未通过，不得进入正式执行。 |
|---|
| | | 当任务涉及暗线、新闻、公告、事件链、证据链、K 线显影或外部信息拓扑时，应使用 `darkline` 技能约束分析流程。窗口只展示摘要、关键路径和证据入口；大段新闻、日志、搜索结果和图片批量内容应落到结果包或 readout 文件。 |
|---|
| | | |
|---|
| | | 执行审核未通过，不得把案例标记为完成或可交付。 |
|---|
| | | ## 6. 禁止事项 |
|---|
| | | |
|---|
| | | ### 3.0 本地案例分析流程优先级 |
|---|
| | | |
|---|
| | | common 案例分析规范规定案例体系底线和默认流程，项目本地 `ana-doc/案例分析规范.md` 可以设计更适合本项目的案例分析流程。 |
|---|
| | | |
|---|
| | | 本地案例流程设计必须满足案例体系硬约束：来源聊天和上游依据可追踪、目标和边界清楚、案例选择口径冻结、关键判断有证据、设计和执行有审核闭环、结论不过读。 |
|---|
| | | |
|---|
| | | 本地流程可以做两类调整： |
|---|
| | | |
|---|
| | | 1. 新增流程：例如新增逐图验收流程、人工回填流程、交易案例复盘流程。 |
|---|
| | | 2. 修改默认流程：例如把案例设计、执行、验收、复盘步骤拆分、合并或替换为项目内更合适的步骤。 |
|---|
| | | |
|---|
| | | 如果只是新增流程，只要不违反案例体系硬约束即可放行。 |
|---|
| | | 如果是修改默认流程，必须在本地 `案例分析规范.md`、`案例分析设计.md` 或对应案例事项中写清楚覆盖范围、替换原因、输入输出、关键证据链和审核点。 |
|---|
| | | |
|---|
| | | 本地案例流程一旦设计完成并通过审核，执行时以本地流程为准；案例审核员也应按已通过的本地流程审计执行结果。只有发现本地流程违反案例体系硬约束时，才回到 common 案例分析规范要求整改。 |
|---|
| | | |
|---|
| | | ### 3.1 案例分析设计流程 |
|---|
| | | |
|---|
| | | 设计流程负责回答“为什么分析、分析什么、怎么分析、怎么验收”。 |
|---|
| | | |
|---|
| | | 设计流程至少包括： |
|---|
| | | |
|---|
| | | 1. 记录来源聊天、上游方法论、样本来源和事项背景。 |
|---|
| | | 2. 在案例总纲中登记案例分析目标、边界、当前状态和预期结论形式。 |
|---|
| | | 3. 在案例分析设计中冻结案例选择口径、分析步骤、证据要求、图片要求、数据输出和验收方式。 |
|---|
| | | 4. 明确是否需要防未来函数、是否需要人工复核关键触发点、是否需要逐图验收。 |
|---|
| | | 5. 提交设计审核。 |
|---|
| | | |
|---|
| | | 设计审核通过后，执行员应按冻结设计执行；如执行中发现设计不合理，应记录偏离原因，并回到设计修订和复审，不得直接换口径继续跑。 |
|---|
| | | |
|---|
| | | ### 3.2 案例分析执行流程 |
|---|
| | | |
|---|
| | | 执行流程负责回答“实际怎么跑、每一步证据在哪里、结果如何复核”。 |
|---|
| | | |
|---|
| | | 执行流程必须按逐案例证据链留痕： |
|---|
| | | |
|---|
| | | ```text |
|---|
| | | 读取已审核通过的案例分析设计 |
|---|
| | | -> 生成或读取候选池 |
|---|
| | | -> 记录候选池来源、筛选条件和筛选结果 |
|---|
| | | -> 选择具体案例并记录入选理由 |
|---|
| | | -> 为每个案例记录背景数据和背景图片 |
|---|
| | | -> 按设计逐步执行关键判断或操作 |
|---|
| | | -> 每一步记录规则、触发条件、数据路径、图片路径和结论 |
|---|
| | | -> 记录最终结果、异常、偏离和复盘结论 |
|---|
| | | -> 生成结果包 / 证据包 |
|---|
| | | -> 回写案例执行日志、案例总纲和案例分析设计 |
|---|
| | | -> 提交执行审核 |
|---|
| | | ``` |
|---|
| | | |
|---|
| | | 执行流程的重点是证明“确实按设计做了”，不是只输出最终 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 像分析员一样把一件事按规则跑完整，并把每一步为什么这么做、证据在哪里、结果怎么来的都留下来。 |
|---|
| | | 1. 不得把其他项目的业务结论、样本、图片或结果包复制为本项目正式案例。 |
|---|
| | | 2. 不得绕过 `案例分析设计.md` 直接把执行结果标为完成。 |
|---|
| | | 3. 不得把 `ana-data/tmp/` 当正式证据入口。 |
|---|
| | | 4. 不得把未经证据支持的猜测写成结论；证据不足时应标记 `HELD_BY_EVIDENCE_GAP`。 |
|---|
