写下思考

最近在准备公司的一次内部分享，找资料的过程中发现了一篇论文《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 的。

具体而言，AI 主要帮我完成的内容包含三部分：分解业务和需求，设计灵感和Review ，以及Coding 。

分解业务和需求

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

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

而在完成一个需求后，我会让 AI 帮我梳理成 MD 文档，存在知识库里，在之后的设计流程中当成上下文来引用。
建议用 Skill 来将需求转为知识库的，例如：

这一阶段，我用 Gemini 或者 Google AI Studio ，以及 Claude。

设计灵感

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

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

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

我一般是这么整理喂给 AI 的知识库：一个总的MD，主要介绍产品的背景，用户群体，解决的问题，以及大致的信息架构和功能等。其他的 MD 则按照功能划分（每个产品都不一样且也看个人习惯）。

这里用的AI还是 Gemini 为主，偶尔用用 Stitch ，我一直认为直接生成设计稿的 AI 思考深度没有生文的 AI 深。Stitch 给的视觉效果还可以，会酌情采纳。

当然 AI 很多时候给的东西我也是不认可的，所以会和他 battle 一下。但是 Gemini 的讨好型人格太容易顺从了，必须给它下达类似“务必诚实”的指令。

AI Review 的阶段，把自己的设计稿和理解扔过去，会得到很多设计细节的补充。比如一些状态，描述等等。

Coding

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

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

比如这是线上情况：

然后调整样式：

通过 Figma MCP 就能还原不少视觉了，对不满意的地方持续的对话就好。同时这一步也建议使用 Skill，可以自己写一个适合自己的，例如：

等组件达到预期，就可以正式替换了

复杂不是信息很多，而是关系很难判断

面对一个功能密集的产品，我不会立刻开始整理页面。更重要的问题是：用户此刻需要做出什么判断，以及系统必须提供哪些信息才能让这个判断成立。

复杂度可以被拆成三个层次：目标、状态与动作。目标解释为什么来到这里，状态说明现在发生了什么，动作则告诉用户下一步能做什么。

清晰不是删掉所有信息，而是让信息在真正有用的时候出现。

先画出主线，再处理支线

我通常从一个最短的成功路径开始，把异常、协作与高级配置暂时放到路径之外。这个过程不是忽略边界情况，而是先建立一个稳定的参照系。

1. 写出用户想完成的结果。
2. 标记过程中不可逆的决定。
3. 找出必须被持续感知的系统状态。
4. 最后才决定页面、组件和交互形式。

主线成立之后，支线才有明确的挂载位置，团队也更容易判断一个新需求应该出现在哪里。

组件只解决了可见的一半

组件库可以减少重复劳动，却不能自动让团队形成一致的判断。如果一个组件为什么存在、什么时候使用以及允许怎样变化都不清楚，它很快会成为另一套需要维护的库存。

真正有效的设计系统同时包含三种东西：可以复用的组件、可以讨论的原则，以及遇到例外时可以执行的协作方式。

让规则能够被校准

规则不应该只存在于设计文件里。它需要与代码、产品决策和真实使用反馈形成闭环。

• 组件说明回答“怎么用”。
• 设计原则回答“为什么”。
• 评审与贡献流程回答“如何改变”。

当这些内容能够被团队持续修正时，设计系统才开始成为一种组织语言。

自动完成不等于替用户决定

AI 可以快速生成方案、补全步骤和处理大量材料，但它并不知道一个结果对用户意味着什么。产品需要明确区分哪些工作可以委托，哪些决定仍然应该由人确认。

我更关心的不是“AI 能不能做”，而是下面三个问题：

1. 用户是否知道系统正在做什么？
2. 用户能否理解结果来自哪些依据？
3. 出现偏差时，用户能否低成本地修正？

保留意图与责任

好的 AI 交互会降低执行成本，同时保留人的意图、判断和最终责任。真正值得设计的，往往就是这些不能被自动化的部分。

工具应该减少切换

我的工作台并不追求工具最多，而是尽量让记录、探索、设计与实现之间少一些中断。重要的材料会留下稳定的位置，临时想法则允许快速进入、快速离开。

给思考留出没有产出的时间

有些问题不能通过继续移动图层解决。我会刻意保留散步、阅读和不打开设计软件的时间，让尚未成形的判断有机会慢慢浮现。

这套系统的目标不是让每一分钟都高效，而是让我可以长期、稳定地保持好奇与产出。