AI 提取 API 承诺提供结构化网页数据，但可靠性仍是难点

Google News 展示了 SitePoint 一则关于 AI 驱动 API 正在重塑网页开发的标题，但更大的变化并不止于一篇文章。如今，开发者可以将网页发送至 API，并直接请求类型化记录，而不必先编写自定义解析器。

这一转变看似简单，却将网页开发中困难的一环从确定性代码转移到了由模型介导的服务。应用程序仍会接收到 JSON，但其中的值可能取决于渲染方式、提示词、模型行为以及不断变化的源内容。

这则转载标题几乎未提供可独立验证的特定产品发布细节。但其前提反映了 Cloudflare、Google、OpenAI 及其他 API 提供商中已有记录可循的技术趋势。

核心竞争并非 AI 提取与人工复制之间的较量，而是基于模型的理解与采用显式选择器、规则和失败状态的传统提取代码之间的取舍。

AI API 对陌生布局的适应能力优于僵化的爬虫。传统流水线则更易于测试、复现和审计。最可信的开发模式，是结合两种方法，而非宣称其中任何一种已经过时。

Google News 捕捉到了从页面到类型化记录的转变

网页提取正从“找到这个元素”转向“返回这些经过验证的字段”。

传统爬虫将页面视为文档树。开发者通过 CSS 选择器、XPath 表达式或页面专用规则定位元素，随后清理字符串、转换类型，并决定字段消失时该如何处理。

当数据源稳定时，这一流程十分有效。但当发布者更改类名、将内容移入客户端组件，或在不同地区展示不同布局时，维护成本就会迅速上升。

AI 提取 API 接受更宽泛的指令。开发者可以请求产品名称、可用状态、文章作者、发布日期和规范 URL。服务会渲染或读取页面、理解其内容，并返回所需字段。

Cloudflare 在 2026 年 7 月将这种方法具体化。其 Browser Rendering `/json` endpoint可接受 URL 或提供的 HTML。开发者可以提供提示词、JSON Schema，或同时提供两者。

Cloudflare 记录了涉及产品详情、职位列表、文章元数据及其他结构化记录的示例。这使提取成为一项托管 API 操作，而不再是一组页面专用的浏览器脚本。

这一变化影响了应用架构。网页可以成为类型化工作流的临时输入，而不再只是为人类阅读设计的终点。

招聘应用可以将各式各样的职位页面转换为统一的内部 schema。监测服务可以规范化没有公开订阅源的网站公告。研究产品则可在建立索引前，从文章中提取日期、组织和主张。

这并不意味着浏览器自动化会消失。提取服务仍需加载页面、等待相关内容，并处理重定向或身份验证。AI 作用于内容获取之后，而不是替代内容获取。

同样的区别也适用于 Google News。聚合订阅源可以表明某个故事存在并提供其标题，但并不能自动证实底层页面中的每一项主张。

因此，开发者需要做出两项独立的可信度判断。第一，系统是否获取到了目标来源？第二，它是否正确解读了该来源？

schema 可以验证 author 字段是否为字符串，却无法证明返回的字符串确实是文章作者。类型正确性与事实正确性仍是不同属性。

这正是 SitePoint 标题重要的原因。AI 提取改变了开发者所面向的接口，但并未消除验证来源的必要性。

其直接益处是减少集成工作量。长期挑战则在于判断何时应让经过解读的数据进入生产系统。

结构化输出让 AI API 更易集成

受 schema 约束的输出，可将模型响应转化为普通应用代码能够检查、拒绝和路由的对象。

自由形式的模型文本会形成尴尬的边界。开发者可以要求返回 JSON，但响应仍可能包含说明文字、缺失键、意外类型或格式错误。

结构化输出缩小了这种不确定性。开发者提供描述允许字段和类型的 schema，API 随后会将响应限制在该形状内。

Google 将结构化输出列为适用于数据提取、分类和智能体工作流的能力。其示例展示了通过 JSON Schema 和类型化应用模型表示的 schema。

OpenAI 于 2024 年 8 月推出了其版本的schema 输出。该公司将严格遵循 schema 与早期的 JSON 模式区分开来，后者仅旨在生成语法有效的 JSON。

这一能力从多个方面改变了开发者体验。

首先，应用代码不再需要从散文式文本中寻找相关答案。它可以反序列化一个已知对象，并应用常规验证规则。

其次，开发者可以将字段标记为必填。缺失的发布日期可以触发审核队列，而不是悄然变成数据库中的空值。

第三，schema 成为提取步骤与下游服务之间的契约。前端代码、数据库、队列和分析系统都可以使用相同的字段定义。

以文章监测流水线为例，其目标对象可以包含标题、作者、发布时间戳、规范 URL、组织以及一小组事实性主张。

提取器返回这些字段，但流水线不应立即发布它们。它可以验证规范域名、标准化日期、将作者与页面元数据进行比对，并保留来源段落。

最后一个字段很重要。没有支撑上下文的提取事实难以审计。更好的 schema 会在每个重要值旁保留源文本、页面 URL、获取时间和提取版本。

这种架构将模型视为带有不确定性的解析器，而非不容质疑的数据库。模型提出结构化解读，确定性代码决定该解读是否符合运营规则。

该设计也支持有针对性的重试。如果缺少必填日期，应用可以仅针对该字段以更明确的指令重新运行，而无需重复所有下游操作。

schema 约束仍有局限。Google 指出，其结构化模式仅支持 JSON Schema 的一个子集。OpenAI 同样说明，结构正确并不能防止返回值内部出现错误。

模型可能在完全有效的日期字段中填入错误日期。它可能将文章更新时间误认为最初发布时间，也可能把宣传性语言解读为已被独立证实的事实。

因此，开发者应将语义准确性与 schema 合规性分开衡量。成功的 API 响应只能证明传输和格式正常，并不能证明提取结果正确。

这正是 AI 驱动 API 与传统解析器的区别所在。元素消失时，选择器通常会明显失败；模型则可能返回一个看似合理的替代值。

合理性在探索阶段很有用。但当系统悄然存储、转载或据此采取行动时，它就会变得危险。

实际应对方式是分层验证。团队可以针对敏感记录结合 schema、领域规则、置信度阈值、来源引用和人工审核。

构建内部研究系统的开发者，也可以将已验证材料保存在可搜索的知识库中。这能让提取出的主张始终与支持它们的文档保持关联。

AI 数据提取正在给爬虫和 API 提供商带来压力

AI 提取不只是取代解析器代码；它还改变了谁来控制网站与应用之间的接口。

网站运营者传统上决定是否提供结构化访问方式。他们可以发布 API、添加 schema 标记、提供 RSS 订阅源，或让信息停留在渲染后的页面中。

AI 提取削弱了这一边界。第三方服务无需网站所有者配合，就能将面向人类的页面转化为非官方的结构化接口。

这一发展同时给多个群体带来压力。

爬虫供应商必须说明，为何其浏览器基础设施、代理管理、调度和可靠性控制仍然重要。模型解读成为流水线的另一阶段，而不是对获取工程的替代。

API 提供商面临的是另一个问题。如果开发者能够从网站中获得可接受的记录，一些人可能会推迟构建或授权使用官方 API。

官方 API 仍具备决定性优势。它们可以提供稳定标识符、文档化含义、更新保障、授权控制，以及公开页面上没有的数据。

默认情况下，AI 生成的接口不提供上述任何保证。名为 availability 的字段可能表示当前库存、地区适用资格，或营销标签。只有数据源所有者能够定义其预期语义。

网站所有者也更有动力发布更优质的机器可读数据。清晰的元数据可以减少提取错误，并改善内容在搜索、助手和聚合器中的呈现方式。

Google News 展示了这一区别的重要性。聚合器可以传递标题和目标地址，但读者仍依赖发布者获取文章，而应用程序必须区分订阅源元数据与原始报道。

这种压力还延伸至前端开发。多年来，团队一直在设计响应式视觉界面，同时将机器访问视为独立的后端问题。

如今，AI 智能体会像读者一样与这些界面交互。它们渲染页面、理解控件、收集数据，有时还会触发操作。无障碍标签和语义 HTML 可以改善这种交互，但两者都不能保证解读正确。

通常称为 MCP 的 Model Context Protocol 提供了另一条路径。它规范了 AI 应用如何连接工具和数据源。网站运营者可以提供经过授权的连接器，而不必让智能体从 HTML 中重建语义。

这带来了一个比“API 对抗爬虫”更有意义的竞争格局。新兴选择涵盖官方结构化访问、由模型介导的提取，以及同时使用两者的混合系统。

官方接口最适合高价值、重复性的操作。AI 提取则适用于长尾来源、原型开发以及缺乏一致 schema 的文档。

混合系统可以先使用官方数据，再用提取结果补足缺口，并将冲突发送至审核。它们还可以比较可见页面内容与 API 响应，以发现过时或不匹配的记录。

经济权衡并不局限于开发时间。团队还必须考虑渲染延迟、模型调用、重试率、审核人力，以及源站变更导致的故障。

简短的提示词可能掩盖这些复杂性。“从这个网站提取所有列表”听起来比维护爬虫更容易。但生产环境中的表现仍取决于分页、重复检测、地域差异、同意横幅和错误恢复。

这种转变也改变了测试方式。传统爬虫测试通常使用保存的 HTML 固件和预期的选择器结果。AI 提取需要更广泛的评估集，其中应包含布局变化、含糊措辞、缺失字段和对抗性内容。

团队应衡量字段级别的精确率和召回率，还应跟踪无依据的值、相互冲突的来源，以及模型或提示词更新后的变化。

这种评估纪律决定了 AI 提取会成为基础设施，还是仅仅停留在方便演示的阶段。

真正的问题是：如何信任来自不可信页面的数据

提供给 AI 提取器的每个网页，既是数据，也可能成为指令的载体。

传统 HTML 解析器不会将一句话理解为命令。语言模型会。这一区别带来了超出普通格式错误标记之外的安全风险。

攻击者可以在页面上放置隐藏或可见的指令。这些指令可能要求提取器忽略任务、修改返回值、泄露上下文，或调用已连接的工具。

OWASP 将这一问题归类为提示词注入。其指南特别指出，通过网站和文件等外部来源传递的间接攻击。

当提取功能连接到拥有更广泛权限的代理时，风险会进一步增大。只读流程可能产生错误数据；而拥有数据库、电子邮件或部署权限的代理，可能造成严重得多的后果。

结构化输出能降低部分格式风险，但无法解决提示词注入。恶意页面可以在保持所需模式的同时，尝试操纵字段值。

例如，提取器可能请求供应商名称和收款去向。敌对文档可能指示模型替换为攻击者控制的账户，同时仍返回有效字段。

应用程序需要围绕提取内容建立严格的信任边界。

模型应只接收完成任务所需的内容。当脚本、注释、隐藏元素和无关导航不提供有用证据时，可在推理前将其移除。

凭据应始终置于模型上下文之外。提取服务应使用权限范围严格受限的令牌，不应继承更广泛代理会话的权限。

高影响操作需要确定性检查。任何由模型生成的 URL，在发起请求前都应通过域名允许列表。金融或身份数据应要求与权威来源进行比对。

开发者也应将模型输出视为不可信输入。在渲染 HTML 前必须转义字段值，对数据库操作使用参数化方式，并在获取 URL 前验证其合法性。

来源追溯提供了另一层防御。NIST 的AI 风险概况将来源追踪描述为记录内容来源和历史的一种方式。

对于提取系统，有用的来源信息包括源 URL、获取时间戳、可见的支持性文本、渲染配置、模型标识符、提示词版本和验证结果。

这些记录有助于团队调查错误答案，也能让他们在模型更新或源站修正后重新处理数据。

可复现性仍然很困难。网站内容会变化，个性化页面各不相同，模型服务也在演进。未来的重试可能不会遇到相同输入，也不会产生相同解读。

团队可以通过在适当情况下存储合法快照或加密哈希来降低这种不确定性。他们可以保留相关段落，而无需留存不必要的个人数据。

数据保护同样值得重视。公开 URL 并不意味着所有提取字段都适合被无限期存储、聚合或用于自动化决策。

开发者必须考虑访问条款、隐私义务、知识产权和 robots 指令。技术能力并不能解决这些政策问题。

即使没有攻击者，质量风险也会出现。页面可能包含旧价格、地区可用性、重复日期、赞助内容，或与正文相矛盾的评论。

模型需要明确的证据优先级。页面元数据可以决定规范 URL，而可见的文章正文则支持事实性主张。评论区不应推翻发布者报道的信息。

即便如此，歧义仍然存在。有时正确结果是 null，而不是自信的猜测。

模式应在源站存在不确定性时允许不确定性。实用字段可以包括 not_found、ambiguous、conflicting 和 requires_review。

这种设计可能产生更少的完整记录，但比强迫每个字段都填入一个貌似合理的值更安全。

最重要的可靠性指标，不是 API 返回 JSON 的频率，而是下游用户能否为每个重要字段值追溯到充分证据的频率。

Google News 信号出现后，开发者应关注什么

下一阶段将由可量化的准确性、授权访问和运营可观测性决定，而不是由新闻标题式的演示决定。

未来几个月，有三个信号值得关注。

第一个是提取服务提供商是否会在真实页面上发布字段级评估。仅符合模式已不再足够。开发者需要看到对模糊日期、动态内容、地区变体、缺失字段和布局变化的结果。

服务提供商应披露其如何评估无依据的值。一个填满所有字段的系统看起来可能很完整，却可能比谨慎的竞争者生成更多错误记录。

独立评估将增强市场信心。测试集应同时包含常规故障和刻意设计的敌对页面。结果应分别衡量渲染成功率、提取准确性和证据质量。

第二个信号是授权机器接口的增长。网站所有者可以发布稳定的 API、信息流、结构化元数据或代理连接器，以定义权限和字段含义。

AI 提取不会淘汰这些接口。相反，它可能通过揭示非结构化访问会产生错误的场景，进一步增加对这些接口的需求。

开发者应关注内容平台是否提供引用、稳定标识符和明确的使用控制。这些功能比一个只会返回流畅文本的端点更重要。

第三个信号是生产流水线内部更好的可观测性。团队需要知道某个字段值由哪个来源支持、由哪个模型生成，以及由哪条验证规则接受。

提取系统应报告随时间变化的情况。作者缺失率或日期冲突率突然上升，可能揭示源站改版、渲染失败或模型退化。

人工审核率同样重要。一个能够自动处理大多数记录、但将每个疑难案例都交给专家的系统，仍可能带来显著价值。其运营者需要对这部分人力投入进行诚实衡量。

Google News 的标题指向了一场真实的架构变化。由于模型可以按需解读页面和文档，Web 开发对预先安排接口的依赖正在降低。

然而，胜出的系统不会将解读等同于事实。它们将结合模型灵活性、明确模式、确定性验证、有限权限、来源追溯和人工审核。

对开发者而言，眼下的问题不是 AI 能否提取一个页面。在许多条件下，它显然可以。更好的问题是，在应用程序信任结果之前，必须具备哪些证据。

从一个边界明确的工作流开始，并建立具有代表性的评估集。对重要字段要求提供引用，保留不确定性，并将 AI 路径与确定性基线进行比较。在每次源站、提示词或模型变更后跟踪准确性。如果这些控制措施仍然负担得起，就扩大工作流；如果它们压倒了预期收益，就继续使用既有解析器或官方 API。Google News 或许能帮助凸显这一趋势，但生产证据必须决定架构。