Writing

最近在准备公司的一次内部分享，找资料的过程中发现了一篇论文《The Out-of-the-Loop Performance Problem and Level of Control in Automation》，主要是讲在自动化进程带来的一系列“脱离回路”和控制水平问题。

虽然是 30 多年前的文章，但是最近对所有产品都在推 AI 自动化的背景下，这篇文章的理论非常有指导意义。所以就简单分享一下，因为原文是英文，所以下面的很多内容可能带有较强的翻译腔，感兴趣的话也可以直接找到原文。

几个关键概念

Situation awareness（SA）： 态势感知，在回路过程中，对系统运行状态开展主动信息加工的核心认知能力。

Out-of-the-loop performance problem： 脱离回路绩效问题，这里的“回路”是指“观察系统 - 理解状态 - 作出决定 - 执行动作 - 获得反馈”的人机控制闭环。人即使仍坐在屏幕前，也可能因为不再亲自判断和操作而在认知上脱离这个闭环。

自动化： 系统代替人的参与流程的过程，AI 流程的推进在我看来也是自动化的一种。

整篇论文大致的方向是：脱离回路绩效问题已被广泛记录为自动化可能带来的负面后果。与一直以手动方式执行同一任务的操作人员相比，使用自动化系统的操作人员既不容易发现系统错误，也更难在自动化失效时改为手动执行任务。概括为两个问题：一是手动技能丧失，二是对系统状态和系统过程的感知丧失。

技能丧失

在一项模拟过程控制任务中，尽管参与者最初接受过手动操作训练，但那些一直担任自动化监督控制者的人，在让系统恢复受控状态时，比那些只以手动模式操作的人更慢、效率也更低。

大量使用自动设备会导致熟练程度下降。他们担心手动技能会因缺少使用而退化，以至于真正需要手动操作时，机组人员已无法熟练完成。

如果操作人员一开始就使用自动化系统，而没有积累充分的手动经验，他们可能根本无法积累或者学习到适当的技能。这些技能不仅对手动完成任务十分重要，对于发现何时需要转为手动操作也同样重要。先前拥有手动操作经验的人，在之后使用自动模式时，也比那些只使用过自动模式的人表现更好。这一发现支持了如下观点：手动经验对于形成识别自动化故障所需的技能十分重要。

态势感知丧失

本文的中心论点是：态势感知（SA）的丧失，是脱离回路绩效问题的重要根源。态势感知被定义为：在一定时间和空间范围内感知环境中的要素、理解这些要素的意义，并推测它们在不久之后的状态。因此，态势感知包括三个层级：

1. 一级态势感知（Level 1 SA）：感知与系统有关的状态变量；
2. 二级态势感知（Level 2 SA）：综合一级信息，并结合操作人员的目标，理解系统状态意味着什么；
3. 三级态势感知（Level 3 SA）：依据这种理解，推测系统未来的发展趋势和事件。

态势感知不足可能直接造成相当一部分脱离回路绩效下降。失去态势感知的操作人员可能更晚才发现问题；为了诊断问题并接管手动操作，他们还需要额外时间重新熟悉相关系统参数。

警觉性、自满与监控

自动模式会使操作人员较难察觉自动化故障，也较难发现系统状态的关键变化。举例：

Billings 报告了多起与自动化监控问题有关的航空事故，并认为以下两种情况会提高事故发生概率：（a）设备的行为看似合理，实际上却是错误的；（b）飞行员没有留意自动化系统当前处于什么状态。

自满被认为是自动化监控中警觉性不足的一个主要因素。Bergeron 指出，飞行员使用自动驾驶仪时，自动化程度越高，越容易不清楚自己身在何处。这至少有一部分被归因于自满，因为自满会使飞行员把注意力投入其他任务。人类控制者倾向于过度信任自动化系统，这被认为是造成自满问题的原因。

Billings 指出：设备如果极其可靠，随着时间推移，飞行员就会越来越依赖它。当设备极少见地发生故障或被禁用时，飞行员可能无法充分发现原本由该设备负责应对的状况。他举例说，曾有两架飞机在襟翼和前缘装置仍处于收起状态时尝试起飞，最终坠毁并造成大量人员死亡。

主动加工与被动加工

前文从警觉性不足和自满的角度讨论了系统问题发现延迟。此外，操作人员是被动的信息接收者，而不是主动的信息加工者，也可能使他们更难发现手动干预的必要性；真正需要干预时，他们也更难重新掌握系统状态。

反馈

系统反馈类型的变化或反馈的完全丧失，也是经常被提到的原因。如果没有适当反馈，人确实会脱离回路：他们可能不知道自己的请求是否已经被系统接收、动作是否正确执行，也不知道问题是否正在发生。

有时，自动化系统的设计会有意遮蔽操作人员所能获得的信息。许多系统的显示界面不再呈现原始系统数据，而是呈现经过处理、整合的信息。当显示的信息有误时，清晰且看似精确的显示结果会具有迷惑性。

自动化对态势感知的益处

自动化并不总会造成上述问题。Curry 和 Ephrath 发现，在一项飞行任务中，自动系统的监控者实际上比手动控制者表现更好。他们认为，原因在于监控者可以把注意力更合理地分配给其他显示信息，从而帮助自己发现系统故障；手动控制者则必须把注意力集中在范围更窄的一组线索上。

控制水平

如今，自动化越来越多地以人工智能或专家系统的形式用于高层认知决策任务。关于如何在复杂系统中成功实现 AI，人们已广泛讨论其技术与实践问题；然而，仍有一个重要问题需要解决：认知任务自动化会怎样影响操作人员的态势感知，以及他们在系统故障或能力不足时作出反应的能力。

为了获得认知任务自动化的积极收益，必须找到一种方法，在减少完全手动操作负担的同时，让操作人员继续主动参与决策回路，从而避免潜在负面影响。一种建议是选择恰当的自动化水平，使其尽可能减少对操作人员态势感知的负面影响。

自动化并非“全有或全无”，而是可以分成不同水平：

研究方法

原文对研究方法阐述了很多，我就不一一赘述了（其实是有些地方我也没看太明白…）。

可以理解为模拟一个“导航系统突然坏掉”的实验。验证：如果一个人之前长期依赖自动化，系统突然坏了，他还能不能快速、准确地接管？

找了 80 名大学生，分成 5 组，每组 16 人。这是“组间实验”，也就是每个人只参加其中一种条件，不会把五种模式全部体验一遍。

实验任务和测量

一个模拟汽车导航任务。每个情境都会给出一个小问题，例如：

• 你要选择哪条路；
• 哪条路更省油；
• 哪条路更快；
• 三条路线各自有一个系统估计的正确概率。

主要测量五件事：

1. 决策时间：选出答案需要多久；
2. 答案是否正确：是否选择最优路线；
3. 信心：对自己答案有多大把握，1 到 10 分；
4. 工作负荷：觉得任务有多累，用 NASA-TLX 测量；
5. 态势感知：是否理解系统之前做了什么。

态势感知又分为两层：

• 一级 SA：你记不记得系统做了什么；
• 二级 SA：你理不理解系统为什么这么做、这对整个任务意味着什么。

结果

系统故障前，参与者选择最高概率方案的比例约为 95%；故障后约为 94%。也就是说，自动化组的人并不是完全不会做题，正确率没有明显崩溃。

这是论文很容易被误读的地方。它发现的主要问题不是“答案错了”，而是“接管时变慢了”。系统坏掉后，之前越依赖自动化，决策越慢。

一级态势感知没有明显下降： 参与者大体还记得系统做过什么。所以不是说他们完全没看屏幕，也不是说他们完全走神了。

二级态势感知明显下降： 他们看见了系统的行为，但没有形成足够深入的情境理解。这正是论文所谓“脱离回路”的核心：人还在旁边，但已经不再主动参与理解和决策。

自动化组反而更有信心： 研究原本预计，依赖自动化的人在系统故障后会觉得自己能力不足。结果却相反：得到过系统帮助的人，信心更高，但他们的接管速度并没有因此更好。简而言之就是：没点 B 数。

作者倾向于推荐“部分自动化”

作者不是说自动化不好，而是认为不同任务应该采用不同程度的自动化。

对于重复、机械、外围的任务，完全自动化可能很好。

但对于直接关系到人类决策目标的核心任务，最好让人保留一定参与，例如：

• 系统给建议，但人自己作决定；
• 系统提出方案，但人必须理解后确认；
• 人可以否决系统；
• 定期让人亲自操作；
• 系统显示理由、依据和不确定性。

重点不是让人机械地点击“确认”，而是让人持续理解：

系统现在在做什么？为什么这样做？如果它失败，我下一步该怎么办？

结语

虽然论文发表于 1995 年，实验中的“专家系统”远不如今天的生成式 AI，但它提出的人机分工问题非常现代。像 AI Coding、自动驾驶、医疗与高风险决策支持、产品接入 Agent 自动化等方向，都有不菲的参考价值。

B端设计做了好些年了，没有哪个工具或者概念能给我的工作方式带来这么多改变。如果说变化最多的是什么，那就是累。AI增强我能力的同时，也让我的工作范围变得更广，工作事项更繁琐。从这点来说，我是很讨厌AI的。以下内容纯手打，0 AI 介入。 具体而言，AI主要帮我完成的内容包含三部分：分解业务和需求，设计灵感和 Review，以及 Coding。

分解业务和需求

B端业务都比较复杂，特别是我现在的行业。让我一个学设计的去理解包含了大量高阶物理/数学的需求还是太强人所难就。而 AI 会尽可能的通俗易懂的去把这些知识抽象出来，让作为普通人的我，也能比较容易的知道这个需求到底在干什么事。

这对我而言是非常非常重要的，B端设计，业务理解程度很多时候比设计能力要重要。所以现在我拿到 PRD 或者用户 Feedback 的第一时间，是喂给 AI ，让它帮我剖析成我更容易看懂的内容。

而在完成一个需求后，我会让 AI帮我整理PRD和我的设计，随后存在知识库里，在未来的设计流程中当成上下文来引用。为了知识库便于 AI理解，格式尽量统一，用 Skill来做是最合适的。比如我个人的 Skill：

这一阶段，我个人习惯用 Gemini 或者 Claude。

设计灵感和设计 Review

在这个阶段之前，一定要一定要一定要自己先去思考设计方案。不然容易被AI带偏，且形成依赖后，自身思考能力会快速下降。

我个人流程是：获取需求-Figma古法设计-AI设计灵感-AI review - 设计定稿。

在通过 AI 获取设计灵感的时候，上下文非常重要。可能遗漏一部分内容会得到完全不一样的回复。所以我让AI 分析完需求后要整理成知识库，知识库足够丰富后，在征求AI 意见的时候，调取需求相关的MD文档，更容易得到好的结果。

顺便说一下我个人的知识库思路，一个总的MD文档，介绍产品的背景，用户群体，解决的问题，以及大致的信息架构和功能等。然后按照功能切碎， 每一个小的功能点都整理成 MD平铺开来，想过分类汇总之类的，但功能错综复杂互相关联不太好分，干脆直接拍平拉倒。 这里用的AI是 Gemini 为主（推荐使用 Google AI Studio），偶尔用用Stitch。我个人感觉直接生成设计稿的 AI 思考深度没有生文的 AI深。 Stitch 给的视觉效果有时候还可以，会酌情采纳， 交互逻辑则有点一言难尽。

AI 的产出质量参差不齐，所以需要多多和它 battle 一下。但是 Gemini 的讨好型人格太容易顺从了，必须给它下达类似“务必诚实”的指令。

在综合 AI 的建议产出设计后，我会把自己的设计稿和理解扔过去，让 AI Review，会得到很多设计细节的补充。以及一大堆夸夸。 这一阶段，我个人习惯用 Gemini 或者 Claude。

Coding

我没有多少开发基础，所以 Coding 对我来说也是一次全新的尝试，往真实的复杂项目里提交代码是我以前不敢想的。
目前我通过 Coding 调整的只有交互和视觉，不涉及复杂的业务逻辑和接口联调。

很常见的场景就是修改和替换组件库，开发用的组件库是 Ant D（很多团队的选择），样式和一些交互上和预期有差距的，像这种就很适合设计师用 Cursor 之类的调整。举个实际的例子，线上环境 Dropdown 使用非常混乱，要统一成我们想要的样式，可以先排查，再纠正样式，最后逐步替换。

排查线上情况：

调整样式： 因为 Ant D组件被其他项目也引用了我不太好直接覆盖，而是再包了一层用在我的项目里。 新增组件后，顺带让 AI把 Storybook 也补充完善，方便预览和修改。需要注意的是，让 AI 做组件，前提是设计自己知道组件有哪些属性、类型等。毕竟让 AI完成的前提是自己知道想要什么。

至于让 AI还原设计的样式和细节，如果 Figma设计稿严格使用 Auto layout，那么更新后的MCP 我觉得已经勉强够用了，Opus 4.6第一遍就能还原大部分的设计细节，接下来的精雕细琢就多来几轮对话就好。不过我依旧习惯在让 AI还原设计稿的时候引入Skill，比如这是我根据我们项目和仓库创建的 Skill：

在组件达到预期后，就可以着手替换了