ScrapeGraphAI实战：用大语言模型驱动自然语言网页抓取与结构化数据提取

1. 项目概述与设计思路

1.1 ScrapeGraphAI 到底是什么

在做信息采集和数据分析的时候，我经常会遇到一个很折腾的场景：目标网站的结构变了，之前写好的爬虫脚本立刻失效，又要重新对着开发者工具看 class、id，一条条改选择器。这种循环持续了很长时间，直到我开始用 ScrapeGraphAI。

这个项目在 GitHub 上的名字是 ScrapeGraphAI/Scrapegraph-ai，核心思路很简单：用大语言模型来驱动网页抓取，不再靠死写 CSS 选择器或 XPath，而是把“你想抓什么”用自然语言告诉它，由模型负责分析页面结构、定位数据、整理输出。本质上，它把传统爬虫的“规则匹配”换成了“语义理解”。

它还引入了一个很有意思的概念：抓取图（ScrapeGraph）。可以把一个抓取任务拆成一连串小步骤，像流水线一样串联起来，每一步之间传数据，最终直接给你一份结构化结果。对我来说，它最大的价值不是“又多了一个爬虫框架”，而是把网页解析这件事从写代码变成了写需求。

这篇文章适合谁看？如果你用过 Requests、Scrapy 这类库，知道选择器是什么，但被页面改版搞得头大；或者你想在项目里快速实现一个“给个链接就能抽数据”的能力，都在这个范围内。我会把它的设计逻辑、具体用法、我踩过的坑全部拆开讲一遍，尽量做到看完能直接上手。

1.2 为什么需要用 LLM 做爬虫

传统爬虫的根基是“定位”。你得告诉程序：目标数据在哪个标签、哪个 class、哪一层兄弟节点里。这个方案在页面稳定的场景下效率很高，但代价是脆弱。页面只要加了个包裹层、改了属性名，或换了渲染方式，之前的 url 规则就全线崩溃。

ScrapeGraphAI 换了一条路：让模型看页面内容来判断“哪里是要找的数据”。它把 HTML 转成文本、Markdown，有时还会配合 DOM 树结构，交给 LLM 去推理。模型不需要知道选择器，只需要理解用户的需求，比如“提取所有文章的标题、发布时间和作者”，就能自己找到相应内容。

这样做带来几个直接好处：

• 页面结构和样式变了，只要内容还在，通常还能抓对；
• 不用针对每个站点单独写解析逻辑，站点多了以后工作量能明显降下来；
• 对动态渲染的页面，配合 Playwright 这类工具也能处理，覆盖面更广。

当然，它也有代价。LLM 的推理速度比正则表达式慢得多，Token 消耗也要花钱，而且模型偶尔会“自由发挥”，把抓取结果整理成不太符合预期的格式。所以它更适合做“规模可控、变化频繁、结构复杂”的任务，而不是让你拿它去爬千万级页面。想要高吞吐量的批量任务，还是传统方案更合适。

1.3 技术栈与架构拆解

ScrapeGraphAI 的核心是用图结构来描述抓取任务。我刚开始看到 “ScrapeGraph” 这个名字时以为是什么复杂的数据结构，用下来才发现，它就是把你需要执行的抓取步骤定义成节点，节点之间用边连接，数据沿着边流动。

常见的内置“图”有这么几类：

• SmartScraperGraph：单页抓取，给定 URL 和需求，直接出结果。这是平时用得最多的。
• SearchGraph：从搜索引擎结果页出发，把多个页面串起来抓取。适合做竞品信息汇总。
• SpeechGraph：抓取结果直接用语音合成播报，偏演示场景，实际工作里很少用。
• ScriptCreatorGraph：让 LLM 自动生成一个抓取脚本，本质是用模型写代码。
• ExtractGraph：直接从一个 URL 批量提取多个维度的信息。

底层方面，它支持对接 OpenAI、Anthropic、Google Gemini、Ollama 本地模型等，也就是说你可以完全离线跑，不用把页面内容发到第三方。这对处理敏感数据来说很关键，我这边有一类内部信息抓取任务，就是全部走 Ollama 的本地模型解决。抓取引擎支持 Requests 和 Playwright，后者在遇到需要 JS 渲染的页面时是必需品。

整条链路你可以理解为三部分：入口是自然语言需求，中间是图编排和模型推理，出口是结构化数据。ScrapeGraphAI 所做的就是把中间这层包装得足够简单，让你不用关心模型怎么调用、提示词怎么组织、结果怎么解析。

2. 核心概念与关键参数

2.1 图结构：理解 ScrapeGraph 的工作方式

要真正用好 ScrapeGraphAI，就必须理解“图”是怎么组织的。官方仓库里的文档把节点分为两类：抓取节点和解析节点。

• 抓取节点负责把页面内容抓下来，可以只抓静态 HTML，也可以渲染 JS 之后再抓。
• 解析节点负责把抓取到的内容连同用户需求一起交给 LLM，让模型返回结构化数据。

图的好处是什么呢？我举个例子。你想抓一个新闻列表页，但摘要信息不完整，需要点进详情页才能拿到正文。传统爬虫你得分别写列表页的解析函数、详情页的解析函数，再用代码把它们串起来。在 ScrapeGraphAI 里，你可以定义两个抓取步骤，前一步把详情页链接找出来，后一步逐个访问这些链接提取正文，中间用边连起来，它就自动执行完了。

这就是“SearchGraph”这类预置图的工作原理。它对搜索页面的结果链接进行遍历，再对每个链接执行一次内容提取，最后汇总。由于链接数量不定，运行时间也会波动，但思路很直观：不要一个人干完所有事，而是拆成步骤，每个步骤只干一件事。

了解了这个原理，你在遇到复杂需求时就能自己组装图。虽然官方提供的预置图覆盖了大多数场景，但真正符合自己业务的流程，通常需要自定义节点逻辑。比如某个页面需要先登录，那你就要在抓取节点之前加一步“带 Cookie 请求”的处理。

2.2 Prompt 设计：决定抓取质量的第一因素

ScrapeGraphAI 把用户输入的自然语言需求直接拼进发给模型的提示词里。所以，你的需求写得清不清楚，直接决定返回结果好不好。我见过不少用户反馈“抓出来的东西不对”，看代码没什么问题，最后几乎全是提示词写得太模糊。

先看一个反面例子：

提取这个页面的所有信息

这种提示词基本等于没有，模型不知道你要什么，就会把整个页面的大段文字一股脑给你，或者自行臆断输出结构。更好的写法是这样：

从页面中提取所有产品的名称、价格、评分和库存状态。 以 JSON 数组格式返回，每个产品包含 name、price、rating、stock 四个字段。

这里我强烈建议，在提示词里明确给出三样东西：

1. 要哪些字段，尽量用明确的名词；
2. 输出格式，JSON、Markdown 表格还是纯文本；
3. 取数范围，是只要第一屏内容，还是要遍历全部分页。

你仔细想就会发现，这跟带人干活是一样的。你只说“把资料整理一下”，对方不知道整理成什么样；但你如果告诉他“把这三列数据抽出来，整理成 CSV，表头用中文”，他就能直接上手。

还有一个细节：模型对数字和名称的理解存在概率性。同一页面跑两次，返回结果可能在字段命名上略有差异。所以我的习惯是在提示词里把字段名固定死，并且在拿到数据之后再做一层校验，而不是默认模型每次输出都是完美的。

2.3 模型 Provider 与本地化部署选择

ScrapeGraphAI 的模型接入层做得很灵活，支持的 Provider 包括 OpenAI、Anthropic、Gemini、Azure OpenAI、Ollama 等。它的设计里把“模型”和“抓取流程”解耦了，所以切换模型不需要改业务代码，只需要改配置项。

我这边在实际项目中试过几类模型，简单做个对比如下：

我个人的建议是：先拿 GPT-4o-mini 这类便宜模型跑通流程，确认提示词没问题后，再根据数据敏感等级决定是继续用云端还是切到本地 Ollama。

如果你选择 Ollama，配置非常简单。先拉一个模型：

ollama pull llama3.2

然后，在代码里指定 Model 为ollama/llama3.2，再配置 Ollama 的服务地址即可。用本地模型的代价是速度和精度，比如一次简单的单页提取可能要花十几秒，而云端模型只要两三秒。

有一点需要特别注意：不同模型的输出格式遵从能力差别很大。GPT-4o 系列对 JSON 格式的把握很稳，而一些参数量较小的模型偶尔会输出多余的注释或 Markdown 标记。遇到这种情况，不要一味换模型，可以在提示词里补充一句“只输出 JSON，不要输出任何解释性文字”，往往能明显改善。

2.4 数据输出格式与结构化提取

ScrapeGraphAI 的核心输出是ScrapeResult对象，里面包含提取结果、抓取截图等信息。默认情况下，如果你不指定额外参数，输出的格式由模型自己决定。但为了后续处理方便，我建议每次都显式要求 JSON 格式。

举一个实际使用 SDK 的例子：

from scrapegraph_py import Client sgai = Client(api_key="your-api-key") response = sgai.smartscraper( website_url="https://example.com/products", user_prompt="提取页面上所有产品名称和价格，输出 JSON 数组", )

response里通常包含result字段，直接就是字符串形式的 JSON。解析这一步的关键在于容错。因为任何一个 LLM 都不可能保证 100% 输出合法 JSON，尤其当页面内容复杂时，可能多一个逗号、少一个引号，导致json.loads抛异常。

我的处理办法是：先用strip()去掉首尾空白，再把常见的 Markdown 代码块标记去掉，最后尝试解析。如果解析失败，就把它当作纯文本返回，并打日志，便于人工介入。这套容错逻辑几乎用在了我所有基于 ScrapeGraphAI 的项目里。

3. 实操过程与核心环节实现

3.1 环境准备与安装

先说环境要求。ScrapeGraphAI 基于 Python 3.9 以上版本，安装时强烈建议用虚拟环境，避免污染系统级 Python。我用的是venv：

python -m venv venv source venv/bin/activate # Windows 下是 venv\Scripts\activate

核心库安装一行命令：

pip install scrapegraph-py

如果只是用 SDK 方式调用云端的 ScrapeGraphAI 服务，这个就够了。但如果你想跑本地库版本，那需要换一种安装方式，因为开源版和 SaaS 版的包名不同。本地库版本安装的是scrapegraphai：

pip install scrapegraphai

我强烈建议你先把“使用方式”和“底层依赖”分开理解。当我们讨论一个开源项目时，说的是代码库；当我们使用 SaaS 服务时，说的是 API。很多东西在文档里混在一起，新人特别容易搞混。我的经验是：如果目标只是快速验证想法，先注册 ScrapeGraphAI 的云服务，拿 API Key 跑一遍；如果想深度定制、离线运行，再切换到本地开源版本。

继续安装，本地版本会默认安装 Playwright，但浏览器内核需要单独下载：

playwright install

这一步很多人漏掉，结果代码一跑就报browser executable not found。另外确认一下 Python 环境里没有缺少torch或transformers，因为本地模型推理依赖这些重量级库。

3.2 第一个样例：SmartScraperGraph

我们先跑通一个最基础的流程：给定 URL，让模型提取产品名称和价格。这里我用的是本地库方式，方便展示完整代码：

from scrapegraphai.graphs import SmartScraperGraph graph_config = { "llm": { "model": "openai/gpt-4o-mini", "api_key": "your_openai_api_key", "temperature": 0.1, }, "verbose": True, } graph = SmartScraperGraph( source="https://example.com/products", prompt="提取所有产品名称和价格，以 JSON 数组格式返回，字段为 name 和 price", config=graph_config, ) result = graph.run() print(result)

这段代码很短，但里面有 4 个关键点：

• llm.model用了openai/前缀，表示走 OpenAI 兼容的接口。
• temperature我习惯调低到 0.1 左右，因为提取信息属于“确定性任务”，不需要模型发挥创造力。
• source可以是 URL，也可以是本地 HTML 文件路径。传本地文件在调试时特别有用，既能省 Token，又能反复测同一份页面。
• graph.run()返回的是一个字典，可以直接按字段取数据。

跑完你大概率会遇到问题：模型输出被截断、字段名和你预期不一致、或者返回了空数组。这些都不用慌，我把常见问题的排查方法单独放在第 4 节里讲，先继续往下走流程。

3.3 自定义提示词与结构化输出

用了一段时间之后，你会发现自己 80% 的时间其实都花在调提示词上。这个项目本身没有逼你写爬虫代码，但它逼你把需求描述清楚。这里我把自己常用的一个“模板”写出来，你可以直接抄：

你是数据提取助手。请从给定网页中提取以下字段： - 字段1：字段1描述 - 字段2：字段2描述 - 字段3：字段3描述 要求： 1. 如果页面中不存在某个字段，用 null 代替，不要省略。 2. 只输出 JSON，不要输出任何解释性文字。 3. 如果有多个条目，以 JSON 数组形式返回。

为什么要写得这么死板？因为我发现模型在输出时，总是倾向于“换一种说法”，导致字段名不稳定。例如你要求price，它可能返回Product Price或价钱。在提示词里明确字段名的同时，再给一个“If not found, use null”的兜底规则，会让结果格式稳定很多。

另外，对于需要返回较多字段的页面，我通常把网页内容分成多个区块来抓。原因很简单：上下文长度有限，如果整页丢给模型，它会抓不住重点。比如一个长文章页面，我先提取标题和 Meta，再单独提取正文，最后合并结果。这比一次性让模型输出全文摘要更可控。你也可以在提示词里指定“只考虑页面左上角的产品区域”来缩小范围，但这种情况模型有时会误解，所以还是分块最靠谱。

3.4 CLI 用法

除了写 Python 代码，ScrapeGraphAI 还提供一个命令行工具，适合快速试一下效果。安装之后直接在终端里跑：

scrapegraphai smartscraper \ --url "https://example.com/products" \ --prompt "提取所有产品名称和价格" \ --model "openai/gpt-4o-mini" \ --api-key "your_openai_api_key"

CLI 的命令规范和 Python SDK 基本一致，只是参数用--传。它的价值在于你不用打开编辑器，直接在终端验证一个想法。我经常用它来测试不同提示词的效果，比如写好一句话，跑一遍看结果，不满意就改提示词再跑，效率比来回改 Python 文件高挺多。

需要注意的是，CLI 工具默认输出到标准输出，如果结果很长，会被终端截断或刷屏。我一般会加> output.json重定向到文件里，再查看结果。

3.5 参数优化与性能调优

跑通之后，很多人会关心怎么让结果更准、更快、更省。这里我从三个维度分享我的调优经验。

准确率维度。核心是提示词和模型选择。如果你的抓取内容涉及复杂的长文本理解，例如从一段新闻里抽出发言人的观点，那用小模型很容易漏信息，这时要换强一点的模型。反过来，如果只是提取标题、日期、作者这种显式字段，小模型就够用了，完全没必要上旗舰型号。

速度维度。影响最大的是页面加载和模型推理。静态页面用默认抓取器就好，不要一上来就开 Playwright，因为浏览器渲染通常要多等好几秒。判断一个页面是否不需要动态渲染，最简单的方法是用 Requests 拉一遍，看看关键数据在不在 HTML 源码里。如果在，就不用上 Playwright。

成本维度。Token 消耗主要受页面文本长度影响。网页除了正文，往往还有导航、广告、页脚这些噪声。ScrapeGraphAI 支持在抓取节点后接一个“内容过滤”步骤，但更实用的做法是在graph_config里设置max_tokens限制输出长度。另一个有效手段是，如果只是测试，就用本地 HTML 文件代替线上抓取，这样重复运行只消耗模型推理的 Token，不消耗抓取流量和渲染时间。

还有一个细节：temperature参数不要设置得太高。我见过有人直接复制默认配置，temperature=0.7，结果抓同一个页面，两次结果不一致。数据提取是“低熵”任务，温度越低，输出越稳定。你会把 temperature 设到 0.2 以下，除非你确实需要模型生成一些非确定性的语义内容。

4. 常见问题与排查技巧实录

4.1 典型报错与解决方法

用 ScrapeGraphAI 的过程中，报错是常态。我把自己遇到最多的几个问题整理成表格，方便直接对照：

这里面最容易踩的坑是Token limit exceeded。你抓一个超长新闻页面，正文动不动几万字，直接塞给模型当然会超。解决办法是先用正则或 BeautifulSoup 把 HTML 里的正文部分提取出来，再交给 ScrapeGraphAI 处理。不要指望模型能在几万 Token 的上下文中做到精确定位，它的注意力会被噪声稀释。

另一个高频问题跟代理有关。如果你的服务器访问 OpenAI API 不稳定，程序会反复重试然后宕掉。代码层面上，我建议把 API 调用封装在重试机制里，比如用tenacity库设置最多重试 3 次，每次间隔递增。但更根本的解法是换模型 Provider，或者把模型服务部署在内网。

4.2 失败重试与日志

ScrapeGraphAI 的verbose参数打开之后会打印详细日志。我建议在所有非生产脚本里都开启，它能帮你看到每次请求调用的模型、消耗的 Token、执行过程中的每个节点状态。

逻辑上，抓取流程会经历“抓取 HTML -> 清理 HTML -> LLM 推理 -> 输出格式化”这几个阶段。如果在日志里看到“Cleaning HTML”阶段花了很久，那说明页面有很多无效标签，可以考虑用内容过滤节点。如果日志显示 LLM 推理刚结束就报错，那大概率是输出格式问题。

对于重试，我自己的做法是这样的：当模型返回结果为空或者格式错误时，先不急着报错，把同一个请求再发一次。因为 LLM 有随机性，第二次大概率能输出正确结果。如果第二次还失败，再走异常流程。这个“一次不行再来一次”的思路看着笨，实际挺管用，毕竟重试一次的成本通常远低于人工排查的成本。

4.3 反爬与速率控制

说到网页抓取，反爬是个躲不开的话题。ScrapeGraphAI 本身不处理反爬，只负责解析，所以遇到 403、验证码、IP 封禁，你得在它之前加处理层。

我的处理顺序是：

1. 设置合理的请求头，尤其是User-Agent，别用默认的 Python 默认 UA；
2. 加入requests的Session，在抓取前先访问一次首页获取必要 Cookie；
3. 控制请求频率，同一域名下，两次请求间隔至少 2 到 3 秒；
4. 如果目标站对 JS 渲染要求很高，再用 Playwright，并配合动态 UA 和随机延迟。

在 ScrapeGraphAI 的graph_config里，你可以传入loader_params来设置请求头：

graph_config = { "llm": { "model": "openai/gpt-4o-mini", "api_key": "...", }, "loader_params": { "headers": { "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36", "Accept-Language": "zh-CN,zh;q=0.9", } } }

为什么这个参数很多人忽略？因为默认配置能跑通大多数规范站点，但一旦遇到严格的反爬策略，就找不到排查方向。先在loader_params里把请求头模拟成一个真实浏览器，能解决掉大部分 403 问题。

需要明确一点：抓取公开数据时要遵守网站的 robots 协议和使用条款，只把爬虫用在合法、合规的场景里。并且，请求频率尽量放低，别把自己的 IP 打爆了，这更多是对自己负责，跑批任务时挂掉是最烦人的。

4.4 成本控制与 Token 用量

LLM 爬虫最大的争议就是成本。如果你抓一个页面消耗 5000 Token，一次抓取按 GPT-4o-mini 的定价算可能还要几分钱，但大批量跑起来，成本就不可忽视了。

这里分享几个我实际用下来的省钱策略。

第一，优先用便宜模型。不是所有任务都需要 GPT-4o，很多简单的单页字段提取，用gpt-4o-mini甚至llama3.2就能完成。你可以先拿便宜模型跑，准确率不够再局部换强模型。

第二，裁剪输入内容。把页面 HTML 先转成纯文本，去掉脚本、样式、导航菜单。本来 5000 Token 的工作量，裁剪后可能只剩 1500 Token，成本直接降 70%。ScrapeGraphAI 内部虽然也有清理步骤，但如果你自己提前处理，会省得更多。

第三，设置max_tokens。这能在模型生成超长结果时及时止损。比如你只提取 5 个字段，输出不超过 300 Token，那完全可以把max_tokens设为 500，防止模型自由发挥写一大段解释。

第四，加缓存。对同一个页面，如果数据没变，没必要反复抓。可以给 URL 和提示词的组合做一层哈希缓存，命中缓存直接读文件，不调用任何模型。我这边专门做了一个“URL + 需求 + 页面版本”的三层缓存，抓取成本降了相当多。

培养一个意识：把 Token 当钱花，把抓取逻辑当成成本优化对象。LLM 很好用，但不是所有场景都适合用，能不用模型的步骤尽量不用。

5. 从爬虫到知识管线的扩展思考

5.1 把 ScrapeGraphAI 嵌入完整数据流程

只把 ScrapeGraphAI 当作一个抓取工具，多少有点辜负它的设计。在实际工程里，我更喜欢把它放在整个数据处理链路里，当作数据接入口。

一个典型流程是：调度器定时触发任务 -> ScrapeGraphAI 抓取并结构化 -> 写入数据库 -> 变更检测 -> 触发下游数据分析。在这个流程里，ScrapeGraphAI 负责最难的“从非结构化页面到结构化数据”这一步，而其他部分可以全部用普通代码解决。

举个例子，我在做某个行业的信息监控时，需要每天跟踪十几家竞品的新闻页。传统做法是给每个网站写一套解析规则，等到网站改版就修一轮。用 ScrapeGraphAI 后，我只需要维护一个需求模板，例如“提取新闻标题、日期、正文摘要、原文链接”。不管网站怎么改版，只要新闻内容还在页面上，模型基本都能找到。

这种模式的另一层价值是，它把“字段变更”的成本从开发变成了配置。以往业务上增加一个字段，要改爬虫代码、改解析正则、重新上线；现在只需要改提示词里的字段列表。对一个小团队来说，效率差异非常明显。

5.2 多步骤抓取与自定义图的设计

当任务变得复杂时，预置图可能不够用，需要自己设计图。比如一个典型的商品页，你可能要先抓列表页拿到所有详情页链接，再逐条抓取详情页的价格和库存。这个流程可以用两个节点串起来。

在代码层面，官方提供了BaseGraph类，可以在里面添加自定义的抓取节点和解析节点。我还没有深入源码层面的高度，但从使用者的角度，你只需要理解每个节点接收什么输入、返回什么输出即可。

设计图的时候有几个经验：

1. 节点职责要单一。一个节点只做一件事，不要既抓列表又抓详情；
2. 节点间数据格式要明确。你可以定义一个 JSON 结构，让上一个节点的结果刚好是下一个节点的输入；
3. 增加异常分支。比如详情页访问失败时，是跳过还是重试？这个逻辑要在图里体现。

最理想的状态是：你的抓取流程变成一张可以配置“依赖关系”的图，不同站点套不同模板，不用为每个站点写一套代码。这也是 ScrapeGraphAI 和传统爬虫相比，最吸引我的地方。

5.3 与 LangChain、RAG 的结合空间

顺着知识管线的思路往下走，ScrapeGraphAI 还可以和 RAG（检索增强生成）链路很好地结合。最朴素的用法是：它负责把网页变成干净的 Markdown 或 JSON，然后交给向量库做切片和 embedding。后续的问答机器人、知识库查询，全都建立在这个结构化的数据之上。

我之前做过一个内部资料助手，数据源是几十个内部系统页面。没有用 ScrapeGraphAI 之前，光是清洗 HTML、抽取正文就写了很长一段代码，而且每个系统页面结构不一样，维护成本很高。后来改用 ScrapeGraphAI 统一抽取正文，所有页面输出同一份 Markdown 格式，下游处理完全无需关心来源差异。

结合 LangChain 的DocumentLoader接口，理论上可以直接把抓取结果包装成统一的 Document 对象，然后接各种文本分割器、向量存储。这样从抓取到问答，链路上没有一处需要手写解析逻辑，维护成本降了一个量级。

当然，这也意味着你要接受模型推理的延迟。在 RAG 的场景里，增量更新不需要实时，但如果你做的是实时页面监控，那就需要考虑异步任务队列。我的建议是：把抓取和入库拆成异步任务，用 Redis/RabbitMQ 做缓冲，避免阻塞主流程。

6. 聊聊我的使用体会

做技术选型的时候，我很少因为“某个框架火”就去用它，更多是看它能不能解决实际问题。ScrapeGraphAI 给我的最大帮助是：它把网页抓取从“面向代码”变成了“面向需求”。我不再需要为每个网站精心编写选择器，也不用在网站改版时苦哈哈地改代码，交需求的时候说一句“我要什么”就够了。

当然，它不是一个万能工具。大规模抓取、极高性能场景，传统方案依然不可替代；精确到像素级别的页面解析，它也不如专门写正则的脚本稳。但恰恰是在中小规模、数据结构频繁变化、人力有限的场景里，它的价值最大。

如果你正准备用它，我的建议是：先花半小时跑通官方示例，再用一个你自己真实的页面做测试。等你试过 3 到 5 个不同网站后，你基本就能感受到它在什么场景是强项，在什么场景是弱项。

还有一个更实际的小技巧：项目写到一半，可以把抓到的 HTML 保存成本地文件，后续所有调试都用文件源，不重复请求线上页面。既快又省钱，还稳定。等你把提示词调好了，再切回线上 URL 跑最终流程。这个小习惯，能让你的调试效率提升不少。