爬虫已死？不，它只是进化了

——从手写 XPath 到 AI 自动化，数据采集正在经历第三次范式迁移

作为一个在爬虫坑里摸爬滚打了快5年的老玩家，我至今还记得第一次写出能跑通的爬虫时的兴奋：几行requests加BeautifulSoup，对着网页F12扒出class名，敲完代码按下运行键，看着终端里哗哗输出的数据，那种"我能掌控整个网页"的快感，简直比喝了冰可乐还爽🥤。

但这种快感就像夏天的冰淇淋，融化速度快得离谱。没过多久我就发现，今天刚写好的爬虫，明天网站一改版就直接罢工；好不容易搞定了登录Cookie，对方反手加了个滑块验证；IP池刚充了钱，转眼就被封了大半……慢慢的，写爬虫的乐趣被无休止的维护工作磨得一干二净。

第一代爬虫：一切都靠"手"

现在回头看，第一代传统爬虫的本质，其实就是用代码把"数据在页面上的位置"精确描述出来。

不得不说，这一代的工具链已经相当成熟了：用requests模拟HTTP请求，用Playwright自动化点击按钮，用XPath精准定位元素，甚至还有Scrapy这种一站式框架帮你搞定调度和去重。但成熟的背后，是一座压得人喘不过气的维护大山：

• 目标网站每次改版，哪怕只是换了个class名，你写的选择器就直接作废，必须对着新页面重新扒结构、写规则——我曾经因为某电商平台一周改三次商品卡片布局，连续熬了三个晚上改代码😩
• 登录状态、Cookie、Session要手动管理，碰上短信验证、滑块验证甚至人脸识别，那简直是噩梦级难度，有时候为了过验证，得额外集成一堆第三方打码服务
• 反爬对抗是一场永无止境的军备竞赛：今天刚换完User-Agent池，明天对方就开始检测浏览器指纹；刚搞定IP代理，对方又加了请求频率限制……永远在被动防守

AI出来之后，我和身边很多爬虫开发者都以为终于解脱了：让GPT帮我写爬虫脚本不就行了？确实，AI能把写代码的效率提升好几倍，以前要半小时写的选择器，现在一句话就能生成。但它解决不了"运行和维护"的核心问题——脚本还是要自己跑，网站还是会改版，反爬还是要自己对抗。AI只是把你从"写代码"的痛苦里解放出来，「用」的成本一点没少。

第二代：把LLM直接塞进爬虫

既然AI这么聪明，那干脆让它自己决策吧——给它看页面截图，让它理解页面内容，自己操作浏览器，自己提取数据。这就是过去一两年火起来的"纯AI爬取"流派，理念听起来特别诱人，仿佛能一键解决所有爬虫难题。

但实际用起来才发现，理想很丰满，现实很骨感，这方案的问题比想象中多得多：

第一个问题是成功率不稳定。LLM本身就存在幻觉，再加上页面加载有时序问题，同样的任务每次执行的结果都可能不一样。比如我用纯AI爬虫爬某论坛帖子，有时候能把评论全抓下来，有时候会漏掉一半的子评论，对于一次性的验证任务还好，但生产环境要求稳定跑、定期跑，这种不确定性根本无法接受。

第二个问题是成本高到离谱。每一步操作都要把DOM结构、截图甚至整个页面内容喂给模型，Token消耗快得惊人。我曾经测试过用纯AI爬取一个复杂的电商商品页面，单次采集的Token成本就超过了1块钱，如果要爬取上万条数据，这个成本能让你直接怀疑人生。

第三个问题比较隐蔽：路径不透明。AI可能为了高效完成任务，直接去调用页面背后的API接口，绕过前端渲染流程，而这个路径用户根本不知道——这恰恰容易触发服务端的反爬检测，甚至可能因为绕过了前端的用户协议，不小心踩到法律边界。

更不用说评论区的子评论展开、"查看更多"按钮点击、多层折叠回复这类动态交互场景，纯AI漏抓的概率相当高，我就遇到过AI把"查看更多"按钮当成广告直接忽略的情况。

第三代在解决什么问题？

如果你仔细梳理这两代爬虫的痛点，会发现它们的核心矛盾非常清晰：

• 第一代：稳定但不灵活，网站改版后维护成本极高
• 第二代：灵活但不稳定，Token成本和不确定性让人头疼

真正的解法，应该是把结构理解和真实环境执行结合起来——既要能适应网站变化，又要保证稳定可靠。最近我在关注一个叫Scrapilot的项目，它的思路就很有意思，核心是两个非常聪明的设计决策：

一、不依赖硬编码选择器，而是用结构相似性对齐算法

不知道你有没有发现，页面上同类型的数据（比如商品卡片、帖子列表、评论块）在DOM结构上往往高度相似。Scrapilot的做法不是让你手写.product-card > .price这种死板的选择器，而是先扫描页面上的结构规律，再叠加AI的语义理解来定位数据。

好处是显而易见的：网站改版之后，只要数据的结构规律还在，算法就能自动重新对齐，不需要人工介入修改代码。我测试过用它爬某新闻网站，对方改版后把新闻标题的class从"title"改成了"news-title"，传统爬虫直接罢工，但Scrapilot居然自动识别出了新的标题位置，数据采集完全没受影响🤯。

二、直接在用户本地的Chrome里跑

这个决策乍一看很普通，但仔细想一下就会发现它的精妙之处：

浏览器指纹、IP地址、User-Agent——全都是你日常在用的真实浏览器的数据，完全不需要额外配置；已登录的Cookie和Session自动继承，连登录这一步都省了；行为层面完全模拟真人操作，比如滚动页面、点击按钮的速度和真人一模一样。

对反爬系统来说，区分真人和爬虫的核心依据就是"这个请求看起来像不像人发出来的"。而在你自己的浏览器里跑任务，本来就是"人发出来的"，从根源上解决了反爬对抗的问题。我用它爬某需要登录的论坛，全程没有触发任何反爬机制，甚至连我自己都分不清这是人工操作还是爬虫在跑。

一些值得关注的细节

除了上面说的核心机制，Scrapilot还有一个我觉得设计非常有前瞻性的东西：Skill + MCP的调度体系。

简单说，你可以把一个采集任务封装成一个Skill，比如"爬取某电商商品价格"、"抓取某论坛热门帖子"，然后通过MCP协议接入OpenClaw调度器，实现定时触发、多步骤工作流、数据自动流转到下游系统（比如数据库、BI工具）。

这个设计背后的逻辑非常重要：数据采集不应该是一个孤立的点，它应该是整个数据流水线的一个环节。以前我们爬完数据还要手动导出、整理，现在可以直接把采集任务和后续的数据分析、存储环节打通，真正实现自动化的数据闭环。

说回行业

爬虫这个领域，其实一直是工程复杂度和业务价值之间博弈的缩影。

第一代爬虫是工程师的游乐场，门槛高但掌控感强，适合技术能力强、能承担维护成本的团队；第二代借AI的东风降低了入门门槛，但把新的不稳定性和高成本引入了系统，更适合一些轻量、一次性的采集任务；而第三代的方向，是在不牺牲可靠性的前提下，把"非技术人也能用"这件事真正做到——以后可能运营同学自己就能配置采集任务，不需要再麻烦开发团队。

当然，第三代方案能不能真正落地，还是要经过大量实际场景的测试。但从目前的思路来看，它确实抓住了前两代的核心痛点，给数据采集领域带来了新的可能性。

如果你在做数据采集相关的工作，或者曾经被反爬折磨得死去活来，不妨关注一下这个方向的进展。也欢迎在评论区聊聊你的实际使用场景——不同场景下各代方案的胜负其实差别很大，比如实时监控类任务更看重稳定性，而一次性的舆情采集可能更适合AI方案。

最后给大家两个行动建议：

• 如果你还在维护传统爬虫，可以尝试引入一些结构识别的工具，降低改版后的维护成本
• 如果想尝试AI爬虫，不要盲目追求纯AI方案，可以看看结合了传统爬虫稳定性和AI灵活性的混合方案

爬虫从来没有死，它只是在不断进化，适应这个越来越复杂的网络世界而已。