| | |
|---|
| | | # 案例审核规范 |
|---|
| | | # 案例审核规范 |
|---|
| | | |
|---|
| | | 创建人员：Codex |
|---|
| | | 文件职责：定义案例分析体系的审核范围、审核流程、设计审核、执行审核、证据链审核和问题阻断标准。 |
|---|
| | | 管理规范/模板：../../全局规范.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。 |
|---|
| | | 记录方式：项目本地审核规范；审核口径变化时更新，并同步项目变更记录。 |
|---|
| | | |
|---|
| | | 统一依赖：本规范必须同时遵守 `../../全局规范.md` 和 `../project-doc/项目规范.md`；项目本地案例审核规范可补充流程，但不得违反全局规范、全局项目规范和本体系硬约束。 |
|---|
| | | ## 1. 基本口径 |
|---|
| | | |
|---|
| | | ## 1. 审核定位 |
|---|
| | | 本项目所有案例审核员必须同时遵守 `../../common/ana-doc/案例审核规范.md` 和本文件。`laoshen` 是本项目案例审核员，同时兼任案例分析开发审核员；案例分析开发相关审核结论统一写入 `ana-doc/案例审计报告.md`。 |
|---|
| | | |
|---|
| | | 案例审核检查案例分析是否真的按目标和设计完成。 |
|---|
| | | ## 2. 审核范围 |
|---|
| | | |
|---|
| | | 审核重点是： |
|---|
| | | 审核员至少检查： |
|---|
| | | |
|---|
| | | 1. 设计是否能满足目标。 |
|---|
| | | 2. 执行是否按设计走。 |
|---|
| | | 3. 每个关键判断是否有证据。 |
|---|
| | | 4. 结果是否和过程、数据、图片一致。 |
|---|
| | | 5. 结论是否过读。 |
|---|
| | | 1. 设计是否明确案例来源、目标、边界、证据要求和产物。 |
|---|
| | | 2. 执行是否按设计完成，证据路径是否可打开、可追溯。 |
|---|
| | | 3. 结论是否降读，是否避免交易建议和未经验证的因果判断。 |
|---|
| | | 4. K 线、成交量、市场背景、替代解释是否按任务需要纳入。 |
|---|
| | | 5. 是否存在从其他项目复制的旧内容、旧路径、旧结果包或旧业务结论。 |
|---|
| | | 6. 是否遵守“主体内容落文档，窗口只展示摘要和证据入口”的上下文保护要求。 |
|---|
| | | |
|---|
| | | ## 2. 设计审核 |
|---|
| | | ## 3. 审计记录位置 |
|---|
| | | |
|---|
| | | 设计审核在正式执行前进行。 |
|---|
| | | | 情况 | 主记录位置 | |
|---|
| | | |---|---| |
|---|
| | | | 初始化审计 | `案例审计报告.md` | |
|---|
| | | | 设计审核 | `案例审计报告.md` | |
|---|
| | | | 执行审核 | `案例审计报告.md` | |
|---|
| | | | 审计发现问题 | `案例审计报告.md` 为主，`案例问题记录.md` 只做跨轮索引 | |
|---|
| | | | 非审计来源问题 | `案例问题记录.md` | |
|---|
| | | |
|---|
| | | 必须检查： |
|---|
| | | ## 4. 审核结论 |
|---|
| | | |
|---|
| | | 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`，仅限修正案例审核流程、审计口径和阻断标准；不得借此修改被审的案例分析规范、案例设计、执行日志、结果包或主产物。 |
|---|
| | | |
|---|
| | | 审核员不得直接改被审计主产物来掩盖问题。 |
|---|
| | | |
|---|
| | | 如确需修改案例分析执行规范，应创建规范维护事项，或额外授予案例体系维护 / 规范维护角色，并记录原因、影响范围和复审入口。 |
|---|
| | | |
|---|
| | | 审核员应抓真问题，不把边角料升级成阻断。 |
|---|
| | | 审核结论使用：`通过`、`有条件通过`、`不通过`、`HELD`。结论必须包含证据入口、阻断项、需要修复的文档或结果包路径。 |
|---|
