一句话看懂：OpenRouter 于 2026 年 10 月 29 日发布教程，演示如何把 PDF 连同描述单行字段的严格 JSON Schema 一起发给能读取文件的大模型，直接得到带类型的表格行，并提醒开发者重点防范两类“静默失败”。
事件核心：发生了什么
这篇教程给出的核心方法很直接：调用 OpenRouter 的 chat completions 接口，以 file content part 形式上传 PDF，同时通过 structured outputs 传入 strict 模式的 JSON Schema，模型即按行返回结构化数据。数量会以整数返回，括号表示的损失“(3,878)”会被整理成 -3878，跨页表格则合并为一个列表。OpenRouter 表示在 5 份测试 PDF（其中 2 份为扫描件）上，能直接读取 PDF 的模型共正确识别全部 644 个单元格。
容易被忽略的是出错环节。按教程描述，失败并非来自模型读表本身，而来自 PDF 进入模型的解析路径：扫描件走免费的 cloudflare-ai 解析器会返回 0 行且不报错；长表格则可能撞上输出 token 上限，返回 finish_reason 为 length 的截断结果。教程建议把空结果和 length 都当作错误处理，扫描件改用能读 PDF 的模型或 mistral-ocr 解析器。
为什么重要
PDF 表格抽取长期是文档处理中的工程活，常见做法是 OCR 加规则解析，再写大量清洗逻辑。这次教程的价值不在新模型，而在把“从文档到结构化数据”的整条链路标准化为 Schema 加解析器路由：字段描述承担负数、脚注等清洗工作，strict 模式保证类型一致，解析器则决定扫描件能否被读进来。对依赖 API 做数据管道的团队来说，这提供了一套可复用的错误检查清单。
对用户/开发者/创作者的影响
开发者最该带走的是防御性写法：不要假设接口返回 200 就一定有数据，而应同时校验行数非空和 finish_reason 是否为 length；处理扫描件时先确认模型的 PDF 读取能力或显式指定解析器。教程给出的 Python 示例覆盖 base64 上传、Schema 封装、结果与成本返回，并附 TypeScript 版本，可直接改造接入财务对账、发票录入或物流单据整理等场景。不过需注意，上述测试结论仅限 OpenRouter 自建的 5 份样本与当时所列模型，不能视为所有 PDF 与模型的通用排名；strict 模式的支持程度也因供应商而异。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
值得关注的后续
一是 OpenRouter 是否会把“空结果、length 截断”等检查固化为 SDK 或服务端默认行为，而非依赖开发者自行判断；二是各家供应商对 strict structured outputs 的支持能否拉齐，影响跨模型迁移成本；三是解析器路由（如 mistral-ocr 与免费解析器）在真实扫描件上的效果差异，是否有更透明的质量反馈。
