业务部门要一张结构化的表。数据来源是一堆合同、公告和年报。
拿模型抽，还是拿人填。现在的答案通常是前者。
AI工具 确实强。
AI对话 能一口气读完一百页年报。
AI编程 也能自己接活。
所以第一反应都是，把文档丢进去，让它输出结构化结果就完了。
我最初也是这么干的。
四份测试物料，全是真实业务文档，不是造出来凑数的。
一份是上市公司的年度报告，一百四十三页，十六个字段，另加一张前十大股东关系表。
一份是政府采购的委托代理协议，五个字段。
另外两份是两家公司的权益分派实施公告，各四页，同十六个字段。
任务口径就是三张字段表。以权益分派公告为例，业务方要的字段长这样。
证券代码。每股现金红利。每十股派现金额。股权登记日。除权除息日。现金红利发放日。是否差异化分红送转。参与分配股本基数。
提示词用的是企业里最主流、最不折腾的那一套。
你是文档信息抽取助手。请从文档里提取上面这些字段，用结构化格式输出。字段值必须来自原文，没有的留空。
第一份试的是白云电器的公告。
抽得相当不错。
证券代码对。每股两分钱对。每十股两毛对。三个日期对。差异化分红也对。
如果测评到此为止，结论会是智能体已经够用了。
可企业场景没有到此为止。
接着往下走，四个现场依次出现。
现场一，换一份文档类型，提示词就作废。
把委托代理协议喂进去，还是这条提示词。
模型很诚实地把证券代码返回了空值。委托代理协议里当然没有证券代码。
可委托人、受托人，还有法定代表人和采购预算，这十几个真正要的字段，它一个都没抽。
字段口径换了文档类型就换了整套，提示词得重写。
现场二，同一份文档跑三次，输出没能完全一致。
还是那份公告，还是同一条提示词，连跑三次。
输出大体正确，但三个金额字段在数字和字符串之间摇摆。
每股现金红利，一次是零点零二，两次是带引号的零点零二。
最典型的是参与分配股本基数。一次是纯数字，两次是带千分位逗号的字符串。
同一个数，两种形态。下游按整数接收的代码，收到后者当场解析失败。
现场三，四份文档就是四轮对话，加四次手工复制。
年报一百四十三页，一次对话窗口塞不下，还得想办法切片。
四份抽完，结果散在四段聊天记录里。要进表格软件，还得手工整理。
抽完了，但数据还不存在。
现场四，这次没抄串，但没有任何机制在兜底。
白云电器那份公告同时写着，每股现金红利零点零二元，以及每十股派发现金红利零点二元含税。
三次运行都没有抄串。但注意这个没出事的性质。
流程里没有任何一环在核对这两处金额。
这次没抄是运气。哪天抄了，它会静默地直接进下游。
四个现场对应四个问题。换文档要重写提示词。输出不稳定。没法批量。没有审核。
这不是某个模型菜。同样的模型，同样的文档，单次抽取质量并不差。
问题出在别处。
二、四个断点，都断在模型外面
先说结论。四个现场没有一个是模型能力不足。
把每个现象拆到工程原理那一层，缺的是围绕模型的生产设施。
断点一，提示词是一份没有契约的配置。
提示词的本质是配置。字段名、业务口径和输出格式，全部写在自然语言里。
可配置在工程里是要被管理的。有版本，能比对，可回归测试。
用自然语言写的提示词，三样全无。
没有字段契约。字段约束没有机器可读的定义。模型靠理解执行，人靠肉眼验收。
没有版本。改一个字段口径，没法知道哪些历史输出用的是旧口径。
没有回归。调提示词的人都知道，修好一个案例，惊动三个案例。
企业字段的口径还特别厚。
同样叫股本，总股本、扣减回购股份之后的股本基数，还有参与分配的股本，三个数在同一份公告里同时存在。差一个定语，就是差一个数量级的错误。
这种口径，一次对话里说不清。说清了也锁不住。
对比一个有契约的世界，字段定义长这样。
字段名。类型。原文定位提示。校验规则。
四件事写死在定义里。这是后面平台化方案的出发点。
断点二，没有约束的解码就是不稳定输出。
第二个现场的机制分三层。
采样层，大模型的解码是概率采样。温度不为零，同一输入不保证同一输出。
这是特性不是缺陷。对话产品需要多样性。
可数据生产要的是确定性。
约束层，会话式输出没有结构化绑定。
结构化输出和函数调用这些能力，在接口层是存在的。
可把文档丢进对话框这个用法里，输出契约完全靠模型自觉。
字段名漂移，类型漂移，都是这么来的。
定位层，拿现场四的两处金额做个解剖。
每股现金红利零点零二元在文首的重要提示区。每十股零点二元在第二节的分配方案里。
两处相隔约八百字，跨越一个章节边界。
模型读的是整段线性文本。没有任何机制告诉它，每股红利这个字段的锚点在哪。
它靠注意力在全文里找回这个值。而注意力有近因偏好，也有噪声。
同一个值离哪个数字更近，是文档排版决定的，不是字段口径决定的。
当字段没有锚点，排版就是命运。
还有一种漂移更隐蔽，表格串列。
年报的主要会计数据表里，本期、上年同期和增减幅三列并排。业务只要本期。
模型没有错认数字。它只是偶尔取错列。而取哪列这件事，提示词里往往忘了说。
这不是识别问题，是口径没有随字段一起被定义。
断点三，会话式的输入输出不是数据流水线。
第三个现场的本质是，会话是给人用的交互形态，不是给数据用的。
企业批量抽取要的东西，会话模式一样都不提供。
没有队列。一百份文档排队这件事，得自己写。
没有并发编排。没有失败重跑。第三十七份超时了怎么办。
没有结果汇聚。抽完不会自动合成一张表。
要让智能体批量跑，得自己写胶水代码。
把文档收进来自己写。循环自己写。提示词硬编码在脚本里。失败处理自己定义。结果入库还得自己写。
二十行脚本看着不难。难的是它没有尽头。
口径变了要改提示词。模型升级要回归全量。老板要一张失败率报表，还得再加两百行。
抽取完成和数据可用之间，隔着一整条数据工程的距离。
断点四，没有校验层，错误直接入库。
第四个现场是四个里最危险的，因为它不可见。
前三个现场至少肉眼可查。这一个要靠人对着原文逐字核。
数据生产系统的常识是，上游错误率不为零，所以要建校验层。
文档抽取场景里，至少四类校验是刚需。
为空校验，核心字段缺失即拦截。
正则校验，格式契约。
逻辑校验，字段之间的关系。比如登记日不能晚于发放日。
计算校验，可推导的字段交叉核对。每十股派现金额应该等于每股红利乘十。
这几行代码能拦下的，恰恰是现场四那类错误。
拿白云电器的真实数值代入验算一遍。
每十股零点二元，正好等于每股零点零二元乘十。差值小于一分钱，放行。
一旦抄串成每股零点二元、每十股零点零二元，两边差了一点九八元，必然拦截。
这组数字天然互为校验码。
正因为它们分居两处、口径相关，抄串才发生。也正因为口径相关，一条计算校验就能逮住它。
规则审核不是碰运气。是把文档里本来就存在的勾稽关系显式化。
可把文档丢进对话框这个用法里，这段代码没有位置。
它的输出口是聊天窗口，不是校验管道。
定性一下。这不是模型能力问题，是缺一层护栏。
模型负责抽得准。护栏负责抽错时兜得住。
四个断点全部指向同一个结论。文档抽取要的不是一个更聪明的模型，而是一条围绕模型的数据生产线。
四个断点之外，先接一个反问。把智能体工程化，不行吗。
写到这里，懂行的读者已经准备反驳了。
你说的四个断点，接口层都有解。结构化输出锁输出契约。自己写脚本做校验和编排。不就补齐了。
这条路确实存在。而且每一步都真的有效。
逐个看。提示词没有契约，改成结构化声明再加输出约束，有效。命名和类型漂移基本消失。
输出不稳定，同上，再把温度调到零，有效。同一输入近乎恒定。
没有批量流水线，写编排脚本，队列加重试加汇聚，有效。但要自己维护。
没有校验层，把校验规则写成代码，有效。四类规则都能覆盖。
也就是说，断点不是模型能力问题。接口层的补法都成立。
这正是我想说的。
问题在于，这条路走到头是什么。
字段口径写在代码里，只有工程师能改。
业务方要加一个字段、改一个口径，得提需求，排期，发版。
校验规则散在脚本里，没有复核工作流。
谁来看告警。复核结果记在哪。改完的数据流向哪。全是空白。
模型每次升级换版，全量回归自己扛。
这条路能走。但走到头你会发现，自己在用代码手搓一个文档抽取平台。
契约要自己造。流水线要自己造。校验和复核也要自己造。而且造出来的东西，工程师之外没人能用。
手搓一遍的最大价值，是让你知道成熟的生产线应该长什么样。
所以下面的对照实验，智能体这一组我准备了两套。
一套是前面的裸对话用法，也就是企业里的主流现实。
一套是工程化用法，也就是技术上的上限。分别对照，结论更公平。
三、把四个断点逐个补上
接下来做对照实验。
对照的另一边，选了一家做文档信息抽取的公司的平台，覆盖从字段定义到抽取，再到审核和结构化交付的全链路。
选它的原因很简单。四个断点各自的解法，它恰好各有一个模块对应。
适合做断点和解法的一一对照，而不是泛泛的功能罗列。
先把实验环境交代清楚。
智能体这边保证可复现。裸对话用国产大模型网页版的默认模型。工程化那边把温度设成固定值。
对照的那套是企业端产品，没有自助试用入口。本文实测在厂商开通的测试环境里进行。
对照基准不建全量金标准。关键字段直接对着公告和年报原文核。
下文凡两套用法可能分化的地方，都拆成裸对话和工程化两列分别呈现。
只用裸对话做对照，对智能体不公平。
实验一，提示词的复用成本。
方法很直接。用权益分派公告的提示词去抽委托代理协议。
平台那边建三套字段模板，按文档类型组织。
结果是，换文档类型，智能体这一组要重写提示词，字段全换。
改一个字段名，提示词要改，还要全量重跑验证。
跨类型复用没有任何机制，只能靠在聊天记录里复制粘贴。
平台那边改的是模板字段。模板版本留存下来，按类型长期复用。
结论是，智能体的配置是一次性自然语言。每次换型重写，改完没法追踪。
平台把字段定义沉淀成可复用的模板资产。
差别不在打字快慢。在配置有没有被当成资产管理。
实验二，抽取稳定性。同一份文档跑三次。
方法还是那份公告，同一条提示词连跑三次，每次都是独立新会话。只看六个关键字段的输出形态。
平台那边用同一模板重复抽取三次，核对输出是否一致。
结果是，裸对话的漂移集中在类型上。
三个金额字段在数字和字符串之间摇摆。股本基数还出现过千分位字符串。
值没错，形态不统一。对人来说两种写法都能看懂。对系统来说，一种是数据，一种是错误。
平台那边字段名和类型由模板锁定，重复抽取输出一致。
实验三，批量处理两份同构公告。
方法上，智能体这边两份逐份对话。平台那边两份批量上传，一次抽取，表格总览。
总耗时，五分钟对两分钟。人工介入次数，两次对零次。
结果形态，四段聊天记录对一张结构化表。
重新解析。重新预测。重新审核。这几项智能体这边没有，平台那边有。
结论是，批量的差距不在速度，在形态。
智能体抽完拿到的是两段文本。平台拿到的是已经到位的一张表。
规模放大之后，这一步人工是线性增长的。
实验四，审核机制。三条核心校验现场过。
方法是从字段定义的审核规则里挑三条最硬的，预先写下预期翻车点。
然后看两组谁能把错误拦在入库前。
三条规则是，每十股派现等于每股红利乘十。登记日不晚于除息日，除息日不晚于发放日。必填字段为空即拦截。
裸对话三次都没有发生错误。预期翻车没翻，但没有任何机制兜底。
工程化脚本两份公告四类校验全部通过，还做了一次拦截演示。
平台那边，把每股现金红利手动改错，重新审核，第一条规则当场标红。
判定依据就是，每十股派现金额不等于每股现金红利乘十。
改回正确值再审，全部通过。正确数据下，三条规则无漏报，无误报。
如实记两处预期之外的发现。
一是，裸对话的漂移只发生在类型层，数值三次全对，比预期温和。
工程化加上固定温度和结构化声明之后，输出是干净数字。约束有效。
但这批校验和编排代码，从此归自己维护。
二是，平台这边日期只锁类型，不归一化格式。
两份同类型公告出来两种日期写法。三条规则在公式搭建器里配置大约十分钟，无漏报，无误报。
实验五，结构化交付。
两组结果各模拟一次进表格软件、进业务系统。
智能体这边四份输出手工整理，对齐字段，约八分钟。
平台这边在结果页直接导出，按字段类型分工作表。两份公告即下即用。
另外还支持结构化数据导出。
小结，五个实验的指向一致。
智能体输出的是给人看的文本。平台输出的是给系统用的数据。
四个断点在后者那里各有一个明确的补法。
四、一条完整的数据生产线
先说模块和断点的对应关系。
没有契约的提示词，对应可视化字段定义。字段名、类型和口径说明，按文档类型组织。
没有约束的会话输出，对应模板锁定字段契约，输出恒定。
没有批量的会话式交互，对应批量上传和任务化处理，结果还能表格化总览。
没有校验层，对应审核规则。逻辑校验。为空校验。大模型校验。正则和计算都用逻辑公式实现。
两个值得单独说的设计。
一是字段值可追溯定位。每个抽取结果能回链到原文位置。
这不是体验优化，是审核的前提。
复核员要对着原文改。没有溯源，就得重新全文找一遍。审核成本翻几倍。
这层能力来自底层的解析引擎，对跨页表格和无线框表格的原样输出是刚需。
二是标注沉淀为模型资产。复核时的人工修正，可以反哺自训练提取模型。
改一次，同类文档下次少错一次。
对照智能体那边，人工修正的成果散落在聊天记录里，模型永远学不到。
这是调提示词和数据资产的分野。
全链路跑完，不做百分比式的准确率统计。
拿几个关键字段逐格对照原文，比一个笼统的准确率更有信息量。
每股现金红利，原文是零点零二元。裸对话三次里两次输出字符串，平台是规整数字。
每十股派现金额，同样两次是字符串。
股权登记日和现金红利发放日，裸对话三次一致，平台也是统一格式。
参与分配股本基数，原文带千分位。裸对话两次输出带逗号的字符串。
边界也说清楚。什么时候不需要它。
一次性的探索式需求，抽完就给人看，不入库，智能体完全够用。为这个上平台是杀鸡用牛刀。
字段口径极简单，比如只要个公司名和日期，漂移也在容忍范围内。
平台有配置成本。三套字段模板加审核规则的首次搭建，比写一条提示词慢。
这笔投入换的是第二次起免费。文档量越大摊得越薄。
它也不是开箱即用的通用订阅服务。按客户需求定制交付，有实施门槛。
轻量、一次性的场景不必选它。
如果本身已有审核、比对和撰写的需求，抽取环节可以一并打包考虑。
一句话，结果只是给人看，用智能体。结果要进系统，才需要生产线。
五、选型自查清单
不管最后选哪条路，这套清单是通用的。
清单一，先问结果要去哪里。
结果只是给人看一眼，智能体加通用识别已经够。
结果要进表格定期更新，需要字段定义加批量。
结果要进数据库或者业务系统，需要全链路，定义、抽取，再到审核和交付，四步都要。
清单二，能力项检查表。
字段契约可配置，且能写业务口径。
输出被契约锁定，类型和命名恒定。
字段值可追溯定位回原文。
批量处理，失败能重跑。
审核规则覆盖为空和正则，逻辑和计算，再加一致性，五类。
结构化导出，并且能和业务系统集成。
长文档和制式文件双引擎，应付复杂表格和多样版式。
人工修正能反哺模型，让第二次起免费。
清单三，一棵决策树。
需求是一次性、少量，结果给人看，智能体直接抽，写清字段口径和输出格式就够。
需求是批量、周期性，结果要进系统，就要走平台化。
口径稳定的，按清单二选型。口径常变的，还要看它支不支持模板版本管理。
六、回到开头
回到开头那四个现场。
同一份文档，同一个模型，单次抽取质量并不差。
差的从来不是模型，是围绕模型的设施。
字段有没有契约。输出有没有约束。批量有没有流水线。结果有没有校验。
四个断点也标定了分工。
智能体负责理解文档。平台负责让理解的结果可复用，可批量，也可信。
模型负责抽得准。生产线负责每次都抽得准，能批量抽，抽完敢用。
企业文档信息抽取的本质，不是一次模型调用，而是一条从文件到业务数据的生产线。
这条线的第一站是字段定义。
所以标题那句话值得再说一遍。抽取的上限，在字段定义时就定了。
