协同需要知道其他操作员正在做什么而非仅自己的画面
别名: 团队活动觉察 · activity awareness · workspace awareness
概念解释
团队活动觉察（activity awareness）是知道同事正在查看什么、判断什么、准备操作什么，以及这些动作会如何影响共同的任务状态。它是态势感知（situation awareness）向团队层面的延伸：个体只对着自己那块画面维持三层态势感知——感知、理解、预测——并不够，因为共同任务的下一步取决于别人正在做的事，而不只是环境本身在变化。仅看自己的局部画面，容易出现重复操作同一个对象、下达相互冲突的指令，或者错误地等待一个其实没人在处理的动作。
机制
协同的核心是预测对方接下来会做什么，而不是记录对方已经做过什么。可见的选择对象、控制权归属、任务所处阶段和简短的状态更新，构成了做这种预测所需的最小线索；但如果把每一次微小的鼠标移动、每一次画面切换都同步给所有人，只会制造额外的监控负担，并把无关的细节也一并暴露出去。真正该呈现的是会改变对方下一步决策的那部分活动——也就是说，筛选标准不是"发生了什么"，而是"这件事会不会让队友做不一样的选择"。这与团队维持最小共同基础（common ground）并按需增量更新的做法是一回事：不必同步全部状态，只需同步会改变对方决策的那部分。
这层机制还有一个容易被忽视的翻转条件：活动状态一旦被展示出来，就会被队友当作可信信息使用；如果这个状态的更新延迟长于任务本身的决策节奏——比如某人已经换了操作对象，但界面上显示的"正在处理"还停留在几十秒前的旧对象——队友会基于这个过时信息做出错误判断，其后果比完全不显示活动状态更糟，因为"没有信息"会促使人去核实，"过时的信息"反而会被直接采信。换句话说，是否该展示活动状态，取决于状态更新延迟能不能压到低于任务的决策周期，这个条件一旦不满足，展示活动状态就从帮助变成了误导。
怎么研究
可以在协同仿真中操纵"是否提供活动状态反馈"这一变量，比较有无活动状态时的重复操作次数、冲突指令次数、澄清性沟通的频率和任务完成时间。更细一层的检验是对照操作日志核算察觉延迟：把队友某次状态变化的时间戳，与另一方随后引用或响应这次变化的时间戳对齐，计算两者之间的滞后；如果这个滞后经常超过任务允许的决策窗口，说明活动状态的呈现速度本身就是瓶颈，而不是操作员不看画面。
访谈还应该检验成员是否真正理解了对方动作背后的意图，而不是只看到一个光标在移动、一个按钮被点亮——单纯的动作可见性和"看懂对方在干什么"是两件事，前者容易做到，后者才是活动觉察真正要解决的问题。
边界
- 状态可见不等于意图清楚：界面显示"操作员乙正在处理阀门 A"，不代表甲能推断出乙打算做什么，尤其是在乙的动作偏离常规流程时。
- 自动生成的"忙碌/空闲"标记依赖轮询或心跳机制，一旦更新延迟超过任务节奏（见上一段的翻转条件），这类标记反而会被当作过时信息之外的确定性证据来用，风险高于不显示。
- 隐私、访问权限和网络时延共同限制了可共享的活动范围：跨安全域、跨企业边界的协同往往无法直接镜像原始画面，只能传递经过抽象的状态摘要。
- 团队规模一旦大到无法把每个人的相关活动都控制在注意力预算之内，就不能靠全量广播解决，只能进一步收紧"会改变决策"这条过滤标准；否则活动觉察本身会变成新的干扰源。
- 异地或跨站点的操作员看到的资产上下文不同，直接镜像原始画面对他们意义有限，需要先做一层与其本地上下文对应的转译。
- 真正意外、超出常规流程的紧急动作，仍需要口头广播确认，不能只依赖界面上的活动状态取代通话。
怎么落地
- 展示操作者、操作对象、动作所处阶段、当前控制权归属和最近一次更新时间，优先呈现那些会改变其他角色下一步决策的动作，而不是全部动作。
- 对高后果操作提供意图预告：在真正下达指令之前，先在共享画面上标出"即将操作"的对象和方向，给队友留出提前介入或提出异议的时间窗口。
- 明确标出活动状态的新鲜度，比如附上更新时间戳或到期变灰，避免队友把过时状态当作当前事实。
- 验证办法：设计两个工位并行处理相关联故障的演练并全程录屏，事后逐条核对每次下达指令之前，另一方画面上是否已经出现足够提前量的意图预告；同时对照操作日志计算冲突指令发生前活动状态的更新滞后，找出滞后明显偏长的场景作为改造对象。