做工业数据采集的工程师大概都有过这种经历：凌晨两点线上告警，某个核心站点采集成功率骤降，排查半小时发现只是前端改了个class名——div.product-price变成了div.price-v2，几百行选择器逻辑全线崩盘。

这类维护噩梦，在过去十年里反复上演。从正则到CSS选择器，从XPath到浏览器自动化，每一代技术都在解决上一代的痛点，却又始终跳不出"依赖DOM结构"的底层桎梏。直到大模型把语义理解能力带入这个领域，整个技术栈才真正开始发生范式级的重构。

一、传统采集技术的三代演进与固有瓶颈

工业数据采集技术的发展，本质上是一部"与前端架构对抗"的历史。每一次前端技术革命，都会倒逼采集侧升级。

第一代：正则表达式的蛮荒时代

最早的网页结构简单，标签嵌套少，开发者习惯用正则表达式直接从HTML字符串里抠数据。比如匹配价格：

import re
pattern = r'¥(\d+\.\d{2})'
price = re.search(pattern, html).group(1)

这种方式写起来快，但维护起来是灾难。标签嵌套稍有变化，正则就可能匹配到错误内容甚至完全失效。更致命的是，当页面出现多个同格式数据时，正则几乎无法精准区分上下文。到了AJAX普及、前端开始动态渲染的阶段，正则彻底力不从心。

第二代：CSS选择器与XPath的黄金时代

jQuery的流行让CSS选择器成为行业标准，BeautifulSoup、lxml、PyQuery等库把这套思路带进了采集领域。开发者不再关心字符串匹配，而是通过DOM树结构定位元素：

from bs4 import BeautifulSoup
soup = BeautifulSoup(html, 'lxml')
price = soup.select_one('div.product-info span.price').text

同期XPath凭借更强的轴定位能力，在复杂场景中占据一席之地。这一代技术统治了行业近十年，直到今天仍是很多系统的主力方案。但它有一个天生缺陷：强耦合DOM结构。只要前端改版调整了标签层级、类名或属性，采集逻辑就会断裂。

据不完全统计，中大型采集系统中，约60%的运维工作量都消耗在选择器维护上。电商、资讯类网站平均每3-6个月一次前端改版，意味着采集规则也要跟着重写一遍。

第三代：浏览器自动化的治标之策

单页应用（SPA）普及后，纯HTTP请求拿不到完整数据，Selenium、Playwright、Puppeteer等浏览器自动化工具成为标配。这代技术解决了动态渲染问题，但本质上还是用选择器定位元素，只是从"解析静态HTML"变成了"解析渲染后的DOM"。

from playwright.sync_api import sync_playwright
with sync_playwright() as p:
    browser = p.chromium.launch()
    page = browser.new_page()
    page.goto(url)
    price = page.locator('.product-price').text_content()

浏览器自动化带来了更高的采集成功率，却也引入了新问题：资源消耗大、速度慢、容易被指纹识别拦截。更关键的是，它没有解决选择器脆弱的根本问题——前端一改版，该崩还是崩。

三代技术走下来，行业陷入了一个怪圈：技术越升级，对抗成本越高，但核心的维护痛点始终存在。

二、第四代技术：语义提取的范式革命

大模型普及后，有人提出了一个反常识的思路：为什么一定要告诉机器"数据在哪个标签里"？能不能直接告诉它"我要什么数据"？

这就是语义提取的核心思想——从"位置定位"转向"意图描述"。开发者不再写span.price，而是直接说"提取商品价格"，模型自己去页面里找。

三种主流实现范式

目前行业内的AI语义采集，大致分为三个技术流派，各有适用场景。

范式一：LLM生成选择器，人工校验执行

这是最保守的融合方案，也是多数团队切入AI采集的第一步。把渲染后的HTML片段丢给大模型，让它根据自然语言需求生成CSS/XPath选择器，人工确认后再投入生产。

def generate_selector(html_snippet, field_desc):
    prompt = f"""
    基于以下HTML片段，为「{field_desc}」生成最稳定的CSS选择器。
    要求：优先使用语义化属性，避免自动生成的随机类名。
    HTML片段：{html_snippet}
    只返回选择器字符串，不要解释。
    """
    return llm.call(prompt)

这种方式的好处是不改变原有执行链路，AI只做"辅助写规则"的工作，执行层还是传统的解析器，性能和成本可控。缺点是治标不治本——网站改版后还是要重新生成规则，只是生成速度变快了。

范式二：端到端语义提取，直接输出结构化数据

这是目前最主流的方案，也是真正意义上的范式跃迁。把清洗后的页面内容（HTML/Markdown/纯文本）连同字段Schema一起发给大模型，模型直接返回结构化JSON。

from pydantic import BaseModel

class ProductSchema(BaseModel):
    name: str
    price: float
    rating: float
    review_count: int

result = llm_extract(page_content, ProductSchema)

这种模式下，前端改版几乎不会影响提取结果——只要页面上还显示着价格，不管它放在span还是div里，不管类名叫price还是money，模型都能根据语义识别出来。

但代价也很明显：每次提取都要调用大模型，Token成本和响应延迟比传统方案高出几个数量级。单页面提取成本从几厘钱跳到几分甚至几毛钱，规模化采集时费用会非常惊人。

范式三：LLM生成提取代码，一次生成反复执行

这是介于前两者之间的工程化折中方案。LLM不直接提取数据，而是生成一段可执行的JavaScript或Python提取代码，后续同类页面直接运行代码，不再调用模型。

# 首次调用：生成提取脚本
extract_code = llm_generate_code(page_sample, schema)

# 后续N个页面：直接执行脚本，零模型成本
for page in pages:
    data = execute_extract_code(page, extract_code)

这种思路兼顾了灵活性和成本：新站点只用一个样本就能生成提取逻辑，后续批量采集边际成本趋近于零。当网站改版导致脚本失效时，再喂一个新样本重新生成即可，实现一定程度的"自愈"。

Crawl4AI、llm-scraper-py等开源工具都在往这个方向探索。从工程角度看，这也是目前最适合大规模落地的路线。

三、工程化落地：混合架构与成本控制

理想很丰满，落地很骨感。真正在生产环境用AI做采集，会遇到一堆现实问题：模型贵、速度慢、偶尔抽风、结果不可控。

纯AI提取在现阶段还无法完全替代传统方案。成熟的工程实践，都是走"传统选择器为主，AI语义兜底"的混合架构。

双轨制提取架构

一套稳健的生产级采集系统，通常会设计成三级提取链路：

1. 一级提取：缓存的CSS/XPath选择器，成本最低、速度最快，优先尝试
2. 二级提取：AI生成的提取代码，成本可忽略，成功率高于纯选择器
3. 三级提取：端到端LLM语义提取，成本高但鲁棒性最强，作为最终兜底

当一级提取失败（返回空值或校验不通过），自动降级到二级；二级也失败，再走三级。这样绝大多数请求都走低成本链路，只有少量异常页面才触发AI兜底，整体成本可控。

成本优化的几个关键手段

Token费用是AI采集落地的最大障碍。这里分享几个经过验证的成本控制手段：

第一，最大限度压缩输入文本。 不要把整页HTML丢给模型，先用Readability.js或类似算法提取正文，去掉导航栏、广告、页脚等噪音，通常能减少70%-90%的Token量。再配合标签精简、属性过滤，压缩比例还能进一步提升。

第二，结果缓存与复用。 同一模板的页面，生成一次提取代码后缓存起来，后续所有同类页面复用。这一条就能把AI调用量降低一到两个数量级。

第三，按字段分级。 核心字段走AI保证准确率，次要字段用传统选择器降成本。比如商品标题和价格用AI提取，库存状态和配送信息用选择器，没必要所有字段都上模型。

第四，小模型替代大模型。 简单提取任务用轻量级模型（如GPT-4o Mini、Claude Haiku）就能搞定，没必要上旗舰模型。实测中，结构化提取场景下，小模型准确率往往能达到大模型的90%以上，成本却只有几十分之一。

质量保障体系

大模型有幻觉，提取结果可能凭空捏造字段，也可能格式不对。工程上必须建立完整的校验机制：

• Schema强校验：用Pydantic等工具做类型校验，格式不对直接重试
• 合理性校验：价格不能为负，评分范围0-5，日期不能晚于当前时间
• 一致性校验：同一页面多次提取结果对比，差异过大则标记异常
• 抽样人工审核：按比例抽取结果人工复核，持续监控准确率

四、踩坑实录：那些AI采集的隐形陷阱

我们团队在过去一年多里，把AI语义提取落地到了十几个采集项目中，踩过的坑不少。这里挑几个最典型的说说。

坑一：Token成本失控

初期最容易犯的错误，就是不加节制地把整页HTML塞给模型。有个项目刚上线三天，API账单跑了五位数，吓出一身冷汗。

后来复盘发现，很多页面正文其实只有几千字，但完整HTML有几十万字符。光页面上的内联样式、SVG图标、埋点脚本就占了绝大部分内容，这些对提取毫无价值，却全算Token。

解法：前置HTML清洗流水线——先去脚本去样式，再提取正文区块，最后精简标签属性。处理后输入Token量普遍降到原来的1/10以下。

坑二：页面改版识别滞后

AI提取号称"不怕改版"，但这是有前提的——改版不能改语义。如果网站把"价格"改成"报价"，把"库存"改成"现货状态"，模型大概率还能识别。但如果页面整体布局大变，数据藏到了折叠面板里，或者改成了图片展示，模型一样抓瞎。

更隐蔽的问题是：改版后提取准确率缓慢下降，但不会直接报错，系统以为一切正常，实际上数据质量已经在悄悄劣化。

解法：建立数据质量监控指标。比如提取字段非空率、数值分布异常检测、同站点跨页一致性比对。当指标偏离基线时自动告警，及时介入排查。

坑三：并发与延迟瓶颈

传统选择器提取是微秒级的，LLM提取是秒级的。直接把AI塞进原有同步链路，整个系统吞吐量会暴跌。

解法：异步化+批量处理。把AI提取做成独立的worker队列，和主采集链路解耦。支持批量的模型尽量批量调用，进一步摊平延迟和成本。

坑四：多模态提取的幻觉

有些团队尝试用多模态模型直接截图提取，绕开HTML解析。听起来很美好——就像人眼看网页一样，完全不依赖DOM结构。

但实测下来坑更多。截图里的文字容易识别错，尤其是小字体、艺术字。表格类数据提取准确率惨不忍睹。最坑的是模型会"脑补"截图里没有的信息，你问它价格，它能编一个看起来很合理的数字出来，防不胜防。

现阶段，多模态提取只适合作为补充手段，不能当主力。

五、演进方向与行业终局

站在2026年这个节点回头看，工业数据采集的技术演进其实有一条清晰的主线：不断提升抽象层级，不断靠近人的自然意图。

从正则到选择器，我们从"匹配字符串"升级到了"定位元素"；从选择器到语义提取，我们又从"定位元素"升级到了"理解内容"。每一次升级，开发者需要关心的底层细节都更少，描述需求的方式都更接近自然语言。

接下来的演进方向也很明确：

第一，专用小模型替代通用大模型。 针对网页提取场景训练的专用小模型，体积小、速度快、成本低，准确率不输给通用大模型。这是规模化落地的关键一步。

第二，从单页提取走向站点级自动发现。 现在还是人工指定字段，未来AI可以自动发现站点上的所有数据类型、遍历所有详情页、自动识别分页和列表，真正实现"输入一个域名，输出全站结构化数据"。

第三，采集与知识图谱深度融合。 提取出来的数据不再是孤立的表格，而是自动对齐实体、建立关联，直接汇入企业知识图谱。采集工具从"数据搬运工"变成"知识生产者"。

但无论技术怎么演进，有一点不会变：工程化能力永远比技术选型更重要。再好的AI模型，没有合理的架构设计、成本控制、质量保障，到了生产环境一样跑不起来。选择器时代积累的工程经验——重试、降级、监控、告警、限流、缓存——在AI时代非但没有过时，反而更加重要。

技术工具会换代，工程方法论长青。这大概就是做底层技术的人，最值得欣慰的地方。