1.2 调度室能接的活：应用场景盘点

1.2 调度室能接的活：应用场景盘点

本节摘要：Crawl4AI 的价值要在具体场景里掂量。本节把常见需求归为四类采集形态——单页抽取、站点深度爬取、增量监控、混合管线——并用一张场景矩阵把大模型语料、检索增强、舆情分析、竞品跟踪等任务对号入座，最后完整走一个"企业知识库供料"的小案例。

承接 1.1 的任务单五要素：要素一"目标与用途"决定了任务的采集形态。形态选错，后面所有工程努力都在还债——用深度爬取去做本该增量监控的事，会把目标站点的历史数据反复抓一遍。本节先把形态讲清，1.3 节再画它与传统爬虫的分界线。

先看一张场景矩阵

调度室接到的活五花八门，但落到采集形态上只有四类。矩阵的两个轴：数据的时间属性（快照型还是持续更新型）与页面范围（固定 URL 还是需要沿链接扩展）。

图 1-2 常见应用场景与采集形态对照矩阵

四类形态对工程能力的侧重点不同。单页抽取拼的是解析与抽取（第 2 章 2.3 节的主场）；深度爬取拼的是调度策略与过滤器（2.2 节）；增量监控拼的是去重指纹与周期调度（2.2 与 5.4 节）；混合管线则是把前三种当积木，用编排串起来（5.5 节的复盘案例就是一条混合管线）。

用代码把"需求关键词到形态"的判断固化下来，评审任务单时可以直接调用：

def classify_task(pages_fixed: bool, data_changes: bool) -> str:
    """按两个布尔问题返回采集形态"""
    if pages_fixed and not data_changes:
        return "single_page"     # 单页抽取：一次抓完即交付
    if not pages_fixed and not data_changes:
        return "deep_crawl"      # 深度爬取：沿链接扩展到边界
    if pages_fixed and data_changes:
        return "incremental"     # 增量监控：周期调度加指纹比对
    return "hybrid"              # 混合管线：先发现新页面，再逐页跟踪

# 三份真实需求过一遍
for req, fixed, changes in [
    ("抓取50个商品详情页做价格快照", True, False),
    ("归档某技术社区近三年全部帖子", False, False),
    ("每日跟踪20个政策网站的更新", True, True),
]:
    print(req, "->", classify_task(fixed, changes))
# 输出：
# 抓取50个商品详情页做价格快照 -> single_page
# 归档某技术社区近三年全部帖子 -> deep_crawl
# 每日跟踪20个政策网站的更新 -> incremental
​

AI 侧的四类典型需求

矩阵左边是采集形态，右边站着的则是 AI 侧的需求方。大模型语料构建（预训练补充、领域微调）通常落在深度爬取形态，量大、周期一次性，对清洗流水线压力最大；检索增强（RAG）知识库落在外圈内——页面范围由知识域决定、内容持续更新，是增量监控加定期全量校准的混合；舆情与情感分析对时效敏感，调度周期以小时计；竞品与市场数据则对字段稳定性要求高，页面模板一改版就要重写抽取 schema。

这些需求有个共同点：下游消费者是程序，不是人眼。这也是 Crawl4AI 把 Markdown 输出做默认产出的原因——模型与向量库吃的是干净文本，不是带广告位的 DOM。下面的案例会看到这一点。

一个完整案例：企业知识库供料

背景：某制造业企业的内部问答产品要接入"设备维修知识库"，来源是厂商公开的文档站，约四十个产品线、每线数十篇手册页，厂商不定期更新。任务单要素一写的是"支持工程师按设备型号检索维修步骤"。

操作：第一版方案拍脑袋用了全量深度爬取，每天把整个文档站重抓一遍。三天后厂商侧发来邮件提醒流量异常。复盘后改为混合管线：每周跑一次链接发现（只抓目录页，提取新出现的文档 URL），对新 URL 做内容抽取，已入库 URL 靠内容指纹判断是否更新。抽取直接用 Crawl4AI 的 Markdown 产出：

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

def content_fingerprint(text: str) -> str:
    """内容指纹：正文做归一化后取哈希，用于增量判断"""
    normalized = "".join(text.split())   # 去掉所有空白，避免排版变化误报
    return hashlib.md5(normalized.encode()).hexdigest()[:12]

async def fetch_doc(url: str) -> tuple[str, str]:
    config = CrawlerRunConfig(cache_mode=CacheMode.BYPASS)
    async with AsyncWebCrawler() as crawler:
        result = await crawler.arun(url, config=config)
        body = result.markdown.raw_markdown
        return body, content_fingerprint(body)

body, fp = asyncio.run(fetch_doc("https://example.com/docs/device-a"))
print(len(body))   # 输出：8642（正文长度，随文档而异）
print(fp)          # 输出：3f9c1a02b7d5（12 位指纹，入库时与旧值比对）
​

结果：改造后周请求量降到原来的百分之三，新文档平均两小时内入库，误报更新从每天上百次降到个位数。

解读：这个案例的转折点不在代码，而在把形态从"深度爬取"纠正为"混合管线"。四类形态的判断口诀（会不会变、在不在一个 URL）值得背下来——它省下的是对方向目标的尊重和自己的工程预算。

变式：同样的管线，把指纹换成按章节分段哈希，就能定位"哪一节改了"，适合手册类长文档；把发现层的目录页换成站点的更新日志页，发现成本还能再降一个量级。

什么样的活不要接

三类需求建议在任务单评审时直接劝退或改造：要求绕过登录付费墙的（合规风险，见 1.5 节）；目标是个人社交内容的情感分析但没有匿名化方案的（个人信息保护风险）；要求"全网实时"的（没有搜索引擎级资源，谈不下来）。调度室的口碑来自拒绝不该接的活，而不是什么都接。

收工前核对三件事：场景能否落进四类形态之一；下游消费者是谁、吃什么格式；有没有一条完整的案例链路（发现、抽取、入库）跑通过。三问皆过，这张任务单可以送进第 2 章的引擎车间了。