自动化悬崖：当部分 AI 自动化比完全不自动化更糟糕时

当一个团队第一次将 70% 的手动流程自动化，却交付了比以前更差的结果时，诊断几乎总是从错误的地方开始。工程师们会检查自动化部分：也许是模型准确率不对，也许是流水线有 Bug。他们很少检查的是，自动化本身的存在——仅仅因为它的存在——是否使得剩余 30% 的人工工作在结构上变得无法做好。

这就是自动化悬崖。这不是自动化组件的失败，而是自动化与手动之间衔接处的失败。

这种模式出现在航空、医疗、软件工程以及现在的 AI 驱动产品中。部分自动化并不只是将任务划分为“计算机处理的部分”和“人类处理的部分”。它降低了人类处理其部分的能力，分散了失败的责任，并创造了一个实际上无人监管的系统。四十年来，研究对此一直很明确。AI 工程界正在实时地重新学习这一点。

没人读过的基础见解

1983 年，Lisanne Bainbridge 发表了一篇名为《自动化的讽刺》(Ironies of Automation) 的论文，准确地指出了这个问题。这篇论文被引用了 1800 多次。但几乎所有发布 AI 功能的人都没有读过它。

Bainbridge 的核心观察是：自动化后留给人类操作员的任务，恰恰是自动化失败的任务——边缘案例、故障状态、模糊情况。这些是最难的任务，而不是最容易的任务。但自动化系统却在相反的方向上训练人类。当自动化处理了所有常规事务时，人类的时间花在监控而不是操作上。他们的技能会退化。他们对系统的心理模型会发生偏差。然后，当自动化失效并将控制权交还时，他们被要求在能力已系统性下降的情况下，发挥出巅峰水平。

她称之为“练习悖论”。操作员不会在日常工作中练习技能，因为自动化处理了这些情况。但自动化最终会遇到它无法处理的情况，并在高风险的情境下，毫无预警地要求操作员立即展现出这些技能。

Bainbridge 针对核电站和过程控制系统写下了这些。它同样适用于过去五年中构建的每一个 AI 辅助工作流，无需任何修改。

四种致命机制

研究文献指出了四种不同的机制，通过这些机制，部分自动化产生的结果比全手动工作更差。准确命名它们是有意义的，因为它们的表现形式不同，需要的应对措施也不同。

警觉性下降。 监控可靠自动化系统的人类操作员，在持续监控 20 分钟内，检测系统故障的能力就会出现明显的下降。这不是注意力或培训的失败——这是人类认知中根深蒂固的特性。对一个几乎从不出错的系统进行持续监控，会使大脑转向被动的、低参与度的模式。对部分自动驾驶的研究表明，随着时间的推移，驾驶员从事次要任务（玩手机、阅读）的频率越来越高，正是因为系统之前一直表现良好。当系统不再正常工作时，恢复时间是灾难性的。

一个反直觉的推论是：偶尔失败的自动化实际上比几乎从不失败的自动化能产生更好的警觉性。可变的可靠性让由于人类参与其中。近乎完美的可靠性则将他们排除在外。

技能退化。 如果自动化组件处理了某一类任务的所有实例，人类就会丧失手动执行该类任务的能力。这一点显而易见。不太明显的是时间线——它比大多数团队预期的要快——以及复合效应。2009 年法航 447 号航班坠毁，原因是皮托管结冰，导致空速数据失效并使自动驾驶仪脱离。两名飞行员在近期的记忆中都没有练习过在高空手动飞行，未能识别并从持续四分钟的失速中恢复。自动化已经足够可靠且持续了足够长的时间，以至于在它失效时生存所需的技能已经消失了。

责任分散。 当自动化和人类共同分担一项任务时，问责制就会支离破碎。在航空领域，空难后的问题是飞行员是否应该覆盖自动化，自动化是否应该表现不同，或者是两者之间的移交设计是否存在缺陷。在 AI 放射学中，当发生 AI 辅助的误诊时，问题在于放射科医生未能发现 AI 的错误，还是 AI 未能发现病灶。在 CI/CD 流水线中，当自动化代码审查遗漏漏洞时，问题在于开发人员是否应该更仔细地审查，还是工具失效了。

这种碎片化的心理效应是可预见的：每个人都减少了努力，因为每个人都期望别人能发现失败。链条末端的责任方——人类操作员——降低了警觉，因为自动化系统本应处理好它。结果是，一个自动化率为 95% 且仅有名义上人工复核的系统，其结果往往比具有真实人类责任感的全手动系统，或完全没有人类假装复核的全自动系统都要差。

手动残余部分的误差累积。 自动化留给人类的任务系统性地变得更难。自动化系统针对中位数情况进行了优化。它们处理规范的输入、常见的模式、看起来像训练数据的情况。它们路由给人类的是边缘案例、模糊情况和高风险的异常情况。人类操作员由于监控而感到疲劳，由于缺乏练习而技能退化，并且在更广泛的系统中分散了责任，现在正在处理工作流中最难的情况。这些情况下的错误率很高。由于整个系统看起来运行良好（自动化部分处理了 95% 的业务量），没有人以适当的审查来审视人类处理的尾部情况。

你在软件工程中见过这种现象

静态分析误报问题是一个典型案例。自动化的代码检查（linting）和安全扫描工具会产生 30% 到 60% 的误报率，具体取决于配置。开发者的反应是任何理性的人都会做的：他们学会了忽略警告。在部署新的代码检查工具后的几个月内，告警疲劳会变得非常彻底，以至于开发者根本不再调查任何标记。本应提高代码质量的工具，反而让开发者习惯于将安全标记视为噪音。

剩下的问题是：该工具对真实漏洞有 22% 的漏报率。这些漏洞正被标记（有时）并被忽略（现在已成常规）。团队的安全态势比引入工具之前更糟，因为该工具创造了一种安全覆盖的假象，却未能实际提供，并在此过程中削弱了本可以发现这些问题的人工评审习惯。

同样的模式也出现在不稳定的测试套件（flaky test suites）中。时而通过时而失败的测试会训练团队重新运行失败的任务，而不是去调查原因。CI 流水线名义上是为了捕捉回归（regressions）。实际上，团队已经被训练得只要重试通过就批准构建。自动化并没有提升质量保证；它创造了一种质量保证的仪式感，却掩盖了其实际的缺失。

加载中…