还在熬夜改选择器？ScrapeGraphAI入门：说句人话就能自动爬取网页数据

发布时间：2026/10/31 7:05:06
还在熬夜改选择器？ScrapeGraphAI入门：说句人话就能自动爬取网页数据

做爬虫这几年，最耗时间的从来不是写业务逻辑，是维护选择器。前端开发随手改个类名、调一下DOM层级，线上爬虫直接返回空数据。小改小修要半小时，碰到全站UI重构，基本等于重写一遍解析规则。手上同时维护十几个站点的那段时间，每次收到采集告警都头疼，加班改选择器成了家常便饭。

最近把一批改版频繁的资讯站切到了ScrapeGraphAI，彻底省了这部分麻烦——不用写CSS选择器、不用写XPath，只用自然语言说清楚你要什么数据，它自动调用大模型解析页面，直接返回结构化结果。普通的UI改版几乎无感，不用人工跟进修改规则。

今天从环境搭建到实战踩坑完整讲一遍，全是跑了半个月的真实经验，半小时就能跑通第一个「说人话」的爬虫。

一、先搞懂：ScrapeGraphAI到底是什么？

它不是另一个Requests或者BeautifulSoup，是大模型驱动的智能爬虫框架。

传统爬虫的逻辑是「人告诉程序怎么取」：你得精确指定用哪个选择器、取第几个标签、属性是什么，错一个字符就拿不到数据。
而ScrapeGraphAI的逻辑是「人告诉程序取什么」：你只用描述业务需求，比如「提取页面里所有文章的标题和发布时间」，大模型自己去分析页面结构，找到对应内容，返回结构化结果。

相当于把「页面解析、元素定位」这部分最繁琐的工作，全丢给大模型做了。开发者只需要关心业务目标，不用跟DOM结构死磕。

核心能力总结下来四点：

  1. 自然语言驱动：描述需求就能爬，不用写任何解析规则
  2. 结构化输出：支持自定义JSON Schema，强制返回固定字段格式，可直接入库
  3. 内置交互能力：自动翻页、滚动加载、处理JS渲染，不用单独接Playwright
  4. 隐身模式：自带浏览器指纹优化，应对基础反爬站点

二、5分钟环境搭建，避过版本坑

2.1 安装SDK

目前最新是v2版本，网上很多老教程还是v1的写法，API变化很大，别直接抄旧代码踩坑。

pipinstallscrapegraph-py

安装完成后可以pip show scrapegraph-py看版本，建议用1.0以上的v2版本，功能更完整。

2.2 获取API Key

去ScrapeGraphAI官网注册账号，在控制台里拿到SGAI-APIKEY。免费额度足够测试和小批量使用，日常跑几十个页面一天也花不了多少。

安全起见建议配置到环境变量里，命名为SGAI_API_KEY，初始化的时候会自动读取，不用硬编码到代码里。

2.3 初始化客户端

v2版本统一用ScrapeGraphAI主类，老版本的Client已经废弃了，这是最高发的新手坑。

fromscrapegraph_pyimportScrapeGraphAI# 方式1：读取环境变量中的API Key（推荐）sgai=ScrapeGraphAI()# 方式2：代码中直接传入（不推荐生产环境用）# sgai = ScrapeGraphAI(api_key="你的API Key")

初始化没有报错就是环境通了，接下来直接写业务逻辑。

三、第一个实战：单页信息提取，三行代码搞定

先从最简单的单页提取开始，比如爬取某公司官网的基础信息。不用分析页面结构，不用找元素位置，一句话说清需求就行。

if__name__=="__main__":url="[https://example.com/about](https://example.com/about)"prompt="提取这家公司的名称、主营业务、成立时间、总部地址"res=sgai.extract(prompt=prompt,url=url)ifres.status=="success":print("提取结果：")print(res.data.json_data)else:print("提取失败：",res.error)

运行之后几秒就能返回结果，你不用管页面里这些信息在哪个标签里、class叫什么，大模型自己会定位提取。

我第一次跑的时候确实有点惊艳——以前要F12找半天选择器、写解析代码的工作，现在一句话就搞定了。对于临时要抓个页面、快速验证需求的场景，效率提升不是一点半点。

四、进阶：指定Schema，输出标准可入库的JSON

纯自然语言返回的格式不稳定，有时候字段名会变，生产环境用一定要指定Schema，强制输出固定结构的JSON。

比如爬电商商品详情页，要求必须返回商品名称、价格、库存、销量四个字段，类型都定义好：

# 定义输出Schema，标准JSON Schema格式product_schema={"type":"object","properties":{"product_name":{"type":"string","description":"商品完整名称"},"price":{"type":"number","description":"商品当前售价，纯数字，不带货币符号"},"stock":{"type":"integer","description":"库存数量"},"sales_count":{"type":"integer","description":"累计销量"}},"required":["product_name","price"]}# 调用时传入schemares=sgai.extract(prompt="提取商品的基础信息",url="[https://example.com/product/123](https://example.com/product/123)",output_schema=product_schema)

只要Schema写得规范，返回的结果字段和类型基本都是对的，可以直接写入数据库，不用再做格式清洗。

踩坑提醒：字段的description一定要写清楚，不要只写个字段名。描述越明确，大模型提取的准确率越高。尤其是数字、日期这类格式要求严格的字段，说明清楚格式要求，能少很多脏数据。

五、列表页翻页：不用写下一页逻辑，说爬几页就爬几页

这是我觉得最实用的功能。传统爬虫要自己找下一页按钮、写点击逻辑、判断终止条件，在这里只要传个参数，它自己识别分页按钮自动翻页。

比如爬搜索结果的前5页商品列表：

fromscrapegraph_pyimportFetchConfig res=sgai.extract(prompt=""" 提取页面上所有的商品信息，每个商品包含：名称、价格、店铺名称。 注意只提取主列表里的商品，不要侧边推荐和广告位的内容。 """,url="[https://example.com/search?q=](https://example.com/search?q=)蓝牙耳机",output_schema={"type":"array","items":{"type":"object","properties":{"name":{"type":"string"},"price":{"type":"number"},"shop":{"type":"string"}}}},fetch_config=FetchConfig(stealth=True,# 开启隐身模式total_pages=5,# 一共爬5页number_of_scrolls=2# 每页向下滚动2次，加载完整内容))

不用写循环、不用找下一页选择器、不用处理滚动加载，配置几个参数就搞定。普通的分页按钮基本都能准确识别，省了大量交互代码。

注意：特别小众的分页样式、或者用图片做按钮的，可能识别不准。复杂分页场景建议还是自己写交互逻辑更稳，普通业务场景完全够用。

六、隐身模式：应对基础反爬

默认的抓取模式特征比较明显，普通站点还好，带基础反爬的页面很容易被拦截。开启stealth隐身模式后，会自动优化请求头、浏览器指纹，模拟真实用户访问，对付普通反爬足够用。

fetch_config=FetchConfig(stealth=True,wait_until="networkidle"# 等待网络空闲再提取，适合JS渲染多的页面)

当然它不是万能的，Cloudflare高级防护、强风控电商站这类硬骨头，还是扛不住，不要指望靠一个参数就能通吃所有站点。

七、实测下来的优缺点，适合什么场景不适合什么

用了半个多月，优势和短板都很明显，不是所有场景都适用。

优点

  1. 零选择器维护：普通UI改版基本不影响，不用跟着前端后面改规则，运维工作量至少降70%
  2. 上手极快：不用懂HTML、不用会DOM，会说中国话就能写爬虫，新手半小时就能上手
  3. 内置能力全：JS渲染、翻页、滚动、反爬基础优化都自带，不用自己搭浏览器环境
  4. 结构化稳定：指定Schema后输出格式很规整，基本不用二次清洗，能直接对接业务

缺点

  1. 速度偏慢：单页处理要几秒，比传统HTTP爬虫慢一个数量级，不适合大批量采集
  2. 有错误概率：大模型偶尔会提取错字段、幻觉出不存在的数据，关键业务必须加校验
  3. 调用成本：按页面量收费，大规模跑的话，成本比自研爬虫高很多
  4. 强反爬扛不住：只能对付基础防护，高强度反爬站点还是要自己做代理、指纹、验证码方案

最适合的场景

  • 快速原型验证、临时需求，不想花时间写解析规则
  • 改版频繁的站点，维护选择器的人力成本太高
  • 结构混乱的非标准化页面，不好写固定选择器
  • 多站点、小批量的长尾采集需求

不建议用的场景

  • 百万级以上的大规模批量采集，速度和成本都扛不住
  • 对准确率要求100%的核心业务数据，不能容忍任何错误
  • 强风控、高反爬的站点，隐身模式不够用

八、踩了一周的坑，提前帮你避开

坑1：版本不兼容，老教程全是坑

网上大量v1版本的教程，用的是Client类和smartscraper方法，v2版本已经全部重构了，照着写会直接报错。优先看官方最新文档，不要随便搜老代码复制。

坑2：Schema写得太模糊，结果不准

字段只写个名字不写描述，大模型很容易理解偏差。比如「价格」，它可能给你返回带¥符号的字符串，也可能给你返回原价不是现价。描述越详细、格式要求越明确，准确率越高。

坑3：翻页失败，只爬了第一页

两种常见原因：一是分页按钮太特殊，模型识别不到；二是页面加载慢，还没渲染完就开始提取了。可以加wait_for参数多等几秒，或者增加滚动次数。

坑4：额度用完不知道，跑一半停了

免费版和付费版都有日限月限，批量跑之前先查一下剩余额度。不然任务跑一半额度耗尽，数据只拿了一半，非常尴尬。

坑5：完全不校验，脏数据直接入库

不要100%信任返回结果。关键字段一定要加规则校验：数字类型的检查是不是数字，URL检查域名是否匹配，异常数据自动标记重试。小批量无所谓，生产环境必须有校验机制。

最后说几句

ScrapeGraphAI不是来替代传统爬虫的，它解决的是传统爬虫最头疼的「解析规则维护」这个痛点。

对于快速开发、多站点、改版频繁的场景，它能帮你省下大量重复劳动；但对于大规模、高精度的核心业务，传统原生爬虫依然是更稳的选择。技术从来没有高低之分，选最合适的就好。

如果你的工作里也有大量改选择器、维护小站点爬虫的体力活，非常建议花半小时试试它，说不定能帮你少加很多班。

合规提示：无论使用哪种爬虫工具，采集数据请严格遵守《网络安全法》及目标网站的robots协议，仅获取公开允许的内容，不得用于非法商业用途。