供应商发来 PDF，同事阅读后把单号和交付日期复制到表格，再转发给另一个人。每天重复几十次，这类工作很容易成为自动化候选。
但提取文字只是第一步。真正有用的成果，是一条可以审核的记录：找到了什么、缺少什么、还有什么需要人判断。一个看似确定却错误的日期，可能比手工录入带来更多返工。
下面介绍的是试点流程思路，不是已交付的实现，也不代表真实客户成果。
先定义记录，再选择模型
先限定一种文档，例如交付确认单，而不是处理公司邮箱里所有类型的附件。明确实际需要使用的字段。
一条交付记录可以包含供应商名称、文档编号、约定交付日期、目的地、来源文件和审核状态。每个字段都应定义有效条件和缺失处理方式，不能把空缺日期补成猜测的承诺。
同时区分文档原有事实和应用计算值。例如系统算出的跟进日期，不应该看起来像供应商提供的日期。
让提取值旁边就有依据
审核人应能直接定位相关页码或原文片段。把提取日期与来源放在一起，比让人重新打开长文档从头搜索更有帮助。
保留原始表达和规范化后的值。如果原文只写“03/04”，且没有明确日期习惯，就应请求确认。同样，交付时间段也不等于某个已经确认的预约时间。
把有歧义的值送去审核，不要悄悄转成确定结论。
不只依赖模型的置信度
“高置信度”不是正确性的证明。提取后再执行明确的规则检查：
- 必填字段是否齐全？
- 单号是否符合预期格式？
- 文档中的机构是否与本次业务相符？
- 日期是否提供了足够信息？
- 是否已收过同一文件或业务编号？
这些规则能发现定义好的问题，但不能证明整条记录都准确。记录触发了哪些规则，让审核人知道为什么需要处理。
让审核队列能指导行动
一个示例设计是：每条资料依次进入已接收、已提取、待审核、已批准或已拒绝状态。审核人在同一处查看原文、拟写入记录和异常项，修改并批准后，结果才写入目标系统。
初期可以逐条人工批准。只有在有代表性的测试后，才考虑对边界明确的情况减少审核，同时保留异常处理路径。建立业务记录，与授权付款、发消息或修改订单，应当是不同动作。
文档内容不等于操作授权
外部文件是输入资料，不是可信指令。OWASP 的提示注入说明介绍了 AI 读取的文档等材料携带间接指令的风险，建议限制权限，并对高风险操作保留人工批准等控制。
在提取流程中，只给处理组件必要权限。拟写入位置和操作是否允许，应由模型之外的逻辑校验。PDF 里的指令不能扩大系统权限；任何单一过滤器都不能保证免受恶意输入影响。
评估完整任务，而不只看提取速度
使用有权处理、且已去除不必要敏感信息的测试资料，覆盖普通文件、扫描件、字段缺失、陌生版式、日期冲突和重复提交。按字段统计错误，不要只按整份文档判断成败。
同时记录人工纠错时间、需要干预的比例，以及重复项是否进入目标系统。比较总处理时间。如果核对结果比手工录入更慢，提取再快也不算有效改进。
接入正式目标系统前的检查
- 重要字段都能找到原文依据吗？
- 歧义和缺失字段是否可见？
- 能否识别重复提交？
- 错误记录能否追溯和更正？
- 是否明确文件访问、保留期限和审核权限？
- 审批是否独立于下游业务操作？
先把一种文档和审核队列做好。扩展的依据应是团队理解了失败模式，而不只是演示看起来不错。
评估方法可参考 AI 质量测试指南。如果希望讨论文档处理试点，可查看 AI 产品与智能体服务，或联系我们。
