# 研报体系导读

创建人员：Codex
文件职责：作为 `project-info/ana-doc` 研报体系入口导读，说明案例分析员、审核员和体系维护者在本体系下如何工作，以及应引用哪些核心文档。
管理规范/模板：目录导读.md；案例分析规范.md；案例审核规范.md；案例存储体系.md。
引用文件：案例分析规范.md；案例审核规范.md；案例存储体系.md；数据抓取脚本说明.md；案例总纲.md；案例分析设计.md；案例执行日志.md；案例审计报告.md；案例问题记录.md；研报体系/研报解析架构.md；研报体系/研报分析架构.md；研报体系/研报采集角色说明.md。
记录方式：体系入口导读；父级研报流程、存储口径、审核口径或行业目录创建方式变化时同步更新。

## 1. 本导读定位

本文不是新的流程母版，也不替代任何规范文件。它只回答一个问题：AI 或人工进入 `ana-doc` 研报体系后，应该先看什么、按什么顺序工作、产物写到哪里、由谁审核。

正式规则以以下核心文档为准：

1. 分析流程看 `案例分析规范.md`。
2. 审核流程看 `案例审核规范.md`。
3. 存储和落点看 `案例存储体系.md`。
4. 研报专业方法看 `研报体系/研报解析架构.md` 和 `研报体系/研报分析架构.md`。
5. 具体行业差异看对应行业目录下的 `<行业>研报解析方案.md`。

行业子目录里的 `案例分析规范.md`、`案例审核规范.md` 和 `案例存储体系.md` 默认只是轻量继承入口。没有经过审核确认的行业自定义时，不要把父级主流程复制到行业子目录形成第二套母版。

## 2. 最小阅读顺序

案例分析员接到研报或行业资料任务后，至少按顺序读取：

1. `研报体系导读.md`
2. `案例分析规范.md`
3. `案例存储体系.md`
4. 涉及外部抓取、本地 MySQL 导出或市场反向补漏时读取 `数据抓取脚本说明.md`
5. `研报体系/研报解析架构.md`
6. `研报体系/研报分析架构.md`
7. 目标行业目录的 `<行业>研报解析方案.md`
8. 目标行业目录的 `案例分析设计.md`

审核员接到设计审核、执行审核、输出审核或复审任务后，至少按顺序读取：

1. `研报体系导读.md`
2. `案例审核规范.md`
3. `案例分析规范.md`
4. `案例存储体系.md`
5. 被审核行业的 `<行业>研报解析方案.md`
6. 被审核行业的 `案例分析设计.md`
7. 被审核行业的 `案例执行日志.md`
8. 对应 manifest、evidence、outputs、result 入口

体系维护者修改规则时，必须同时检查：

1. `目录导读.md`
2. `研报体系导读.md`
3. `案例分析规范.md`
4. `案例审核规范.md`
5. `案例存储体系.md`
6. 受影响行业目录内的轻量继承文档

## 3. 核心文档职责

| 文档 | 使用者 | 职责 |
|---|---|---|
| `目录导读.md` | 所有人 | 说明 `ana-doc` 目录、行业容器、数据目录和当前案例入口 |
| `研报体系导读.md` | 所有人 | 说明如何进入研报体系工作，指向核心规范 |
| `案例分析规范.md` | 案例分析员 | 唯一分析流程入口，包含研报体系接入流程、资料归档、主动补数据、市场反向补漏、核心文档输出和审计触发规则 |
| `案例审核规范.md` | 审核员 | 唯一审核流程入口，包含设计审核、执行审核、存储审核、输出审核、结论边界审核和复审规则 |
| `案例存储体系.md` | 分析员、审核员 | 定义 raw、converted、extracted、supplement、evidence、manifest、outputs、tmp、result、img 和 MySQL 追溯口径 |
| `数据抓取脚本说明.md` | 分析员、审核员 | 说明 `ana-data/tools/` 中外部抓取、本地 MySQL 只读导出和市场反向补漏脚本的使用、落点和审核口径 |
| `研报体系/研报解析架构.md` | 分析员、方案编写者 | 定义行业方案继承机制、三类核心视图和解析原则 |
| `研报体系/研报分析架构.md` | 分析员、审核员 | 定义研报资料处理、证据抽取、主动补数据、市场反向补漏、暗线分流和人读文档闭环 |
| `研报体系/研报采集角色说明.md` | 研报采集员、任务安排者 | 定义通用研报下载、原始文件归档、manifest 字段以及“谁安排、谁审核”的采集流程 |
| `案例总纲.md` | 分析员、审核员 | 父级真实案例账本；行业容器不创建平行总纲 |
| `案例分析设计.md` | 分析员、审核员 | 父级或行业内的事项设计、批次设计、执行步骤、证据要求和验收方式 |
| `案例执行日志.md` | 分析员、审核员 | 记录实际执行过程、偏离、异常、自检和证据入口 |
| `案例审计报告.md` | 审核员 | 记录设计审核、执行审核、输出审核、复审和审计问题 |
| `案例问题记录.md` | 外部反馈、跨轮跟踪 | 只记录外部反馈、执行者无法自行闭环或需跨轮/跨角色跟踪的非审计问题 |

## 4. 行业容器和真实案例

行业目录是容器，不是一个真实案例。例如：

```text
ana-doc/有色案例/
ana-doc/机器人案例/
```

真实案例统一登记到父级 `案例总纲.md`。同一行业长期研究通常是一个长期案例，多次读取资料使用 `batch_id` 和 `run_id` 区分；只有研究目标不同，才新建不同案例。

行业目录根目录保留以下文档：

1. `目录导读.md`
2. `案例分析规范.md`
3. `案例审核规范.md`
4. `案例存储体系.md`
5. `案例分析设计.md`
6. `案例执行日志.md`
7. `案例审计报告.md`
8. `案例问题记录.md`
9. `<行业>研报解析方案.md`

其中行业 `案例分析规范.md`、`案例审核规范.md`、`案例存储体系.md` 默认只声明继承关系和少量行业补充。行业专业变量、专属字段、行业输出拆分、专属表和缺口清单，优先写入 `<行业>研报解析方案.md` 和该行业 `案例分析设计.md`。

## 5. 案例分析员工作方式

### 5.0 研报采集员的独立下载入口

`case_analysis.report_collector` 是下载和归档角色，不是案例分析员。项目内人工或已登记角色明确安排下载后，该角色可直接获取公开互联网中无需登录、无需绕过访问控制的研报，不设置逐次管理审批。采集员保存原始文件并生成 manifest；谁安排下载，谁审核结果。具体行业、主题、来源和落点由每次任务指定，未指定时不得自行把角色锁定到某个行业。详细规则见 `研报体系/研报采集角色说明.md`。

慧博来源允许采集员直接操作已处于可用状态的安卓模拟器，在 APP 内搜索、输入、筛选、点击、打开、截图并触发缓存，再通过 ADB 盘点和复制本地缓存。上述下载和模拟器操作属于日常采集权限，不设置逐次管理审批、独立审核、A001 或逐点击证据包；普通失败可在同一任务内修复和重试，由任务安排者做普通结果验收。固定包名为 `cn.com.hibor`，固定缓存目录为 `/sdcard/Android/data/cn.com.hibor/files/myfile/`。采集员不得修改模拟器原件；只有项目副本通过 `%PDF-` 魔数校验后才能补 `.pdf`，并须复核远端/本地 SHA-256、可打开性和 manifest。正式容器未明确时先进入 `ana-data/tmp/<task_id>/`。登录、验证码、付费提示、权限提示和其他访问控制仍交回人工，禁止绕过。完整操作与字段口径仍以 `研报体系/研报采集角色说明.md` 为准。

ADB 设备串号按运行时发现或任务显式 `-s <serial>` 处理；当前已验证实例为 `emulator-5554`，但不得把旧 `127.0.0.1:21503` 固化为默认事实。ADB 从缓存只读复制仍是默认路径；新模拟器另已验证 `/sdcard/Pictures` ↔ `F:\hb` 共享通道，可作为快速传输或回退，不要求每次双路径复制。共享通道只是项目外临时暂存：缓存原件不变、全程唯一名/CreateNew、不覆盖，并要求 `%PDF-`、bytes、缓存 SHA、共享端 SHA 和项目副本 SHA 闭合；正式权威仍是项目内 PDF 原件与 manifest。

该轻量下载入口不等于研究分析或正式案例执行授权；资料解析、结论输出和案例审核仍按后续任务及相应规范办理。可复用自动化脚本按普通本地开发工具管理，允许在已登记事项内开发、测试、修复和重跑，不要求管理端逐次一次性授权或普通源文件字节级预冻结。

慧博默认选取采用可复算客观规则：输入不完整时使用“标题检索 + 最近 2 年”，主体/标题必须明确匹配；只接受详情页可识别机构、日期和页数的 PDF。评分综合任务点名条件、页数、报告深度、时效性和机构/分析师多样性；无明确名单时不得主观判断“知名分析师”，默认同一机构只取 1 份。同分按硬条件、总分、页数、日期和结果原始顺序处理，扫描上限为 20 屏或 100 个不重复候选，不足时回传缺口。完整分值、重试、停止、缓存差分、校验和 manifest 规则见 `研报体系/研报采集角色说明.md` 第 4.2 节。

研报采集现作为项目公开能力 `REPORT-COLLECTION-CAPABILITY-V1` 提供给人工和已登记角色。角色通过 Codex 原生任务向 `case_analysis.report_collector` 单次发送 `report_collection_request`，请求者负责普通验收；采集员以 `report_collection_terminal` 返回 PDF 原件、manifest、可选元数据型交付说明、失败/缺口和额度摘要。PDF 与 SHA-256 是权威原件；采集员不把正文转 Markdown，OCR/Markdown/表格属于保留 PDF SHA-256 血缘的独立下游能力。

慧博额度按北京时间自然日管理：名义上限 30、自动化正常目标 25、硬停止 27、永久保留 3。额度按可能触发新的不同研报下载计数，触发后的损坏、重复、非 PDF 或不确定状态仍保守占用；项目原件复用或不重新打开 APP 的既有缓存复制不占新额度。达到 27 必须返回部分终态，禁止为了凑数使用第 28–30 份。完整请求字段、状态、交付、计数和账本规则见 `研报体系/研报采集角色说明.md` 第 4.3 节。

### 5.1 新行业首次接入

案例分析员第一次接到某个行业任务时：

1. 在父级 `案例总纲.md` 登记行业任务来源、目标、边界和预期输出。
2. 创建或确认 `ana-doc/<行业>案例/`，不得在行业目录内创建 `案例总纲.md`。
3. 创建行业容器基础文档和 `<行业>研报解析方案.md`。
4. 行业方案必须继承 `研报体系/研报解析架构.md`、`研报体系/研报分析架构.md`、`案例分析规范.md`、`案例审核规范.md` 和 `案例存储体系.md`。
5. 行业方案写清行业边界、核心变量、输出方案、专属表、存储落点、市场反向补漏口径、darkline 触发边界和缺口清单。
6. 提交新行业容器创建审核和行业方案审核。
7. 审核通过前，只能做容器初始化、资料清点或 dry-run，不得进入正式研报结论输出。

### 5.2 已有行业批次分析

案例分析员接到一批研报、公告、网页、数据表或外部资料时：

1. 确认父级 `案例总纲.md` 中已有真实案例。
2. 确认本批资料的 `case_id`、`batch_id`、`run_id`。
3. 读取行业方案，确认资料是否在行业边界内。
4. 在行业 `案例分析设计.md` 冻结资料来源、样本范围、执行步骤、证据要求、输出物、存储路径、darkline 触发边界和验收方式。
5. 设计审核未通过前，不得正式归档、转换、抽取或输出结论。
6. 按 `案例分析规范.md` 执行资料归档、转换、抽取、主动补数据、市场反向补漏、暗线分流、核心文档输出和审计触发。
7. 在行业 `案例执行日志.md` 记录全过程、偏离、异常、自检和本轮结论边界。
8. 生成或更新 manifest、evidence、outputs、result 入口和验证记录。
9. 提交执行审核或输出审核。

### 5.3 单篇和批量产物

单篇研报不能只做摘要，必须保留：

1. doc_id。
2. 页码、段落、句子或表格定位。
3. 时间、单位、口径和对象归属。
4. 事实句、指标句、观点句、公司映射、风险句。
5. 证据置信度和数据缺口。

批量研报不能压成一个大摘要，必须输出或更新：

1. `input_manifest.csv`
2. `conversion_status.csv`
3. `evidence_fact_table.csv`
4. `classification_summary.csv`
5. `unresolved_data_gap.csv`
6. `source_gap_audit.csv`
7. `batch_summary.md`
8. `next_action_list.csv`

如果资料之间存在支持、反对、重复观点或口径冲突，必须分账记录，不能强行合并成单一结论。

### 5.4 外部信息和 darkline

凡是在研报案例流程中需要网上补充消息、收集外部信息、分析新闻公告、分析事件链、分析证据链、检查市场显影、判断暗线或解释异常市场表现，都必须使用 `darkline` 技能和 darkline 信息拓扑方法。

darkline 内容必须与普通行业事实分账。价格、库存、供需、估值或机制解释本身不能直接叫暗线；暗线必须描述意图、目标、组织行为、人心变化、政策铺垫、资本动作或事件链。

## 6. 审核员工作方式

审核员不是只看 summary，而是检查案例是否按设计执行、证据是否可追溯、存储是否可复核、结论是否不过读、问题是否闭环。

审核员至少按 `案例审核规范.md` 执行以下审核：

1. 新行业容器创建审核。
2. 行业方案审核。
3. 设计审核。
4. 执行审核。
5. 存储归档审核。
6. 输出审核。
7. 结论边界审核。
8. 复审。

设计审核重点：

1. 父级总纲是否登记真实案例。
2. 行业方案是否可执行，不是模板。
3. 设计是否写清 case/batch/run、输入范围、执行步骤、证据要求、输出物、存储路径和验收方式。
4. 是否说明主动补数据、市场反向补漏、darkline、单篇/批量最低产物、`unresolved_data_gap` 和 `source_gap_audit`。

执行审核重点：

1. raw 是否进入行业统一 raw 池。
2. converted、extracted、supplement、evidence、manifest 是否按 `案例存储体系.md` 落点。
3. 单篇定位和批量最低产物是否存在。
4. 数据卡、证据链、缺口清单和 source gap audit 是否可复核。
5. 暗线、市场显影和普通行业事实是否分账。
6. 输出是否进入案例级 outputs 和 result 入口。

输出审核重点：

1. 是否有行业视图、市场视图、公司视图。
2. 是否有基础事实卡、核心变量数据卡、历史比较、横向比较和结构占比。
3. 市场反向补漏发现的遗漏对象是否进入补资料和缺口流程。
4. 重要场景假设是否有影响映射、触发条件、失效条件和主要风险。
5. 公司文档是否先给投资读法和当前状态，再展开业务结构、行业暴露、核心竞争力、证据链和风险。

审核结论写入 `案例审计报告.md`。审计发现的问题主记录也写入 `案例审计报告.md`，不要转写成 `案例问题记录.md` 来规避修复。

## 7. 存储和产物落点

原始资料统一进入行业 raw 池：

```text
ana-data/cases/<行业案例>/raw/
```

行业级通用产物进入：

```text
ana-data/cases/<行业案例>/converted/
ana-data/cases/<行业案例>/extracted/
ana-data/cases/<行业案例>/supplement/
ana-data/cases/<行业案例>/evidence/
ana-data/cases/<行业案例>/manifest/
```

案例级正式输出和引用关系进入：

```text
ana-data/cases/<行业案例>/<case_id>/outputs/
ana-data/cases/<行业案例>/<case_id>/manifest/
ana-data/cases/<行业案例>/<case_id>/evidence/
```

父体系兼容目录：

```text
ana-data/tmp/<行业案例>/<case_id>/<run_id>/
ana-data/result/<行业案例>/<case_id>/
ana-data/img/<行业案例>/<case_id>/
```

数据抓取和只读导出脚本统一放在：

```text
ana-data/tools/
```

工具目录只保存脚本，不保存正式抓取结果。脚本产物必须按 `案例存储体系.md` 进入行业 `supplement/evidence/manifest` 或父体系 `tmp/result/img`，并在执行日志和 manifest 中留痕。

禁止事项：

1. 不得创建 `ana-data/cases/<行业案例>/<case_id>/raw/` 保存原始资料。
2. 不得按 batch 或 run 拆 raw 原始资料目录。
3. 不得把临时文件当正式证据入口。
4. 不得只保存结论而无法反查 raw、converted、evidence、manifest 和输出路径。

## 8. 问题、审计和回写

问题记录口径：

1. 审核员发现的问题主记录写入 `案例审计报告.md`。
2. 分析员自发现且本轮可处理的问题，写入 `案例执行日志.md`、自检、验证报告、manifest、数据缺口表或结果包，并直接处理。
3. 外部反馈、跨角色、跨轮或分析员无法自行闭环的问题，才写入 `案例问题记录.md`。

回写口径：

1. 行业方案变化，回写 `<行业>研报解析方案.md` 并提交方案复审。
2. 执行步骤、输入范围、证据要求或验收方式变化，回写 `案例分析设计.md` 并提交设计复审。
3. 结论入口、完成状态或案例目标变化，回写父级 `案例总纲.md`。
4. 输出文档、证据链、manifest、存储路径变化，回写对应结果包和审计记录。

审核或复审未通过前，不得标记完成或对外交付。

## 9. 完成标准

一个研报案例或批次至少满足以下条件，才可以进入交付或阶段完成状态：

1. 父级总纲有真实案例登记。
2. 行业方案可执行，且通过行业方案审核。
3. 案例分析设计通过设计审核。
4. 原始资料、转换产物、抽取事实、补充资料、证据、manifest 和输出路径可追溯。
5. 单篇定位、批量最低产物、数据缺口、source gap audit 和市场反向补漏按需完成。
6. 人读文档以行业视图、市场视图、公司视图为核心入口。
7. 强结论有来源、数据日期、历史比较、横向比较、结构占比或公司/链条案例。
8. 暗线、事件链、意图判断与普通行业事实分离。
9. 执行审核、输出审核或复审已通过。

如果以上条件不满足，应使用 `HELD`、`DATA_GAP_REVIEW`、`DATA_PARTIAL`、`MECHANISM_ONLY` 或 `HELD_BY_EVIDENCE_GAP` 等状态，不得用强结论覆盖缺口。

## 10. 最重要的原则

1. 父级规范是母版，行业子规范默认只做轻量继承。
2. 真实案例登记在父级总纲，行业目录只是行业容器和过程账本。
3. raw 原始资料只进行业统一 raw 池。
4. 结论必须能反查证据，证据必须能反查来源。
5. 需要外部信息、市场显影或暗线判断时必须使用 darkline。
6. 审核未通过不得交付。