Cai
8 days ago bf157a136d9b08c14b4da2997dc5a03b1a1af33d
common/ana-doc/案例审核规范.md
@@ -20,6 +20,12 @@
4. 结果是否和过程、数据、图片一致。
5. 结论是否过读。
案例审核员还必须检查案例事项是否符合自身适用规范文档。适用范围包括 common 全局规范、全局项目规范、common 案例分析规范、项目本地案例分析规范,以及该案例直接声明采用的案例设计、存储、执行和审核规则。
如果案例设计或执行违反规范中的硬约束,例如跳过必要审核、未记录关键证据链、越权改写正式产物、候选选择与设计不一致、结论超出证据边界,必须反馈为审计问题。
如果只是命名、格式、表达方式等不影响案例目标、证据链、结论和后续使用的轻微差异,不应作为阻断问题。若规范之间冲突或规范本身不清楚,应标记为规范问题,不得强行按审核员个人理解加规则。
## 2. 设计审核
设计审核在正式执行前进行。
@@ -102,6 +108,15 @@
如果案例分析事项包含案例分析开发,案例分析开发的方案审核、实现审核、测试验收和复审结论也统一写入 `ana-doc/案例审计报告.md`,不另写到 `dev-doc/开发审计报告.md`。
案例分析开发中的临时草稿脚本可以不做独立代码审核;但只要代码用于生成正式案例结论、案例筛选、图表证据、账户流水、验收包、结果包、审计辅助报告或可复用工具,就必须纳入案例审核。审核重点不是把轻量脚本套成重型开发流程,而是确认案例证据可信:
1. 输入案例、样本范围、过滤条件是否和案例设计一致。
2. 输出图片、表格、流水、summary、manifest 或等价结果包是否能和案例执行日志对上。
3. 候选、入选、买入、卖出、退出、结论标签是否和案例规则一致。
4. 代码是否改写原始证据、污染正式数据或覆盖不可变结果。
5. 至少抽查关键案例,必要时人工复算 1-3 个操作点或关键行。
6. 是否需要防未来函数或数据泄漏必须按案例目标判断;涉及交易、买卖、收益验证、实时判断或自动动作时必须检查,后验理解、图形归纳、案例复盘、方法论总结类案例可以不作为实盘时点安全审核,但结论必须降读。
只有问题需要跨轮跟踪、跨案例汇总或由案例分析员长期处理时,才在 `案例问题记录.md` 中建立索引或关联,不重复全文。
审核报告至少包含:
@@ -119,6 +134,17 @@
审核员可以运行只读检查脚本、打开图片、读取表格、人工计算关键触发点。
审核员可以维护项目本地 `案例审核规范.md`,仅限修正案例审核流程、审计口径和阻断标准;不得借此修改被审的案例分析规范、案例设计、执行日志、结果包或主产物。
审核员不得直接改被审计主产物来掩盖问题。
如确需修改案例分析执行规范,应创建规范维护事项,或额外授予案例体系维护 / 规范维护角色,并记录原因、影响范围和复审入口。
审核员应抓真问题,不把边角料升级成阻断。
## 9. 长期行业成果路径审核
1. 长期行业研究的正式人读成果应从 `ana-data/cases/<行业>案例/当前成果索引.md` 进入,并合并维护在 `核心文档/`;审核员不得反向要求其为每个任务或批次另建 `<case_id>/outputs/`。
2. 候选应位于 `ana-data/tmp/<行业>案例/<task_id>/<run_id>/`。审核通过前不得进入核心文档;审核通过后不得继续把任务目录当作第二个当前成果入口。
3. `<case_id>/outputs/` 仅用于一次性专题、单公司或独立案例。判断路径是否合规时,先判断事项是“长期行业累计成果”还是“一次性独立案例”。
4. 旧任务输出的收口应一次检查内容合并、证据血缘和路径映射,不按文件拆分多轮审核。