From e87cfdcb76a359d217130b33ffb4ed917b64d230 Mon Sep 17 00:00:00 2001 From: 1 <wentingyear@gmail.com> Date: Thu, 25 Jun 2026 20:56:54 +0800 Subject: [PATCH] fix: rebuild project-info system documents --- ana-doc/案例审核规范.md | 153 ++++++++------------------------------------------ 1 files changed, 26 insertions(+), 127 deletions(-) diff --git "a/ana-doc/\346\241\210\344\276\213\345\256\241\346\240\270\350\247\204\350\214\203.md" "b/ana-doc/\346\241\210\344\276\213\345\256\241\346\240\270\350\247\204\350\214\203.md" index c7091d6..27f845f 100644 --- "a/ana-doc/\346\241\210\344\276\213\345\256\241\346\240\270\350\247\204\350\214\203.md" +++ "b/ana-doc/\346\241\210\344\276\213\345\256\241\346\240\270\350\247\204\350\214\203.md" @@ -1,137 +1,36 @@ -# 案例审核规范 +# 案例审核规范 -创建人员：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`。结论必须包含证据入口、阻断项、需要修复的文档或结果包路径。 -- Gitblit v1.9.3