让爬虫“会看网页”了：Lightfeed 想用 LLM 和浏览器自动化，重写数据抓取这门苦活

网页抓取这件事，终于有人不想再靠“补丁人生”了

如果你做过爬虫、做过电商情报，或者只是认真折腾过一次公开网页数据采集，大概都经历过那种熟悉的崩溃：昨天还好好的 CSS 选择器，今天页面一改版就全线报废；登录弹窗突然冒出来，分页按钮换了位置；HTML 里夹着一堆无关导航、追踪参数和乱七八糟的脚本，最后喂给模型的文本比有用信息多得多。

Lightfeed 最近在 GitHub 开源的 extractor，想解决的正是这个行业里最不性感、却最折磨人的问题。它是一套基于 TypeScript 的网页数据提取库，核心思路很直接：用 Playwright 负责“看见并操作网页”，再用大模型把页面内容抽成结构化 JSON。你可以用自然语言去描述目标，比如“提取打折商品及原价、现价、链接”，然后把结果约束进 Zod schema 里，交给模型按结构吐出来。

这听上去像是“AI + 爬虫”的又一次排列组合，但我的第一反应不是兴奋，而是警惕。因为过去一年里，市场上已经出现过太多“AI 自动抓网页”的故事：演示视频里行云流水，真到生产环境就满地鸡毛。Lightfeed 这次稍微不一样的地方在于，它没有只讲模型有多聪明，而是把重点放回了工程现实——怎么清洗 HTML、怎么控制 token、怎么修复失败的 JSON、怎么在不同浏览器环境里跑、怎么尽量避开反爬机制。这才是数据采集真正的战场。

它不是一个“更会聊天的爬虫”，而是一条更完整的数据管线

从项目说明看，Lightfeed Extractor 做了几件很务实的事。第一层是浏览器自动化。它支持本地、无服务器和远程浏览器，底层走的是 Playwright，并且内置了反机器人补丁和代理配置。这一段非常关键，因为今天的网页早就不是 2015 年那种“一把 requests 走天下”的时代了。大量站点依赖前端渲染、懒加载、弹窗、埋点和行为检测，没个真正的浏览器上下文，连页面主内容都未必拿得全。

第二层是内容预处理，也就是它口中的“LLM-ready Markdown”。这是我觉得最聪明的一步。大模型不是不能读 HTML，但它读乱 HTML 的效率非常差，像是让一个人从快递箱、说明书和塑料泡沫里找发票。Lightfeed 会把 HTML 转成更适合模型理解的 Markdown，还能只提取主体内容、清理 URL 里的追踪参数、修复相对链接。表面上看是“格式转换”，本质上是在省 token、保精度、降成本。对于真正跑批量任务的人来说，这比模型排行榜上的几分提升更有意义。

第三层则是结构化提取本身。项目支持 OpenAI、Gemini、Anthropic、Ollama 等各种 LangChain 兼容模型，开发者可以把 schema 交给模型，让它以 JSON 模式输出结果。如果输出崩了，还有一层 JSON recovery 去“善后”。这听起来像个小功能，实际上非常像深夜救命绳。做过 LLM 结构化输出的人都知道，最烦的不是模型答错，而是答得“差一点对”——少了个逗号，多嵌一层数组，或者在深层对象里悄悄缺一个字段。能恢复这些半残结果，意味着整个数据管线不会因为一点语法问题直接翻车。

为什么现在这类工具突然变得重要

这不是 Lightfeed 一家的问题，而是整个数据行业的拐点。过去，网页抓取的核心竞争力是“谁更会写规则”。你得熟悉 DOM、XPath、CSS Selector，还得有一支不断维护规则的团队。页面一变，规则就得跟着改。规模一上来，技术债会像野草一样疯长。

大模型的出现，让“规则驱动”第一次有机会转向“语义驱动”。同样是抓一个商品列表，过去你要精准定位 .product-card .price；现在你可以告诉模型，“找出所有商品名、品牌、价格、评分和链接”。这并不意味着传统方法过时了，而是意味着抓取逻辑开始从“页面长什么样”转向“页面表达了什么”。对于新闻聚合、价格监控、竞品追踪、SEO 分析、市场情报这些场景，这种转变非常诱人。

而且，网页本身也越来越像一个会“表演”的界面，而不是静态文档。搜索、翻页、关闭弹窗、选择地区、切换语言，这些动作过去都需要工程师手写流程；现在 Lightfeed 还把自家的 browser-agent 接进来，让你用自然语言命令浏览器完成导航。这一步有点像把“爬虫工程师”拆成了两个角色：一个负责操作网页，一个负责读懂网页。前者像 AI 测试员，后者像 AI 录入员。这个分工，很可能会成为下一代数据自动化产品的标准配置。

但别高兴太早：AI 抓取离“万金油”还差得远

当然，我不觉得这类工具已经解决了网页采集的根问题。它更像是把问题从“规则维护”搬到了“模型可靠性与成本控制”。你不再反复修选择器，却会开始担心模型幻觉、字段漏提、不同模型输出风格不一致，甚至同一页面在不同时间抽取结果略有偏差。对于金融、法律、医疗这类高敏感领域，这种不确定性不是一句“平均准确率不错”就能糊弄过去的。

另外，反爬对抗也不会因为你用了 LLM 就自动失效。网站封禁你的，往往不是你提取 JSON 的方式，而是你的访问行为、IP 信誉、请求指纹和频率模式。Lightfeed 提供 stealth 模式和代理配置，确实能提升可用性，但这场猫鼠游戏不会结束。说白了，AI 只能让爬虫“更像人”，却不能保证网站愿意把门打开。

还有一个更现实的问题：成本。Lightfeed 一直强调 token 效率，这说明他们很清楚，LLM 抽取真正跑到生产环境时，账单会很快把理想主义打回原形。对高频、大规模采集任务来说，最稳妥的策略往往仍然是混合架构：能用规则和传统解析解决的就别上模型，只有在页面复杂、结构多变、人工维护成本过高时，再让 LLM 出场。AI 不是替代一切的魔法，而是应该被派去处理那些“不值得人类天天修补”的脏活。

开源这一步，可能比产品本身更有意思

我反倒觉得，Lightfeed 把这套东西放上 GitHub，是比功能列表更值得关注的一件事。原因很简单：网页数据提取长期都是一门“灰色工程学”，很多公司内部都在做，但很少愿意把最佳实践讲透。因为这里面既有商业壁垒，也有合规边界，还混杂着大量不够优雅但非常实用的技巧。

现在把这套能力拆成开源库，一方面会吸引开发者试验更多场景，比如电商商品、文章摘要、招聘信息、房源、公开目录页；另一方面也会逼着行业更坦诚地面对一个问题：当网页越来越不是给机器看的，人们是不是更需要一层“AI 中介”，把混乱的页面重新翻译成结构化世界？

从竞争格局看，Lightfeed 并不是唯一在做这件事的团队。Firecrawl、Browserbase 加上 AI agent、Apify 生态里的新工具，甚至一些 RPA 厂商，都在往“让模型理解并操作网页”这个方向靠拢。不同之处在于，有人更像云服务，有人更像开发框架，有人偏企业工作流。Lightfeed 当前的优势，是它把“浏览器自动化 + HTML 清洗 + LLM 提取 + JSON 修复”串得比较顺。但未来决定成败的，恐怕不是 demo 漂不漂亮，而是谁能在 10 万个页面、几百种页面模板和一堆奇葩边缘案例里，依然把错误率压住。

这也是我觉得它真正有价值的地方：它没有承诺一个完美的 AI 神话，而是在认真修一条通往生产环境的路。那条路不炫，却很长，也很值钱。对许多企业来说，数据抓取从来不是创新秀场，而是每天都得交作业的基础设施。谁能把基础设施做得更稳，谁就更接近下一波 AI 自动化的真实红利。