解析规则交给 AI，是效率提升还是系统隐患？

在过去一年里，一个越来越常见的声音开始出现在数据圈：

"解析规则这一步，其实可以交给大模型。"

理由听起来很诱人：

HTML 结构复杂、页面频繁改版、人工维护 XPath 成本高，而大模型"看一眼页面就能写规则"。

但工程经验告诉我们一句老话：
凡是感觉"省事"的地方，往往藏着系统性风险。

这篇文章不讨论立场，只做一件事：
用一组可复现的 A/B 实验，对比「人工解析规则」和「大模型生成解析规则」在真实爬虫场景中的表现。

一、实验问题定义

我们要回答的不是"能不能用"，而是三个更工程化的问题：

在真实页面环境下，大模型生成的解析规则成功率如何？
当页面出现轻微结构变化时，哪一方更稳定？
在代理 IP、多地区页面差异下，规则是否会发生漂移？

二、实验场景说明

业务背景

假设我们在做一个内容聚合服务，需要采集资讯类网页的三个字段：

标题
正文
发布时间

页面特点如下：

页面由服务端渲染
存在广告、推荐模块
不同地区访问返回的 HTML 存在细微差异

这是一个非常典型、但并不极端的爬虫场景。

三、A/B 两组方案定义

A 组：人工编写解析规则

特点：

由工程师手动分析 DOM
使用稳定层级 XPath
明确字段边界
可解释、可调试

B 组：大模型生成解析规则

流程：

抓取完整 HTML
将 HTML 片段 + 字段描述交给大模型
由大模型输出 XPath / CSS Selector
程序直接使用该规则解析

这是目前很多"AI + 爬虫"方案真实采用的模式。

四、实验环境与代理配置

为了避免"本地页面过于干净"的问题，实验中所有请求都通过代理 IP 发起，确保：

页面为真实线上版本
触发地区差异
包含更多不确定性因素

下面是统一使用的请求代码示例。

python 复制代码

import requests

proxies = {
    "http": "http://用户名:密码@:proxy.16yun.cn:3100",
    "https": "http://用户名:密码@proxy.16yun.cn:3100"
}

headers = {
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)",
}

def fetch_html(url):
    response = requests.get(
        url,
        headers=headers,
        proxies=proxies,
        timeout=10
    )
    response.raise_for_status()
    return response.text

说明：

代理IP使用亿牛云爬虫代理
用户名、密码、域名、端口需替换为实际配置
每次请求随机更换 IP，模拟真实访问

五、解析实现对比

A 组：人工解析代码

python 复制代码

from lxml import etree

def parse_by_human(html):
    tree = etree.HTML(html)

    title = tree.xpath("//h1[@class='article-title']/text()")
    content = tree.xpath("//div[@class='article-content']//p/text()")
    publish_time = tree.xpath("//span[@class='publish-time']/text()")

    return {
        "title": title[0] if title else None,
        "content": "\n".join(content).strip(),
        "publish_time": publish_time[0] if publish_time else None
    }

特点非常明显：

XPath 较长
明确避开广告区域
每一步都可人工验证

B 组：大模型生成解析规则（示意）

假设大模型返回的结果如下：

json 复制代码

{
  "title": "//h1/text()",
  "content": "//div[contains(@class,'content')]//text()",
  "publish_time": "//time/text()"
}

解析代码如下：

python 复制代码

def parse_by_llm(html, rules):
    tree = etree.HTML(html)

    def extract(rule):
        result = tree.xpath(rule)
        return result[0].strip() if result else None

    return {
        "title": extract(rules["title"]),
        "content": extract(rules["content"]),
        "publish_time": extract(rules["publish_time"])
    }

从代码角度看，B 组非常"优雅"。

六、实验结果统计

我们对同一批 URL 进行 200 次请求，统计结果如下（文字描述）：

首次成功率
- A 组：约 97%
- B 组：约 92%
页面结构轻微调整后
- A 组：成功率下降到约 90%
- B 组：成功率下降到约 65%
多地区代理访问
- A 组：字段偶发为空，但结构稳定
- B 组：正文字段明显掺杂推荐内容、版权信息

七、问题出在哪里

通过失败样本回放，我们发现几个非常关键的现象。

1. 大模型倾向于"语义正确，而非结构正确"

它更容易选择：

最短 XPath
最宽泛的 class 匹配
表面看起来"像正文"的区域

但工程上，最像正文的区域，往往不是最稳定的区域。

2. 代理IP放大了规则不稳定性

不同 IP 访问返回的 HTML 中：

广告模块顺序不同
推荐内容位置变化
A/B 测试标签不同

人工规则通常会主动规避这些区域，而大模型并不知道哪些是"危险区域"。

3. 错误往往是"静默的"

B 组最危险的一点不是报错，而是：

能解析
有内容
但内容是错的

这类错误如果没有人工抽检，很可能直接进入数据仓库。

八、实验结论

通过这次 A/B 对抗实验，我们得到一个非常清晰的工程结论：

大模型适合做"解析规则的候选生成器"
不适合直接成为"生产解析规则的唯一来源"
关键字段的解析，必须是确定性、可解释的

一句话总结：

大模型可以帮你"想规则"，但不能替你"承担规则失效的后果"。

九、一个更稳妥的落地建议

在真实项目中，更推荐的组合方式是：

大模型负责：
- 新站点初始规则生成
- 页面结构分析建议
人工负责：
- 规则确认
- 关键字段兜底
系统负责：
- 失败率监控
- 代理 IP 场景回放

这不是反对 AI，而是让 AI 放在它最擅长的位置。