网站故障修复，规模扩大后哪些工作不适合继续手工做
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /48ec35ea85e5.html
📄
网站故障修复，规模扩大后哪些工作不适合继续手工做
当站点从几十个页面长到几千个、从一个人维护变成多人协作时，真正该停掉的手工操作不是"全部自动化"，而是那些结果不可复核、依赖个人记忆、且出错后影响面会随规模放大的工作。判断标准可以落到一个具体对象上：你手里那份记录页面状态的资料。如果它只能靠人逐条打开页面确认，规模一大就会先失真，再拖慢修复决策。
先拿一份资料做判断：哪些手工动作会随规模失效
假设你手上有一份列出全部待检查页面的清单，每行是网址、上次确认时间、当前状态。页面只有几十个时，人工逐条打开、肉眼比对、手动改状态是可行的。规模扩大后，同样的动作会出现三种失效：
- 覆盖失效：人只能抽查一部分，未抽查的页面状态变成盲区。
- 时效失效：清单更新速度赶不上页面实际变化速度，资料很快过期。
- 一致性失效：多人各自记录，同一页面的状态出现互相矛盾的版本。
这三种失效不需要精确统计就能识别：只要你发现"上次谁改的、改成什么"要靠问人才能还原，这份资料就已经不适合继续手工维护。
适合保留手工的三类工作
不是所有手工都该停。以下情况继续人工反而更稳：
- 需要判断意图的工作：例如判断某个页面内容是否真的答非所问，这依赖对业务的理解，脚本只能标记异常，不能替你下结论。
- 低频且高影响的工作：例如整站结构级调整，一年做几次，人工复核成本可接受，出错代价却很高。
- 规则尚未稳定的工作：当判断标准还在变，先手工跑几轮把规则固定下来，再考虑自动化，比先写脚本再反复改更省事。
换句话说，手工适合处理"每次都要重新判断"的事，不适合处理"判断标准已经固定、只是重复执行"的事。
把手工动作拆成可执行方案：一个假设例子
假设你的清单里有 2000 个页面，需要定期确认它们是否仍能正常访问、标题是否被意外改动。手工做法是逐条打开。可执行方案可以这样拆：
- 第一步，固定检查规则：明确"正常"指返回成功状态、标题与基线一致。规则不固定，自动化只会把混乱放大。
- 第二步，批量取回状态：用脚本按清单批量请求页面，把状态码和标题写入结果文件，而不是人工打开。
- 第三步，只把异常交给人：结果文件里正常项自动归档，异常项进入待处理列表，人工只看这份短列表。
- 第四步，用结果决定下一步：如果异常集中在某一类页面，说明问题出在模板或发布流程，修复方向应指向流程；如果异常随机分散，才逐页处理。
这个例子的关键不是用了什么工具，而是把"全量人工确认"压缩成"人工只处理异常"。假设原来 2000 条都要人看，现在只看几十条异常，节省的时间可以投到规则维护上。数字仅用于说明比较方法，不代表你的实际比例。
注意：某些现象归零不等于处理正确
把手工改成批量处理后，你可能观察到待处理列表变短，甚至某类异常归零。这不能单独证明修复正确。合理解释至少还有：检查规则写得太宽，把真异常漏掉了；请求被目标站点限流，部分页面根本没取到；清单本身漏了页面，没被检查自然没异常。要区分这些原因，可以保留原始结果文件，对比"检查覆盖数"和"异常数"两个量，而不是只看异常数下降。
什么时候该停、什么时候该继续手工
可以用一个条件判断：当同一判断规则需要重复执行超过你能稳定复核的次数时，就该转为批量处理；当规则本身还在变、或需要业务判断时，继续手工。前者对应状态检查、链接确认、标题基线比对这类工作；后者对应内容质量评估、结构决策这类工作。规模扩大带来的真正变化，是"重复执行"的量超过了人工可复核的边界，而不是手工本身错了。
落到动作上：先选一份你正在手工维护的清单，标出其中判断标准已经固定的字段，把这些字段改成批量取回、人工只审异常。跑完一轮后，用覆盖数和异常数的对比判断方案是否成立，再决定扩大范围还是回到手工。
