直接回答:当页面数量、栏目层级和更新频率超过一个人能在一次工作周期内逐页检查的范围时,逐条手工改标题、逐页提交地址、逐篇记收录状态这三类工作最先变得不适合继续手工做。继续硬做的代价不是“累”,而是漏改、重复改和判断失真,最终让后续决策建立在错误样本上。更合理的分界是:需要逐页判断语义的工作继续人工,需要全量一致执行且可被规则描述的工作转为批量或半自动。
规模扩大后常出现这种情况:编辑每天手工调整一批页面标题、手工记录哪些页面被收录,工作日志很满,但过一段时间回看,问题页面数量并没有下降。对此有两种解释。
这两种解释对应完全不同的动作:前者应当补人力或排优先级,后者应当先把可规则化的工作抽出来批量处理。区分它们的关键证据不是“改了多少页”,而是同一批页面在两次检查中的状态是否一致。如果同一批页面隔一段时间复查,出现改过又被改回、标题风格前后不一、已处理清单和实际页面不符,那更支持解释二。
判断标准可以简化为一句话:这项工作是否需要针对每个页面的独特内容做语义判断?不需要的,就不该继续逐页手工做。
反过来,以下工作即使规模变大也应当保留人工判断:页面主题是否重复、某篇内容是否值得保留、栏目结构是否符合用户查找路径、以及涉及品牌表述和事实准确性的文字。把这些也交给规则批量处理,代价通常比手工更高。
面对规模扩大,通常有两种看似都合理的做法。
做法A:继续手工,但排优先级,只处理最重要的页面。它成立的条件是:页面总量仍在可控范围(例如几百个以内),且问题集中在少数高价值页面,长尾页面的问题不影响整体结构。代价是长尾问题长期累积,且“重要”的判断会随人员变动而漂移。
做法B:把可规则化的工作转为批量或半自动执行,人工只做判断。它成立的条件是:规则能被清楚写出,且执行结果可被抽查验证。代价是前期需要把规则整理成文档或脚本,并且在规则写错时会一次性影响大量页面,所以必须配套小范围试跑和回滚准备。
选择的分界不在于团队人数,而在于这项工作能否被写成一条不依赖具体页面内容的规则。能写出来,就倾向做法B;写不出来,就留在做法A并接受进度较慢。
假设一个站点从 200 个页面扩展到 2000 个页面,其中约 1500 个是同一模板生成的列表页。团队原本逐页手工检查标题是否重复。
改为批量处理后,动作是:先导出这批页面的现有标题,按模板变量分组,找出变量缺失或重复的组合,再统一调整模板输出规则,最后只抽查其中几十个页面确认效果。结果是处理时间大幅缩短,但会暴露一个新的下一步——模板改动可能同时影响其他栏目,因此需要先确认模板的复用范围,再决定是否扩大改动。
如果这批页面并不共享模板,而是各自独立撰写,那么批量处理的前提就不成立,应当回到逐页判断,只是把优先级排清楚。
无论选哪种做法,都要避免把单一现象当成结论。例如“抓取量下降”或“某类页面收录数归零”,既可能是批量改动带来的正常波动,也可能是规则写错、模板误伤、服务器响应异常,甚至只是统计口径变化。这些现象本身不足以证明处理正确或错误。
更可靠的做法是保留一份改动前的对照样本:同一批页面在改动前后的状态记录。改动后先看对照样本是否按预期变化,再看是否出现样本之外的异常。如果对照样本符合预期且无额外异常,可以扩大范围;如果对照样本本身就不一致,应先停下排查规则,而不是继续推进。
规模扩大后的核心不是“手工还是工具”,而是把工作分成两类:需要逐页语义判断的留给人工,可被规则描述且需要全量一致的交给批量执行,并为后者保留验证和回退的余地。