网站规划书规模扩大后哪些工作不适合继续手工做
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /18efd3a25dc9.html
📄
网站规划书规模扩大后哪些工作不适合继续手工做
结论先给：当页面数量、栏目层级或参与人数超过一个人能持续记住并核对的范围时，内部链接维护、页面模板一致性检查、失效链接巡检、结构化数据字段核对、内容更新排期提醒这几类工作就不适合继续靠手工做。判断标准不是站点有多大，而是同一件事是否已经需要反复回忆上次怎么处理。只要出现这种反复，手工方式的错误率会随规模上升，规划书里就应该把对应环节改写成由规则或脚本执行。
先判断哪些手工工作已经开始失控
可以用一个假设例子来理解这个门槛。假设规划书里写明每篇内容都要保留三个固定字段：所属栏目、更新周期、负责人。站点只有二十个页面时，手工在表格里维护完全可行；当页面扩展到几百个，并且同一栏目下有人新增、有人删除、有人改标题时，表格里的字段就会和实际页面脱节。这时继续手工核对，等于每次都要重新读一遍全部页面，工作量随规模线性增加，而错误往往集中在“上次改过但没同步”的位置。
更可靠的判断依据是看三件事是否同时出现：同一类修改每周重复发生、修改结果需要跨多个页面保持一致、出错后不容易通过肉眼发现。三项都满足，就说明这项工作应该从手工清单里移出去，交给可重复执行的规则。只满足一项时，手工仍然可以接受，不必为了“自动化”而提前增加复杂度。
哪些工作适合交给规则或脚本，哪些仍要人工判断
适合交给规则的工作，特征是判断标准明确、结果可验证。例如：页面标题是否为空、模板里是否缺少某个必要区块、内链是否指向已删除的页面、结构化数据字段是否与页面内容一致、更新日期是否超过规划书设定的周期。这些都可以用脚本扫描并输出清单，人工只需要处理清单里的异常项。
仍要人工判断的工作，特征是涉及取舍和语境。例如：某个栏目是否应该合并、某篇内容是否值得继续维护、页面之间的优先级如何调整。这些决定依赖对用户需求的理解，脚本只能提供数据，不能替你做判断。规划书里应该把这两类分开写，避免把需要判断的事写成机械清单，也避免把机械的事留给人工反复核对。
一个反例：规模变大也不该全面自动化
反例是内容质量审核。即使站点扩大到几千个页面，也不能把“这篇内容是否真正回答了用户问题”交给规则判断。规则可以检查标题长度、字段完整度、内链数量，但这些指标合格并不等于内容有用。如果规划书把质量审核也写成自动通过，结果会是页面数量继续增长，但真正能解决问题的页面比例下降。这个反例说明：规模扩大改变的是执行方式，不改变判断责任。适合自动化的是可验证的一致性工作，不是价值判断。
规划书里应该怎么改，下一步动作是什么
下一步动作很具体：在规划书里新增一节，把当前所有手工维护项列出来，逐项标注“判断标准是否明确”和“出错后能否被脚本发现”。两项都明确的，写成由脚本定时执行的检查项；只满足一项的，保留人工但加上复核节点；两项都不满足的，先不处理，等条件成熟再决定。
这个动作的结果会直接影响后续排期：被移出人工清单的工作不再占用编辑时间，编辑可以把精力放在内容判断上；仍保留人工的环节会因为有了明确复核节点而减少返工。规划书不需要一次写完所有规则，但需要明确哪些工作已经不适合继续手工做，以及由什么替代。只要这一步落实，规模扩大带来的维护压力就会从“人越来越忙”转成“规则越来越清楚”。
