PDF.ai 提取字段时，结果能连到“哪页、哪一个字段”

让AI“整理一下这份PDF”，得到的常常是一段不方便继续处理的文字。如果真正要把信息放进台账或表单，更有用的是先约定字段。PDF.ai当前v2的Extract接口就以JSON Schema为输入，返回符合结构的数据，并附上字段对应的来源片段。

完整官方Extract文档给出的引用不只有页码，还包含schemaLink：例如result.people[2].name，说明这段来源对应结果里第三个人的姓名。对于嵌套记录，这比在整份结果末尾笼统放一个PDF链接更有用。

先说清要填哪几格

以整理公开活动通知为教学情境。你想收集活动名称、举办地点、报名截止时间与参与条件，可以先把这些字段写进schema，规定文字、日期表达或列表等结构，再说明材料没有报告时应如何表示。

这里需要技术人员配置接口，不是普通聊天窗口里随口输入一句话。官方示例使用title和author两个文档元数据字段，演示结构如何提交；引用中的people路径则演示字段定位方式，都不能当成某份真实通知的提取结果。

固定结构带来的变化在后面：同一字段可以进入同一列，来源片段可以跟着字段一起展示，人工复核时不用从一大段自然语言里再次找“这一格到底出自哪里”。至于不同文件的日期、单位与缺失值怎样统一，仍需要业务规则明确处理。

接口返回data.result存放提取结果，data.citations存放引用，包括content、pageNumber和schemaLink，另返回文档标识docId。应用可以把它们组合成一个可查看的字段卡片：左边是准备写进系统的值，旁边是原文与页号。

这是一种接入方式的解释，并不是本文运行得到的界面。它的意义是让提取和复核能相互连接，尤其适合那些“字段不多，但每格都要说明出处”的文档整理任务。

官方API总览也区分Parse、Extract、Split与Ask：前者恢复文本和版面，Extract按结构取字段，Split拆分文档，Ask处理问题。需要固定表格时，直接选择字段提取，比每次要求聊天模型输出同一张表更容易形成稳定接口。

Extract接受文件、公开链接或已有docId。若已经取得可复用的解析标识，再传docId就不重复计解析额度；提取本身仍会消耗额度。官方还按照字段数量与文档页数分别计算提取用量，因此“缓存了文件”不等于后续处理全部免费。

PDF.ai是商业在线服务，需要API密钥与相应计划。schema约束的是结果形状，不能单独保证内容正确。较好的起点，是选一类字段清楚的公开文档，让每个准备写入的值都带着页码与来源片段，再决定是否接进日常数据流程。