在进入提示词编写和节点实现之前需要先对目标工作流应当具备的核心能力进行系统性拆解。本章工作流的能力设计与第 9 章相比最大的差异在于两点其一是输入端从“白底产品图语义清晰、视觉干净”变为“扫描财报图像语义模糊、视觉嘈杂”对 OCR 与多模态视觉理解提出了更高要求其二是出口端从“开放式图文内容”变为“严格契约的结构化 CSV”对字段对齐、数值精度、校验闭环提出了新要求。这两点共同决定了本章工作流必须从“输入端范式”转向“输出端范式”。10.2.1输出端范式目标Schema驱动的提取第 9 章工作流的能力设计起点是“用户输入了什么”——上传一幅产品白底图后工作流再从图像出发逐节点生成内容。这是典型的“输入端范式”。本章工作流则恰好相反能力设计的起点是“用户需要的输出是什么”——一张结构化的 CSV 表每一列对应一个会计指标。这种“目标 Schema 驱动”的提取是本章相对于前三章的根本性范式转向。为什么必须用输出端范式原因有三。第一扫描财报的信息密度极高一份 8 页财报常常包含 200 多个数字但下游真正需要的字段只有 15~30 个。如果按“先识别全部、再过滤”的思路走OCR 与 LLM 的 token 消耗会爆炸式增长。第二目标 Schema 的存在为字段语义锚定提供了精确锚点——LLM 不需要“猜测”哪些是关键指标而是按 Schema 逐项去 OCR 文本中“找”。第三目标 Schema 是后续数值校验闭环的依据——如果没有预先定义的字段校验勾稽关系从何谈起“输出端驱动”这一原则可以推广到所有数据采集场景先定义你要的字段含字段名、字段类型、字段语义说明再去驱动提取过程远比“先提取一堆杂数据再筛选”高效得多。这一原则也是本章工作流提示词设计八要素中“目标 Schema 声明”放在第二位仅次于“输入声明”的根本原因。10.2.2数据采集与数据生成的适用边界第 7~9 章3个案例都属于“数据生成”范式——AI 创造内容。本章及第 11 章则属于“数据采集数据治理”范式——AI 把已有但散乱的数据归整为可消费形态。两种范式在工程上有几条关键差异整理为表 10-2。表 10-2 数据生成范式与数据采集范式的能力对比对比维度数据生成范式第 7-9 章数据采集范式第 10-11 章核心任务从需求或素材产生新内容从原始材料抽取既有信息评价标准相关性、可读性、美观度准确性、完整性、可追溯错误代价可读性下降业务决策被误导幻觉风险可接受创造性容忍零容忍数字不能编造校验机制主观感知客观校验勾稽关系、单位、范围人工介入点审稿、改稿复核可疑字段、修复异常典型输出形态文章图片报告CSV数据库表API理解两种范式的差异才能在节点设计时做出正确的工程选择。例如在数据生成中我们可以接受“七分准、三分美”但在数据采集中我们必须追求“九九准、零编造”。这种零容忍直接决定了本章必须引入数值校验闭环、字段级置信度、异常标注三道独立护栏。10.2.3七节点能力拆解在能力层确定之后下一步是把整体目标拆解为可独立设计、可独立测试的节点。本章工作流最终落地为开始与结束之间的七个核心节点页面切分节点pdf_split、OCR 识别节点ocr_loop以循环子图形式实现、表格区域定位节点table_locate、字段语义锚定节点field_anchor、数值校验节点value_validate、异常标注节点anomaly_mark、CSV 输出节点csv_output。这七个节点恰好对应数据采集的七道独立工序。特别值得说明的是 OCR 识别节点的实现方式。扣子编程对循环逻辑有明确约束——“严禁在主图创建闭环循环必须实现为子图src/graphs/loop_graph.py在主图中增加一个普通节点在普通节点的实现中调用子图”。因此 ocr_loop 在主图中表现为一个普通节点但其内部通过子图loop_graph对页面图像列表逐页迭代调用多模态视觉模型。这种“主图 DAG循环子图”的混合结构既保证了主图拓扑的清晰也把循环逻辑封装到了独立子模块中是扣子编程对多页多对象处理的标准范式。特别值得强调的还有中间嵌入的两个节点——数值校验节点与异常标注节点。它们是本章相对于第 9 章工作流最重要的两项工程创新。在最初版本的工作流中字段语义锚定节点之后直接连接到 CSV 输出节点试运行时发现输出 CSV 中存在多处肉眼可见的错误如净利润比营收还高、资产总计与负债权益不相等这些错误在源 OCR 阶段就已经埋下但缺乏闭环校验。引入这两个节点后整条链路就具备了“识别 → 映射 → 校验 → 标注”的四阶段能力输出 CSV 的可信度显著提升。如图 10-1 所示。图 10-1 工作流七节点DAG结构页面七节点的拓扑关系如下页面切分pdf_split→ OCR 识别ocr_loop循环子图→ 表格区域定位table_locate→ 字段语义锚定field_anchor→ 数值校验value_validate→ 异常标注anomaly_mark→ CSV 输出csv_output。其中 OCR 识别节点是主图中唯一的“循环触发节点”其余六个节点都是直链式连接。10.2.4数值校验闭环让AI数据采集“可信”在 AI 数据采集场景中“可信”是一个比“准确”更难达成但更应被追求的工程目标。准确意味着每个数字都对可信意味着即便某个数字偶尔出错系统能主动发现并标注。前者依赖底层模型的精度后者依赖工程层面的校验机制。本章设计的数值校验闭环由三类规则构成。第一类是勾稽关系校验。财务报表本身具有严格的恒等关系——资产合计负债合计所有者权益合计、营业利润营业总收入营业总成本各项收益各项损失、净利润利润总额所得税费用。工作流会对每一组关系做反向校验差异在 ±0.5% 以内的视为通过超过的标注为待复核。第二类是单位归一化校验。中文财报的金额单位常常混用元、万元、亿元且单位声明可能出现在表头、表注甚至完全省略。校验规则要求所有金额字段必须归一化到同一单位推荐元并在 CSV 的 unit 字段中显式声明同一字段在不同期间的数量级差异超过 10 倍时触发预警。第三类是范围合理性校验。基于会计常识的范围约束——毛利率应在 [0%, 100%]、ROE 一般在 [-50%, 50%]、资产负债率应在 [0%, 100%]。任何字段值落在合理范围之外都需要复核因为这往往是 OCR 把小数点位置识别错了的征兆。【提示】数值校验闭环并非“修正错误”而是“暴露不确定性”。AI数据采集系统在面对模糊或难识别的字段时正确的做法不是赌一个最可能的数字而是诚实地标注“待复核”。这一原则与第9章经验六“合规护栏应当在框架层面提供默认值”一脉相承但在数据采集场景下表现得尤为关键——一次错误的财务数字流入下游BI系统可能误导整个投研决策。