火车头采集教程：旧规则失效时怎样修订操作笔记
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /74f9cfeaa2ae.html
📄
火车头采集教程：旧规则失效时怎样修订操作笔记
先给结论：不要急着把旧笔记删掉，而是把它降级为“历史记录”，另建一份带验证日期的现行版。修订的触发点不是你觉得它过时，而是你按笔记操作后，出现了和预期相反的结果，并且能用可核对的证据说明是哪一步变了。
先分清是笔记错了，还是这次任务特殊
假设一个情境：你有一份自己写的火车头采集教程笔记，记录某类列表页的翻页抓取步骤。过去按它操作能稳定拿到数据，这次却只抓到第一页，后面全部为空。直觉会告诉你“规则失效了”，但这个结论下得太快。
至少有三类解释：一是目标页面的翻页方式变了；二是你这次选的采集入口和笔记假设的不一致；三是笔记里的某条规则本来就只在特定条件下成立，只是以前没暴露。要区分它们，靠的不是再试几次，而是留下可核对的证据：本次使用的入口地址、抓取到的实际条数、日志里报错或空值出现的位置、以及和上次成功时相比改了哪一步。
如果空值集中在翻页环节，而列表本身抓取正常，问题更可能在翻页规则；如果列表内容也变了结构，那更可能是页面整体改版。这两种判断会导向完全不同的修订动作，所以先定位，再改笔记。
修订时把“结论”和“依据”分开写
旧笔记最容易失效的部分，往往是只写了结论、没写依据。比如只写“翻页用某条规则”，却没写这条规则是针对哪种页面结构、在什么条件下验证过。一旦结论失效，你连它当初为什么成立都说不清，只能整段重写。
更耐用的写法是每条关键步骤都配一行依据：这条规则适用于什么页面特征、上次验证是什么时候、验证时抓到了多少条。这样出现异常时，你能快速判断是依据变了，还是结论本身写错了。修订动作也很明确：只改依据已经变化的那几条，其余保留，而不是把整份笔记推倒重来。
一个实际动作是给笔记加“验证日期”和“适用条件”两栏。做完这一步，下次再遇到相反结果，你能直接看出这条规则多久没被验证过，从而决定是先重测还是先怀疑页面。
用一次对照测试决定改哪一版
当你怀疑旧规则失效，又不想凭感觉改，可以做一个对照测试：用旧笔记的步骤和一份只改了单个环节的新步骤，分别跑一次，比较两者抓到的条数和空值位置。注意这只是假设性的比较方法，不是真实项目结论。
如果只改一个环节就恢复正常，说明问题出在那个环节，修订范围就锁定在那里；如果两种方式都失败，说明变化不在你改的那个点，需要回到上一步重新定位。这个动作的价值在于：它把“我觉得是这里的问题”变成“改这里之后结果有没有变化”，从而决定下一步是继续缩小范围，还是换一个方向排查。
测试时只改一个变量，否则你无法判断是哪个改动起了作用。这一点比测试本身更重要。
把修订结果写回笔记，而不是留在脑子里
定位到原因后，修订要落到笔记上，否则下次还会踩同一个坑。建议保留旧版本，另起一份现行版，并在旧版标注“已被某次异常替代，原因见现行版”。这样既不会丢失历史判断，也不会让新旧规则混在一起。
- 把失效的那条规则划掉，而不是直接删除，方便日后回溯。
- 在新规则旁注明验证日期和当时抓到的实际条数。
- 如果这次异常属于偶发，单独记一条“待观察”，不要立刻改主流程。
判断是否偶发，可以看同样的步骤在相近条件下是否重复出现相反结果。只出现一次就大改笔记，容易把本来正确的规则改坏。
什么时候该整段重写，什么时候只改一行
只改一行的条件：页面结构基本没变，异常集中在单个环节，且对照测试能稳定复现。整段重写的条件：入口方式、页面类型或你的采集目标本身变了，旧笔记的前提已经不成立。
区分这两者的依据是前提有没有变，而不是结果有多糟。结果差但前提没变，通常是小修；结果还行但前提已经换了对象，反而应该重写。修订笔记的终点不是让它看起来更新，而是让你下次照着做时，能复现出和预期一致的结果，并知道这个结果是在什么条件下得到的。
