edit | blame | history | raw

案例分析规范

创建人员：MB-X
文件职责：记录 wuji 项目案例分析体系的本地规范入口和项目补充口径。
管理规范/模板：../../全局规范.md；../../common/ana-doc/案例分析规范.md；../../common/ana-doc/案例分析环境创建指南.md。
引用文件：案例审核规范.md；案例总纲.md；案例分析设计.md；案例执行日志.md；案例审计报告.md；案例问题记录.md；案例存储体系.md。
记录方式：本地规范入口；项目案例分析流程或补充规则变化时维护更新，重大变化同步写入项目执行日志和项目变更记录。

1. 基本口径

本项目已启用案例分析体系，所有案例分析事项同时遵守：

  1. ../../全局规范.md
  2. ../../common/project-doc/项目规范.md
  3. ../../common/ana-doc/案例分析规范.md
  4. ../../common/ana-doc/案例审核规范.md
  5. 本文件和 案例审核规范.md

本文件只记录 wuji 项目的本地补充，不复制 common 规范正文。当前本地补充只覆盖明确登记的专项案例流程，不默认扩展到其他案例事项。

2. 本地入口

入口 作用
案例总纲.md 记录案例分析事项背景、目标、状态和结论
案例分析设计.md 记录案例选择口径、执行步骤、证据要求和验收方式
案例执行日志.md 记录实际执行过程、数据路径、图片路径和偏离
案例审计报告.md 记录设计审核、执行审核和复审结论
案例问题记录.md 记录非审计来源问题，或审计问题跨轮索引
案例存储体系.md 记录案例数据、图片、结果包和临时文件存储口径
人工反馈问题处理流程.md 记录用户、同事等人工反馈如何登记、分级、出方案、送审、返修和关闭
案例复盘流程.md 记录漏发现、误放行、问题复发或反馈闭环不完整时如何复盘、找根因、落地方案和输出发起人摘要

3. 当前补充

  • 项目初始化阶段只建立案例分析环境，不生成真实案例结论。
  • 正式案例分析事项开始前，必须先在 案例总纲.md 和 案例分析设计.md 登记来源、目标、边界和设计。
  • 设计审核未通过前，不进入正式执行；执行审核未通过前，不把案例事项标记为完成。

3.1 无忌交易系统专项案例流程

适用范围：
ANA-WUJI-BASELINE-2023-2026 及后续明确引用无忌交易系统 baseline 的案例事项。

纳入依据：
case_analysis.reviewer 已在 案例审计报告.md 中通过设计审核，审计 ID 为 AUDIT-ANA-WUJI-BASELINE-FLOW-20260607-001。

正式流程入口：
wuji/无忌交易系统案例执行流程.md

专项要求：

  1. 后续无忌交易系统案例必须以 wuji/profile/source_note/笔记精简版.md 为直接 baseline，以 wuji/baseline反馈.md 记录取舍和用户确认事项。
  2. 每轮执行必须同时遵守三条核心原则：尽全力贴合蓝本、全流程可审核、人工审核方便。
  3. case_image_board.md 是人工审核第一入口；case_story_board.md、CSV、账本和文字说明是追溯材料，不得替代图片主入口。
  4. 选股证据图必须优先使用约 100 个交易日范围的日 K 图；买入、卖出证据图必须优先使用 1 分钟 K 图；买卖点、仓位、时间和原因必须尽量用中文标注在图中。
  5. 每条代码规则、人工裁决、账本字段和收益字段必须能追溯到 笔记精简版.md、baseline反馈.md 或已审核流程文档；找不到来源时标记 BASELINE_MAPPING_MISSING，不得进入严格 baseline 收益统计。
  6. 正式小样本 run 前必须产出或冻结 run_config、baseline_rule_mapping.csv、baseline_excluded_rule_table.csv、code_validation_report.md、baseline_mapping_check.csv、sample_recalc_check.csv、账本字段和图片字段样式。
  7. 案例状态按 STRUCTURE_PILOT、STRICT_MANUAL_REPLAY、RETURN_STAT_READY 分层；未到 RETURN_STAT_READY 且执行审核未通过前，不得引用完整 baseline 收益率、成功率、胜率或回撤。
  8. 正式小样本 run 前还必须冻结市场 3000 上涨闸门具体时点口径、放量参数基准、是否保留 V0B 对照、交易成本 / 滑点 / 涨跌停不可成交约束，以及图片生成脚本字段和样式。
  9. 如后续修改 baseline 取舍、市场闸门、买卖规则、收益口径、图片审核入口或代码验证前置要求，必须重新提交设计复审。

3.2 人工反馈问题处理流程

用户、同事或其他人工阅读者反馈案例问题时，必须按 人工反馈问题处理流程.md 处理。

纳入依据：
case_analysis.reviewer 已通过人工反馈问题处理流程文档审核，审计 ID 为 AUDIT-ANA-HUMAN-FEEDBACK-PROCESS-20260611-DOC-001。该流程已正式纳入本地案例分析规范。

最低要求：

  1. 反馈问题必须先写入 案例问题记录.md 留档；已存在同类问题时并入原问题，不重复建项。
  2. 简单问题可以直接改对应文档或入口，再送文档复审；不强制写单独方案，避免层层加码。
  3. 复杂问题必须先出处理方案并送审，方案审核通过后再改其他文档或重新跑案例。
  4. 文档修改完成后必须送审确认；涉及结果包、图片、账本或脚本的，还必须重新执行并送执行审核。
  5. 处理过程中不得顺手扩大范围；未受影响的已审核读数、账本和结论边界不因反馈处理自动失效。

3.3 案例复盘流程

当案例分析或案例审核流程出现漏发现、误放行、问题复发、反馈闭环不完整、可见消息处理连续性不足、角色职责边界不清，或用户明确要求复盘时，必须按 案例复盘流程.md 处理。

纳入依据：
case_analysis.reviewer 已通过复盘流程设计复审，审计 ID 为 AUDIT-ANA-WUJI-FEEDBACK-REVIEW-POSTMORTEM-20260612-DESIGN-REREVIEW-001。本流程已正式纳入本地案例分析规范；落地复审通过前，不关闭 ANA-ISSUE-CASE-POSTMORTEM-PROCESS-GAP-20260612-001。

最低要求：

  1. 复盘问题必须先写入 案例问题记录.md，并保留触发来源、原始反馈或准确摘要、影响范围和当前状态。
  2. 复盘必须同时检查分析员流程和审核员流程，不得只解释某个文件如何返修。
  3. 复盘必须形成事实链、问题清单、根因判断、系统性方案、落地文档和验收方式。
  4. 复盘设计审核通过不等于复盘完成；正式落地到规范、问题记录和执行日志后，必须提交落地复审。
  5. 复盘结束后，分析员必须向用户 / 发起人输出简明结果，说明问题列表、漏发现原因、关键解决方案、已落地文档和保留边界。
  6. 复盘不得层层加码；未受影响的已审核读数、账本、图片和结论边界不因复盘自动失效。