当页面、组件和内容数量增长到一个人无法在每次改版时逐一核对,手工维护交互优化就会从“细致”变成“不可靠”。判断标准不是工作量大小,而是这项工作是否依赖逐页记忆、是否每次都要重复同一判断、以及出错后能否被快速发现。适合保留手工的是高价值、低频、需要语境判断的决策;适合改写为规则或退出的,是重复、可枚举、结果可验证的执行环节。
规模扩大后,最危险的做法是把所有交互检查都交给工具,或者反过来坚持全部人工过一遍。更可行的做法是按“判断密度”和“重复频率”分三堆。
这个划分的前提是:团队已经能说清哪些交互属于关键路径。如果连关键路径都没有共识,先不要急着自动化,否则规则会把错误判断放大到全站。
最先失效的通常不是最复杂的工作,而是那些“每次都要记得做”的检查。它们有三个共同点:依赖个人记忆、没有固定触发时机、出错后不会立刻暴露。
这里要说明一个常见误判:如果某项检查的请求量或抓取量突然归零,不能单独证明“已经处理干净”。也可能是页面被合并、入口被移除、或者统计口径变化。要结合页面清单和负责人确认,再决定是否退出这项手工工作。
规模扩大往往伴随旧内容或旧系统退出。此时不要按“新旧”一刀切,而要看交互部分是否仍在承担用户任务。
假设一个旧版帮助中心准备下线,其中有一部分表单仍被用户用来提交问题。直接删除页面会中断任务;全部保留又会增加维护面。更合理的取舍是:保留表单本身及其提交入口,改写周边说明文字,退出已经无人使用的旧版导航和装饰性交互。判断依据可以来自两个方向:该入口是否仍有真实提交行为,以及是否有其他页面承接同一任务。前者说明用户还在用,后者说明可以迁移而不是硬留。
如果两个条件都不成立,退出是合理选择。但要先确认没有外部页面或旧邮件直接指向该入口,否则用户会落到空页面。这个确认动作本身也应该从手工通读改为按来源清单核对,否则规模一大就会漏。
把手工检查改写成规则,不等于追求全自动。关键是先定义“什么算通过”,再决定用什么方式检查。可验证的结果通常长这样:
这些规则可以用模板约束、构建检查或定期抽查实现。选择哪种方式,取决于团队已有的发布流程。如果发布流程本身不稳定,先修流程,再谈规则,否则规则会在不同环境里给出不同结果。
一个实际动作是:先选一个复用率最高的组件,把上述规则写成检查项,在下一次发版时运行。结果会直接影响下一步——如果检查能稳定发现真实问题,就扩展到同类组件;如果误报频繁,说明规则定义还不清楚,应先回到人工判断,而不是继续加规则。
退出不是删除记忆,而是把判断依据留下来,供下一次决策使用。至少保留三类信息:
当这三类信息齐备时,退出手工检查才是可复查的。缺少任何一类,规模继续扩大后,同样的问题会以另一种形式回来。反之,如果某项工作仍然高频、高风险、且没有稳定规则,就继续保留手工,并给它固定的触发时机和负责人,而不是靠临时想起。