网站重新上线：网站规模扩大后哪些工作不适合继续手工做
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; ShapBot/0.1.0
🔗 /e78aa347db9a.html
📄
网站重新上线：网站规模扩大后哪些工作不适合继续手工做
网站重新上线后规模扩大，最先暴露的往往不是技术问题，而是协作问题：同一批页面，运营说“已经处理完”，开发说“没收到清单”，SEO 说“线上还是旧标题”。手工维护在页面几十个时可行，到了成百上千个，问题不再是做得快不快，而是没人能说清当前状态。判断一项工作该不该继续手工做，关键看它是否满足三个条件：改动频率高、判断规则可以写清楚、出错后能通过线上结果核对。满足得越多，越应该交给脚本或系统；只满足一两个，手工反而更稳。
先区分两种解释：是执行不到位，还是手工方式本身撑不住
面对“同一事实不同理解”，常见两种解释。
第一种是执行问题：清单没同步、责任人漏做、交接时口头传递信息。这种情况下，把任务分派清楚、加一次复核就能改善。
第二种是方式问题：工作本身依赖人工记忆和逐个操作，规模一上来，遗漏是必然结果。此时加人只能延缓，不能消除。
区分两者的证据不在会议记录里，而在线上可核对的结果中。选一批有代表性的 URL，分别记录手工处理前后页面标题、正文关键字段、链接指向的实际值，再和任务清单逐条对照。如果清单标记完成、线上却仍是旧值，且这种情况集中在“需要逐页复制粘贴”的环节，更可能是方式问题；如果线上值正确、只是不同角色看到的清单版本不一致，更可能是执行问题。这个动作的结论会直接决定下一步：前者要改流程和工具，后者只需统一信息源。
规模扩大后，这几类工作继续手工做的代价最高
以下判断不依赖具体工具，只看工作特征。
- 批量标题、描述与结构化数据的生成和校验。规则一旦确定，人工逐页填写既慢又难保持一致。适合脚本生成候选值，再由人抽查。前提是规则本身已经稳定；规则还在频繁变时，先手工试几页反而更快。
- 站内链接与失效链接的巡检。页面越多，人工点击越不可行。可定期抓取并输出异常清单。注意抓取量下降不等于问题解决，可能是抓取被限制、站点结构变化或临时故障，需要结合服务器日志和实际返回状态判断。
- 重定向规则的维护。旧链接到新链接的映射一旦超过几十条，手工维护容易冲突和遗漏。适合用映射表统一管理，上线前先在小范围验证。
- 发布前的固定检查项。如必填字段、重复标题、页面可访问性。这些规则明确、结果可核对，适合自动化拦截。
反过来，下面这些不适合过早自动化：内容选题判断、页面质量的主观评估、涉及品牌语气和合规的最终审核、规则尚未稳定的新流程。它们的共同点是判断标准难以写成确定规则，或者出错代价高但发生频率低。
一个假设例子：如何用一次核对决定要不要写脚本
假设重新上线后站点从 200 个页面扩到 2000 个，运营每周更新约 50 个页面的标题和描述。团队争论是否值得投入做批量处理。
可以这样设计核对：随机抽取 100 个近期更新过的页面，记录任务清单中的预期值和线上实际值，统计不一致的数量及原因。假设结果是不一致集中在“同一模板批量修改”的页面，而单独修改的页面基本正确，那么更合理的动作是先为批量修改场景建立规则表和校验脚本，而不是全面自动化。执行后再次抽查同一批页面，如果不一致减少，说明方式问题得到缓解，下一步可以扩展到其他规则明确的环节；如果没有改善，说明问题出在信息同步或权限，需要回到执行层面处理。
这个例子中的数字仅用于说明比较方法，不代表任何实际站点的表现。
把分歧转成可核对项目的三个动作
- 为每项争议工作定义一条可在线验证的断言。例如“所有已发布页面的标题与规则表一致”，而不是“标题都处理好了”。
- 指定一个中立的核对人。由不直接执行该项工作的人按断言抽查，避免执行者自证。
- 记录核对结果对应的下一步。一致则维持手工或降低频率；不一致且原因集中在批量操作，则转为脚本或系统处理；不一致但原因分散，则先修信息同步。
网站重新上线后，抓取、索引和排名是不同环节，某项数据变化不能单独证明手工或自动哪个更好。能帮助团队作决定的，是把“谁说得对”变成“线上实际值是什么”，再根据不一致的分布选择继续手工还是改为自动。这样每次争论都会留下可复核的记录，下一次判断会更快。
