1. 先想清楚：LLM 到底插在采集链路的哪一段
很多朋友一听到"基于 LLM 的开源爬虫项目"，第一反应是让大模型自己去上网、自己点、自己翻页，然后数据就哗哗地流出来。我踩过的坑告诉你，这套想象在真实项目里几乎跑不通，成本高、速度慢、稳定性差，跑一百个页面能错三十个。所以在动手挑项目之前，得先把"LLM 在这条链路上到底负责哪一段"这个问题想透，否则你选出来的工具大概率是玩具，不是生产工具。
我的经验是把一次采集拆成五段：发现入口（找 URL）、获取页面（发请求、渲染、绕过动态加载）、清洗正文（去掉导航广告）、结构化抽取（把文本变成字段）、质量校验（判断这条数据能不能入库）。传统爬虫在第二段和第三段非常成熟，全是确定性代码，跑一万次结果一样；而在第四段最头疼，因为每个站点的 HTML 结构都不一样，写死选择器的脚本，站点一改版就得返工。LLM 真正的价值落点在第四段，以及第五段的"模糊判断"，还有就是第一段和第二段里那些需要"看情况决定下一步"的决策。
注意：任何声称"全流程都交给模型"的方案，在日常采集里都不可取。确定性的事情交给代码，模糊的事情交给模型，这条线划不清楚，项目一定烂尾。
1.1 传统采集在真实业务里到底卡在哪
不用模型的老办法，无非三种。第一种是硬编码选择器，用 CSS 或 XPath 定位元素，写起来快，但维护成本高得离谱，我手上一个二十来个站点的采集任务，平均每月有六到八处因为页面改版而失效。第二种是配置化模板，把选择器抽到配置文件里，改版时改配置不改代码，缓解了一点，但配置本身就是人力开销，而且每接一个新站，仍然要人肉去 F12 抠结构。第三种是用正文提取算法做通用清洗，再用正则去捞字段，这类方案对"标题、时间、正文"这种规整字段还行，一旦要抽"薪资范围、公司规模、融资阶段"这类语义字段，正则就彻底崩溃。
真正卡人的地方不是技术难度，而是长尾。二十个站点能靠人力硬啃，两千个站点就必须靠自动化，而自动化的瓶颈恰恰在"每个站点的结构都不一样"这件事上。LLM 擅长什么？擅长在没见过的情况下做语义判断。给它一段 HTML 或者一段清洗后的文本，问它"这里面哪一段是发布时间"，它大概率能给你答对，哪怕这个站它从来没见过。这就是它能顶上去的位置。
1.2 模型在采集链路里的四个合理落点
第一个落点是抽取规则生成。让模型看着页面的 HTML 片段，输出一条 XPath 或者 CSS 选择器，人审一遍确认没问题，然后这条规则就固化下来跑一个月。这种做法把"一次性用模型"和"长期用代码跑"结合了起来，成本极低，稳定性极好，我个人最推荐这一种，尤其适合站点数量中等、页面结构相对稳定的场景。
第二个落点是直接语义抽取。把清洗后的正文丢给模型，要求它按 JSON Schema 输出字段。上手最快，代码量最少，代价是每个页面都要花 token，量大以后成本是硬约束，而且输出存在格式漂移的风险，必须配校验和重试。
第三个落点是决策与规划。比如列表页要翻多少页、详情页要不要点"展开全文"、某个链接算不算目标实体。这类判断传统代码也能写，但要写一堆启发式规则，用模型做一层判断反而更省人力，代价是延迟变高。
第四个落点是数据质检。抽出来的字段是不是空、日期格式对不对、金额单位是"万"还是"元"、地址有没有被截断，这些用规则能查一部分，剩下的模糊判断交给模型打分，把可疑条目打回去人工复核，能省掉大量肉眼扫表的时间。
1.3 哪些场景压根不该上模型
我见过不少人上来就想用模型做全站抓取，结果跑到一半被账单劝退。以下几种情况我建议直接放弃模型方案：页面结构高度统一、字段少于五个的站点，老老实实写选择器，一个站点半小时搞定，用模型纯属自找麻烦；需要百万级页面采集的项目，除非你能接受先做规则生成再离线跑，否则 token 成本会远超你的计算；还有强实时的场景，比如要求五百毫秒内返回结果，模型那一轮推理延迟就超标了。
反过来，最适合上模型的是这些情况：站点数量大但每个站点量不大（长尾特征明显）；字段语义复杂，需要理解上下文才能判断（比如从一段招聘描述里判断"是否接受应届"）；页面结构频繁变动、维护人力跟不上；以及历史数据已经堆积了一堆脏数据，需要回头做一轮清洗和补齐。这四种场景，模型带来的收益能明显盖过成本。
2. 五个项目的定位差异与选型方法
社区里被反复提到的"基于 LLM 的爬虫项目"，粗略归类其实就这五种形态，我用代称来说，重点是拆解它们各自解决哪一段问题，你去对照着找同类方案就行，不必纠结具体是哪个仓库。因为这五个方向在近两年被反复实现，同方向的实现思路高度相似，理解了形态，你换哪个具体库都是照着同一套逻辑用。
| 形态 | 核心做法 | 上手难度 | 单页成本 | 稳定性 | 适合谁 |
|---|---|---|---|---|---|
| 抽取型采集器 | 清洗正文后交给模型按 Schema 抽字段 | 低 | 中 | 中 | 快速验证、字段语义复杂 |
| 规则生成型 | 模型看 HTML 输出选择器，规则固化成代码 | 中 | 极低（一次性） | 高 | 站点数量中等、长期维护 |
| 浏览器操作型 | 模型做规划，调用点击、滚动、翻页工具 | 高 | 高 | 低 | 强交互页面、流程式操作 |
| 视觉理解型 | 截图 + 视觉模型定位并抽取 | 中 | 高 | 中 | 反抓取严格、DOM 混乱 |
| 管道框架型 | 分块、抽取、校验、重试组成流水线 | 中 | 中 | 高 | 生产环境、批量任务 |
2.1 抽取型：最短路径把文本变成字段
这类项目的定位非常清晰：你给我一个页面，我负责把字段抽出来。内部流程通常是"抓取 → 正文清洗 → 分块 → 提示词组装 → 模型调用 → JSON 解析 → 返回"。它的代码结构往往很薄，一个入口函数加一个提示词模板，剩下的都交给模型。上手成本极低，半小时能跑通第一个 demo，这也是它传播最广的原因。
它的优势是通用性。同一条提示词，换十个结构完全不同的站点，通常七八个能直接出结果。劣势也很明显：每个页面都要付一次推理费用，量大以后账单很吓人；而且模型输出不是强约束的，偶尔会多写一句解释、少一个大括号、把数字写成字符串，必须做容错。我一般会在这类项目外面再包一层 Pydantic 校验，校验不过就打回重试，重试两次还失败就落库标记待人工处理，这套组合能把有效率从七八成拉到九成五以上。
2.2 规则生成型：一次性烧钱换长期稳定
这类方案我感觉被低估了。它的思路是：先用模型分析页面的 DOM 结构，让它输出"标题在哪个选择器、价格在哪个选择器"，人工确认后把这些选择器写进配置文件，之后就跑纯代码的采集，不再调用模型。整个过程的模型调用只发生在"新站接入"这一步，一个站点调个三五次，成本可以忽略。
它的价值在于把不确定的推理，转换成确定的规则。规则一旦固化，速度是毫秒级的，成本几乎为零，而且出问题容易定位——页面改版了，选择器取不到值，报错很明确，改一条配置就行。代价是它对页面结构的依赖仍然存在，只是把"每次都要人写选择器"变成了"模型帮你写第一版"。我现在的做法是：新站接入用这套跑一遍生成规则，之后加一个定时巡检，每天抽几个页面验证字段非空率，一旦非空率掉下来就报警，人工介入重新生成。这套机制维护两百个站点的采集任务，我一个人的精力是够用的。
2.3 浏览器操作型：能力上限高，落地难度也高
这类项目背后的模型要做的不是抽取，而是决策：当前页面上有哪些可交互元素、下一步该点哪个、要不要滚动、要不要翻页、什么时候算采集完成。实现上一般是这样：把页面的可交互元素（按钮、链接、输入框）序列化成一段结构化文本给模型，模型返回一个动作，执行后再把新状态喂回去，如此循环。
它解决的是传统爬虫最难啃的那类页面：必须登录、必须点开筛选、必须点"加载更多"才能看到数据、必须走多步表单。传统方案也能做，但要为每个站点写一套流程脚本。这类项目用通用决策替代了专用脚本，理论上一个方案通吃。
但实测下来，我对这类方案的评价是"演示惊艳，生产谨慎"。原因有三个：每走一步都要调一次模型，一个页面走十步就是十次推理，延迟和成本都堆得很高；模型的动作选择存在不确定性，同一个页面两次跑出不同路径，难以复现问题；页面元素一多，序列化文本会变得非常长，很容易超出上下文限制，必须做元素筛选，而筛选逻辑本身又需要调优。
2.4 视觉理解型：绕过 DOM 的另一条路
这类项目的思路是：不解析 HTML，直接截图，交给视觉模型去识别"这一块是价格、那一块是标题"。它最吸引人的点在于对页面结构的完全无视，甚至能处理用图片渲染文字的站点。
我对它的定位是"补充手段"而不是"主力方案"。视觉模型的单次调用成本比纯文本高不少，一张截图往往要按千级 token 计费；而且它输出的坐标和文字存在偏差，对于十个以上字段的复杂页面，准确率会明显下降。我一般在两种情况下会用它：一是页面关键数据以图片形式呈现，文本抽取完全无从下手；二是纯文本抽取连续失败，需要交叉验证到底是我抽错了还是页面本身有问题。
2.5 管道框架型：最像生产系统的那个
最后一类是工程化程度最高的：它不强调"让模型做多少事"，而是强调"整条流水线怎么组织"。典型结构包括抓取层、清洗层、分块层、抽取层、校验层、重试层、落库层，模型只是抽取层里的一个可替换组件。框架本身提供并发控制、失败重试、缓存、Schema 定义、结果合并这些脚手架。
这类项目初期配置稍微麻烦一点，要写 Schema、要配参数，但它是我唯一敢直接放到生产环境跑的类型。因为采集任务出问题的时候，你需要的不是"模型再聪明一点"，而是"哪一层挂了、挂了多少、能不能重跑、重跑会不会重复入库"。这些问题只有结构化的框架能回答。后面第四节的实操，我就是按这类框架的思路来搭的，你对照着任何同类实现都能套进去。
3. 选型前的成本账：先把 token 算清楚再动手
我见过太多人项目做到一半才发现跑不起，问题全出在动手前没算账。这一节把计算方法摊开，你把自己的数字代进去就能得出一个量级，判断方案是否可行。
3.1 单个页面的 token 估算
先估算输入。中文内容大致按"一个字约等于一点二个 token"来算，英文按"一个单词约一点三个 token"。取一个中等复杂度的页面，抓下来原始 HTML 可能有三四百 KB，但经过正文清洗以后，有效文本通常在一到三千字之间，对应的 token 量在两千到四千。这里的关键动作是清洗必须做，且要做狠。不做清洗直接塞 HTML，同样一个页面 token 能翻二十倍，成本直接爆炸，而且抽取准确率反而下降，因为导航、脚本、样式这些噪声会干扰模型判断。
再估算输出。要求模型返回 JSON，字段数在五到十个之间，输出的 token 一般在两百到五百。输出侧的成本相对小，但输出长度的不可控性要防——有些模型喜欢在 JSON 前面加一段"好的，根据您的要求"，这几十个 token 白烧，还会让你的解析器报错。
3.2 一个具体算例
假设你的任务是每天采集五万个详情页，平均每页清洗后两千五百字，输入约三千 token，输出约三百 token。
- 输入总量：50000 × 3000 = 1.5 亿 token / 天，即 150 百万 token
- 输出总量：50000 × 300 = 1500 万 token / 天，即 15 百万 token
按市面上常见的小模型价位段（每百万输入 token 几元、输出 token 十几元这个量级）估算，一天的成本在几百元上下；如果换成大模型，量级会直接跳到几千甚至上万元一天。这个差距就是选型的分水岭：能用小模型加好提示词解决的，绝不上大模型。我自己的经验是，抽取类任务里八成的场景，小模型配合明确的 Schema 和两三个示例，效果和大模型的差距在五个百分点以内，而成本差一个数量级。
3.3 用规则生成型做对比
同样是五万个页面，如果走规则生成型方案：新站接入时每站调五次模型，假设一共五百个站点，总共两千五百次调用，一次输入五千 token（含 HTML 片段），总消耗一千二百五十万 token，一次性成本几块钱到几十块钱。之后每天跑纯代码采集，模型成本为零。
两相对比，差距是三个数量级。这就是为什么我反复强调：先问清楚这个站点的结构会不会变、量有多大。量大且结构稳定的，规则生成；量小且结构混乱的，直接抽取。选错方向，后面所有优化都是在错误的路上狂奔。
4. 从零搭一条"抓取 + 抽取 + 校验"的管线
这一节给一套可以直接抄的骨架。我不绑定具体某个开源项目，因为它本质上就是几百行代码的组织方式，你把它套到任何同类库上都能跑。整条管线分四步：抓取清洗、Schema 定义与提示词、模型调用与容错、并发限速与缓存。
4.1 环境准备与依赖清单
依赖保持最小：一个 HTTP 客户端、一个 HTML 解析器、一个数据校验库、一个异步调度库，加上模型服务的官方 SDK。别一上来就装一堆框架，调度、存储、监控这些东西等管线跑通了再往里加，否则你会在配置里泡三天还没抓到第一个页面。
pip install requests beautifulsoup4 pydantic tenacity提示：抓取前务必确认目标站点的服务条款与 robots 约定，控制请求频率，只采集公开信息。这一条不是形式主义，是真会让你吃官司的东西。
4.2 第一步：抓取与正文清洗
清洗的质量直接决定后面所有环节的成本和准确率。我的做法分三层：先删掉脚本、样式、导航、页脚、评论这些明显无用的标签；再按"文本密度"打分，把段落数少、链接占比高的块判定为噪声丢弃；最后保留主体容器里的纯文本，段落之间用换行分隔，保留原始的层级关系。
import re from bs4 import BeautifulSoup NOISE_TAGS = ["script", "style", "nav", "footer", "aside", "form", "noscript"] def clean_html(raw_html: str) -> str: soup = BeautifulSoup(raw_html, "html.parser") for tag in soup(NOISE_TAGS): tag.decompose() # 按文本密度筛掉链接占比过高的块 for block in soup.find_all(["div", "section", "ul"]): text = block.get_text(strip=True) if len(text) < 50: block.decompose() continue link_text = "".join(a.get_text(strip=True) for a in block.find_all("a")) if len(link_text) / max(len(text), 1) > 0.5: block.decompose() text = soup.get_text("\n", strip=True) text = re.sub(r"\n{3,}", "\n\n", text) return text这段代码不长，但里面有两个容易忽略的细节。第一个是len(text) < 50这个阈值，它是用来砍掉那些纯装饰性的小盒子的，阈值太低砍不干净，太高会把真正的短字段（比如价格、评分）连带砍掉，我一般设在四十到八十之间，按目标站点调。第二个是链接占比阈值零点五，列表页和导航区天然链接密集，这个规则能砍掉绝大部分，但要注意有些正文里链接也很多（比如带大量引用链接的文章），这时候会误伤，所以我在清洗后会加一个兜底判断：如果清洗完的文本长度小于五百字，就退回原始文本再抽一次，不直接丢。
4.3 第二步：用 Schema 把模型的输出锁死
不定义 Schema 就让模型自由发挥，是抽取失败的头号原因。用 Pydantic 定义一个数据模型，把字段名、类型、是否必填全写清楚，然后把 Schema 的 JSON 描述直接拼进提示词里，让模型照着填。这一步能让格式错误率下降一大截。
from typing import Optional from pydantic import BaseModel, Field class ItemDetail(BaseModel): title: str = Field(description="标题原文，不做改写") publish_time: Optional[str] = Field(None, description="发布时间，格式 YYYY-MM-DD，无法确定填 null") price: Optional[float] = Field(None, description="价格数值，单位元，去掉货币符号") location: Optional[str] = Field(None, description="所在城市，只保留城市名") summary: Optional[str] = Field(None, description="一百字以内的内容摘要")字段描述里我写了几条硬性规定，这些规定是有讲究的。"不做改写"是为了防止模型自作主张润色标题，那样抽出来的数据和原文对不上，下游去重会失效。"无法确定填 null"极其重要，不写这句，模型遇到缺失字段时会编一个看起来合理的值填进去，这种幻觉数据混进库里比空值危险十倍。"去掉货币符号"和"单位元"是为了后续做数值聚合，不然一会儿"¥3,000"一会儿"3千"一会儿"三千元"，你后面清洗要哭。
4.4 第三步：调用、解析、校验、重试
这一层是整个管线的稳定性核心。模型返回的内容永远不要直接信，先做 JSON 提取（很多时候它会包在代码块里），再做 Schema 校验，不通过就打回重试。重试的时候把上一次的错误信息带上，让模型自己修，这个技巧能把重试成功率提高不少。
import json, re from tenacity import retry, stop_after_attempt, wait_exponential def extract_json_block(text: str) -> str: fenced = re.search(r"```(?:json)?\s*(\{.*?\})\s*```", text, re.S) if fenced: return fenced.group(1) start, end = text.find("{"), text.rfind("}") return text[start:end + 1] if start != -1 and end != -1 else text @retry(stop=stop_after_attempt(3), wait=wait_exponential(min=1, max=8)) def extract_item(page_text: str, call_model) -> ItemDetail: prompt = build_prompt(page_text, ItemDetail) raw = call_model(prompt) payload = json.loads(extract_json_block(raw)) return ItemDetail(**payload)这里有三个实战要点。extract_json_block里的正则用了非贪婪匹配加re.S，是为了应对模型把 JSON 分多行写的情况；如果模型返回的内容里出现多个花括号块（比如先解释再给结果），取第一个和最后一个花括号之间的内容通常最稳。重试的退避策略用指数退避，min 一秒 max 八秒，别用固定间隔，模型服务在高峰期偶尔抖动，固定间隔重试容易连续撞墙。第三点是重试次数别贪多，三次足够，超过三次还失败的基本是页面本身有问题（比如正文没抓到、页面是登录墙），继续重试纯烧钱，直接落库标记待查更划算。
4.5 第四步：并发控制与结果缓存
并发这块，我的原则是宁可慢一点也不要被封。用异步加信号量限制同时进行的请求数，同时对同一个域名做速率限制。这里必须提醒：并发数和请求频率要按目标站点的承受能力来调，很多站点对每秒请求数有明确上限，超了就直接拒绝服务，你调得再快也是白搭。
import asyncio, hashlib, json, os SEM = asyncio.Semaphore(5) async def fetch_one(url, session, cache_dir="./cache"): key = hashlib.md5(url.encode()).hexdigest() path = os.path.join(cache_dir, f"{key}.json") if os.path.exists(path): return json.load(open(path, encoding="utf-8")) async with SEM: await asyncio.sleep(0.3) # 全局限速，按目标站点调整 resp = await session.get(url, timeout=15) data = {"url": url, "html": resp.text} json.dump(data, open(path, "w", encoding="utf-8")) return data缓存这一步很多人省掉，然后调试的时候反复抓同一个页面，既慢又给对方服务器添麻烦。我用的缓存键是 URL 的哈希，缓存原始 HTML 而不是抽取结果，这样调提示词的时候可以直接复用本地 HTML 反复试，一轮调优能省掉几百次网络请求。等提示词稳定了，再在抽取层加一层结果缓存，键用"URL 哈希 + 提示词版本号"，提示词一改自动失效，不会读到脏结果。
5. 常见问题与排查实录
跑了这么久，遇到的问题基本集中在五类。这一节把现象、原因、处理方式整理成对照表，再补充几条我觉得最有价值的经验。
5.1 字段漂移与幻觉数据
最常见的问题是"字段名对、内容错"。比如要求抽发布时间，模型给你返回了一个看起来像日期但实际是页面底部的版权年份；要求抽价格，它把"原价划掉"的那个数字抽了出来。这类问题的根源通常是上下文里存在多个候选值，而提示词没有说清楚该选哪个。
处理方式有两条。第一条是在字段描述里加消歧说明，比如"如果是促销价和原价同时存在，取实际成交价"，这句话能让准确率明显提升。第二条是给两三个正例，让模型看到"输入长什么样、输出长什么样"，示例的作用远大于形容词。我在提示词里踩过的坑是：一开始写"请准确抽取价格"，完全没用；改成"页面中可能同时出现原价、折扣价、分期价，只取当前实际支付金额，其余忽略"，准确率立刻上去了。
还有一种更隐蔽的幻觉：字段缺失时编一个值。比如页面根本没有地点信息，模型返回了一个"北京"。防这个的唯一办法是反复强调"无法确定必须填 null"，并在校验层加统计——监控每个字段的空值率，某个字段空值率突然从百分之三十掉到零，八成是模型开始编了，这时候要去查提示词是不是哪次改动把"允许为空"这句删了。
5.2 上下文超限与截断
长页面放不进去是第二个高频问题。一本产品说明书写了五万字，塞进上下文直接把限制撑爆。硬塞的后果不只是报错，更常见的是被静默截断，模型只看到了前半部分，抽出来的字段缺一半，而且它不会告诉你。
我的处理策略是分块加合并：按段落边界切块，块大小控制在两千字左右（约两千五百 token），每块单独抽一遍，然后把结果按字段合并——字符串字段取第一个非空值，列表字段做并集去重，数值字段取最早出现的那个（通常正文开头是核心信息）。分块要注意别从句子中间切，简单做法是按双换行切段，然后把段落累加到接近上限再开新块，这个策略简单但效果好。
分块带来的副作用是成本翻倍，所以我在分块前会先判断：如果清洗后文本总长小于八千字，直接单次调用；超过才分块；超过五万字的，先做一轮摘要压缩再抽。这个分级判断能省掉大量不必要的分块开销。
5.3 页面没渲染完就开始抽
动态渲染的页面，用普通请求拿到的是骨架 HTML，正文全是空的。这时候模型很老实——你给它空文本，它要么返回一堆 null，要么开始编。判断方法很简单：清洗完的文本长度小于两百字，基本可以断定没渲染出来。
处理顺序建议是这样：先检查是不是被要求登录或者被拦截，看返回状态码和页面标题；确认是动态渲染问题，就换带浏览器内核的方案，等页面关键元素出现后再取内容；如果换了渲染方案还是短，那就是页面真的没内容，别硬抽了。我在这里浪费过不少时间——反复调提示词想"让模型更聪明"，实际上问题根本不在模型，在于它拿到的是空数据。先验证输入，再怀疑模型，这条顺序能帮你省掉很多冤枉时间。
5.4 排查速查表
| 现象 | 最可能的原因 | 处理动作 |
|---|---|---|
| 全部字段为 null | 正文清洗后文本过短或为空 | 打印清洗结果长度，检查渲染与清洗规则 |
| 偶发 JSON 解析失败 | 模型输出夹杂说明文字 | 加 JSON 块提取，提示词加"只输出 JSON" |
| 某字段空值率骤降 | 模型开始编造缺失值 | 检查提示词中"允许 null"的说明是否丢失 |
| 抽取结果与页面内容不符 | 上下文被截断，只看到前半部分 | 检查 token 数，启用分块合并 |
| 同一页面两次结果不同 | 未固定温度参数 | 温度设为 0 或接近 0 |
| 批量任务中途大面积失败 | 触发速率限制，请求被拒 | 降并发、加退避、按域名限速 |
| 成本较预估高出数倍 | 未清洗直接送 HTML，或分块过碎 | 加强清洗、调整块大小 |
| 抽取字段顺序错乱 | Schema 描述不清，字段歧义 | 在字段描述中加区分说明与示例 |
5.5 我在实际项目里的几条经验
第一条：先把清洗做好，再谈模型选型。我早期一个项目换过三次模型，效果提升不到五个点；后来花两天重写清洗规则，同样的模型准确率提了二十多个点。输入质量决定了效果上限，模型只是逼近这个上限。
第二条：永远保留原始 HTML。抽取失败的时候，你需要能离线复现，而不是重新抓一遍（可能页面已经变了，也可能对方开始限流）。原始 HTML 存本地或者对象存储，配一个"提示词版本 + 抽取结果"的表，出问题能精确定位是哪次改动导致的。
第三条：抽样人工复核不能省。自动化程度再高，每天抽百分之一的结果人工看一遍，能让你在数据污染扩散之前发现问题。我现在的做法是每天固定抽五十条，看标题、时间、价格三个关键字段，十分钟的事，但救过好几次。
第四条：把提示词当代码管理。加版本号、写变更记录、改一次跑一次回归集。回归集不用大，二十个页面覆盖五种典型结构就够，但必须有，否则你改了一句话觉得"应该更好了"，实际上把另一个场景改坏了都不知道。
第五条：先跑通一条链路再谈规模。我见过太多项目一开始就设计分布式、消息队列、多级缓存，两周过去一个页面都没抓成。正确的顺序是先让一个页面从头到尾跑通、字段正确率达标，再考虑加并发、加存储、加监控。规模问题在有了第一个能跑的东西之后再解决，效率高得多。
这套东西我从最早用模型抽字段踩坑，到现在维护几百个站点的采集任务，最大的感受是：模型能把最难的那一段从"写不完的规则"变成"调得动的提示词"，但它替代不了工程。清洗、校验、重试、缓存、监控，这些枯燥的部分决定了方案能不能活在线上，而模型只是让它变得可能的那一块拼图。
