企业官网建设流程全解析

上个月接了个工业供应商比价的采集项目，一开始按传统思路做，五个行业采购平台，光CSS选择器就写了三百多行，又是调XPath又是处理动态渲染，联调了一周刚上线没两天，其中一个平台做了前端架构升级，类名全换成了随机哈希串，DOM嵌套结构也改了，采集程序直接报空，又加班改了三天才稳住。

当时就觉得不能再这么下去了，索性把解析层全部重构，换成大模型驱动的语义提取。网络请求、代理调度这些底层还是用原来的框架，但解析部分一行选择器都没写，全用自然语言描述要提取的字段和规则。
结果五个平台只用了一天就全部对接完成，上个月那个平台又改版了一次，我们只在prompt里补了半句规则说明，十分钟就修复上线，全程没碰解析代码。

这段时间深度用下来最大的感受就是：大模型不是给采集工具加了个新功能，而是彻底重构了整个技术范式。原来的核心是「匹配DOM结构」，现在的核心是「理解文本语义」。过去工程师的大部分精力都花在和前端改版、反爬策略斗智斗勇，现在只需要说清楚你要什么数据，剩下的交给大模型做语义识别。

一、传统采集的死局：越维护，成本越高

做过采集的人都懂，这套范式的痛点是骨子里的，不是优化选择器就能解决的。

1. 选择器维护地狱

这是最无解的问题。只要网站前端改版，哪怕只是换个UI框架、改个类名生成规则，CSS选择器和XPath就会批量失效。
尤其是互联网公司的运营页、电商页，一两个月迭代一次是常态。很多项目维护成本比开发成本还高，改bug的时间比写新功能还多。

2. 非结构化数据无解

商品详情、技术参数、用户评论、资讯正文，这些内容没有固定的DOM结构，格式千变万化。写正则吧，变个格式就匹配不上；穷举情况吧，永远有新的格式冒出来。
最后往往是写了几百行规则，覆盖率还是上不去，总有漏网之鱼。

3. 跨站点复用为零

同是电商平台，淘宝和京东的结构天差地别；同是采购网站，每个供应商的页面逻辑都不一样。
传统方案每接一个新站点，就要重新写一套解析规则，几乎没有复用性。站点越多，工作量越大，边际成本根本降不下来。

二、核心架构：三层结构，彻底告别选择器

很多人对大模型采集的理解就是“把HTML丢给大模型返回JSON”，这么做的结果就是成本高、噪声大、准确率低。
真正落地的方案，一定是「预处理降噪 + 语义提取 + 结构化校验」的三层架构，每一层都有明确的分工。

1. 预处理层：砍掉80%无效token

这是整个方案里性价比最高的一步，也是最容易被忽略的一步。
原生HTML里，script脚本、style样式、导航栏、侧边广告、相关推荐、页脚版权，这些和目标数据无关的内容，通常占了页面90%以上的token量。直接丢给大模型，不仅贵，还会干扰提取结果。
预处理的核心就是「降噪」：先通过正文提取算法定位目标区域，再剥离所有冗余属性（class、style、onclick等），只保留标签语义和核心内容（文本、链接、图片地址）。
处理完之后，token量通常能压缩到原来的10%-20%，成本直接砍到十分之一，同时因为排除了无关内容，提取准确率反而会提升。

2. 语义提取层：用自然语言定义规则

这是和传统方案最本质的区别：不用写选择器，而是用「Schema定义 + 自然语言规则」的方式描述需求。
一般配合大模型的结构化输出或者函数调用能力，先定义好输出的JSON结构和字段类型，再用自然语言补充每个字段的提取规则。
举个商品采集的实际例子，核心prompt大概是这样：

你是一个数据提取助手，从下面的HTML页面中提取所有商品信息，严格输出JSON数组，不要任何解释文字。 每个商品对象包含以下字段： - name: 字符串，完整的商品标题，不要省略 - price: 数字类型，当前售价，单位为元，只保留数字，去掉货币符号和千分位 - sales: 数字类型，月销量，格式如"1.2万+"转换为12000，"900+"转换为900 - link: 字符串，商品详情页的完整绝对URL 输出示例： [{"name":"XXX","price":99.9,"sales":1200,"link":"[https://xxx.com/xxx](https://xxx.com/xxx)"}] 页面HTML内容： --- {preprocessed_html} ---

就是这么简单，没有任何选择器，没有任何正则，把需求说清楚，大模型直接返回结构化数据。

3. 校验层：守住数据可用性的底线

大模型不是100%准确的，偶尔会出现格式错误、字段缺失、内容偏差。所以校验层是必不可少的，否则输出的数据没法直接用。
我们一般做三层校验：

• 格式校验：检查是不是合法JSON，必填字段有没有缺失，类型是不是正确。有问题自动重试一次，还不行就标记异常；
• 逻辑校验：比如价格是不是正数、链接是不是合法URL、数值是不是在合理区间，过滤明显错误的数据；
• 一致性校验：对关键数据做交叉验证，比如和历史数据对比，偏差太大就人工复核。
  经过校验之后，输出的数据和传统采集的输出完全一致，下游的数据库、数据分析系统一行都不用改。

三、三个进阶玩法：效率再提一个量级

掌握了基础架构之后，这几个进阶玩法能把大模型的优势发挥到极致。

1. 一套规则适配多个站点

同行业的网站，字段定义都是类似的，但DOM结构千差万别。传统方案每个站写一套选择器，大模型方案同一套prompt就能通用。
比如我们做的供应商比价项目，五个不同的采购平台，基础提取规则完全一样，只需要针对每个平台微调一两句字段描述，准确率都能稳定在90%以上。
适配新站点的时间从原来的2-3天，直接缩短到2-4小时，效率提升一个数量级。

2. 天然免疫DOM层反爬

现在很多网站的前端反爬手段是类名混淆、标签嵌套、插入干扰元素。传统选择器碰到这种直接抓瞎，要花大量时间逆向分析。
但对语义提取来说，这些手段完全失效。只要文本内容和链接在页面里，不管标签怎么乱套、类名怎么随机，大模型都能通过语义识别出目标内容。
当然IP限制、验证码、行为校验这些服务端反爬还是要单独处理，但前端DOM层面的对抗成本直接降为零。

3. 智能链路采集

不用写下一页的选择器，直接告诉大模型“找到页面中‘下一页’对应的链接，返回完整URL”，它就能从各种按钮、文字、图标里准确识别出来。哪怕翻页按钮改了位置、换了样式，只要语义是下一页，就不会错。
甚至可以做更深的自动遍历：告诉大模型“提取页面中所有详情页的链接”，不用写任何匹配规则，自动完成列表到详情的链路采集。

四、成本与精度：最关心的两个问题算透

聊到大模型，大家第一反应都是“贵不贵？准不准？”，我们算笔明白账。

1. 成本：比人工维护便宜太多

很多人只看到token的钱，却忽略了人力成本才是大头。
先算直接成本：预处理之后，普通列表页大概500-1000 token，详情页1000-2000 token。用国产主流模型，每百万token大概5-15块钱。也就是说，采集一万个页面，成本大概在几十块钱。
再算人力成本：传统方案，一个站点开发几千块，改版一次维护又是几千块。站点多、迭代快的话，一年的人力成本几万到几十万。
对于中小规模、多站点、页面迭代快的采集项目，大模型方案的综合成本只有传统方案的1/5甚至更低。

2. 精度：做好三点到90%+

不是随便丢段HTML进去就好用，做好这三个优化，准确率能提升一大截：

• 加示例：在prompt里给1-2个正确的输出样例（Few-shot），准确率能直接提升10%以上，这是成本最低的优化；
• 分块处理：长页面不要一次性丢进去，按内容区块拆分，分别提取再合并，避免大模型遗漏尾部内容；
• 定义明确：每个字段的规则越具体越好，比如“取红色标注的当前价格，不要划线的原价”，不要用模糊的表述。

我们实测的不同场景准确率：

• 电商/采购商品列表：92%-95%
• 新闻资讯正文提取：95%-98%
• 工业产品参数详情：88%-92%

这个精度对于比价、舆情、数据分析这类业务场景，完全够用。

五、踩坑总结：五个最容易犯的错误

这段时间踩了不少坑，总结几个最典型的，大家少走弯路。

1. 别直接丢全量HTML

图省事直接把整个页面HTML传进去，是新手最容易犯的错。不仅token成本高、速度慢，还会把广告、推荐内容当成目标提取，准确率很低。一定要先做预处理降噪。

2. 别转成纯文本提取

把HTML转成纯文本再提取，会丢失链接、图片地址、表格结构这些关键信息。要用简化的HTML，保留a、img、table等语义标签，只去掉冗余属性，兼顾信息量和token成本。

3. 别让大模型做流程控制

翻页、去重、请求调度、异常重试这些流程逻辑，一定要用传统代码实现。大模型只负责内容提取，各司其职，既稳定又便宜。让大模型控制流程，不仅贵，还容易出逻辑错误。

4. 别什么场景都硬上

如果是表格、规整列表这种结构非常稳定的页面，传统选择器的速度、精度、成本都更优。大模型适合结构复杂、多变、非结构化的场景，不要为了用而用。

5. 别踩合规红线

这是底线。无论用什么技术采集，都要遵守目标网站的robots协议，不得爬取涉密数据、公民隐私数据，严格遵守《数据安全法》《网络安全法》，合法采集和使用公开网络数据。

六、实测对比：两种方案的完整数据

我们在工业供应商比价项目中做了完整的对照测试，五个采购平台，每个平台采集1000条商品数据，结果如下：

从数据能很直观地看出：

• 单看采集直接成本，大模型略高一点，但人力成本差了一个数量级；
• 页面迭代越频繁、站点数量越多，大模型方案的优势越明显；
• 结构稳定的大批量采集，传统方案依然有优势；但多变场景下，大模型的效率是碾压级的。

最后说几句

做了快六年的网络数据采集，从正则表达式到CSS选择器，从模拟浏览器到接口逆向，技术工具一直在变，但核心逻辑一直是「匹配结构」。
大模型带来的不是某一个环节的优化，而是底层范式的重构：从「和DOM结构对抗」变成了「和语义内容对话」。

未来的采集工程师，核心竞争力不再是写选择器、写正则、逆向前端的能力，而是设计高质量prompt、优化处理流程、平衡成本与精度的能力。
技术永远在迭代，拥抱变化，才能不被淘汰。

合规提醒：网络数据采集需严格遵守相关法律法规及网站协议，尊重数据版权与隐私保护，合法合规开展技术实践。