Scrapy维护者曝AI写爬虫真相：96%开发者不信

96%的开发者不相信AI生成的代码功能正确，但只有48%会在提交前检查。这是Sonar最新调查的数据，也是Adrian Chaves（Scrapy核心维护者、Zyte工程师）最近反复引用的一个数字。

他坐在Zyte的办公室里，对面是刚发布的Web Scraping Copilot——一个让大语言模型（LLM，Large Language Model）直接写爬虫代码的工具。作为维护了Scrapy多年的工程师，Adrian对"氛围编程"（vibe coding，指把代码生成当黑箱使用的开发方式）有复杂的感受。

写代码变快了，但瓶颈转移了

Adrian的第一句话就打破了预期：2026年爬虫开发最难的部分不是写代码，而是读页面。

LLM能秒生成一个看似完整的Spider（Scrapy的爬虫脚本），语法正确、结构工整。但当你让它去解析一个电商网站的商品列表时，问题才开始——页面结构变了怎么办？反爬虫机制触发了怎么识别？动态加载的内容在哪里？

「代码生成是廉价的，」Adrian说，「理解页面结构才是昂贵的。」

这和很多人的直觉相反。大家以为AI会替代爬虫工程师，但Adrian认为替代的是"打字员"那部分工作。真正值钱的判断力——哪个字段是价格、哪个是促销价、分页逻辑藏在哪里——LLM still struggles（仍然 struggle）。

他用了一个类比：给新手司机一辆自动驾驶汽车，他能更快到达目的地，但遇到修路、恶劣天气、导航失效时，没有驾驶经验的人根本不知道问题出在哪。

为什么Scrapy的设计反而更适合AI

这里有个反直觉的发现。Scrapy是2008年为人类开发者设计的框架，模块化、管道清晰、扩展点明确。Adrian发现这些"老派"设计特质，让LLM生成的代码质量反而更高。

框架的约束成了护栏。当LLM知道必须输出一个Item Pipeline、必须继承Spider类、必须处理Request/Response对象时，它的幻觉空间被压缩了。相比之下，让LLM从零写一段自由格式的requests+BeautifulSoup脚本，输出更不可预测。

「好的设计在半路迎接未来，」这是Adrian的原话。

他解释：Scrapy的组件化不是为了AI准备的，但恰好匹配了LLM的上下文窗口限制——你可以分模块让AI生成，再组装。Spider负责抓取逻辑，Pipeline负责清洗，Exporter负责输出，每个部分的职责边界清晰，降低了AI的犯错概率。

这不是说Scrapy比新框架"AI-native"，而是说经过时间检验的抽象层，对人和机器都是友好的。

AI真正帮上忙的三个场景

Adrian没有全盘否定AI的价值。他列出了三个LLM确实能提升效率的具体环节：

第一，样板代码。Cookie处理、User-Agent轮换、重试逻辑——这些每个Spider都要写、但毫无创造性的代码，AI生成又快又准。

第二，XPath/CSS选择器的初稿。让AI看一段HTML片段，猜出提取标题、价格、库存的选择器，准确率够高。工程师再微调，比从零写快得多。

第三，错误解释的翻译官。当Scrapy抛出Twisted异步异常或编码错误时，把Traceback扔给AI，它能用自然语言解释"大概是什么问题"，省下去Stack Overflow翻帖的时间。

但Adrian强调了一个前提：这些帮助都建立在开发者懂Scrapy的基础上。如果你不知道Pipeline是什么，AI生成的代码出了问题，你连调试入口都找不到。

「氛围编程的危险在于，它让你跳过理解的过程，直接获得答案。」

Zyte Copilot的实验与妥协

作为Zyte的员工，Adrian参与了Web Scraping Copilot的开发。他描述了一个内部争论：要不要让Copilot完全隐藏Scrapy的底层细节？

产品团队倾向于"一键生成，用户不用懂代码"。Adrian坚持保留"查看生成的Spider代码"选项，甚至鼓励用户修改。他的理由是：爬虫是对抗性场景，目标网站随时会变，没有代码可见性就没有修复能力。

最终产品走了中间路线。Copilot生成代码，但代码可编辑、可导出为标准Scrapy项目。Adrian把这比作"带手动模式的自动驾驶"——日常用自动，紧急情况切手动。

这个设计决策背后是对行业现实的认知。Zyte的客户里，既有需要快速原型的小团队，也有维护上千个Spider的企业。前者可能真的不在乎代码，后者必须把生成结果纳入现有CI/CD流程，可审计、可回滚。

「没有一种交互模式能同时满足这两种需求，」Adrian承认，「所以我们做了分层。」

反爬虫军备竞赛中的变量

采访的后半段转向了更阴暗的话题：AI生成爬虫对反爬虫生态的影响。

Adrian的观察是，LLM降低了写"能跑起来"的爬虫的门槛，但没有降低写"能长期稳定跑"的爬虫的门槛。结果是更多半吊子爬虫涌入，触发更激进的反爬策略，最终伤害的是整个生态。

他举了一个例子：某旅游网站最近升级了反爬，不是针对专业爬虫团队，而是针对大量AI生成的、行为特征高度相似的脚本——相同的请求间隔、相同的Header组合、相同的鼠标轨迹模拟（如果用了无头浏览器）。

「当生成成本趋近于零，模仿成本也趋近于零，」Adrian说，「防御方反而更容易识别模式。」

这对认真做数据业务的公司是坏消息。他们需要更复杂的指纹随机化、更真实的浏览器行为模拟，而这些恰恰是目前LLM不擅长的领域——不是生成代码，而是理解"为什么这段代码能骗过检测"。

维护者的长期赌注

采访结束前，Adrian谈到了Scrapy项目的未来规划。一个关键方向是增强与AI工具的互操作性：更好的结构化输出格式、更清晰的元数据暴露、让LLM更容易"理解"一个Spider在做什么。

但他反对另一个极端：把Scrapy本身变成"AI-native"框架，用自然语言替代代码作为核心接口。

「代码是精确的，自然语言是模糊的。在对抗性场景里，模糊是致命的。」

Adrian的赌注是：未来五年，爬虫开发的主流形态不是"说话就能爬"，而是"AI辅助的专业开发"。工程师的核心竞争力从"记住API细节"转向"判断页面结构、设计反爬策略、调试复杂问题"。

Scrapy的角色，是成为这个过渡期的基础设施——既拥抱AI工具，又不放弃对代码质量的坚持。

采访原文发布在Zyte博客，Adrian在文末留了一个问题给读者：你现在在爬虫工作流里用AI做什么，又在哪撞了墙？