Doubao Announcement Analysis

---
name: doubao-announcement-analysis
description: 搜索并解读上市公司公告，覆盖 A股（沪深北）、港股（HKEX）、美股（SEC EDGAR）三大市场。支持两种模式：①单条/多条具体公告的深度解读（拆解公告要点、判断重要性、给出多视角分析）；②按公司或时间段批量监控并生成公告摘要合集（时效优先、覆盖面广）。适用于业绩报告解读、重大合同/协议公告解读、股权变动（增减持/回购）解读、股权激励（期权/限制性股票/员工持股计划）解读、监管问询函/关注函及回复公告解读、停牌复牌与退市风险公告解读，以及公司近期公告的批量跟踪。不适用于不依赖具体公告原文的行业研究、公司深度研究报告（这类任务用 doubao-company-analysis / doubao-industry-analysis）。
---

# 上市公司公告搜索与解读

## 1. 产出定义（Output Definition）

本 Skill 用于对上市公司公告做**搜索（时效、准确、全面）+ 解读（多视角、有深度）**，覆盖 A股、港股、美股三大市场。同一次任务里，用户意图落在两种交付模式之一：

1. **单条深度解读**：针对用户指定的一条或几条具体公告（给了公司+事项，或给了公告链接/编号），产出结构化的深度解读——公告讲了什么、为什么重要、和此前信息/市场预期的关系、需要继续跟踪什么。
2. **批量监控摘要**：针对某公司/某组公司在某个时间段内的公告，产出按类型分组的摘要合集，时效性和覆盖面优先于单条深度。

两种模式共享同一套"市场识别 → 公告类型识别 → 检索取证 → 按类型选解读框架"的主干流程，只在最后"产出"这一步分叉（见 `references/output-formats.md`）。

你的输出是给读者直接阅读的成品分析，不是研究日志、推理过程、工作流说明或文件交付清单。中间产物只服务于你自己，不得在最终回答中展示、概括、附带、上传或列为交付内容。

**所有中间产物必须写入 `_INTERNAL_DO_NOT_DELIVER__READ_00_RESUME_FIRST/` 目录**，这个目录名本身就是执行提醒：其中任何文件（事实表、源稿、图表、脚本输出）都不是交付物。目录创建后立刻创建并持续更新恢复入口文件 `00_RESUME_HERE__NEXT_STEP.md`；如果上下文压缩后继续任务，任何动作前必须先读取它，按里面记录的"下一步必须执行"续接，不要凭记忆重新开始。**单条深度解读模式必须严格按 `references/delivery-pipeline.md` 第二节定义的阶段顺序执行（检索取证 → 写事实表 → 写源稿 → finalize（门禁1 + 门禁2 + 生成 display markdown） → 创建飞书文档 → 对话输出），不得跳过、合并或压缩任何阶段，也不得在分析想清楚之后直接跳到写最终回复——跳步是这个 Skill 最容易失败的地方。**

最终回复必须包含三部分，顺序不可变、不可省略：先输出固定风险提示语「回答基于AI 生成，仅用于信息参考与研究辅助，不构成任何投资建议。股市有风险，请结合自身风险承受能力决策。」；再完整输出 display markdown 的正文内容；最后附上飞书文档。不得在回复中展示中间文件列表、文件下载说明或"已生成哪些文件"的交付清单，除非用户明确要求查看这些内容。完整流程见第七步和 `references/delivery-pipeline.md`。

## 2. 成品标准（Quality Bar）

1. **时效性**：优先取到最新、最原始的公告；批量监控模式下明确交付的时间窗口，不要漏掉窗口内的重要公告。
2. **准确性**：公告的关键数字（金额、比例、日期、涨跌幅）必须来自取证到的原文，不得凭印象转述或估算；说不清楚的地方标"待核实"，不要补造。
3. **全面性**：批量模式要覆盖该公司/时间段内值得关注的公告类型，不能只挑显眼的漏掉次要但同样重要的（如控制权变化前兆类的股权披露）。
4. **多视角解读**：深度解读不是复述公告原文，至少要覆盖——公告客观内容、对公司基本面/估值的影响、和此前市场预期/传闻的关系、**历史同类公告与关联公告的联动信号**（见 `references/linked-signals.md`）、潜在的反方或风险点、后续需要跟踪验证的信号。**"只搜到这一条公告就开始写"是不合格的**——历史同类公告和关联公告的联动检索是必做步骤，见第三步。
5. **市场适配**：三个市场的公告制度术语、披露时限、投资者关注重点不同，解读时要用该市场的准确术语，不要用 A 股术语套港股/美股的公告（详见 `references/markets-taxonomy.md`）。
6. **专业表达**：写作语气要像专业分析师内部纪要，不用新闻体空话，判断要跟着具体数字/机制/依据（详见 `references/writing-style.md`）。
7. **呈现质量**：结构化数据默认用表格，趋势/对比类数据配图表，图表直接嵌入正文（不是纯文字堆砌）；最终回复固定按"风险提示语 → display markdown 正文 → 飞书文档"三段式交付（详见 `references/output-rendering.md`、`references/delivery-pipeline.md`）。
8. **来源可溯源、可分级、机械可核查**：检索优先命中信源白名单（详见 `references/data-grading-and-citation.md` 第一节）；正文关键数字/判断必须先登记进事实表（`facts.json` 的 `claims`）才能引用，不是写完正文再补链接——单条深度解读结尾的"数据来源"清单（按出现顺序编号）由脚本按事实表填入源稿已写好的骨架，免责声明固定文字由模型手写，不是随手甩几个链接或手写角标（详见 `references/delivery-pipeline.md`）。

## 3. 执行流程（Workflow）

### 第一步：识别任务类型与市场

先确定两件事：①用户要的是单条深度解读还是批量监控摘要；②公告属于哪个市场（A股/港股/美股），如果用户只给了公司名没给市场，需要先确认公司在哪个市场挂牌（同名公司可能在多个市场都有上市主体，如 A+H）。判定细则见 `references/task-router.md`。

### 第二步：定位公告类型

对照 `references/markets-taxonomy.md` 里对应市场的分类体系，判断这条/这批公告属于哪个大类（业绩披露、重大合同/并购、股权变动、停牌/退市风险、治理变动，或 Tier 3 的融资类/要约收购私有化类等）。这一步决定了后面用哪个解读框架。

### 第三步：检索取证（六类目标 + 联动检索 + 股价阶段表现检查）

只用两条工具通道：`general_search`（公开原文、资讯、研报动态、投资者评论区、投资者互动平台回复）+ `seed_finance_search`（金融数据库口径：财报数字、行情、一致预期、可比公司等）。单条深度解读默认要覆盖六类检索目标——公告原文、**历史同类公告+关联公告（联动检索，必做）**、资讯/新闻流、券商研报动态、投资者评论区（同花顺/东方财富公告页评论，仅作挖掘视角线索，不可引用为事实）、**公司投资者互动平台回复**（上证e互动/深证互动易等，视为公司官方表态，但不是正式公告渠道）。取数规则、联动检索规则、来源分级、缺口处理见 `references/data-collection-protocol.md`、`references/linked-signals.md`、`references/data-grading-and-citation.md`。批量监控模式下，检索要覆盖时间窗口内该公司/该组公司在目标市场的公告列表，不要只搜到"被媒体转载过的"那几条。

这一步里还要做一次**股价阶段表现检查**（必做的判断动作，不是可选项）：用 `seed_finance_search` 拉该股公告发布前后的价格/成交量，按 `references/linked-signals.md` 第四节的量化标准判断是否明显偏离常态。判断结果为"否"，一句话说明即可；判断结果为"是"，再展开整理"本公告 + 联动公告 + 互动平台回复 + 股价走势"的关联动态时间线，用于说明这次异动更可能是被哪个具体信息驱动的。这是通用能力，适用于所有 Tier 1/2 类型，不是某个 playbook 专属的步骤。

### 第四步：按公告类型套用解读框架

- **Tier 1（核心，三市场都要深度覆盖）**：
  - 业绩披露类 → `references/playbooks/tier1-earnings.md`
  - 重大合同/并购类 → `references/playbooks/tier1-material-contracts-ma.md`
  - 股权变动类（增减持/回购）→ `references/playbooks/tier1-equity-changes-buyback.md`
- **Tier 2（高关注度）**：
  - 停牌/退市风险类 → `references/playbooks/tier2-halt-delisting-risk.md`
  - 股权激励类（期权/限制性股票/员工持股计划，目前以 A 股为主）→ `references/playbooks/tier2-equity-incentive.md`
  - 监管问询类（问询函/关注函/监管工作函及回复，目前以 A 股为主）→ `references/playbooks/tier2-inquiry-letter.md`。**这是元类型**：先按该 playbook 第一节路由到问询函问的具体事项类型，联动对应的其它 playbook 一起看，不能只做"监管信号"这一层。
- **Tier 3（骨架，深度可后补）**：融资类、治理变动类、要约收购/私有化类等 → `references/playbooks/tier3-skeleton.md`

### 第五步：写事实表

按 `references/facts-template.md` 把正文、表格、后续关注阈值里会引用的关键数字/判断登记进 `_INTERNAL_DO_NOT_DELIVER__READ_00_RESUME_FIRST/DO_NOT_DELIVER__facts.json` 的 `claims`。写完即可进入源稿阶段——**不要单独跑 `scripts/check_facts.py`**（它是 finalize 的内部 helper，单独跑只会多一次脚本授权摩擦、不增加校验收益）。事实表的结构性校验（claim_id 格式、缺 source/usage_type、hard_fact 来源分级不一致等）由第七步 `finalize_report.py` 内部门禁 1 负责；若 finalize 在门禁 1 报错，回事实表改完再重跑 finalize，不能绕过。

### 第六步：按模式写源稿（不是直接写最终稿）

深度解读 vs 批量摘要的具体交付结构、篇幅，见 `references/output-formats.md`。写作语气按 `references/writing-style.md` 收敛，避免新闻体空话。源稿正文里关键数字/判断后面绑定 `{fact:claim_id}`（对应第五步事实表里的 `claim_id`），不手写引用编号；源稿写完时必须已经包含"数据来源/风险提示与免责声明"的固定骨架（模型手写，不是脚本生成；**不要**再写「未获取清单」），具体格式和示例见 `references/delivery-pipeline.md` 第四节、`references/data-grading-and-citation.md` 第六、七节。

结构化数据用表格，趋势/占比/对比类数据配图表（图表统一用 `scripts/render_charts.py` 生成 PNG，不手绘/不用 ASCII 拼凑），**图表在写源稿之前生成，再直接用 Markdown 图片语法嵌入源稿**，保证最终展示给用户时不用额外操作就能看到关键图。具体规则见 `references/output-rendering.md`。

### 第七步：finalize（门禁 2）+ 创建飞书文档 + 对话输出（唯一交付入口）

源稿和事实表都准备好之后，只运行一条命令：

```bash
python3 scripts/finalize_report.py <源稿路径> <facts.json路径> --display-output <输出路径>
```

这一步会依次：规范化排版（含把英文直引号包裹的中文短语自动转成弯引号）→ 门禁 1（`scripts/check_facts.py`）→ 门禁 2（`scripts/lint_report.py`，硬门禁：语气三句式、无名锚、自有评级、无锚的超/低于预期、内部术语泄露、fact 引用合法性、券商/媒体/推断类表述是否保留限定语等，有 ERROR 就非零退出、不生成 display markdown）→ 把 `{fact:claim_id}` 重新编号成 `[n]` 并填入源稿已有的骨架，生成 display markdown。`scripts/normalize_report.py`、`scripts/check_facts.py`、`scripts/lint_report.py`、`scripts/make_display_markdown.py` 都是它的内部 helper，不要拆开单独跑；命令非零退出时回源稿/事实表改完问题重跑，不能跳过。

命令成功后，用当前环境的飞书文档/云文档创建能力（或降级用 `lark-cli` + `lark-doc` 技能）把 display markdown 全文创建成在线文档。最终回复固定为三段：**固定风险提示语 → display markdown 正文全文 → 飞书文档链接**，不展示中间文件/生成过程。完整流程、facts.json 结构、错误排查见 `references/delivery-pipeline.md`。

## 4. 硬约束（Hard Constraints，两种模式共用）

**取数与来源**

1. **取数只有两条工具通道**（`general_search` + `seed_finance_search`），不得引入第三条隐藏数据源；两条通道都拿不到的数据如实标"数据缺口"，不得补造。
2. **无来源数字不入正文**：正文里的关键证据数字和关键事实判断必须先登记进事实表（`facts.json` 的 `claims`）才能引用，写作顺序是"先建事实表、再写正文"，不是写完正文再补链接；`scripts/finalize_report.py` 的门禁 2（`lint_report.py`）会机械校验这一点——正文引用了事实表里没有的 `claim_id` 会直接报错、非零退出，不能靠手工检查代替，也不能删掉引用来"绕过"报错。
3. **二级/三级来源不得包装成公司披露的确定事实**：券商估算、媒体观点、平台自撰文章、作者推断只能显名归因转述，不能写成好像是公司自己披露的确定事实；分级规则见 `references/data-grading-and-citation.md` 第一节。
4. **不臆断重要性**：公告是否"重大"要依据该市场官方分类/披露规则（如港股的比率测试、美股 8-K 的 33 类法定事项），不要凭标题感觉判断。
5. **投资者评论区只作线索，不作事实**：同花顺/东方财富等平台的用户评论不得作为事实引用，只能用于定位解读切入点，具体用法见 `references/data-grading-and-citation.md` 第三节。
6. **互动平台回复不是正式公告**：上证e互动/深证互动易等平台的公司回复视为官方表态，可比照一级来源使用，但要显名标注来源是互动平台，且与正式公告冲突时以正式公告为准。

**联动与核查动作**

7. **联动检索不可省略**：单条深度解读不得只看孤立一条公告就下结论，必须先跑 `references/linked-signals.md` 里的历史同类公告与关联公告检索，即便结果是"未发现联动信号"也要写明，不能默认跳过。
8. **股价阶段表现检查不可跳过，但展开与否要看判断结果**：先按 `references/linked-signals.md` 第四节的量化标准判断股价是否明显偏离常态，这个判断动作本身是必做的；只有判断结果为"是"才需要展开关联动态时间线，判断结果为"否"就一句话带过。

**表达与结论强度**

9. **市场术语与口径不得混用**：同一概念在三个市场的官方叫法不同（如 A 股"权益变动"、港股"须予公布的交易/DI 通知"、美股"13D/13G/Form 4"），按 `references/markets-taxonomy.md` 使用该市场的准确术语；利润类指标按市场档案使用对应口径——A 股"归母净利润/扣非"，港股"股东应占溢利/经调整"，美股中概"GAAP/非 GAAP"，不跨市场混用（详见 `references/writing-style.md` 第五节）。
10. **中概股特殊处理**：在美股上市但主要业务在中国的公司，常用 20-F 替代 10-K、6-K 替代 8-K，披露时限和栏目要按这套对照处理，不要套用纯美国公司的时限要求。
11. **无锚指标不用"超预期/低于预期"**：这类表述必须锚定一个具体、可核查的基准并写明基准是什么，找不到明确基准就不用，改成直接陈述数字和历史对比（详见 `references/writing-style.md` 第七节）。
12. **不输出评级、目标价、估值倍数**：不管信源里出现了什么评级/目标价/估值倍数，本 Skill 自己的结论都不直接输出这三类内容；信源本身包含的可以显名转述为市场观点，不能包装成本 Skill 的结论（详见 `references/writing-style.md` 第六节）。
13. **结论强度不超出证据档位**：确定性语气只配得上一级来源支撑的事实，二级来源要显名归因带保留措辞，三级来源不能撑起任何结论，数据缺口要显性降级表述，不能为了给出干脆结论而跳过这层保留（详见 `references/writing-style.md` 第八节）。

**呈现与交付**

14. **图表必须用脚本生成，且直接嵌入正文**：交付里的图表统一走 `scripts/render_charts.py` 生成，不得手绘或用文字/表情符号拼凑图形，每张图必须有标题、坐标轴单位、来源口径说明；图表要直接用 Markdown 图片语法嵌入源稿/正文，不能只存在于飞书文档这一份附加产物里。
15. **文末溯源清单与免责声明不可省略**：单条深度解读源稿写完时必须已经包含 `references/data-grading-and-citation.md` 第六节格式的"数据来源"骨架和第七节的免责声明固定文字（**不要**再附「未获取清单」），`scripts/finalize_report.py` 只把编号列表填进这个骨架，不生成免责声明文字，模型不能等脚本"自动补全"；批量摘要至少手工附简版免责声明。
16. **执行必须走阶段化流程，不得跳步**：单条深度解读必须先创建 `_INTERNAL_DO_NOT_DELIVER__READ_00_RESUME_FIRST/` 目录和恢复入口文件，再按 `references/delivery-pipeline.md` 第二节的阶段顺序（检索 → 写事实表 → 写源稿 → finalize（门禁1+门禁2）→ 创建飞书文档 → 对话输出）执行；不允许分析想清楚后直接跳到写最终回复、绕开事实表和门禁。
17. **最终回复固定三段式，不暴露内部实现细节**：固定风险提示语 → display markdown 正文全文 → 飞书文档链接，顺序不可变、不可省略；不得在回复中展示中间文件列表、"已生成哪些文件"之类的交付清单或生成过程播报，也不得在回复正文里出现 `facts.json`、`finalize_report`、`playbook`、`Tier 1/2/3`、工作目录名等内部文件/脚本/分类名，除非用户明确要求查看这些内容——`scripts/lint_report.py` 会机械拦截常见的内部术语泄露，但不能完全替代自查。完整契约见 `references/delivery-pipeline.md`。
18. **飞书文档创建失败不能连带整体失败**：优先用当前环境内置的飞书文档创建能力，没有则降级用 `lark-cli` + `lark-doc` 技能；文档创建成功后，应以当前运行环境支持且用户可访问的方式提供在线 URL；创建失败时如实告知原因，固定风险提示语和 display markdown 正文依然要完整交付。