丽江网推：网站规模扩大后哪些工作不适合继续手工做
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /c51e081e0a60.html
📄
丽江网推：网站规模扩大后哪些工作不适合继续手工做
结论先说：当页面、栏目或内容更新量超过一个人能稳定核对的范围，手工做全站内链、逐条改标题描述、逐页检查索引状态、按篇记录效果这几类工作就不适合继续手工做。但这条结论有边界——如果站点只有几十个页面、更新频率低、业务词集中，手工反而更可控。判断是否该换做法，关键不是“规模大不大”，而是“同一动作是否需要重复核对，且错误会互相牵连”。
先分清：哪些手工活只是累，哪些已经会出错
累和错是两件事。累的工作可以靠加班顶住，错的工作会随着页面增加不断放大。适合继续手工的，通常是判断型工作：确定一个栏目该不该做、某类页面是否值得保留、一篇内容的角度是否偏离用户需求。这些工作没有稳定规则，交给工具反而容易做偏。
不适合继续手工的，是重复核对型工作。典型有三类：
- 全站内链调整。新增一个栏目后，需要回头检查旧页面是否该指向它。页面少时肉眼能看完，页面多时必然漏掉一部分，而漏掉的内链不会报错，只会安静地失效。
- 标题与描述的逐页修改。手工改几十页还能记住改过哪些，改几百页就需要一张外部清单来对照，清单本身又成了新的维护负担。
- 索引状态逐页查询。查询本身不复杂，复杂的是记录哪一页在什么时候查过、结果是什么、下次该复查哪一批。
这三类的共同点是：动作有明确规则，结果需要留痕，且前后批次之间要能对比。规则明确、需要留痕、需要对比，就是可以交给批处理或规则化流程的信号。
一个会让结论失效的反例
假设一个丽江本地站点只有四十个页面，其中三十页是稳定的服务介绍，十页是季节性的活动说明。这种情况下，手工维护内链和标题完全可行，甚至更稳：编辑清楚每个页面的上下文，改动时顺手就能判断会不会影响别的页面。
如果此时照搬“规模扩大就该自动化”的说法，引入一套批量改标题的流程，反而可能出问题。批量规则通常按模式匹配，比如统一给某类页面加后缀。但四十个页面里可能有三四个页面的标题已经因为特殊原因单独调整过，批量执行会把这些例外一起覆盖。例外被覆盖后不会立刻显现，要等到某次复查才发现，而那时已经很难还原原来的写法。
所以边界是：页面数量少、例外比例高、改动需要结合上下文判断时，手工更合适。反过来，页面数量多、规则统一、例外少、需要定期复查时，手工就开始拖后腿。
把手工工作换成规则化流程时，先做哪一步
不要一上来就全面自动化。先挑一类工作做小范围验证，最合适的是内链检查。具体动作是：列出当前所有页面，标出每个页面应该指向的核心页面，然后只检查这批指向是否存在、是否指向了正确的地址。
这个动作的结果会直接影响下一步。如果检查后发现漏链集中在某几个栏目，说明问题出在栏目结构而不是页面数量，应该先调整结构，而不是急着上批量工具。如果漏链分散、没有明显规律，说明靠人工已经无法稳定覆盖，这时再考虑用规则化方式定期跑一遍，才有依据。
同样的思路可以用在索引状态上。先手工抽查一批页面，记录查询日期和结果，隔一段时间再查同一批。如果两次结果差异很小，说明这批页面状态稳定，不需要频繁复查；如果差异明显，说明需要缩短复查间隔，或者找出导致差异的共同原因。这里要注意，查询结果变化可能来自页面本身改动，也可能来自抓取节奏调整，不能只凭一次变化就断定是某个操作导致的。
哪些工作即使规模扩大也不该完全交出去
有两类工作即使页面很多，也建议保留人工判断环节。
第一类是内容角度的确定。批量生成或批量改写可以让页面数量快速增加，但每个页面是否真的回答了用户的问题，仍然需要人来看。规模扩大后可以批量处理格式和结构，但不能批量决定“这篇内容值不值得存在”。
第二类是异常页面的处理。规则化流程擅长处理符合模式的情况，遇到不符合模式的页面时，通常只能跳过或报错。这些被跳过的页面往往才是需要单独判断的。所以流程跑完后，要留出查看异常清单的环节，而不是只看成功处理了多少条。
把这两类留在人工环节，其余重复核对型工作逐步规则化，才是规模扩大后比较稳的分工方式。下一步可以从整理一份当前手工工作的清单开始，标注每项工作的页面覆盖范围和例外比例，再决定先换掉哪一项。
