采集规则编写 - 怎样记录变更与复盘
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /d9e45c9ab19c.html
📄
采集规则编写 - 怎样记录变更与复盘
采集规则编写中的记录变更与复盘，核心是给每条规则建立可追溯的版本档案：每次改动前记录原规则、改动原因和预期影响，改动后用小样本验证结果，再定期对比改动前后的采集质量。这样做的目的不是走流程，而是当采集结果异常时，能快速判断是哪次改动引入的问题，避免反复猜测。
为什么采集规则必须留下变更记录
采集规则通常包含入口页、列表页、详情页的定位方式、字段提取逻辑、翻页处理和去重条件。这些部分相互依赖，改一处可能影响多处。例如只调整了列表页的分页参数，却导致详情页链接拼接错误，最终表现为大量空字段。
没有变更记录时，出现异常只能靠记忆回溯，而记忆往往不准确。有了记录，可以把“结果异常”直接对应到“某次改动”，把排查范围从整条规则缩小到具体字段或具体步骤。记录同时也是复盘的原料，没有记录，复盘只能停留在感觉层面。
变更记录清单：每项查什么、怎么查、说明什么
- 改动时间与操作人：查规则文件的修改时间或版本库提交记录；如果结果与预期时间不符，说明可能存在多人同时改动或未提交的本地修改。
- 改动前后的规则片段：查版本对比，重点看定位表达式、字段映射和翻页逻辑；如果差异出现在定位表达式，说明采集失败可能来自页面结构匹配问题，而非网络问题。
- 改动原因：查当时的任务备注或沟通记录，写明是页面改版、字段新增还是修复错误；原因缺失时，后续复盘无法判断这次改动是否仍有必要保留。
- 预期影响范围：查改动说明中标注的受影响字段和页面类型；如果实际异常字段不在预期范围内，说明改动存在未预料的副作用，需要检查规则之间的耦合。
- 验证样本与结果：查改动后跑过的小样本记录，包括样本页数量、字段完整率和异常条数；如果没跑过样本就全量运行，说明验证环节缺失，异常风险会放大。
- 回滚方式：查是否保留了上一版可用规则；如果没有，说明一旦新规则失效，恢复时间会明显拉长。
复盘时重点对比哪些指标
复盘不是重读一遍记录，而是用可比的数据回答“这次改动到底有没有达到目的”。建议固定对比以下几项：
- 字段完整率：改动前后各取同一批样本页，统计目标字段非空的比例。完整率下降说明提取逻辑可能过严或页面结构已变化。
- 重复率：统计同一内容被重复采集的比例。重复率上升常见于翻页逻辑改动或去重条件被削弱。
- 异常类型分布：把失败样本按超时、定位失败、字段为空、编码错误分类。类型集中说明问题在某一环节，类型分散说明可能是入口或网络层面的问题。
- 单页耗时：对比改动前后的平均处理时间。耗时明显增加时，要检查是否新增了不必要的请求或等待条件。
这些指标要基于同一批样本对比，样本不同则数据没有可比性。假设某次改动后完整率从 95% 降到 80%，而异常类型集中在“定位失败”，那么复盘结论应指向定位表达式，而不是去调整请求频率。
一个可执行的小样本验证步骤
每次改动采集规则后，先不要全量运行。按以下步骤做一次快速验证：
- 从目标页面中挑选 10 到 20 个具有代表性的样本，覆盖列表首页、中间页和最后一页。
- 用改动后的规则只跑这批样本，记录每个字段的提取结果。
- 把结果与改动前的记录逐字段对比，标出变好、变差和不变的部分。
- 如果关键字段完整率没有下降，再扩大到 100 条左右复测；如果下降，先回滚或修正，不要继续扩大范围。
适用条件是页面结构相对稳定、样本容易获取。如果目标页面本身每次加载内容都不同，样本对比的参考价值会下降，此时应增加样本数量并记录页面差异，而不是直接下结论。
把记录变成可复用的复盘习惯
记录变更与复盘的价值在于积累。每次改动都留下“改了什么、为什么改、结果如何”，一段时间后就能看出哪些改动真正有效、哪些字段容易出问题、哪些页面类型需要更宽松的规则。
下一步可以从最近一次采集规则改动开始，补一份变更记录，并用同一批样本跑一次前后对比。如果发现没有可对比的旧数据，就先固定当前版本作为基线，之后的每次改动都按上面的清单执行。
