| | |
|---|
| | | # 案例审核规范 |
|---|
| | | # 案例审核规范 |
|---|
| | | |
|---|
| | | 创建人员：management.admin |
|---|
| | | 文件职责：记录 `project-info` 项目案例审核员必须遵守的本地审核规范。本文件引用 common 案例审核规范，不得削弱 common 硬约束。 |
|---|
| | | 管理规范/模板：../../common/ana-doc/案例审核规范.md；../../common/ana-doc/案例分析环境创建指南.md。 |
|---|
| | | 引用文件：案例分析规范.md；案例总纲.md；案例分析设计.md；案例执行日志.md；案例审计报告.md；案例问题记录.md；../项目配置清单.md。 |
|---|
| | | 创建人员：management.admin |
|---|
| | | 文件职责：记录 `project-info` 项目案例审核员必须遵守的本地审核规范，覆盖研报案例的设计审核、执行审核、存储归档审核、输出审核、结论边界审核和复审。 |
|---|
| | | 管理规范/模板：../../common/ana-doc/案例审核规范.md；../../common/ana-doc/案例分析环境创建指南.md。 |
|---|
| | | 引用文件：案例分析规范.md；数据抓取脚本说明.md；案例存储体系.md；案例总纲.md；案例分析设计.md；案例执行日志.md；案例审计报告.md；案例问题记录.md；研报体系/研报解析架构.md；研报体系/研报分析架构.md；../项目配置清单.md。 |
|---|
| | | 记录方式：项目本地审核规范；审核口径变化时更新，并同步项目变更记录。 |
|---|
| | | |
|---|
| | | ## 1. 基本口径 |
|---|
| | | |
|---|
| | | 本项目所有案例审核员必须同时遵守 `../../common/ana-doc/案例审核规范.md` 和本文件。`laoshen` 是本项目案例审核员，同时兼任案例分析开发审核员；案例分析开发相关审核结论统一写入 `ana-doc/案例审计报告.md`。 |
|---|
| | | |
|---|
| | | 审核员的目标不是只看 summary，而是确认案例是否真的按设计执行、证据是否可追溯、存储是否可复核、结论是否不过读、问题是否闭环。 |
|---|
| | | |
|---|
| | | 本文件负责把 `研报解析架构.md` 和 `研报分析架构.md` 中的研报专业要求转化为 ana 案例体系的审核口径。行业目录内的 `案例审核规范.md` 默认只作为继承入口和行业补充检查，不应复制本文件的阶段门、审核类型、阻断条件和问题闭环规则。 |
|---|
| | | |
|---|
| | | ## 2. 审核范围 |
|---|
| | | |
|---|
| | | 审核员至少检查： |
|---|
| | | |
|---|
| | | 1. 设计是否明确案例来源、目标、边界、证据要求和产物。 |
|---|
| | | 1. 设计是否明确案例来源、目标、边界、证据要求、输出物和验收方式。 |
|---|
| | | 2. 执行是否按设计完成，证据路径是否可打开、可追溯。 |
|---|
| | | 3. 结论是否降读，是否避免交易建议和未经验证的因果判断。 |
|---|
| | | 4. K 线、成交量、市场背景、替代解释是否按任务需要纳入。 |
|---|
| | | 5. 是否存在从其他项目复制的旧内容、旧路径、旧结果包或旧业务结论。 |
|---|
| | | 6. 是否遵守“主体内容落文档，窗口只展示摘要和证据入口”的上下文保护要求。 |
|---|
| | | 3. 文件、证据、输出和 manifest 是否按 `案例存储体系.md` 归档。 |
|---|
| | | 4. 研报观点是否被拆成事实、数据、观点、假设和缺口，而不是直接当事实。 |
|---|
| | | 5. 结论是否降读，是否避免交易建议、收益承诺和未经验证的强因果判断。 |
|---|
| | | 6. K 线、成交量、市场背景、替代解释、市场反向补漏是否按任务需要纳入。 |
|---|
| | | 7. 暗线、事件链、意图判断是否与普通行业事实分离。 |
|---|
| | | 8. 单篇定位、批量最低产物、`unresolved_data_gap.csv`、`source_gap_audit.csv` 和冲突观点分账是否完整。 |
|---|
| | | 9. 是否存在从其他项目复制的旧内容、旧路径、旧结果包或旧业务结论。 |
|---|
| | | 10. 是否遵守“主体内容落文档和结果包，窗口只展示摘要和证据入口”的上下文保护要求。 |
|---|
| | | 11. 涉及外部抓取、本地 MySQL 导出或市场反向补漏脚本时，是否遵守 `数据抓取脚本说明.md`，脚本产物是否有 manifest、参数、SQL、hash、输出路径和只读边界。 |
|---|
| | | 12. 审核请求引用的正式文档、条目 ID、结果包和证据入口是否在提交审核前已经落地；如无法证明提交前已存在，必须标记为补录风险或时序缺陷，不得直接给出无条件通过。 |
|---|
| | | |
|---|
| | | ## 3. 审计记录位置 |
|---|
| | | 审核前置核查要求： |
|---|
| | | |
|---|
| | | 1. 审核员接到设计审核、执行审核、输出审核或复审请求后，必须先核查消息中列出的审核对象是否真实存在。 |
|---|
| | | 2. 前置核查至少记录：消息 ID、消息创建时间、审核对象路径、条目 ID、文件位置或行号、当前文件修改状态、是否存在提交后补录风险。 |
|---|
| | | 3. 若审核对象在正式文档中不存在，审核结论只能为 `需补充`、`退回修改` 或 `HELD`，不得用消息摘要替代正式文档进行审核。 |
|---|
| | | 4. 若审核对象当前存在但无法确认是否在提交前已存在，审计报告必须写明“提交前落地状态无法证明”，结论不得高于有条件通过，除非后续重新提交审核。 |
|---|
| | | 5. 若确认存在提交后补录、先执行后补设计、先提交后补证据等时序倒置，必须作为审计问题记录，要求分析员按补录后的当前版本重新提交审核。 |
|---|
| | | |
|---|
| | | ## 3. 审核类型 |
|---|
| | | |
|---|
| | | 研报案例至少覆盖以下审核类型： |
|---|
| | | |
|---|
| | | 1. 新行业容器创建审核：检查 `<行业>案例/` 目录、基础文档、行业方案、父级导读登记和审计入口是否完整，并确认行业目录没有平行的 `案例总纲.md`。 |
|---|
| | | 2. 行业方案审核：检查 `<行业>研报解析方案.md` 是否继承研报解析架构、研报分析架构和父级案例存储体系。 |
|---|
| | | 3. 案例设计审核：检查目标、边界、输入资料、执行步骤、证据要求、输出物、存储路径和验收方式是否完整。 |
|---|
| | | 4. 执行过程审核：检查执行日志是否能还原研报读取、转换、抽取、补充、分析、输出和归档全过程。 |
|---|
| | | 5. 存储归档审核：检查行业级 `raw/`、`converted/`、`extracted/`、`supplement/`、`evidence/`、`manifest/`，案例级 `outputs/`、`manifest/`、`evidence/`，以及父体系 `tmp/`、`result/`、`img/` 是否按规则使用。 |
|---|
| | | 6. 输出文档审核：检查行业视图、市场视图、公司视图和扩展文档是否有证据支撑。 |
|---|
| | | 7. 结论边界审核：检查强结论、投资读法、公司判断、行业判断是否过读。 |
|---|
| | | 8. 复审：检查前次审计问题是否被修复，是否产生新问题；行业方案、案例设计、存储路径、证据链、输出文档或结论边界发生实质变化时，也必须进入复审。 |
|---|
| | | |
|---|
| | | 行业子审核规范使用规则： |
|---|
| | | |
|---|
| | | 1. 行业 `案例审核规范.md` 必须声明继承父级 `案例审核规范.md`、父级 `案例分析规范.md`、父级 `案例存储体系.md` 和两份研报方法母版。 |
|---|
| | | 2. 没有行业自定义审核点时，行业 `案例审核规范.md` 只记录继承关系、当前覆写状态和少量行业补充检查。 |
|---|
| | | 3. 行业专业审核点应来自 `<行业>研报解析方案.md`、行业 `案例分析设计.md` 和已通过的设计审核，不能削弱父级阶段门、阻断条件、证据追溯、存储归档和结论边界要求。 |
|---|
| | | 4. 如果行业子审核规范和父级审核规范冲突，审核员先按父级审核规范执行，并把冲突点作为审计问题或规范维护事项处理。 |
|---|
| | | |
|---|
| | | ## 4. 研报分析流程审核 |
|---|
| | | |
|---|
| | | 审核员必须按 `案例分析规范.md` 的“案例分析员融合执行流程”检查研报案例，不得只看最终 summary。 |
|---|
| | | |
|---|
| | | | 阶段 | 审核重点 | 阻断条件 | |
|---|
| | | |---|---|---| |
|---|
| | | | `G0` 任务接入 | 来源聊天、目标、边界是否进入总纲或设计 | 来源不明、目标和用户要求不一致 | |
|---|
| | | | `G1` 行业容器 | 行业目录是否存在，是否无平行 `案例总纲.md` | 行业过程明细写回父级或行业内建总纲 | |
|---|
| | | | `G2` 行业方案 | `<行业>研报解析方案.md` 是否从模板升格为可执行方案 | 方案缺失、仍是模板、没有行业边界和输出方案 | |
|---|
| | | | `G3` 案例登记与设计 | 父级总纲是否登记真实案例，行业设计是否冻结 batch/run | 没有父级总纲，或把每批资料误建成新案例 | |
|---|
| | | | `G4` 设计审核 | 设计审核是否先于正式执行 | 未审核就正式分析 | |
|---|
| | | | `G5` 资料归档与转换 | raw、converted、manifest、hash、文件头识别是否完整 | raw 未归档、路径不可复核、转换状态不清 | |
|---|
| | | | `G6` 抽取与补数 | evidence、extracted、supplement、缺口和 darkline 是否按需处理 | 观点当事实、缺关键数据却写强结论 | |
|---|
| | | | `G7` 人读输出 | 行业视图、市场视图、公司视图是否有证据支撑 | 只有标题式结论或三类视图缺失 | |
|---|
| | | | `G8` 自检与归档 | tmp/result/img 分流、manifest、验证报告是否完整 | 临时文件当证据，缺 result 入口或图片 manifest | |
|---|
| | | | `G9` 执行审核与回写 | 审计、复审、总纲/设计/方案回写是否完成 | 未复审就标记完成或对外交付 | |
|---|
| | | |
|---|
| | | 分析流程审核要求： |
|---|
| | | |
|---|
| | | | 审核面 | 必查问题 | 阻断条件 | |
|---|
| | | |---|---|---| |
|---|
| | | | 案例分析员融合执行流程 | 是否按 `案例分析规范.md` 的“案例分析员融合执行流程”执行，覆盖来源、总纲、设计、设计审核、执行、日志、结果包、执行审核、修复复审和回写 | 研报流程只写专业处理步骤，缺少 common 生命周期任一硬控制点 | |
|---|
| | | | ana 来源和总纲 | 研报任务来源、目标、行业、边界是否先进入父级总纲 | 只有行业方案或输出文档，父级总纲没有来源入口 | |
|---|
| | | | ana 设计冻结 | 行业设计是否写清 `case_id/batch_id/run_id`、输入范围、执行步骤、证据要求、输出和验收 | 设计只是标题或任务描述，不能指导执行 | |
|---|
| | | | 研报行业方案 | `<行业>研报解析方案.md` 是否把行业边界、核心变量、输出方案、专属表、流程覆写和缺口写清 | 方案仍是模板，或只引用母版但无行业展开 | |
|---|
| | | | 研报归档转换 | raw、converted、source_document、conversion_status、hash、文件头识别是否可追溯 | 只读资料、不归档，或转换结果无法反查 raw | |
|---|
| | | | 研报抽取补数 | extracted、evidence、supplement、数据卡、缺口、`unresolved_data_gap`、`source_gap_audit` 和 darkline 分流是否存在 | 观点直接进结论，缺核心数据却没有缺口状态 | |
|---|
| | | | 人读输出 | 行业视图、市场视图、公司视图是否从证据链生成 | 三类视图缺失，或细分文档替代顶层视图 | |
|---|
| | | | 存储分流 | 行业级通用产物、案例级输出、父体系 `tmp/result/img` 是否各归其位 | raw 或通用产物落入逐案例目录，tmp 被当正式证据 | |
|---|
| | | | 审计闭环 | 执行日志、审计报告、修复、复审、总纲/设计/方案回写是否完整 | 未复审就交付，或审计问题没有主记录 | |
|---|
| | | |
|---|
| | | 行业方案审核必须单独给结论。审核员至少检查： |
|---|
| | | |
|---|
| | | 1. 方案是否明确本行业包含和不包含的范围。 |
|---|
| | | 2. 方案是否列出核心子行业、技术路线、商业模式、产业链分层或主导变量。 |
|---|
| | | 3. 方案是否说明行业视图、市场视图、公司视图和扩展文档怎么输出。 |
|---|
| | | 4. 方案是否定义行业专属表、文件型清单或明确本轮暂不建表。 |
|---|
| | | 5. 方案是否说明 raw、converted、extracted、supplement、evidence、manifest、outputs、tmp、result、img 的落点。 |
|---|
| | | 6. 方案是否说明是否覆写母版流程；如果覆写，是否保留父级总纲、设计审核、执行日志、执行审核、问题闭环和结论回写。 |
|---|
| | | 7. 方案是否明确缺口清单、市场反向补漏和 darkline 触发边界。 |
|---|
| | | 8. 方案是否仍写着“模板”“待正式任务补齐”等不能支撑正式执行的状态。若仍是模板，只能允许容器初始化或体系 dry-run，不得允许正式研报分析。 |
|---|
| | | |
|---|
| | | 管理端自检和正式审核必须区分。Codex 或管理端可以做体系维护自检，但自检结论不能冒充 `case_analysis.reviewer / laoshen` 的正式审核结论；正式放行仍以项目配置清单中的审核员角色为准。 |
|---|
| | | |
|---|
| | | 方案、设计和输出复审触发规则： |
|---|
| | | |
|---|
| | | 1. `<行业>研报解析方案.md` 新建、从模板升格、重要优化，或变更行业边界、核心变量、输出方案、专属表、流程覆写、存储落点、缺口清单时，必须审核或复审。 |
|---|
| | | 2. `案例分析设计.md` 新建，或变更资料范围、case/batch/run、执行步骤、证据要求、输出物、存储路径、darkline 触发边界或验收方式时，必须审核或复审。 |
|---|
| | | 3. 正式资料归档、转换、抽取、补数、证据组织、核心文档输出或 manifest 归档完成后，必须执行审核。 |
|---|
| | | 4. 核心文档准备对外交付、进入正式结果入口或回写完成状态前，必须通过输出审核或执行审核。 |
|---|
| | | 5. 仅修改错别字、格式、链接显示等不影响流程、证据、存储、输出和结论边界的小修，可以只抽查维护记录；如审核员判断影响可复核性，仍应要求复审。 |
|---|
| | | |
|---|
| | | 市场反向补漏审核要求： |
|---|
| | | |
|---|
| | | 1. 设计是否说明本轮是否需要市场反向补漏；如果不做，是否有清楚的适用性判断。 |
|---|
| | | 2. 需要做补漏时，是否使用 `darkline` 拉取或分析近 3 个月强显影股票清单，至少覆盖涨停或多次涨停、连续大涨、放量突破、逆行业上涨、明显强于同行、资金持续显影。 |
|---|
| | | 3. 是否按公司核心业务重新归因，而不是只按题材标签、宽关键词或研报覆盖标签归类。 |
|---|
| | | 4. 是否给每个对象标记 `scope_type`：`CORE_INDUSTRY`、`ADJACENT_DOWNSTREAM` 或 `FALSE_THEME_OR_NOISE`。 |
|---|
| | | 5. `CORE_INDUSTRY` 是否进入补资料清单；`ADJACENT_DOWNSTREAM` 是否单独 review；`FALSE_THEME_OR_NOISE` 是否只保留审计记录。 |
|---|
| | | 6. 是否产出 `market_manifestation_gap_audit.csv`、`market_manifestation_gap_priority.csv`、`market_manifestation_gap_summary.json` 或等价结构化表。 |
|---|
| | | 7. 是否把市场反向补漏用于发现缺口，而不是直接当作投资结论或公司推荐依据。 |
|---|
| | | |
|---|
| | | ## 5. 设计审核 |
|---|
| | | |
|---|
| | | 设计审核在正式执行前进行。行业方案未通过审核或复审时，设计审核不得放行；设计审核未通过，不得进入正式研报分析执行。 |
|---|
| | | |
|---|
| | | 必须检查： |
|---|
| | | |
|---|
| | | 1. 父级 `案例总纲.md` 是否记录来源聊天、上游依据、行业范围、目标和边界。 |
|---|
| | | 2. 是否确认行业案例目录；不存在时是否按新行业创建流程创建。 |
|---|
| | | 3. 是否读取父级 `案例分析规范.md`、`案例审核规范.md`、`案例存储体系.md` 和研报方法母版。 |
|---|
| | | 4. 是否创建或更新 `<行业>研报解析方案.md`。 |
|---|
| | | 5. 行业方案是否说明行业边界、子行业、核心变量、人读输出、行业专属表和缺口。 |
|---|
| | | 6. 设计是否明确原始资料来源、样本范围、执行步骤、证据要求、输出物、存储路径和验收方式。 |
|---|
| | | 7. 设计是否把 `案例分析规范.md` 的“案例分析员融合执行流程”落成具体步骤，而不是只写阶段名或最终目标。 |
|---|
| | | 8. 是否说明是否需要外部信息补充、市场反向补漏或 darkline 分析；需要市场反向补漏时，是否写明近 3 个月强显影股票扫描口径、scope 闸门、补资料输出和不把市场显影直接当投资结论的边界。 |
|---|
| | | 9. 是否说明主动补数据触发条件、`unresolved_data_gap.csv`、`source_gap_audit.csv`、单篇/批量最低产物和冲突观点分账要求。 |
|---|
| | | 10. 是否说明 MySQL 或结构化记录的使用范围和追溯方式。 |
|---|
| | | 11. 如需使用 `ana-data/tools/` 脚本，是否说明脚本名、输入范围、关键词或 SQL 来源、输出路径、manifest、只读边界和复核方式。 |
|---|
| | | 12. 是否明确 `PASS / FAIL / HELD` 或等价验收标准。 |
|---|
| | | 13. 设计条目是否在提交设计审核前已经写入正式 `案例分析设计.md` 或行业子目录对应设计账本；审核员必须记录条目 ID、文件路径和行号。若设计条目为提交后补录，必须退回或要求重新提交审核。 |
|---|
| | | |
|---|
| | | 如果案例事项使用行业自定义流程，设计审核必须检查该流程是否满足父级案例体系硬约束。行业流程通过设计审核后，执行审核以已通过的行业流程为准；只有发现行业流程违反父级硬约束时，才要求整改。 |
|---|
| | | |
|---|
| | | ## 6. 执行审核 |
|---|
| | | |
|---|
| | | 执行审核在案例执行后进行。执行审核未通过，不得把案例事项标记为完成或可交付。 |
|---|
| | | |
|---|
| | | 必须检查： |
|---|
| | | |
|---|
| | | 1. 执行是否按已审核通过的设计进行。 |
|---|
| | | 2. 执行日志是否记录资料归档、转换、抽取、补充、证据、输出和自检。 |
|---|
| | | 3. 执行日志是否能按“案例分析员融合执行流程”还原：来源总纲、行业方案、设计审核、raw 归档、转换抽取、补数分流、证据数据卡、人读输出、归档自检、执行审核。 |
|---|
| | | 4. 原始资料是否全部进入行业统一 raw 池 `ana-data/cases/<行业案例>/raw/`，且未被覆盖、改写。 |
|---|
| | | 5. 转换文本、表格、OCR、页面切分结果是否进入行业级 `converted/`。 |
|---|
| | | 6. 事实、指标、观点、公司映射、缺口是否进入行业级 `extracted/` 或等价结构化记录。 |
|---|
| | | 7. 外部公开资料补充和市场反向补漏是否进入行业级 `supplement/`，市场显影证据、范围闸门和补漏结论是否进入行业级 `evidence/` 或等价结构化记录。 |
|---|
| | | 8. 通用证据事实、数据卡底座、来源定位是否进入行业级 `evidence/`；案例结论证据映射是否进入案例级 `evidence/`。 |
|---|
| | | 9. 单篇研报是否保留 doc_id、页码或段落定位、句子/表格索引、时间、单位、口径、对象归属和置信度。 |
|---|
| | | 10. 批量研报是否输出或更新 `input_manifest.csv`、`conversion_status.csv`、`evidence_fact_table.csv`、`classification_summary.csv`、`unresolved_data_gap.csv`、`source_gap_audit.csv`、`batch_summary.md`、`next_action_list.csv` 或等价结构化记录。 |
|---|
| | | 11. 资料之间的支持、反对、重复观点和口径冲突是否分账记录，没有被强行合并。 |
|---|
| | | 12. 正式输出是否进入案例级 `outputs/`。 |
|---|
| | | 13. 行业级 `manifest/` 是否记录文件清单、来源清单、处理批次、执行轮次、hash 或等价摘要，并包含 `case_id`、`batch_id`、`run_id`；案例级 `manifest/` 是否记录本案例引用了哪些行业级资料。 |
|---|
| | | 14. 临时文件是否进入 `ana-data/tmp/<行业案例>/<case_id>/<run_id>/`，且没有被当成正式证据或正式结果入口。 |
|---|
| | | 15. 结果入口或交付包索引是否进入 `ana-data/result/<行业案例>/<case_id>/`；涉及图片时，图片、截图、OCR 图片或图册是否进入 `ana-data/img/<行业案例>/<case_id>/`。 |
|---|
| | | 16. MySQL 或结构化记录是否能反查案例 ID、原始资料、转换结果、证据和输出路径。 |
|---|
| | | 17. 如使用 `ana-data/tools/` 脚本，输出是否进入行业 `supplement/evidence/manifest` 或父体系 `tmp/result/img`，SQL 是否只读，manifest 是否记录脚本参数、输出路径和 row_count。 |
|---|
| | | 18. 结论是否没有超过证据。 |
|---|
| | | |
|---|
| | | 执行审核还必须抽查本轮是否正确处理 `batch_id` 和 `run_id`： |
|---|
| | | |
|---|
| | | 1. 同一研究目标的多次资料读取是否仍属于同一个案例。 |
|---|
| | | 2. batch 是否只表达输入批次，不表达新的行业案例。 |
|---|
| | | 3. run 是否只表达执行轮次，不替代设计审核或审计记录。 |
|---|
| | | 4. manifest、source_document、conversion_status、evidence_index 和案例输入清单中的 `case_id/batch_id/run_id` 是否一致。 |
|---|
| | | |
|---|
| | | ## 7. 输出审核 |
|---|
| | | |
|---|
| | | 输出审核在核心文档对外交付、进入正式结果入口或回写完成状态前进行。审核员必须检查人读文档是否真正满足研报体系的输出要求： |
|---|
| | | |
|---|
| | | 1. 行业视图是否讲清行业是什么、怎么运行、核心变量和产业链逻辑。 |
|---|
| | | 2. 市场视图是否讲清价格、库存、供需、政策、资金显影和市场阶段。 |
|---|
| | | 3. 公司视图是否讲清公司业务结构、行业暴露、核心竞争力、投资读法、风险和失效条件。 |
|---|
| | | 4. 关键结论是否有来源、数据日期、历史比较、横向比较、公司或链条案例。 |
|---|
| | | 5. 专业术语是否用普通人能理解的方式解释。 |
|---|
| | | 6. 研报观点、事实、推理、暗线假设和投资读法是否分账。 |
|---|
| | | 7. 数据不足时是否降级为 `DATA_GAP_REVIEW`、`DATA_PARTIAL`、`MECHANISM_ONLY` 或 `HELD_BY_EVIDENCE_GAP`。 |
|---|
| | | 8. 输出前是否读取市场反向补漏结果；如果发现遗漏公司、子行业、资源品种、技术路线或关键变量，是否先进入补资料和缺口流程。 |
|---|
| | | 9. 成熟子行业、核心技术路线或核心公司是否具备基础事实卡；缺失基础事实时是否降级，不直接写强结论。 |
|---|
| | | 10. 人读文档是否按结构化记录和证据数据卡 -> 子行业详细材料 -> 子行业总览 -> 公司文档 -> 行业/市场总览和索引的顺序更新，最终入口是否仍是行业视图、市场视图、公司视图。 |
|---|
| | | 11. 重要场景假设是否写清影响映射、触发条件、失效条件和主要风险。 |
|---|
| | | 12. 对外交付版本是否能从 `ana-data/result/<行业案例>/<case_id>/result_index.md` 进入，并能反查到 `outputs/`、证据映射和 manifest。 |
|---|
| | | |
|---|
| | | ## 8. 研报案例高风险问题清单 |
|---|
| | | |
|---|
| | | 审核员必须重点发现以下问题： |
|---|
| | | |
|---|
| | | 1. 没有创建行业容器目录，把行业案例过程明细写回父级 `ana-doc/`，或在行业目录内创建平行的 `案例总纲.md`。 |
|---|
| | | 2. 行业子规范和父级 `案例分析规范.md`、`案例审核规范.md`、`案例存储体系.md` 冲突。 |
|---|
| | | 3. 行业子审核规范或行业子分析规范复制父级通用流程后形成第二套母版，导致执行 AI 不清楚以父级还是子级为准。 |
|---|
| | | 4. 行业方案缺失，或行业方案没有继承研报解析架构、研报分析架构和父级案例存储体系。 |
|---|
| | | 5. 行业方案仍是模板、没有行业边界、没有输出方案或没有专属表/缺口定义，却开始正式研报分析。 |
|---|
| | | 6. 设计审核未通过就开始正式研报分析。 |
|---|
| | | 7. 案例设计没有写清目标、边界、资料来源、证据要求、输出文档和验收方式。 |
|---|
| | | 8. 案例设计只写阶段名或最终目标，没有把 ana 控制点和研报专业动作融合成可执行步骤。 |
|---|
| | | 9. 审核请求引用的设计、执行日志、审计对象、结果包或证据入口在提交审核时未落地，后续补录后冒充审核前记录。 |
|---|
| | | 10. 把同一长期行业案例的资料批次误拆成多个正式案例，或把不同研究目标误塞进同一个案例。 |
|---|
| | | 11. 原始研报没有进入行业统一 raw 池 `ana-data/cases/<行业案例>/raw/`，按 case/batch 分散存放 raw，或 raw 原始文件被覆盖、改写。 |
|---|
| | | 12. 转换文本、表格、OCR、抽取结果、补充资料没有进入行业级统一目录，或输出文档没有进入案例级 `outputs/`。 |
|---|
| | | 13. 临时文件没有进入父体系 `ana-data/tmp/<行业案例>/<case_id>/<run_id>/`，被放入案例资料目录，或被当成正式证据、正式结果入口。 |
|---|
| | | 14. 结果入口或交付包索引没有进入父体系 `ana-data/result/<行业案例>/<case_id>/`；涉及图片时图片没有进入 `ana-data/img/<行业案例>/<case_id>` 或缺少图片 manifest。 |
|---|
| | | 15. 没有 manifest、来源清单、证据索引或等价可追踪记录。 |
|---|
| | | 16. MySQL 结构化记录不能反查到行业级原始资料、转换结果、抽取结果、证据，或案例级输出路径。 |
|---|
| | | 17. 只采信券商结论，没有拆出事实、数据、假设、观点和证据。 |
|---|
| | | 18. 核心指标没有数据卡，或缺少数据日期、来源、历史比较、横向比较和结论强度。 |
|---|
| | | 19. 重要结论没有公司、项目、链条、数据或案例支撑。 |
|---|
| | | 20. 用故事、机制解释或专家观点替代指标数据。 |
|---|
| | | 21. 缺少市场反向补漏，或只写“已补漏”但没有近 3 个月强显影股票清单、核心业务重归因、scope 闸门、缺口清单和补充资料记录。 |
|---|
| | | 22. 行业边界被关键词污染，把相邻行业、下游噪音或伪主题纳入核心结论。 |
|---|
| | | 23. 暗线、事件链和意图判断混入普通行业事实。 |
|---|
| | | 24. 需要网上补充、外部信息、新闻公告、事件链、市场显影或暗线分析时，没有使用 `darkline` 技能。 |
|---|
| | | 25. 批量处理没有 `unresolved_data_gap.csv`、`source_gap_audit.csv`、`batch_summary.md`、`next_action_list.csv` 或等价记录。 |
|---|
| | | 26. 资料之间存在支持、反对、重复观点或口径冲突，但输出里被合并成单一结论。 |
|---|
| | | 27. 输出文档只有标题式结论，没有证据、推理、失效条件和结论边界。 |
|---|
| | | 28. 行业视图、市场视图、公司视图缺失，或被细分文档替代。 |
|---|
| | | 29. 公司文档没有投资读法、风险、证据链或当前状态判断。 |
|---|
| | | 30. 基础事实卡缺失、核心变量无数据卡、场景假设无影响映射，却输出强结论或投资读法。 |
|---|
| | | 31. 结论超过证据，资料不足却没有标记 `DATA_GAP_REVIEW`、`DATA_PARTIAL`、`MECHANISM_ONLY` 或 `HELD_BY_EVIDENCE_GAP`。 |
|---|
| | | 32. 审计问题没有进入 `案例审计报告.md`，需跨轮或跨角色跟踪的问题没有进入 `案例问题记录.md`，或执行者自发现且可处理的问题被误写入 `案例问题记录.md`。 |
|---|
| | | 33. 行业方案、案例设计、核心输出、存储路径、证据链或结论边界发生重要变化，但没有提交复审。 |
|---|
| | | 34. 核心文档输出完成后，没有通过输出审核或执行审核就对外交付、进入正式结果入口或回写完成状态。 |
|---|
| | | 35. 抓取脚本、SQL、网页快照、市场反向补漏结果或查询 CSV 留在 `ana-data/tools/`、私人工作区或未登记路径，没有进入规范落点。 |
|---|
| | | 36. 使用脚本执行写库 SQL、泄露数据库密码/token/cookie，或把市场显影扫描结果直接写成投资结论。 |
|---|
| | | |
|---|
| | | ## 9. 证据抽查方法 |
|---|
| | | |
|---|
| | | 审核员不仅阅读结论，还要抽查证据链。 |
|---|
| | | |
|---|
| | | 建议方法： |
|---|
| | | |
|---|
| | | 1. 从父级案例总纲追到行业目录案例设计、执行日志、审计报告和问题记录，确认链路完整。 |
|---|
| | | 2. 从输出文档反向追到案例级证据映射，再追到行业级 `evidence/`、`extracted/`、`converted/` 和 `raw/`。 |
|---|
| | | 3. 抽查 1-3 个强结论，确认来源、数据日期、横向比较、历史比较和公司案例是否存在。 |
|---|
| | | 4. 抽查 1-3 个公司或细分行业，确认公司映射、指标和投资读法没有过读。 |
|---|
| | | 5. 抽查 manifest 和文件路径，确认不是临时文件、私有工作区或旧项目路径。 |
|---|
| | | 6. 对涉及脚本或自动化输出的结果，检查输入范围、参数、输出路径和证据包是否与案例设计一致。 |
|---|
| | | 7. 对涉及市场显影或暗线的内容，检查是否使用 darkline，并与普通行业事实分离。 |
|---|
| | | 8. 对涉及 `ana-data/tools/` 的结果，抽查脚本 SQL 或参数、只读边界、row_count、hash、manifest 和输出文件是否能互相反查。 |
|---|
| | | |
|---|
| | | ## 10. 审核结论 |
|---|
| | | |
|---|
| | | 审核结论使用： |
|---|
| | | |
|---|
| | | ```text |
|---|
| | | 通过 |
|---|
| | | 有条件通过 |
|---|
| | | 不通过 |
|---|
| | | HELD |
|---|
| | | ``` |
|---|
| | | |
|---|
| | | 结论必须包含： |
|---|
| | | |
|---|
| | | 1. 审核 ID。 |
|---|
| | | 2. 审核类型：行业容器创建审核 / 行业方案审核 / 设计审核 / 执行审核 / 存储归档审核 / 输出审核 / 结论边界审核 / 复审。 |
|---|
| | | 3. 审核对象。 |
|---|
| | | 4. 审核依据。 |
|---|
| | | 5. 检查结果。 |
|---|
| | | 6. 问题清单。 |
|---|
| | | 7. 阻断项。 |
|---|
| | | 8. 需要修复的文档、结果包或路径。 |
|---|
| | | 9. 是否允许进入下一阶段。 |
|---|
| | | |
|---|
| | | `有条件通过` 只能用于不影响追溯、证据可信度和结论边界的轻微问题；凡影响证据链、存储归档、设计冻结、审核闭环或结论边界的问题，不得有条件通过。 |
|---|
| | | |
|---|
| | | ## 11. 必须阻断的问题 |
|---|
| | | |
|---|
| | | 以下问题必须阻断： |
|---|
| | | |
|---|
| | | 1. 设计目标和来源聊天不一致。 |
|---|
| | | 2. 设计审核未通过就执行正式案例。 |
|---|
| | | 3. 行业方案缺失且任务属于新行业研报案例。 |
|---|
| | | 4. 行业方案仍是模板或缺少行业边界、核心变量、输出方案、专属表/缺口定义，却进入正式分析。 |
|---|
| | | 5. 行业子规范违反父级规范或父级存储体系。 |
|---|
| | | 6. 原始资料未进入行业统一 raw 池，或无法确认来源、hash、路径。 |
|---|
| | | 7. 关键判断缺证据，导致无法复核。 |
|---|
| | | 8. manifest、证据索引或结果包缺失，导致链路断裂。 |
|---|
| | | 9. MySQL 或结构化记录无法反查原始资料、转换结果、证据和输出路径。 |
|---|
| | | 10. 使用未来信息支持实时判断、交易结论或收益结论。 |
|---|
| | | 11. 结论明显过读。 |
|---|
| | | 12. 暗线、事件链和普通行业事实混写并影响结论。 |
|---|
| | | 13. 需要外部信息、新闻公告、市场显影或暗线分析时未使用 `darkline`。 |
|---|
| | | 14. 批量研报分析缺少 `unresolved_data_gap.csv`、`source_gap_audit.csv`、核心 manifest 或证据索引，导致缺口、来源或批次无法复核。 |
|---|
| | | 15. 核心文档缺少行业视图、市场视图、公司视图，或基础事实卡、数据卡、证据链缺失导致强结论不可复核。 |
|---|
| | | |
|---|
| | | ## 12. 不应阻断的问题 |
|---|
| | | |
|---|
| | | 以下问题一般不阻断，但可以记录为修正建议： |
|---|
| | | |
|---|
| | | 1. 文档格式不够美观，但关键路径和证据可读。 |
|---|
| | | 2. 字段名不完全一致但映射关系清楚。 |
|---|
| | | 3. 非关键备注缺失。 |
|---|
| | | 4. 非关键案例的轻微说明不足。 |
|---|
| | | 5. 后续工程化尚未开始。 |
|---|
| | | 6. 输出文档仍需润色，但证据链、结论边界和审核入口完整。 |
|---|
| | | |
|---|
| | | ## 13. 审计记录位置 |
|---|
| | | |
|---|
| | | | 情况 | 主记录位置 | |
|---|
| | | |---|---| |
|---|
| | | | 初始化审计 | `案例审计报告.md` | |
|---|
| | | | 设计审核 | `案例审计报告.md` | |
|---|
| | | | 执行审核 | `案例审计报告.md` | |
|---|
| | | | 新行业容器创建审核 | 行业目录 `案例审计报告.md`；父级 `案例总纲.md` 登记相关案例入口 | |
|---|
| | | | 行业方案审核 | 行业目录 `案例审计报告.md` | |
|---|
| | | | 设计审核 | 行业目录或父级对应 `案例审计报告.md` | |
|---|
| | | | 执行审核 | 行业目录或父级对应 `案例审计报告.md` | |
|---|
| | | | 存储归档审核 | 行业目录或父级对应 `案例审计报告.md` | |
|---|
| | | | 输出审核 | 行业目录或父级对应 `案例审计报告.md` | |
|---|
| | | | 结论边界审核 | 行业目录或父级对应 `案例审计报告.md` | |
|---|
| | | | 复审 | 原审核记录所在 `案例审计报告.md` | |
|---|
| | | | 审计发现问题 | `案例审计报告.md` 为主，`案例问题记录.md` 只做跨轮索引 | |
|---|
| | | | 非审计来源问题 | `案例问题记录.md` | |
|---|
| | | | 外部反馈、执行者无法自行闭环或需跨轮/跨角色跟踪的非审计问题 | `案例问题记录.md` | |
|---|
| | | |
|---|
| | | ## 4. 审核结论 |
|---|
| | | |
|---|
| | | 审核结论使用：`通过`、`有条件通过`、`不通过`、`HELD`。结论必须包含证据入口、阻断项、需要修复的文档或结果包路径。 |
|---|
| | | 审核员不得直接改被审计主产物来掩盖问题。如需修改规范，应创建规范维护事项或取得案例体系维护授权，并记录原因、影响范围和复审入口。 |
|---|
