网页内容提取实测：Jina、Scrapling与web_fetch对比，开源方案无限次

在用 AI 辅助创作时，一个常被忽略的巨大成本，可能不是调用模型的次数，而是为了理解一篇文章，需要塞给 AI 的原始网页内容所消耗的 Token。最近，我针对几种主流的网页内容提取方案进行了一次完整的实测对比，包括 Jina Reader、开源框架 Scrapling 和基础的 web_fetch 工具，结果差异之大，有些出乎意料。

问题是如何暴露的？

典型的 AI 辅助写作流程是：找到参考文章 → 获取全文 → 交由 AI 消化并重写。

起初，最直接的选择是使用 web_fetch 这类工具，给一个 URL 就返回页面内容。但很快发现了问题：

• 一篇普通的技术博客，轻松就能返回 8000 到 15000 个 Token 的原始文本。
• 遇到结构复杂的页面，如 GitHub README 或官方文档，内容量可能更多。
• 如果需要同时参考 3-5 篇文章，光是“读取”这个环节，就可能消耗掉数万 Token。

更麻烦的是，web_fetch 返回的通常是整个页面的 HTML 转换结果，其中混杂了大量的导航栏、侧边栏、页脚、广告和“相关推荐”等噪音。真正有价值的正文内容，可能只占总文本量的 30%。这不仅浪费了宝贵的 Token 配额，也增加了 AI 理解核心内容的难度。

三种网页提取方案实测对比

为了客观对比，我选取了一篇 Substack 上的文章《How I Dropped Our Production Database》作为测试对象，在相同条件下（限制最大字符数）横向对比了三种提取方法的效果。

方案一：Jina Reader

用法：

web_fetch(“https://r.jina.ai/原始URL”, maxChars=30000)

Jina Reader 是一项专门用于网页内容提取的服务。它会自动渲染页面，智能抽取正文，并去除导航、广告等无关元素，最终返回结构清晰的 Markdown 格式文本。

实测效果如下：

Title: How I Dropped Our Production Database and Now Pay 10% More for AWS
I'm working on expanding the [AI Shipping Labs website](https://aishippinglabs.com/) ...
My gradual plan was:
1.   Move the current static site from GitHub Pages to AWS S3
2.   Move DNS to AWS so the domain is fully managed there
...

可以看到，文章的标题、正文、链接、图片地址以及列表格式都被完整、干净地保留了下来。提取速度也很快，大约在 1.4 秒左右。

主要缺点：它的免费服务有每日 200 次的调用限制。对于内容创作频率较高的用户来说，这个配额可能两三天就会用完。

方案二：web_fetch 直接抓取

用法：

web_fetch(url, maxChars=30000)

用同样的命令去抓取那篇 Substack 文章，结果直接返回了 fetch failed 错误。

这是因为 Substack 等平台部署了反爬虫机制，基础的 web_fetch 工具无法绕过。对于 Medium、部分付费墙博客以及国内的微信公众号，同样会遇到此类问题。

即使是对那些可以成功抓取的静态页面，web_fetch 返回的也是整个页面的 HTML 转译内容，噪音极多，Token 浪费严重。

结论：web_fetch 仅适用于无反爬的静态页面，如 GitHub README 或普通技术博客，不适合主流内容平台。

方案三：Scrapling + html2text

Scrapling 是一个开源的 Python 爬虫框架，在 GitHub 上的项目地址是 D4Vinci/Scrapling。它将自己定位为“为现代 Web 设计的自适应爬虫框架”，其核心特性包括：

• 原生绕过反爬：内置的 StealthyFetcher 能够绕过 Cloudflare Turnstile 等主流反爬系统，无需额外配置。
• 自适应选择器：当网站改版导致原有的 CSS 选择器失效时，它能自动重新定位目标元素，无需手动维护规则。
• 零依赖启动：只需 pip install scrapling 即可安装，没有复杂的浏览器驱动配置烦恼。

基本用法：

python3 scrapling_fetch.py <url> 30000

脚本的核心逻辑如下：

1. 使用 Fetcher.get() 方法获取页面的完整 HTML。
2. 按优先级尝试多个正文选择器，例如：article → main → .post-content → [class*="body"]。
3. 定位到正文所在的 HTML 元素后，使用 html2text 库将其转换为干净的 Markdown。
4. 根据参数截断到指定的字符数。

实测效果：

# How I Dropped Our Production Database and Now Pay 10% More for AWS
### A Terraform command executed by an AI agent wiped the production infrastructure...
I'm working on expanding the [AI Shipping Labs website](https://aishippinglabs.com/) ...
1. Move the current static site from GitHub Pages to AWS S3
2. Move DNS to AWS so the domain is fully managed there
...

输出结果与 Jina Reader 几乎一样干净，标题层级、超链接、图片 URL 和列表格式都被完好保留。提取速度约 3 秒，最关键的是，它没有任何使用次数限制，也不需要 API Key。

意外发现：对微信公众号的支持

在测试微信公众号文章链接（mp.weixin.qq.com）时，结果出现了显著差异：

• Jina Reader：直接返回 403 状态码，无法获取任何内容。
• web_fetch：请求被中断或拦截。
• Scrapling：能够完整获取正文，并输出为格式良好的 Markdown，文章内的图片链接也得以保留。

微信公众号有其专门的反爬策略，Jina 和基础抓取工具都难以突破。但 Scrapling 的 StealthyFetcher 成功绕过了这些防护。这一发现意义重大，意味着之前要么依赖搜索工具（只能获取摘要），要么需要手动打开浏览器复制的繁琐流程，现在可以通过一行命令直接获取公众号全文。

最终推荐的组合策略

基于以上实测，我总结出一套分级使用策略，以在效果、成本和成功率之间取得最佳平衡：

优先级	方案	适用场景	限制与缺点
1	Jina Reader	大部分英文博客、Substack、Medium	每日 200 次免费限额
2	Scrapling	Jina 超限后、微信公众号、有反爬的平台	无限制，速度稍慢（约3秒）
3	web_fetch	静态页面、GitHub、无防护的技术文档	返回全页噪音多，无法应对反爬
4	浏览器渲染 (如 Firefox)	需要登录状态、或反爬机制极端的网站	速度最慢，资源占用高

操作建议：

• 域名路由：遇到 mp.weixin.qq.com 的链接，直接调用 Scrapling，避免浪费 Jina 的宝贵配额。
• 字符数设置：统一将 maxChars 参数设为 30000，既能保证获取完整正文，又不会因内容过长而撑爆 AI 的上下文窗口。

一个重要技巧：Scrapling 必须配合 html2text

最初使用 Scrapling 时，我曾尝试直接调用其 get_all_text() 方法来提取纯文本，以为这样更简单。但结果不尽人意：

How I Dropped Our Production Database and Now Pay 10% More for AWS A Terraform command executed by an AI agent wiped the production infrastructure...

输出变成了没有任何格式的纯文字流：段落合并、链接和图片地址消失、标题层级丢失。对于 AI 写作而言，保留文中的链接（用于溯源）和图片 URL（作为素材参考）至关重要。

正确的做法是先获取 HTML 内容，再使用 html2text 进行转换：

import html2text
h = html2text.HTML2Text()
h.ignore_links = False  # 保留链接
h.ignore_images = False # 保留图片引用
h.body_width = 0        # 不自动折行，保持原格式
md = h.handle(element.html_content)

经过这一步处理，Scrapling 的输出在格式上就和 Jina Reader 一样干净通用了。

总结

• Jina Reader：效果最好，格式最干净，速度最快，但每天有 200 次的硬性限额。
• Scrapling + html2text：效果与 Jina 相当，无使用限制，并能攻克微信公众号等特殊平台（这是 Jina 的短板）。
• web_fetch：仅作为备选，适用于无防护的静态页面。
• 策略：将 maxChars 设为 30000 以节省 Token；为微信公众号域名设置专属规则，直连 Scrapling。

通过这次对比，一个清晰、高效且低成本的网页内容提取工作流就浮出水面了。合理利用这些 开源实战 工具和 技术文档 ，能显著提升 AI 辅助创作的效率与经济性。如果你也在探索自动化内容处理，不妨到 云栈社区 与其他开发者交流更多实战心得。

参考链接：

• Scrapling GitHub 仓库：https://github.com/D4Vinci/Scrapling
• Jina Reader 官方文档：https://jina.ai/reader
• html2text PyPI 页面：https://pypi.org/project/html2text