采集规则编写在网站规模扩大后哪些工作不适合继续手工做
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /326170d1f2f6.html
📄
采集规则编写在网站规模扩大后哪些工作不适合继续手工做
当页面从几十个涨到几千个，最先崩掉的不是服务器，而是手工维护的一致性。判断标准很直接：一项工作如果每次都要靠人记住上次怎么填、靠人眼比对字段是否齐全，它就不适合继续手工做，应该转成采集规则里的可执行条件。下面以你手里一份旧栏目导出表为对象，说明怎么把它变成规则，以及哪些环节必须交给规则而不是人。
先判断哪些手工动作已经变成规模负担
把最近一次更新旧内容的过程写下来，看每一步依赖什么。如果某一步依赖的是“我记得这个字段以前是这么填的”，它就属于规模负担。常见的有三类：字段补全、链接改写、重复判断。字段补全指每加一批页面都要手动确认标题、摘要、分类是否齐；链接改写指旧路径迁移后逐条替换；重复判断指人眼扫一遍看有没有同一资料被收两次。
这三类工作的共同点是判断条件固定、结果可预期。固定条件正是规则擅长处理的部分。反过来，涉及取舍的工作，比如某份旧资料到底该保留还是下架，仍然需要人先做一次决定，规则只负责执行这个决定。
用一份旧资料表拆出可执行条件
假设你手上有一份旧栏目导出表，字段包括标题、原路径、发布时间、正文摘要。你要决定哪些记录继续保留、哪些随旧系统一起退出。不要先动手删，先把它转成规则能读的条件。
- 给每条记录标一个保留理由，例如“仍有访问入口”“被其他页面引用”“仅存档不再更新”。理由必须是可判定的，不能写“感觉还有用”。
- 把理由翻译成字段条件。例如“被其他页面引用”对应正文里存在指向该路径的链接；“仍有访问入口”对应导航或列表页仍列出该地址。
- 对无法用现有字段判定的理由，补一个字段再入库，而不是留给人每次临时判断。
做完这一步，规则要处理的就不是“这条好不好”，而是“这条满足哪个条件”。条件固定之后，同一批数据反复跑，结果才稳定。
规则该接管的三个环节与不该接管的两个环节
规则适合接管的是可重复、可枚举、结果确定的动作：
- 字段校验：入库前检查必填项是否为空、格式是否符合约定，不符合的记录单独列出。
- 路径映射：旧路径到新路径的对应关系写成映射表，由规则统一替换，避免逐条手改漏掉。
- 重复识别：按标题或正文特征比对，把疑似重复的记录集中输出，交给人工确认而不是直接删。
不该交给规则的是两类判断。第一类是价值取舍，比如某份旧资料是否还值得保留，这取决于业务判断，规则只能执行结论。第二类是异常解释，比如某批记录突然全部校验失败，原因可能是源表结构变了，也可能是导出时字段错位，需要人先看原始数据再决定改规则还是改源。
这里有一个容易踩的坑：抓取量或记录数归零，不能单独证明规则写对了。它同样可能意味着源表为空、字段名对不上导致全部被过滤、或者导出步骤本身失败。看到归零先查源数据，再查规则条件，最后才考虑是不是真的没有可处理内容。
一个注明假设的短例子
假设某旧栏目有 500 条记录，其中 120 条正文里含有指向其他页面的链接，80 条仍出现在导航中，其余 300 条既无引用也无入口。按前面的条件，前 200 条进入保留流程，后 300 条进入退出流程。规则负责按条件分流并输出两份清单，人只需要抽查分流结果是否符合预期。
如果抽查发现某条记录正文里确实有链接，却被分到了退出清单，先检查链接匹配条件是否只认绝对路径、而源表里写的是相对路径。修正条件后重跑，结果会变化。这个动作的意义在于：它把“人眼漏看”变成了“条件写错”，而条件写错是可以一次性修好、之后不再重复的。
把退出流程也写成规则的一部分
旧内容退出不是删掉了事。规则要同时处理三件事：把退出记录单独存档、把仍被引用的路径改成指向替代页面、把导航和列表里的入口去掉。这三步如果手工做，规模一大必然出现“页面删了但入口还在”的情况，访问者点进去看到空页面，比保留一份旧内容更糟。
所以规则编写时，退出条件要和引用检查绑在一起。一条记录只有在“无入口、无引用、无保留理由”三个条件同时成立时才进入退出清单。任何一个条件不成立，就退回保留流程。这样规则输出的不是一份删除名单，而是一份带原因的分流结果，下一步动作才有依据。
