1.1 任务单与范畴：Crawl4AI 的定义

1.1 任务单与范畴：Crawl4AI 的定义

本节摘要：Crawl4AI 是一个为 AI 应用供料的开源爬取框架，范畴是"把网络上的原始页面变成模型可直接使用的干净文本与结构化数据"。本节用调度室的第一张任务单来锚定它的定义：任务、字段、量级频率、合规、验收五要素齐了，采集才算开工。

从一个含糊的需求说起

"帮我抓点电商评论，要能训练情感分析模型。"——这是产品同学常挂在嘴边的一句话。它含糊，但不是废话：它至少暴露了用途（训练情感分析模型）和大致来源（电商评论）。调度室要做的第一件事，就是把这句话翻译成任务单。含糊的需求直接交给脚本，结果通常是抓回一堆混杂着广告、导航、推荐位的页面，模型吃了直摇头。

Crawl4AI 的定义要从这个翻译工作说起。它是开源社区维护的爬取框架，基于 Playwright 驱动真实浏览器内核，专门面向 AI 场景做了三件事：把页面整理成对大模型友好的 Markdown；用声明式 schema 做结构化抽取；把缓存、会话、深度爬取这些工程件内置成配置项。一句话概括它的范畴：从"拿到 HTML"到"拿到模型能用的数据"之间的全部脏活，它都想接。

注意范畴的另一半——它不做什么。Crawl4AI 不替你决定抓什么（任务定义是你的事），不替你判断能不能抓（合规是你的事），也不替你训练模型（下游是你的事）。框架的边界划得清楚，工程责任才分得清楚。

任务单五要素

我们把这节的核心工具——任务单——拆开看。五要素缺一不可，且每个要素都在向后约束一个工程环节。

图 1-1 抓取任务单五要素及其约束的下游环节

五要素写成代码，就是一张可以被调度室"受理"的任务单。用 dataclass 而不是字典，是为了让缺项在评审时一眼可见：

from dataclasses import dataclass, field

@dataclass
class CrawlTask:
    """抓取任务单：调度室受理的最小单位"""
    name: str                          # 任务名，如 电商评论情感语料
    purpose: str                       # 用途：训练/评估/检索增强，决定数据粒度
    fields: dict                       # 字段 schema：{"content": "评论正文", "rating": "评分"}
    scale: str                         # 量级与频率：如 5万条 / 每日增量 2000
    compliance: list = field(default_factory=list)  # 合规约束清单
    acceptance: str = "字段完整率不低于98%"          # 验收标准

task = CrawlTask(
    name="电商评论情感语料",
    purpose="微调情感分析模型",
    fields={"content": "评论文本", "rating": "1至5星", "sku": "商品编号"},
    scale="5万条，3站合并，日增量不超2000",
    compliance=["遵守robots协议", "匿名化用户昵称", "请求间隔不低于2秒"],
)
print(task.name)        # 输出：电商评论情感语料
print(len(task.fields)) # 输出：3
​

拿到任务单之后，用 Crawl4AI 完成最小的一次"受理回执"——抓一个页面并检查产出形态。安装与配置细节留给第 2 章，这里先看它交回什么：

import asyncio
from crawl4ai import AsyncWebCrawler, CrawlerRunConfig, CacheMode

async def main():
    # 最小任务：抓取单页，输出模型友好的 Markdown
    config = CrawlerRunConfig(cache_mode=CacheMode.BYPASS)  # 绕过缓存，保证拿到新内容
    async with AsyncWebCrawler() as crawler:                # 异步上下文管理浏览器生命周期
        result = await crawler.arun("https://example.com", config=config)
        md = result.markdown.raw_markdown                   # 页面整理后的 Markdown 文本
        print(type(result).__name__)                        # 输出：CrawlResultContainer 或 CrawlResult（随版本）
        print(len(md))                                      # 输出：约 1200（页面不同而异）
        print(md[:80])                                      # 输出：Example Domain 的正文前 80 字符

asyncio.run(main())
​

注意第二段代码里没有任何选择器——这就是 Crawl4AI 与传统脚本的第一处分野：默认产出就是"可读文本"，而不是一堆等待清洗的 HTML 标签。

范畴的两条边界线

边界一：Crawl4AI 不是数据集。它产出的是原始语料，距离"可以训练的数据集"还差第 3 章的整条流水线：清洗、去重、标注。把它当数据集用，等于把矿石当钢水。

边界二：Crawl4AI 不是合规护身符。框架提供浏览器模拟、代理、频控这些技术手段，但"该不该抓这个站点"的判断责任始终在人。技术能力与合规纪律的关系，1.5 节展开。

常见坑：拿到需求就先写选择器。字段 schema 没定稿，解析代码写了也是返工——上游一改版，任务单五要素里只有"字段"是天天被推翻的那个，先和下游模型同学对齐它。

关键直觉：任务单越具体，调度室成本越低。"抓点评论"和"三站各取两万条、含星级与时间戳、昵称脱敏、字段完整率 98%"，后者的工程报价可能只有前者的一半——因为不确定性被提前消掉了。