1.3 与传统爬虫的分界线

1.3 与传统爬虫的分界线

本节摘要：通用搜索引擎爬虫与面向 AI 的采集（Crawl4AI 所代表的流派）共享 HTTP 与 HTML 这些底层技术，却在目标、调度粒度、质量标准三个维度上分道扬镳。分清这条线，才能理解为什么后者要长出浏览器内核、结构化抽取与 Markdown 输出这些"重装备"。

一条分界线是怎么画出来的

时间往回拨二十多年。早期的通用爬虫（搜索引擎蜘蛛）要解决的问题极其明确：在有限带宽里把尽可能多的网页搬回来建索引。于是整个架构围绕"广度与吞吐"进化——礼貌队列按域名分级、去重靠布隆过滤器、解析只提取链接与标题摘要，页面正文是什么质量并不重要，排序算法自会处理。

面向 AI 的采集是另一条演化路径。它的服务对象从"排序算法"换成了"模型训练与检索"，质量标准随之剧变：一条混着推荐位文案的评论，对搜索引擎无害，对情感分析模型是毒药。目标变了，装备就得换——纯 HTTP 拿不到浏览器渲染后的内容，于是真实浏览器内核进场；DOM 不是模型友好的输入格式，于是 Markdown 生成与内容净化进场；"抓回来再说"的粗放流程撑不起字段完整率 98% 的验收线，于是声明式抽取 schema 进场。Crawl4AI 就是把这条路径上的装备打包成框架的典型代表。

三个维度上的差异

空说演化史容易飘，落到可操作的维度上，两条路线的差异集中在三处。

图 1-3 通用爬虫与面向 AI 采集的三维对比

第三行"质量标准"最值得展开。搜索引擎的容错来自它有排序层兜底，而训练管线没有兜底：重复样本会让模型过拟合权重高的表述，噪声文本会污染词表分布。这就是为什么第 3 章要花整整一章讲清洗——那不是加分项，是这类采集的生存底线。

用一段代码看清"解析轻重"的差异

同一个页面，两类爬虫的"处理深度"差别可以用代码直观感受。通用风格只关心链接，面向 AI 风格关心正文形态：

import asyncio
from crawl4ai import AsyncWebCrawler, CrawlerRunConfig, CacheMode
from crawl4ai import JsonCssExtractionStrategy

# 通用风格：拿 HTML，提链接，到此为止
async def general_style(url: str) -> int:
    async with AsyncWebCrawler() as crawler:
        result = await crawler.arun(url, config=CrawlerRunConfig(cache_mode=CacheMode.BYPASS))
        links = result.links.get("internal", [])   # 框架已把页内链接按内外分组
        return len(links)

# 面向AI风格：声明字段 schema，输出结构化记录
schema = {
    "name": "文档条目",
    "baseSelector": "a.doc-link",                  # 每条记录对应一个匹配元素
    "fields": [
        {"name": "title", "selector": "span.title", "type": "text"},
        {"name": "href",  "selector": "a",         "type": "attribute", "attribute": "href"},
    ],
}

async def ai_style(url: str) -> list:
    config = CrawlerRunConfig(
        cache_mode=CacheMode.BYPASS,
        extraction_strategy=JsonCssExtractionStrategy(schema=schema),  # 声明式抽取
    )
    async with AsyncWebCrawler() as crawler:
        result = await crawler.arun(url, config=config)
        import json
        return json.loads(result.extracted_content or "[]")

async def main():
    url = "https://example.com/docs"
    print("链接数:", await general_style(url))    # 输出：链接数: 87
    for row in await ai_style(url)[:2]:
        print(row)                                 # 输出：{'title': '设备手册A', 'href': '/docs/device-a'}

asyncio.run(main())
​

两段代码的对比揭示了分界线的工程含义：左边是"搬运工"，右边是"分拣员"。JsonCssExtractionStrategy 这类声明式抽取器，就是 Crawl4AI 为"字段级质量"长出的器官——schema 写一次，页面改版时只改 schema，不动调度代码。

排错：装备装错了任务单怎么办

分界线不只是理论，排错时它就是诊断表。实践中最常见的翻车，是把两条路线的装备装错了任务单。症状一：用面向 AI 的重装备去铺广度优先的站点普查，浏览器内核一页一页开，半天跑不完一个中等站点——在排班表上表现为吞吐骤降、内存攀升，处置办法是退回纯 HTTP 的通用风格做第一遍发现，只对最终目标页启用 schema 抽取，两段式排班兼顾覆盖与质量。症状二：反着装，用通用风格去抓动态站点，result.links 数出来永远是 0 或残缺，日志里 HTML 只有一堆空骨架 div，说明内容靠脚本渲染，必须换浏览器内核并配 wait_for 等待目标元素出现。第三种最隐蔽：schema 抽取返回空列表——先打印 result.html 确认选择器在渲染后的 DOM 里真实存在，再查 baseSelector 拼写与目标节点是否落在 iframe 里，这三处排查完，九成空结果能定位。

联系比差异更重要

讲完分界线，也得讲回流。两条路径的底层积累是共享的：robots 协议的礼貌传统、URL 规范化与去重技巧、增量抓取的指纹思路，都诞生于搜索引擎时代，面向 AI 的采集直接继承。学这套教程不需要先学搜索引擎爬虫，但遇到调度问题时，去翻一翻那套成熟积累，常常有现成答案。

带走三句话：目标不同（索引 vs 供料），装备不同（吞吐 vs 质量引擎），但底层礼节与去重智慧同源。下一节回到调度室内部，看任务单上的目标刻度与拦路挑战。