火车头采集规则：怎样建立长期维护机制
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /17791e59d4bf.html
📄
火车头采集规则：怎样建立长期维护机制
把火车头采集规则当成需要版本管理的配置资产，而不是一次性写完的脚本，是建立长期维护机制的核心。具体做法是：为每套规则指定负责人、记录适用页面类型与失效条件、定期用固定样本回归测试，并把修改原因写进变更记录。这样多人协作时，接手的人能判断规则该不该改、改哪里、改完是否还有效。
先明确维护对象：规则、任务与数据流向
火车头采集规则通常包含网址采集、内容页匹配、字段提取、替换过滤、发布配置等部分。长期维护要区分三层：
- 规则层：标签定位、正则、XPath、CSS选择器、分页与列表页逻辑。
- 任务层：采集范围、发布目标、去重方式、更新频率。
- 数据层：字段是否完整、编码是否正确、是否出现空值或错位。
三层混在一起改，最容易返工。建议每次修改只动一层，并在记录中写明动了哪一层。
用文档固定交付物，减少协作歧义
多人协作时，口头交接几乎必然导致重复劳动。每套规则至少配一份说明，内容包括：
- 规则名称与用途，例如“某栏目列表页+内容页采集”。
- 适用页面结构特征，例如列表是否分页、内容是否异步加载。
- 字段清单与对应提取方式，标明哪些字段允许为空。
- 已知失效条件，例如页面改版、字段位置调整、反爬策略变化。
- 最近一次验证时间和验证样本。
这份文档不需要复杂，关键是让接手的人能独立判断规则是否还可用。
设定回归测试：用固定样本判断规则是否失效
长期维护不能靠“感觉还能用”。可以保存一小批固定样本页面，每次修改规则或怀疑失效时重新采集，对比字段结果。判断依据可以这样设：
- 字段完整率：标题、正文、时间等关键字段是否出现大面积空值。
- 内容正确性：正文是否混入导航、推荐、版权等无关内容。
- 编码与格式：是否出现乱码、HTML标签残留、时间格式错乱。
- 数量异常：列表页采集条数是否明显少于预期。
如果只有少量字段异常，可能是单页结构差异；如果关键字段同时失效，更可能是页面模板整体变化。前者可以加条件判断，后者需要重写对应规则。
版本管理与变更记录：让每次修改可追溯
火车头采集规则可以导出为文件，建议按“规则名+日期+修改人”命名，或使用版本控制工具保存。每次修改记录三件事：
- 改了什么，例如把某个字段的定位从CSS选择器换成XPath。
- 为什么改，例如原选择器在改版后匹配到多个元素。
- 验证结果，例如用哪几个样本页面测试、关键字段是否恢复。
这样当规则再次失效时，可以快速回退到上一个可用版本，而不是从零重写。
多人协作的分工与检查点
比较常见的分工方式是：一人负责规则编写，一人负责发布与数据检查，另一人负责定期回归测试。代价是沟通成本上升，但能减少“改坏没人发现”的风险。如果只有一两个人维护，可以合并角色，但检查点不能省：
- 修改前先备份当前规则文件。
- 修改后在测试任务中跑固定样本，不直接发布到正式库。
- 确认字段完整、内容正确后再更新正式任务。
- 把本次修改写入变更记录，并通知相关协作人。
适用条件是页面结构相对稳定、采集频率不高；如果目标页面频繁改版，回归测试频率也要相应提高。
什么时候该重写而不是继续修补
出现以下情况时，继续在旧规则上打补丁的代价通常高于重写：
- 页面从静态列表改为接口加载，原有网址采集逻辑不再适用。
- 字段位置大面积变化，多个关键字段同时失效。
- 规则中堆叠了大量针对个别页面的例外判断，已经难以读懂。
判断方法是：统计最近几次修改中，有多少是在修同一类问题。如果同一字段反复失效，说明定位方式本身不够稳定，应考虑换一种提取思路，而不是继续加替换规则。
下一步可以选一套正在使用的火车头采集规则，按上面的字段清单和固定样本做一次回归测试，把结果写进规则说明，作为后续维护的基线。
