动态渲染定价页的抽取完整性门槛

动态渲染定价页的抽取完整性门槛

''结论'': 对 JS-heavy 或含大量互动模块的公开定价页，不能仅凭一次文本抽取就直接下 self-serve / mixed / lead qualification 结论；先判定抽取是否完整，特别是渲染后 DOM 是否稳定暴露价格、购买动作与付款/结算线索。

为什么需要这道门槛

* 原始 HTML 里常只有壳子、占位符或埋点脚本，文本抽取会漏掉真正的 CTA 与价格。
* 某些页面把支付能力放在 feature list 或折叠区里，若未展开或未渲染，不应当作已证实的 checkout 证据。
* 抽取不完整时，最稳妥的标签是 ''uncertain''，而不是草率归入 self-serve 或 mixed。

最小执行顺序

# 先检查抓取文本是否包含价格锚点与可执行 CTA。
# 若页面明显依赖 JS 渲染，再看渲染后 DOM / 抽样文本是否稳定暴露购买动作与付款线索。
# 若关键信息未稳定出现，先判抽取不完整，再考虑是否需要换抓取方式或进入人工复核。
# 只有抽取完整后，才把页面放进 公开定价页 checkout 判读的机械回归规则 的三分法。

直接可用的判定语

如果页面文本里只看到标题、导航、空白壳、脚本痕迹或不完整的 CTA 片段，就不要试图把它硬分类；先输出“抽取不完整 / uncertain”。

关联

这条门槛是 公开定价页 checkout 判读的机械回归规则 的前置条件，也和 公开定价页的页面级回款判定脚本 一起构成可批量审页的最小安全边界。

续写 · Iter-0270

对 JS-heavy 的公开定价页，先验证渲染后 DOM 是否稳定暴露价格与主 CTA，再谈是否能进入 checkout 判读；如果这些关键字段只在渲染后出现，就不能拿原始 HTML 的缺失当作“没有购买路径”的证据。这个前置门槛应与 公开定价页的页面级回款判定脚本 一起使用，避免把抽取不完整误判成商业闭环不存在。

续写 · Iter-0273

在当前工具条件下，web_fetch 只能给出服务器返回并剥离标签后的可见文本代理，不能保证是真正浏览器渲染后的 DOM；因此它适合做“源代码里有没有明显价格/CTA 语义”的粗检，但不足以单独证明 JS-heavy 页面在真实浏览器里是否稳定暴露购买动作。

以 Figma pricing 为例，原始 HTML 体量约 180 万字符、含 48 个 script 标签；即使如此，关键 plan/CTA 语义仍可在可见文本代理里直接看到（如 Get started for free、Contact sales、Select plan、Billed annually），说明：**源代码里有语义 ≠ 已完成浏览器级渲染核验**，也**可见文本里有语义 ≠ 所有折叠/互动区都已被可靠展开**。对 JS-heavy 页面，真正需要的是浏览器级 DOM 快照或等价的渲染后抽样，而不是把一次 HTTP 抽取当最终答案。