惊雷算法应对：站点规模上来后，哪些活别再手工干
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /d13d852e8720.html
📄
惊雷算法应对：站点规模上来后，哪些活别再手工干
直接回答：当页面、栏目和模板数量超过一个人能逐条核对的程度，手工做的代价就不再是时间，而是判断失真——你会开始凭印象处理，而不是凭证据。适合继续手工的是判断类工作，比如决定某个页面该保留、合并还是删除；不适合继续手工的是可枚举、可重复、可用规则描述的工作，比如逐页改标题、逐条查链接、逐张图补说明。下面用一个具体对象走一遍转换过程。
先拿一个栏目做样本，判断它是否已经“手工会失真”
假设你手里有一个商品栏目，包含若干分页、筛选项和详情页。先不要全站铺开，只取这个栏目。判断标准不是“页面多不多”，而是三个可观察的信号：
- 同一类修改，你需要打开超过几十个页面才能完成一轮；
- 修改规则能写成一句话，比如“标题里去掉重复的品牌词”；
- 不同人做同一件事，结果不一致，或者你自己两次做的结果不一致。
三条中命中两条，说明这个栏目已经从“手工可管”滑向“手工不可控”。此时继续手工的代价是：你花在操作上的时间挤掉了判断时间，而判断恰恰是算法应对中最不能省的部分。
把“逐页改”拆成规则、数据源和验证点
还是这个栏目。手工做法通常是：打开页面，看标题，改标题，保存，下一个。要转成可执行方案，先把它拆成三样东西。
规则
用一句话写清改什么、依据什么。例如：“当详情页标题与所属分类名完全重复时，保留分类名，补充该页唯一属性。”规则必须能判定真假，不能是“优化一下标题”这种无法执行的表述。
数据源
规则依赖的字段要能批量取到，比如页面地址、当前标题、所属分类、唯一属性。如果这些字段只能靠人工打开页面抄，那说明第一步不是自动化，而是先把数据整理出来。这一步的手工是值得的，因为它产出的是可复用资产。
验证点
批量处理前，先定一个能证伪的检查：处理后，重复标题的数量是否下降；抽样若干页，标题是否仍能对应页面内容。注意，重复标题数量下降本身不等于处理正确——它也可能来自页面被合并、被删除或未被抓取。所以要把“数量变化”和“抽样内容”放在一起看。
两种做法的取舍：全自动批处理和半自动队列
到了执行阶段，常见两种选择，各自成立的条件不同。
- 全自动批处理成立的条件：规则足够确定，错误可回滚，且你能接受一次处理影响整个栏目。代价是，一旦规则写错，错误会同时落在大量页面上，回滚成本高。
- 半自动队列成立的条件：规则只能覆盖大部分情况，仍有例外需要人判断。做法是系统生成待处理清单和推荐值，人只做确认或修改。代价是仍然需要人工时间，但人工从“操作”变成了“审核”。
选择依据不是哪个更先进，而是你的规则能否覆盖例外。规则覆盖率高、可回滚，选批处理；例外多、判断依赖上下文，选队列。把这两条写下来，比讨论工具选型更有用。
一个假设例子：从手工改到规则处理的完整链路
假设某站点有若干详情页，标题里都带着同一串重复词。手工做法是逐页删。转换后的方案是：
- 导出这些页面的地址和当前标题；
- 写一条规则，识别并去掉重复词，保留页面唯一属性；
- 先在一个小范围上跑，抽样检查标题是否仍对应内容；
- 确认后扩大范围，并记录处理前后的重复标题数量；
- 处理后观察抓取与索引情况，区分“页面被正常处理”和“页面被错误合并”这两种解释。
这个例子里，实际动作是“先在小范围跑并抽样”。它的结果决定了下一步：如果抽样发现标题与内容不匹配，说明规则本身有问题，应回到规则修改，而不是扩大范围；如果抽样通过但索引表现异常，则应先排查是否存在页面合并或抓取受阻，而不是继续批量修改。
哪些工作即使规模变大，也建议保留手工
不是所有事都适合交出去。以下几类仍然依赖人的判断：
- 决定一个页面是保留、合并还是删除，这涉及内容价值和用户意图；
- 判断某个异常是规则问题还是抓取、索引环节的问题；
- 处理规则覆盖不到的例外页面。
区分标准很简单：如果一件事能用“如果……就……”完整描述，并且结果可验证，它就可以脱离手工；如果它需要权衡多个目标，且不同选择各有代价，就保留人工。规模扩大后真正该做的，是把可枚举的部分交出去，把判断的部分留下来，而不是把所有事都推给流程。
