问题是怎么暴露的
在用 AI 做内容创作时，流程大概是这样的：找到一篇参考文章 → 读取全文 → AI 消化后写稿。
web_fetch 是最直接的工具，给一个 URL 就返回内容。但用着用着发现不对：
- 一篇普通技术博客，轻松返回 8000-15000 token
- 遇到 GitHub README 或文档页，可能更多
- 一篇文章采集 3-5 个信息源，光读内容就烧掉几万 token
更麻烦的是，web_fetch 返回的是整个页面，包括：导航栏、侧边栏、页脚、广告、"相关推荐"……真正有用的正文可能只占 30%。
三个方案的实测对比
拿了一篇 Substack 文章做测试：《How I Dropped Our Production Database》，同条件（max 12000字符）横向对比三种提取方式。
方案一：Jina Reader
用法：
web_fetch("https://r.jina.ai/原始URL", maxChars=30000)Jina 是专门做网页内容提取的服务，会自动渲染页面、抽取正文、去掉导航和广告，返回干净的 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)
测试同一篇文章——直接报错：fetch failed。
Substack 有反爬机制，web_fetch 根本进不去。对于 Medium、部分付费博客、微信公众号，同样的问题。
即使是能抓到的页面，返回的也是全页 HTML 转 Markdown，噪音多、token 浪费严重。
结论：只适合静态页面（GitHub README、普通技术博客），不适合有反爬的主流平台。
方案三：Scrapling + html2text
Scrapling 是一个开源 Python 爬虫框架（GitHub: D4Vinci/Scrapling），项目定位是"为现代 Web 设计的自适应爬虫"。核心特性：
- 原生绕过反爬：StealthyFetcher 能绕过 Cloudflare Turnstile 等主流反爬系统，不需要额外配置
- 自适应选择器：网站改版导致 selector 失效时，能自动重新定位元素，不需要手动维护
- 零依赖启动：
pip install scrapling，没有复杂的浏览器驱动配置
用法：
python3 scrapling_fetch.py <url> 30000
脚本逻辑：
- 1用
Fetcher.get()拿到页面 HTML - 2按优先级尝试正文选择器：
article → main → .post-content → [class*="body"] - 3找到正文后，用
html2text把 HTML 转成 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 几乎一样干净，标题层级、链接、图片 URL、列表都保留了。速度约 3 秒，无限制，不需要 API Key。
意外发现：微信公众号文章
测试微信公众号链接（mp.weixin.qq.com）时：
- Jina → 直接 403 拦截，内容为空
- web_fetch → 请求被中断
- Scrapling → 完整拿到正文，Markdown 格式，图片链接也保留
微信公众号有专门的反爬，Jina 和 web_fetch 都进不去，但 Scrapling 的 StealthyFetcher 能绕过去。
这个发现意义很大——之前我们读公众号文章要么靠搜索工具（只能拿摘要），要么靠浏览器渲染（慢且复杂），现在一行命令就能拿全文。
微信公众号文章：Scrapling 直接能拿全文，Jina 403，这一条就值得把 Scrapling 装上。
最终推荐策略
经过实测，确定了这套分级策略：
| 优先级 | 方案 | 适用场景 | 限制 |
|---|---|---|---|
| 1 | Jina Reader | 大部分英文博客、Substack、Medium | 200次/天 |
| 2 | Scrapling | Jina 超限、微信公众号、反爬平台 | 无限制 |
| 3 | web_fetch | 静态页面、GitHub、技术文档 | 全页噪音多 |
| 4 | Browser Firefox | 需要登录态、极端反爬 | 最慢 |
域名快捷路由： mp.weixin.qq.com 直接用 Scrapling，跳过 Jina，不浪费配额。
关于 maxChars： 统一设 30000，既保证完整正文，又不会塞爆 context。
坑：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_content，再用 html2text 转换：
import html2text h = html2text.HTML2Text() h.ignore_links = False h.ignore_images = False h.body_width = 0# 不自动折行 md = h.handle(element.html_content)
这一步加上去，输出就和 Jina 一样干净了。
- Jina：最好用，格式最干净，但每天 200 次限额
- Scrapling + html2text：效果和 Jina 相当，无限制，能读微信公众号（Jina 做不到）
- web_fetch：有反爬的平台直接失败，只适合静态页面
- maxChars 统一设 30000：省 token 的同时保留完整正文
- 微信公众号直接走 Scrapling，不要浪费 Jina 配额
