做采集这行久了会发现一个怪现象：写请求、处理编码、管理请求头这些活儿，早就有成熟轮子，一两个小时就能搭起来；真正把项目拖垮的，是后面那件事——目标站点改了版，选择器全废，几万条任务跑出来的字段全是空。基于 LLM 的开源爬虫项目，扎堆出现的原因就在这儿：它们不解决"怎么把网页下载下来"，而是解决"怎么知道这一坨 HTML 里哪块是我们要的"。这篇东西我按"替换环节"把这类项目分成五类，逐个拆它们的架构取向、上手路径、真实跑起来的脾气，再把 token 账单、静默失效、字段幻觉这些坑摊开讲。适合已经写过爬虫、被维护成本折磨过，想看看大模型能不能把这块活儿接过去的人；也适合刚接触采集、想知道这条路值不值得走的人。
1. 先搞清楚 LLM 在采集链路里到底顶替了谁
1.1 传统采集的成本大头其实在"适配"
很多人以为爬虫的成本在带宽或者机器上，实际跑过半年以上批量任务的人都知道，钱和人力基本都花在适配和维护上。一个站点从列表页到详情页，往往要写十几条选择器，每条选择器都绑死在某个 class 名或者某个 DOM 层级上。前端换个构建工具，class 名从list-item变成listItem__abc123，你的脚本一声不吭地挂掉，而且不报错——它只是抽不到东西，返回空列表，日志里一切正常。
这类维护工作的特点是：单次修复成本不高，二十几分钟能改完，但频次高、不可预期，而且极度依赖"人还记得这个任务存在"。任务一多，几十个站点各自有一套选择器，维护就变成了体力活。更要命的是长尾站点：一个月只采一次的站、结构极其不规范的老站、同一页面里混着好几种卡片布局的站。为这些站写精确选择器，投入产出比很差；不写吧，数据缺口又摆在那。
大模型进入采集领域，本质上就是来填这个"长尾适配"的坑。它不需要你提前知道 class 叫什么，你只要用自然语言描述"我要这个列表里每条商品的名称、价格、评价数"，它去页面里找。找得准不准另说，但至少你不用为每个站单独写一套规则。
1.2 大模型真正解决的是定位与容错，不是发请求
这里必须把一个认知纠正过来：LLM 在采集链路里不负责网络层，它不解决并发、不解决限速、不解决失败重试。它的价值集中在三个位置。
第一个位置是字段定位。给一段裁剪过的 HTML，让它指出目标字段对应的节点路径或者直接吐出值。这一步替代的是人工写选择器。
第二个位置是结构归一。同一个字段，A 站叫"到手价"，B 站叫"促销价"，C 站写在一张图里。传统做法是每个站写一套映射规则，LLM 的做法是给它一个统一的目标结构，让它自己判断该往哪个字段里填。
第三个位置是流程决策。翻页按钮长什么样、这条记录是不是重复、这个页面是不是被限流了返回了空壳、下一步该点哪里——这些判断传统上要靠一堆启发式规则堆出来，规则一多就互相打架，LLM 在这些模糊判断上表现确实比硬编码规则稳一些。
注意：三个位置里，只有第一个是"必须用 LLM"的，后两个都可以用规则先兜一遍，规则兜不住再上模型。这个顺序搞反了，成本会翻好几倍。
1.3 三种不该上大模型的场景
不是所有采集任务都值得引入模型。我踩过几次之后总结出三种明显不该上的情况。
结构高度稳定、量特别大的任务。比如每天要拉几十万条、页面结构三年没变过的站。这种场景规则解析又快又便宜，一页解析耗时以毫秒计，成本近乎为零。上模型只会把账单和延迟同时拉高，收益接近于零。
字段极少、逻辑极简的任务。只想抓一个标题加一个链接，正则一行就完事。这种活儿交给模型，等于用卡车送一份快递。
对确定性要求极高的任务。模型输出有波动，同样的输入两次可能给出略微不同的结果。如果你的下游系统不能容忍这种波动，或者必须做到逐字段可审计，那就老老实实写规则，规则至少是确定的。
反过来说，什么场景值得上？页面结构多变、站群数量多、字段语义复杂、人工维护跟不上的场景。一句话判断标准：当你每周花在改选择器上的时间超过写业务逻辑的时间，就该考虑这条路了。
2. 五个项目的分野：按"替换环节"分成五类
开源社区里挂着"LLM 爬虫"名头的项目很多，但仔细看架构，它们其实在替换链路里完全不同的位置。搞混这一点，选型必翻车。我按替换环节把它们归成五类，下文用 A 到 E 代指。
2.1 提示驱动解析型：把选择器交给模型去猜
A 类的定位最窄也最清晰：它就是一个"HTML 到结构化数据"的转换器。你喂它一段 HTML 或者一个 URL，再给一段字段描述，它返回 JSON。内部流程通常是：抓页面 → 清洗 DOM（剥掉脚本、样式、注释）→ 按 token 预算切块 → 逐块让模型抽取 → 合并结果 → 做一次 schema 校验。
这类项目的优点是接入成本极低，几十行代码就能跑通，而且不侵入你现有的采集框架——你原来的调度、去重、存储全都不用动，只把最后一步的解析函数换掉。缺点也很明显：它不懂翻页、不懂登录、不懂动态渲染。页面如果是靠前端脚本渲染出来的，它拿到的 HTML 里根本没有数据。
上手这类项目，第一件要做的不是调提示词，而是把 DOM 清洗做好。我见过太多人直接把整页 HTML 塞进去，一个页面十几万字符，token 爆掉不说，模型注意力还被导航栏、页脚、推荐位这些噪音分散，抽出来的东西驴唇不对马嘴。我的做法是先做一遍"正文候选区"筛选：按文本密度排序，只保留密度最高的两三个块，通常能把体积压到原来的十分之一。
2.2 自然语言编排型：一句话生成整条采集流程
B 类走得更远一点。它接收的不是字段描述，而是一句需求，比如"把这个站所有文章的标题、作者、发布时间抓下来，翻完所有分页"，然后它尝试生成一条完整的采集流程——包括从哪进、怎么翻页、抽哪些字段、什么时候停。
这类项目的技术核心是"页面理解 + 动作规划"。它会先把入口页渲染出来，识别出列表区域、分页控件、详情页链接的特征，再生成一套动作序列。听起来很美好，实际用起来你会发现它对页面规整度有要求：列表页结构清晰、分页是标准控件的站，它跑得很好；遇到瀑布流加载、分页靠"加载更多"按钮、详情页需要点击展开的站，它生成的流程经常半路卡住。
我的建议是把它当"流程草稿生成器"用，而不是当"全自动采集器"用。它生成的流程能帮你省掉前期摸索的时间，但生成完必须人工审一遍，把里面的动作序列固化成确定性脚本。指望它无人值守地跑一个月，目前还不现实。
2.3 浏览器智能体型：让模型自己点页面
C 类是五类里最"像人"的：它直接驱动一个无头浏览器，每一步都由模型看当前页面截图或者简化后的 DOM 树，决定下一步点哪、填什么、往哪滚。它的输入输出循环是"观察 → 决策 → 执行 → 再观察"。
这类项目的优势在于覆盖面——理论上人能操作的页面它都能操作，包括那些层层点击才能展开的内容、需要悬停才出现的菜单、需要滚动才加载的列表。代价是速度慢、成本高。每次决策都要一次模型调用，一个页面走十步就是十次调用，遇到复杂交互几十次都打不住。而且它对页面渲染的时序很敏感，元素还没出来它就点，直接超时。
这类项目我建议只用在两个地方：一是样本量小但获取难度高的数据，比如一个月只要几百条、但要绕好几层交互才能拿到的那种；二是用它来"探索"一个新站的结构，摸清路径之后再用 A 类或者规则去批量跑。拿它做主力批量采集，账单会让你怀疑人生。
2.4 模式约束抽取型：先定 schema 再填值
D 类和 A 类看着像，差别在约束强度。A 类是"给描述，自由抽"；D 类是"先定义严格的结构，再往里填"。它会要求你预先声明字段名、类型、是否必填、取值范围，然后在抽取时把这份 schema 作为强约束传下去，输出必须严格匹配。
这种做法的好处是下游极其省心。抽出来的东西直接能入库，不用再做一堆类型转换和空值处理。字段缺失时它会明确返回空而不是瞎猜，这对数据质量监控很关键——你能清晰地统计出"价格字段的空值率从 2% 涨到了 40%"，进而判断页面是不是改版了。
代价是灵活性下降。schema 定错了，抽取结果就是错的；而且页面字段的语义边界模糊时（比如"销量"到底算不算"评价数"），强约束反而会让模型做出错误归类。所以用这类项目，schema 设计要花心思，宁可先粗后细，跑一段时间看数据分布再收紧。
2.5 自适应调度型：模型负责盯异常和翻页
E 类替换的是调度层。它不负责抽字段，负责判断"这一轮跑得对不对"。具体包括：判断当前页面是不是正常的业务页（还是被拦了、还是空壳）、判断分页有没有到头、判断这条记录是不是和上一条重复、判断这次请求该不该重试。
这类项目在长期跑批量任务时价值最大。传统调度器的判断逻辑都是硬编码的：状态码 200 就继续、页面里找不到"下一页"就当结束。实际情况远比这复杂——有些站返回 200 但内容是个提示页，有些站的"下一页"按钮在最后一页依然存在只是变灰了，有些站翻到第三页会跳回第一页。这些情况硬编码规则要写几十条 if，还经常漏。让模型做一次语义判断，几十个 token 就解决了。
2.6 一张表看五种形态的取舍
| 形态 | 替换环节 | 单页成本 | 速度 | 适合场景 | 主要短板 |
|---|---|---|---|---|---|
| A 提示驱动解析 | 解析 | 低 | 中 | 站群多、结构杂、字段中等 | 不处理渲染与交互 |
| B 自然语言编排 | 流程生成 | 一次性较高 | 慢（仅生成阶段） | 新站快速摸底 | 复杂交互易断路，需人工固化 |
| C 浏览器智能体 | 交互执行 | 很高 | 很慢 | 小样本、高难度页面 | 成本与耗时不可控 |
| D 模式约束抽取 | 解析+归一 | 低 | 中 | 数据要直接入库、重质量 | schema 设计成本高 |
| E 自适应调度 | 调度判断 | 极低 | 快 | 长期批量任务的稳定性 | 不产出数据，只做判断 |
这张表建议存下来。选型时先问自己"我到底卡在哪一环"，答案落在解析就选 A 或 D，落在流程就选 B，落在交互就选 C，落在长期跑的稳定性就选 E。绝大多数人的实际痛点在解析和调度这两环，也就是 A、D、E 三个。
3. 逐个体检：架构、上手路径、实测表现
3.1 项目A：解析层的"最后一公里"
A 类项目的代码量通常很小，核心就三件事：DOM 清洗、分块、抽取。我把它的上手路径拆成四步。
第一步是跑通最小闭环。给一个静态页面的 URL，让它抽出三个字段，确认整条链路能通。这一步大多数人十分钟能搞定，因为这类项目通常自带一个命令行入口或者一个极简的调用示例。
第二步是接管 DOM 清洗。默认的清洗逻辑一般是剥掉script、style、noscript标签，但这远远不够。真实页面里噪音的大头是导航、面包屑、侧边栏推荐、页脚版权、弹窗文案。我的做法是加一层启发式过滤：统计每个块级元素的文本长度与链接文本占比，链接占比超过 60% 的块大概率是导航或推荐位，直接丢掉；文本长度小于 30 字符的块也丢掉。这套规则粗糙但有效，实测能砍掉七成以上的无效内容。
第三步是处理长页面。字段在页面不同位置时，整页塞进去会超预算。我的做法是按字段描述先做一次粗定位——比如"价格"这个词在页面哪个区域出现过，把那个区域前后若干节点切出来单独送给模型。这一步用纯字符串匹配就行，不需要模型参与。
第四步是加校验。模型返回的 JSON 必须过一遍类型校验和值域校验。价格字段返回了"面议"、销量字段返回了"1.2万+"，这些都要在入库前转成数值或者置空。
实测下来 A 类项目在字段数 5 到 15 个、页面结构中等复杂的场景下，准确率让我满意。它真正难受的地方是字段语义模糊的时候——一个页面上同时有"原价""现价""会员价""到手价"，你描述里只写了"价格"，它会随机挑一个。这种情况必须在字段描述里把排除项也写清楚。
3.2 项目B：把需求文档当配置文件用
B 类项目的使用体验很像在跟一个实习生对话：你说需求，它给你一份方案，方案能不能用要你自己审。它的典型流程是"给入口 URL + 给需求描述 → 生成动作序列 → 执行并输出结果"。
上手它要准备的东西比 A 类多。你得把需求写清楚，包括：要哪些字段、翻页怎么翻、什么时候停、遇到异常怎么办。写得越含糊，生成的流程越离谱。我一般会写成半结构化的一段话，把边界条件都列上，比如"如果页面出现验证环节，停止并记录 URL"。
它的输出通常是一份可读的动作描述或者一份脚本。我的做法是拿到之后不改脚本，而是照着脚本的逻辑手写一份确定性版本，把里面的模型调用全部去掉。这样既省了前期摸索的时间，又保证了后期跑批量的效率。
这类项目最容易出问题的地方是"停止条件"。它生成的分页逻辑经常是"直到找不到下一页按钮"，而实际页面里最后一页的按钮往往还在，只是不可点。所以拿到流程后第一件事就是给停止条件加硬性上限：最多翻多少页、连续多少页没有新数据就停。这个上限不给，跑飞是迟早的事。
3.3 项目C：跑得最像人，也最贵最慢
C 类项目我建议先做一次成本试算再决定要不要用。一次决策一次调用，一个中等复杂度的详情页走八到十五步很常见。假设单次调用输入 2000 token、输出 200 token，一个页面就是十几次调用的开销。跑一百个页面还行，跑一万个页面账单就不好看了。
它的优势场景很明确：那些必须交互才能拿到内容的页面。比如数据藏在折叠面板里、藏在需要点击切换的标签页里、藏在滚动才加载的列表里。这类页面用 A 类项目拿到的 HTML 里压根没有数据，规则解析更是无从谈起。
用它的时候有几个细节必须处理。第一是等待策略，不能点完立刻截图，要给渲染留时间，最好是等某个标志性元素出现再继续，而不是死等固定秒数。第二是截图分辨率，太低了模型看不清，太高了 token 消耗大，我一般用中等分辨率配合放大局部区域。第三是动作白名单，只允许点击、滚动、输入这几类动作，禁止任何会改变数据状态的操作，避免误触删除、提交之类的东西。
还有一点常被忽略：C 类项目的运行日志极其重要。它每一步的决策都该记下来，出问题时你要能回放"它在第几步看错了什么、点了什么"。没有这份日志，排查基本靠猜。
3.4 项目D：字段可控性最好的一类
D 类项目用起来最像"正经工程"。你得先写一份 schema，把每个字段的名字、类型、约束写清楚，然后它按这份 schema 去抽。写 schema 的过程本身也是梳理需求的过程，很多模糊的地方在写 schema 阶段就会暴露出来。
我一般这样组织 schema：必填字段控制在三到五个，其余全部可选；数值类字段单独标注单位换算规则；枚举类字段把合法取值列全；每个字段加一句简短说明，说明里带上"不要包含什么"。最后这一条特别关键，模型的错误大多来自边界不清，而不是能力不足。
它的输出质量监控也好做。因为是强 schema，每个字段的填充率、类型错误率都能直接统计。我会给每个站维护一份字段健康度报表，某个字段的填充率一周内掉了 20 个百分点，基本可以断定页面改版了，不用等用户反馈。
这类项目让我不太满意的地方是它对嵌套结构的支持。遇到"一个页面里有多个规格、每个规格下有多档价格"这种层级数据，schema 写起来会很啰嗦，模型也容易在层级对应关系上出错。这种场景我宁可用 A 类自由抽取，再自己写代码做层级归并。
3.5 项目E：长期跑批量任务时的"看门人"
E 类项目不产出数据，它做判断。我第一次用它是因为一个跑了半年的任务突然开始产出重复数据——翻页到最后一页之后又跳回第一页，一直循环，一直到任务超时。加了个页数上限能挡住，但治标不治本。后来把"这一页是不是新内容"的判断交给模型，问题就解决了：它对比当前页和上一页的核心内容，判断是否重复，重复就停。
它的接入点一般有三个。页面有效性判断：拿到 HTML 后先判断这是正常业务页还是提示页/空壳页，后者直接进重试队列而不是当成"没有数据"。翻页终止判断：结合当前页内容与历史页做语义比对，避免死循环。重试决策判断：请求失败后，判断这次失败是偶发还是持续，偶发就退避重试，持续就熔断并告警。
这类判断单次消耗的 token 很少，通常几百 token 就够，但收益极大。我的经验是：只要你的任务要连续跑超过一周，就该在调度层加一个语义判断的兜底。它能挡住的那些坑，靠硬编码规则要写很久，而且永远写不全。
4. 把 token 账单摁住的几个实操手段
4.1 先算清一次采集的单价
算账这件事很多人懒得做，结果月底看到账单才慌。算法的框架很固定：单页输入 token 数 × 输入单价 + 单页输出 token 数 × 输出单价，乘以页数。
输入 token 的大头是 HTML。这里有个数量级的直觉要建立：一页普通详情页的原始 HTML 大概在 5 万到 20 万字符，直接送进去显然不现实。经过清洗（剥脚本样式）、正文区筛选、属性裁剪（保留 class 和少量 data 属性，其余全删），通常能压到 3000 到 6000 token。属性裁剪这一步效果最明显，很多页面的 HTML 里一半体积是各种埋点属性和内联样式。
输出 token 相对可控。要求模型只返回 JSON，不解释、不加注释、不加代码块标记，一个 10 字段的记录通常 200 到 400 token 就够。
举个粗算的例子：假设清洗后单页 4000 输入 token、300 输出 token，跑 10 万页，输入侧就是 4 亿 token。按市面上中等规模模型的公开计价，输入百万 token 大致在几元到几十元区间，这个量级的总开销落在几千元档。听着不便宜，但如果你算上人工维护选择器的时间成本，很多时候是划算的。
提示：算完之后做一次"降级测试"。把同样一批页面用规则解析跑一遍，对比模型抽取的结果差异。如果规则能覆盖 80% 的页面，那模型只处理剩下 20%，账单直接砍到五分之一。
4.2 三级降级：规则优先、小模型兜底、大模型只在关键节点
我在所有项目里都推这套三级结构。
第一级是规则。能写选择器的地方尽量写选择器，能正则的地方尽量正则。这一步不花钱、速度快、结果确定。规则只覆盖最规整的那部分页面，覆盖率低没关系。
第二级是小模型。规则抽不到或者抽出来不合校验的页面，走一次小模型的调用。小模型指的是参数规模较小、单价较低的那类，做字段定位这种任务足够用。这一步的成本通常是旗舰模型的几十分之一。
第三级才是大模型。只有前两级都失败的页面才升级到大模型，处理那些结构特别乱、字段特别多、需要跨区域推理的硬骨头。
这套结构的实际分布通常是：规则覆盖六到七成，小模型再吃掉两成多，真正需要大模型的不到一成。总成本比"全量走大模型"低一个数量级，效果差异却很小。
分级判断的逻辑要写清楚。我的做法是给每级设置明确的"失败标准"：必填字段缺失超过阈值算失败、类型校验不通过算失败、数值超出合理区间算失败。三条里中一条就升级。不要用"模型觉得抽得不好"这种模糊标准，会失控。
4.3 缓存、去重与结果校验的三件套
缓存要缓存两层。一层是 HTML 原始内容缓存，按 URL 加时间戳做键，避免同一页面重复抓取；另一层是抽取结果缓存，按"页面内容哈希 + 字段描述哈希"做键。第二层特别值钱：调试提示词的时候同一个页面会被反复抽取几十次，有了这层缓存，调参成本几乎为零。
去重要在入库前做。同一个记录可能因为翻页重叠、列表重排被采到多次。我一般用业务主键（商品 ID、文章链接的规范化路径）做唯一约束，配合内容哈希判断是否真的更新过。注意别只用标题做去重键，标题重复太常见了。
结果校验是最后一道闸。至少要做四件事：类型校验（字符串不能进数值字段）、值域校验（价格不能是负数、日期不能在未来）、完整性校验（必填字段不能为空）、分布校验（抽一批样本看各字段的取值分布是否合理，比如价格中位数突然掉到原来的十分之一，八成是抽错了小数点或者抽到了别的字段）。
代码上大概长这样：
def extract_with_fallback(page_html, schema): # 一级：规则解析 result = rule_parse(page_html, schema) if validate(result, schema): return result, "rule" # 二级：小模型 cleaned = clean_dom(page_html) result = llm_extract(cleaned, schema, model="small") if validate(result, schema): return result, "small_model" # 三级：大模型，强制要求返回证据片段 result = llm_extract(cleaned, schema, model="large", require_evidence=True) if validate(result, schema): return result, "large_model" # 全部失败，入库标记待人工核查，不要丢弃 return mark_for_review(page_html, schema), "failed"注意最后一行：全部失败的时候不要直接丢弃。把原始 HTML 存下来，标记成待核查，这批数据就是你优化规则的原料。我一般每周看一次待核查队列，从中找出新的页面模式，补进规则层。
5. 那些跑坏之后才会知道的事
5.1 结构化输出偶尔"差一口气"
要求模型返回严格 JSON，它大部分时候能听话，但总有那么几个百分点的输出会带点毛病：多一个字前导语、少个闭合括号、字符串里混进未转义的引号。单看概率不高，跑一万页就是几百条解析失败。
处理办法有两层。第一层是解析时做容错，先尝试直接解析，失败则尝试用正则从输出里截取第一个完整的 JSON 对象，再失败则尝试修补常见错误（补括号、去尾部逗号）。第二层是提示词层面做约束，明确要求"只输出 JSON，不要任何解释和代码块标记"，同时在输出参数上开启结构化输出模式，让服务端帮你强制约束格式。
还有个隐蔽的坑：字段值里带换行和特殊字符。模型有时候会在字符串值里塞一个真实换行符，JSON 解析直接报错。这个只能靠在提示词里明确"字符串内不要包含换行，需要分行的地方用分号代替"。
5.2 页面改版不报错，只是数据慢慢变空
这是我在所有坑里栽得最狠的一次。目标站改版，字段的容器换了个层级，模型还能抽出东西，但抽出来的是隔壁的推荐商品价格。整个过程没有任何报错，任务正常跑，数据正常入库，直到下游反馈"这批商品价格全是 9.9"才发现。
这类问题没法靠报错发现，只能靠监控。我现在给每个采集任务都挂三个指标：必填字段空值率、数值字段的中位数、字符串字段的平均长度。三个指标里任何一个在一天内偏离基线超过 20%，就触发告警。空值率涨了多半是选择器失效，中位数突变多半是抽错了字段，平均长度骤降多半是抽到了空字符串或者占位符。
加这套监控的成本很低，一个定时任务加几个聚合查询就够，但它能让你在数据污染下游之前发现问题。
5.3 翻页死循环与重复入库
翻页这块的坑比想象中多。除了前面说的"最后一页按钮还在"，还有几种典型情况：分页参数被忽略（你传 page=5，服务端永远返回第一页）、分页跳转后有重定向回到首页、前端路由变了但 URL 没变导致抓到同一份缓存。这些情况表现出来都是"任务一直在跑，数据一直是那几条"。
三道防线一起上。第一道是硬上限，最大页数、最大运行时长，超了就停。第二道是内容去重，连续 N 页的内容哈希相同就终止。第三道是语义判断，让模型对比当前页和前面几页的核心内容，判断是不是重复。三道里硬上限是必须的，它是最后的安全绳。
5.4 模型会"礼貌地编造"缺失字段
这个坑最阴。页面里明明没有评分，模型为了让输出完整，给你填了个 4.5。页面里没有发布时间，它按内容推测了一个。你不仔细看根本发现不了，因为格式完全正确、数值也在合理范围。
对付这个只有一招：要求返回证据。在提示词里明确要求，每个字段值必须附带原文里的对应片段，找不到就返回空。然后在代码里做校验：有值但没有对应证据片段的，一律置空。这一步会牺牲一点填充率，但换来的是数据可信。
还有个小技巧：把"允许为空"这件事在提示词里强调到位。很多幻觉来源于模型认为"必须有值"，你明确告诉它"找不到就返回 null，返回 null 不会被惩罚"，幻觉率会明显下降。
5.5 请求礼节与边界：别把项目跑成事故
技术上能跑通，不代表可以随便跑。这块的边界必须自己守住。
遵守站点的抓取规则文件。这个文件里写明了哪些路径允许抓、哪些禁止、建议的抓取间隔。技术上绕过它很容易，但那不叫本事，叫给自己找麻烦。
控制请求频率。我的默认配置是单域名并发不超过 2，请求间隔至少 1 秒，遇到响应变慢自动退避。批量任务一律安排在访问低谷时段跑。这些设置会让任务慢一些，但能跑得久。
只采公开数据，不碰个人信息。姓名、联系方式、身份证号这类字段，即使页面上明摆着也不要采。一旦涉及个人信息，问题的性质就变了，跟技术无关。
给自己留一份采集清单。哪个站、采什么字段、什么频率、数据存哪、保留多久，全部记录下来。这份清单在出问题时能帮你快速定位，也是对自己行为的一种约束。
6. 我的组合方案：怎么把它们拼成一条能长期跑的流水线
如果让我从零搭一条能跑半年的采集流水线，我会这样组合。
调度层用 E 类的思路，但判断逻辑自己写：任务队列、并发控制、失败重试、熔断告警这些用成熟组件，只在三个判断点上接模型——页面有效性、翻页终止、重试决策。这三个点加起来，单页增加的 token 消耗不到一百，但能挡掉大部分"任务跑飞"的情况。
解析层用三级降级结构：规则优先，小模型兜底，大模型只在关键节点。schema 用 D 类的强约束写法，必填字段控制在五个以内，每个字段带排除说明。所有输出必须过校验，校验不过的进待核查队列，绝不静默丢弃。
探索层用 B 类。遇到一个新站，先用自然语言编排型项目快速摸一遍结构，生成流程草稿，人工审完之后固化成确定性脚本，再交给调度层批量跑。这一步能把新站的上手时间从半天压到一小时。
交互层用 C 类，但严格限制使用条件。只有那些确实需要点击、滚动才能拿到数据的页面才走这条路，而且必须设页数上限和成本上限。
这套组合跑下来，我的实际体验是：单页成本比全量大模型低一个数量级，维护工作量比纯规则低一大截。真正需要人工介入的地方集中在两处——待核查队列的定期清理，以及新站结构的首轮摸底。
最后分享一个我觉得最值的小习惯：每次解析失败都把原始 HTML 存下来，按站点归档。攒到几十个样本之后，你会发现失败案例高度集中——往往就那么三五种页面模式在反复出问题。针对这几种模式补规则，比漫无目的地调提示词有效得多。我从去年开始做这件事，现在规则层的覆盖率从最初的五成多提到了七成以上，模型调用量省下来的钱够买好几块硬盘了。
