在同一需求，三种做法：一个AI小工具里的产品经理、工程师与架构师中，我们介绍了用三种不同方法去做同一件事——从股票 交易所披露易搜索年报/半年报等公告，下载 PDF，抽取营收同比、EPS 同比、分红变化，再汇总成报告。目的是说明与AI的不同协作方式，适配不同角色与不同交付形态。

这篇文章介绍了如何对这个工具进行优化，提高搜索和读取信息的准确性。这个过程是典型的多工具 AI 辅助开发 + 人在环路整合，不是「一个万能 Agent 包办」。这是因为实际的应用是各部相同的，有着各自独特的要求和特点；并不存在万能的AI工具可以解决所有的问题。而我们在优化这个简单的工具过程中，充分体现了人的不可或缺的作用。

一、背景：为什么「能下载 PDF」还不够

1.1 业务目标

面向非技术用户：输入股票代码与日期 → 自动检索披露易年报/中期报告 → 下载 PDF → 抽出营业收入、EPS、每股股息 → 生成 Excel。

1.2 早期系统已经解决了什么

• Web 一键跑通检索、下载、抽取、汇总
• 不依赖线上 LLM 推理，成本和速度可控
• 对「写法标准」的报告效果尚可

1.3 真实年报带来的痛点

• 同一指标，表名、单位、正负号写法各异
• 附註编号夹在数字中间，易被当成营收/EPS
• 厚报告里损益表可能在第 50～120 页之后；目录和「五年財務概要」易抢先命中
• 亏损公司写「每股虧損」而不是「每股盈利」
• 多数公司当年不派息——空白往往是对的，不能一律当失败

二、总体架构：生产规则 + 离线 AI 读懂

2.1 线上链路（生产）

浏览器 → Web(FastAPI) → 检索披露易 → 下载 PDF
       → pdfplumber 抽文本 → 规则抽取 → Excel

特点：确定性、可审计、可回归；适合批量与重复运行。

2.2 离线链路（优化）

错例 PDF → NotebookLM（固定 Prompt）
        → 正确答案 + 定位 tip + 易错点
        → Cursor 改规则代码 → 期望值回归 → 再跑一批

2.3 一句话小结

AI 负责「读懂与归纳」；规则引擎负责「执行与交付」；开发助手负责「把 tip 变成可维护代码」。

三、NotebookLM 怎么用才「能落地代码」

3.1 Prompt 设计原则

不要只问「营收是多少」。要求模型按统一结构输出：

1. 正确答案（本期/上期/单位/表名/页码）
2. 给规则引擎的 tip（可执行：搜哪些词、避开哪些坑）
3. 易错点（「找第一个数字」会错在哪）
4. 跨报告规律（反复出现的表名/EPS/单位写法，并举例文件名）

3.2 为什么这样设计

• 「正确答案」→ 回归期望值
• 「tip」→ 直接改关键词、打分、正则
• 「易错点」→ 防止只修表象
• 「跨报告规律」→ 从个例修 bug 升级为规则库建设

3.3 样本策略：分批进行，总结规律和技巧，像训练模型一样迭代 —— 但学的是规则

我们分批把报告交给 NotebookLM（例如第一批5份，第二批15份），每批产出规律/技巧后立刻改代码、做回归，再开下一批。这和 训练 AI 模型 在闭环上很像：

相似点	说明
样本驱动	先看错例，再学规律
分批加数据	能力逐步覆盖更多写法
需要回归	防修好 A 弄坏 B

但请注意：这不是在微调/训练一个抽取模型：

	训练抽取模型	我们的分批 tip
学到哪里	权重参数（偏黑箱）	显式规则（关键词、打分、正则）
更新方式	梯度下降 / 微调	人把规律/技巧写进代码
NotebookLM 角色	若仅作标注器	顾问 + 标注 + 规律提炼
线上推理	常仍依赖模型	仍走规则，不必每份报告再问 LLM

这是 样本驱动的规则迭代（AI 辅助知识工程），类比训练闭环，产物却是可审计的规则库，而不是新的模型 checkpoint。

四、NotebookLM + Cursor：务实的多工具 AI 辅助开发

4.1 为什么不「一个 Agent 包办」

年报理解、代码改造、生产抽数，对工具的要求不同。强行端到端，往往在 可控性、成本、可回归 上吃亏。更务实的做法是：让不同 AI 做它最擅长的一段，再由人整合。

4.2 分工怎么切

工具	擅长	在本项目中的职责
NotebookLM	长 PDF、跨页对照、归纳写法	读年报 → 正确答案 + 可执行 tip
Cursor	读代码库、改实现、补单测	tip → 规则代码 / 回归用例
规则引擎（自研）	稳定、便宜、可解释	生产环境真实抽数与出 Excel
人	选样本、验收、定优先级	闭环调度与质量把关

4.3 这种方法论想强调什么

• 不是「全面 AI 化」口号，而是工具组合
• 每个环节可单独替换（换文档 AI、换 IDE 助手），生产契约（规则+Excel）不变
• 特别适合个人开发者 / 小团队：没有标注平台和 GPU，也能把准确度啃上去

五、落地后的关键改进

5.1 总览：从「碰巧命中」到「按报表语义建模」

能力层	在解决什么问题	抽象做法
A. 定位	数在哪一页、哪一张表	全库扫描 + 像真表打分；降权「像表但不是表」的页
B. 消歧	同名/近名结构选哪个	同义词表 + 优先级（主表优于摘要/OCI/窄口径）
C. 净化	哪些数字绝对不是答案	噪声黑名单：Notes、叙述句、目录页码、假单位
D. 解析	同一指标的多种写法	单位/正负号/列顺序/中英标题的显式解析器
E. 交付	结果可信	上年对照、出处页码、分组着色、空值语义（无股息≠失败）

先找对地方，再选对口径，再丢掉干扰，再读懂写法，最后让人核得过。

5.2 能力 A｜定位：在整本 PDF 里找到「值得读的表」

抽象目标： 不把「扫到的第一个财务字样」当成答案来源；要找到 主表所在页及其邻页。

抽象手段： 关键词召回 + 页面打分（真表特征加分、假阳性降权）+ 跨页窗口（±N 页）。

对应实例：

• 整本扫描损益/全面收益表，不再只扫前几十/百页
• 目录页、五年財務概要 / Financial Highlights 降权
• 命中页 ±2 纳入，避免收入在前页、EPS 在后页
• 股息单独搜 董事會報告 相关页，再并入阅读范围

年报现实： 厚报告主表常在后部；摘要与目录「长得很像表」。

---

5.3 能力 B｜消歧：同名结构里选出「业务口径正确」的那一个

抽象目标： 文档里常有多张相关表、多行相关指标；系统要有 显式优先级，而不是「谁先出现用谁」。

抽象手段： 表名同义词扩展 + 主/次结构排序 + 业务口径偏好（整体优于窄口径）。

对应实例：

• 表名覆盖：綜合損益表、全面收益/收入表、中期簡明表、英文 Comprehensive Income 等
• 拆表时：綜合損益表优先，单独「其他全面收益表」降权
• EPS 两行并存时：优先「持續及已終止」，略降「仅持續經營」
• EPS 行优先 Basic / 基本及攤薄，避开附注叙述里的「每股盈利」字样

年报现实： 命名不统一；同一概念有「整体 / 持续经营 / OCI」等多口径。

---

5.4 能力 C｜净化：先定义「什么绝不是答案」

抽象目标： 抽取质量往往不取决于「多认出几个正例」，而取决于 少吃进多少噪声。

抽象手段： 结构角色过滤（标签行 vs 叙述句）+ 形态过滤（附註小号、无千分位的假金额）+ 负向语句（明确不派息）。

对应实例：

• 营收只认表格标签行（REVENUE / 營業額 / 收益），忽略「Turnover of…」类叙述
• drop_note_refs：去掉夹在金额前的 Notes 小号（如 5、12）
• 千分位金额加分，降低把年份/页码当营收的概率
• 「不建議派付股息 / no dividends will be paid」→ 合法空结果，而非抽取失败

年报现实： PDF 转文本后，噪声数字往往比真值更「好抓」。

---

5.5 能力 D｜解析：把「写法多样性」收成同一语义字段

抽象目标： 承认发行人不会统一排版；为每个字段建立 小型写法文法（单位、括号亏损、列顺序、中英标题）。

抽象手段： 单位检测（含优先级）+ 有序 token 解析（裸数与括号数）+ 标题别名（盈利/亏损）。

对应实例：

• 单位：千港元 / $’000；千美元优先于裸 $’000；EPS 区分港仙/港元/美分
• 列顺序：0.10 与 (2.56) 同排时按阅读顺序取本期/上期
• 亏损标题：「每股虧損」+ (1.44)港仙 与「每股盈利」同等对待
• (x) cents、HK cents (x)、$(0.23) 等 EPS 写法分支

年报现实： 「找不到」逐步减少后，错误更多来自 读错列、读错单位、读错口径。

---

5.6 能力 E｜交付：让结果可核对、可解释、可扩大股票池

抽象目标： 规则系统的终点不是 JSON，而是 人敢签字的表；空值也要有语义。

抽象手段： 同期对比列、出处页码、视觉分组、异常货币醒目提示。

对应实例：

• Excel：去年营收 / 去年 EPS / 去年股息；蓝绿橙分组着色
• 页码出处列；USD 报表醒目标出
• 完整度与低置信度提示（便于抽检）

年报现实： 没有核对体验，准确度再高也难以规模化使用。

这是 「AI 辅助的规则工程」，配合 多工具 AI 辅助开发：用文档大模型加速从异构年报中提炼规律，用编程助手加速规则落地，用确定性规则完成生产抽取——兼顾理解力、工程效率与可控性。

后续我们的生产路径仍坚持规则，原因如下：

• 可回归：同一 PDF 反复跑结果应一致
• 可解释：错了能指出是表名、单位还是列顺序
• 成本与合规：批量年报不必每份都走大模型推理
• 人机分工：AI 适合「发现」；规则适合「执行」

可复用的工作流清单

1. 先做最小可用规则系统，跑通链路
2. 用真实错例喂 NotebookLM，强制输出规律/搜索技巧而非散文
3. 用 Cursor 做规律/搜索技巧 → 规则 → 期望值单测，小步提交
4. 维护「回归期望值表」，防修好 A 弄坏 B
5. Excel 必须对人友好（上年值、单位、页码、着色）
6. 明确分工：文档 AI 在优化环，规则在生产环，编程 AI 在落地环
7. 心里要有谱：分批像训练一样迭代，但交付物是规则，不是新模

结语

文档智能不必一上来就「端到端大模型」。对港交所这种 强结构、弱统一 的 PDF，更划算的路径往往是：

用 AI 读懂差异，用规则吃掉差异；用不同 AI 工具各打一段，再整合交付。

NotebookLM 把「会计师读年报的经验」压成 tip；Cursor 把 tip 变成可回归的代码；规则引擎在生产环境稳定出数。分批 tip 的节奏很像训练，但我们训练的是 规则库的覆盖面，不是模型权重——这对个人开发者和小团队，往往是更务实的一条路。