第 12 章：人机协同决策（Integrating Automation with Humans）

12.1 人的能力与应对（Human Capabilities and Coping）

人机集成在实际项目中往往是事后才被想起，甚至在预算紧张时被直接砍掉。设计者往往默认人类具有足够的弹性与适应力，可以弥补技术系统的脆弱。本节从感知与认知两条线索出发，介绍人的能力边界与典型应对策略，并整理出一份贯穿全章的设计注意事项表（Table 12.1），把工程化建议以"工作分析、注意/记忆/认知加工、决策"三类展开。

12.1.1 感知与认知能力（Perceptual and Cognitive Capabilities）

信息处理的三块核心能力是注意、认知和记忆（[2], [3]）。人先感知环境信息，注意机制把其中一部分"放行"进入后续加工，被注意到的内容再借助记忆进行认知处理，最终形成对情境的理解。注意被比喻为过滤器、聚光灯和水池三种形态，其焦点随信息的显著性或人的主动调控而变化，例如控制台上闪烁的异常读数会立即吸引注意力，又如嘈杂派对中仍能听清一段低语的故事。

注意并非单一资源，而是分布在多个通道上，包括感知通道（听觉/视觉）、处理代码（空间/言语）、加工阶段（感知/认知/响应）等。例如边听带歌词的音乐边做数学题比同时阅读小说更可行——后者会与歌词争夺言语资源；又如在熟悉的公路上驾驶能保留较多对话资源，但在陌生路段则极易过载感知和认知注意。

短时记忆容量是有限的，经典结果是 7 ± 2 个互不关联的孤立项目；但记忆高手经过训练后能记住数百个无关联项目。专家的优势在于能将项目以功能关系组织起来，从而突破容量上限——飞行员与管制员必须熟记数百页程序与标准，并在时间压力下调用。一旦信息通过练习或显著性从短时记忆进入长时记忆，便可在多年后仍被召回；不过长时记忆也会衰减，所以关键信息需要周期性复训。

认知加工是信息处理的主战场。两种典型模式是自下而上与自上而下加工：婴儿或处于陌生情境的人几乎只用自下而上，注意力被显著特征捕获并由这些特征驱动理解（典型问句："这里在发生什么？"）。随着经验积累，长时记忆中的先验成为提示，人得以用自上而下加工去验证或否定对情境的假设（典型问句："这正是我所想的吗？"），例如看到红黄绿三灯上下叠放能立即被识别为交通灯。复杂领域里，专家把系统状态的某些时序模式与特定画面联系起来，资深管制员可凭两次雷达扫描判断是否存在潜在的间隔冲突。

12.1.2 自然主义决策（Naturalistic Decision Making）

信息处理与理解之后，人需要做出反应决策。决策建模的两条路线是经典决策理论（规范性模型，描述决策"应该"怎么做）和自然主义决策（描述性模型，描述决策"实际"怎么做，参见 [14]）。经典决策要对候选方案的效用做定量评估（见第 3 章及 [15]），但现实中要么拿不到所需数值，要么没有时间与认知资源去完成计算。

描述性模型揭示了实际决策的若干规律。Satisficing（满意即可）是一类典型方法——人不枚举全部候选，而是找到"够好"的方案就停止。例如飞行员绕航避天气时，不会把所有备选航线一一评估，而只会挑一条偏离原计划最小、且不受天气影响的航线，哪怕它并非全局最优。Kahneman、Slovic 与 Tversky 总结出多种启发式（见 [17]）：可得性（availability）让人倾向于选择最近或最频繁想起的方案；代表性（representativeness）让人倾向于把方案与已知的相似方案归为同类；锚定（anchoring）让人在初始数值估计之上做后续调整，初始值构成锚并使后续估计偏向初始方向。这些启发式减轻了工作记忆与认知加工的负担，但代价是结果可能"次优"却高效"够好"。

描述性模型之后，研究者开始对消防、航空、医疗、军事等领域内的真实专家做现场观察。这类情境的共性是时间压力、高风险、训练充分、信息不充分、动态变化、团队协调（[18]）。有专家被问及决策过程时说："我不做决策，我不记得自己做过决策"（[19]）——意思是几百次相似经历已经让某一选项在专家脑中"显然"被识别为可行。这种把当前情境与先前的相似经验做模式匹配，从而快速得出满意行动方案的过程，称为识别启动型决策（recognition-primed decision making）。

识别启动型决策建立在专家对系统的心理模型（mental model）之上。心理模型是对真实系统的表征，使人能接收环境信息并预测其后续演化（[20], [21]）——消防员对不同建筑的火势蔓延有模型，气象预报员对对流性雷暴生消有模型，飞行员对飞机响控制输入有模型。心理模型既要简单到能让人快速跑心算，又要足够丰富以涵盖关键复杂性，并能迁移到相似情境，例如波音经验有助于预测空客的响应，但并非总准确。经验积累后，专家会知道哪些模块对预测关键、哪些可丢弃以减轻负荷。

专家另一种简化方式是用情境结构（structure）约束可能性。结构是关于系统运行的共享知识，从根本上限定了系统状态的演化（[22], [23]）——结构既可以是系统固有属性（如波音 737 的最大上升剖面），也可以是人工事先强加（如纽约都会区机场的进出港程序）。掌握结构，飞行员便知飞机不可能一分钟爬升到三万英尺；管制员按 LaGuardia 离港程序放行，便能保证不会与 Newark、JFK 的进出港发生间隔冲突。结构知识既能帮助预测，又能把不可能的演化筛掉以节省认知资源。

12.2 在设计中纳入人（Considering the Human in Design）

上一节阐述了人的能力与局限，本节讨论这些能力与局限对系统设计的影响。Table 12.2 把设计注意事项按三类组织：信任、不确定信息、长时程决策。

12.2.1 信任与决策逻辑透明度的价值（Trust and Value of Decision Logic Transparency）

把决策支持系统部署到现场，首先要让用户信任系统提供的信息与建议（[24], [25]）。这里采用的信任定义取自 Muir（[25]）：信任是系统成员对另一成员的可靠与胜任表现的预期，与客观可靠与胜任既相关又不完全等同。"可靠"指表现一致可预测，"胜任"指在指定边界与约束内执行所分配功能。信任不等同于客观测度这一事实，意味着存在感知偏差——偏差可能源于前述认知加工局限、信息不足无法准确反映可靠与胜任，或"故意性信任失调"。故意性失调包括：人因对自己能力缺乏信心而过度依赖系统，或因对自动化的普遍不信任、担心被取代而拒绝使用系统。

建立对决策支持系统的恰当信任需要两条支柱：(1) 了解系统的能力与能力边界，(2) 了解系统提供的信息与建议的可靠性。

有些决策支持系统很简单，例如一个紧凑算法，其输出可靠性只要算法实现正确便一目了然，更重要的是用户能把系统内化为一个完整的心理模型。逻辑简单的好处是用户能完全理解，从而准确预测系统的行为与边界。波音 767 水平状态显示器上的"绿弧"就是一个例子——它用线性外推给出飞机将在何处截获所选高度（Figure 12.1），但没考虑飞行管理系统里飞行员预置的意图；当一次模拟进近中飞行员反复改变俯仰、观察绿弧变化时，几百次反馈足以让其掌握绿弧功能与限制。

然而，复杂动态环境里多数决策支持系统极其复杂，验证可靠性本身就困难，因为存在难以预料的突发行为。受认知与记忆局限的约束，即便专家用户也难以完全把握系统的所有细节。但用户仍需要一个"够用"的心理模型——细节多少要靠用户、训练者与设计者在迭代中共同决定：训练太少会得到低细节心理模型，用户预测不准，导致不信任；训练过多又会超出人的注意力与理解力，反而把主要功能淹没在次要细节里。

系统的客观可靠性与胜任是确定的，但如定义所言，信任还包含感知维度，从而可能产生不反映客观事实的失调（miscalibrations），包括不信任、麻痹、滥用与故意性失调（[24], [25]）。用"可信度"刻画客观可靠性与胜任的组合（Figure 12.2）：把"信任"作为"可信度"的函数画出，完美校准应为一条对角线——信任随可信度线性上升；偏离对角线就出现某种失调。

信任偏低于对角线即"不信任（disuse）"，表现为对自动化的忽视或低使用率（[24]）。系统误警过多会把用户推向过度谨慎，造成弃用。信任偏高于对角线即"麻痹（misuse）"，表现为对自动化的过度依赖，可能导致监测失灵或决策偏差（[24]）。当系统长期给出准确建议时，用户倾向于降低认知投入，不再仔细权衡系统建议就直接行动；当系统反馈不足以让用户察觉其变差时也会出现麻痹（[26]）。

"滥用（abuse）"有多种形式。最常被讨论的是设计者过度自动化一个功能，留给人的只是监督或监控的角色；当自动运转良好时，人长期保持警觉会产生压力与疲劳（[27]）。另一种滥用是用户把系统用于设计者未预期的用途——多数情况下这些用途富有创造性，但同时把系统的胜任边界拉伸到设计者未曾覆盖的领域。M-PESA 就是一个典型例子：这是一个用于为预付费手机充值的小额转账服务，但肯尼亚等国本土银行体系不稳定，用户对它的信心超过本土银行，把它当成事实上的银行系统使用，由此引发了原系统不要求、但银行业务必须满足的客户端信息保护问题（[26]）。

12.2.2 针对不同确定度设计（Designing for Different Levels of Certainty）

设计决策支持系统需要在"提供信息/建议以支持所需决策"与"顾及人处理能力的边界"之间取得平衡，设计过程往往要迭代。为恰当校准用户信任，设计者须根据领域确定信息层级与类型的平衡点。本节针对决策支持的不同确定度给出若干设计考虑。

当决策支持系统能给出明确答案时，它应当：

1. 以决策本身的术语给出信息或建议。算法设计者往往按"待解问题"的术语思考信息，而用户解读信息需要的是另一种术语。决策支持输出生成之后，必须由设计者翻译成能融入用户情境的术语与形式。以航空天气决策支持为例，仅给出当前与未来的天气状态并不足以称为"决策支持"——要把天气翻译成面向运行决策的建议；空中交通管制员关注的不是"现在和未来的天气如何"，而是"是否要因天气关闭这条离港航路、何时关闭"。

2. 及时给出信息或建议。一些决策需要提前数小时做出，而另一些是秒级时间关键的——同样的系统输出，若给出的时刻不对，就支持不了对应的决策。

3. 可靠地给出信息或建议。如前所述，系统可靠性是用户建立信任的关键，必须在多种情境下评估可靠性后再投入运行。

4. 提供频繁观察信息或建议可信度的机会。设计者要向用户定期传达系统在不同情境下的可靠与胜任，以及建议被执行或未被执行后的反馈。仅靠一次性的客观测度，校准不出真正的信任。

5. 提供建议背后的推理依据。对长时程决策系统而言，用户有余裕消化补充信息；在"信息过载"与"信息不足"之间存在权衡，但已有研究表明展示建议背后的推理能帮助用户理解系统并提升信任。

当决策支持系统所依赖的信息本身具有不确定性、且每条信息附有置信度时，还要考虑额外因素。最好同时给出置信度指示，以及帮助用户理解"系统认为不确定之处"的补充信息。下面以 Route Availability Planning Tool (RAPT) 为例。

RAPT（Figure 12.3）是一个帮助空管管理者判断机场离港航路是否被天气阻塞、并寻找未阻塞替代航路的工具。它为每条航路在未来 30 分钟内每 5 分钟一个时间点分配一个状态颜色——红（阻塞）、黄（受影响）、深绿（影响轻微）、绿（通畅）。其状态由两部分组合得到：Corridor Integrated Weather System (CIWS) 提供的确定性天气预报，加上一个考虑离港空域使用情况的航路阻塞算法。航路阻塞模型计算该航路前 45 分钟飞行时间内天气影响的严重程度。该工具的不确定性既来自天气预报的准确度，也来自对飞行员是否会飞入不同天气类型的判断。当为每个颜色建议确定阻塞级别时，算法本身的信任问题就出现了。RAPT 自 2003 年起持续原型迭代，期间反复调整算法以更贴合管制员对"应当给出什么指引"的预期，并对算法在雷暴天气下提升离港流量的量化效果做了改进（[28]）。

在 RAPT 的纽约原型中，设计者决定在"信息相当确定"时显示绿色或红色，在"存在不确定"时给出黄色。雷暴情境下黄色建议因此较多。设计者随后通过训练让用户在出现黄色时主动去看附加信息——他们需要的是该航路的天气在波动性、范围、严重程度、地理分布与影响位置上的细节（[29]），例如弹窗里展示的过去阻塞色状态与该离港航路上的回波顶高度。回波顶重要是因为雷暴有自然生消周期，回波顶高度是其中一项指标。除此之外，管制员还可以参考 RAPT 时间线上方的 CIWS 天气图，其中展示了风暴地理位置与风暴类型（如可预报的锋面或较难预测的"爆米花"对流）。结合这些附加信息，管制员可以用自己的判断决定是否与何时开放或关闭离港航路，从而最大限度利用可用容量。

系统给出误导信息或糟糕建议是设计中要面对的现实。不确定信息的解读加上现实情境的复杂性，使得任何决策支持系统都不可能永远正确。此时系统团队中的另一成员——人——必须维持整体系统的正常运行。贯穿整个设计过程，设计者都必须考虑人在系统中的角色：为了在系统出错时人能介入或补位，人的角色必须在"好日子"与"坏日子"都是主动的。设计者影响人与决策支持及环境交互的主要渠道是训练：训练通常在系统安装时或用户上岗时一次性提供；偶尔会有复训机会来唤起用户对工具细节的记忆。

训练要解决的问题包括： - 用领域数据和术语，按场景示例说明决策支持系统在用户决策过程中的角色； - 说明系统在什么范围内可被信任、值得依赖； - 说明系统在什么范围内不可被信任； - 给人在系统不可靠时该做什么的指示。

训练应清晰划分决策支持系统与人各自负责的功能。这部分最好在使用现场以实时方式传达，新的工具与方法也最容易在这种环境下与自然主义决策过程融合。非常规情境可在仿真中演练；至少要使用历史真实数据与术语做桌面演练，以传达人机分工。

训练还要传达系统的能力。能力不仅指工具的"按钮操作"，还包括系统的信息或建议如何影响运行决策。同样的内容应嵌入运行场景传达，以利训练向运行决策的迁移。场景化能帮助用户快速建立对系统关键模块的准确心理模型，从而快速建立信任。

训练也应覆盖系统能力的限制。限制要讲清楚，并把限制对运行决策的影响提示给用户。以 RAPT 为例，天气预报的一个限制是：对"爆米花"对流的预报本就比对大尺度锋面差。训练时应鼓励管制员用稳健的流量管理规划策略（例如分配在多种天气下都可行但未必最优的航路）来应对爆米花对流的不可预测性。如果用户知道当前是爆米花对流，就应在受影响区域将需求降到低于良好天气下的最大容量，以应对可能出现的容量突降。

12.2.3 支持长时程决策（Supporting Decisions over Long Timescales）

在需要支持的一些决策中，决策者有小时甚至天数的时间去收集信息再行动。信息的不确定度在决策空间中可能大幅变化。本节给出一个理解"长时程下信息不确定度与决策"关系的构造。

决策者面对长时程问题时通常要回答三个核心问题：现有信息下哪个行动或策略最好？现在就要决定还是等等？什么时候复盘过去的决策并更新策略？围绕这三个问题去谈程序与决策支持，有两个关键要素：预报信息质量与渐进决策（progressive decision making）。预报信息质量决定了规划的合理极限与世界按预期演化的可能性；该预报应以对运行决策有用的不确定度度量表达。许多复杂系统实体具有随机性，信息会以某种固定频率变化，要求用户周期性地基于最新预报复盘旧决策。

选好要预报的变量很重要——该变量应与用户可执行的决策直接相关。要有效使用预报，决策者需要理解预报的行为及其在预报视野内的质量；尤其要掌握预报误差的量级与符号、偏差、波动。图 12.4 给出一条示意性的预报特征曲线，刻画了预报不确定度、预报视野、可接受风险与实施视野之间的交互——所有这些都是围绕某一具体行动策略在时刻 \(t_\text{impact}\) 应对预报影响而展开的。

影响发生的时刻记为 \(t_\text{impact}\)，策略能对 \(t_\text{impact}\) 起作用的最晚实施时刻记为 \(t_\text{implement}\)。以公共卫生事件为例：疾病偶发暴发由公共卫生部门在某个 \(t_\text{impact}\) 时刻正式宣布；之所以受到监测，是因为公共卫生部门可以通过发放疫苗或向本地医院发布公共卫生警报来减轻事件影响。有的行动（如发送公共卫生警报邮件）几小时内就能起效，其 \(t_\text{implement}\) 接近 \(t_\text{impact}\)；而疫苗生产与分发需要几个月，其 \(t_\text{implement}\) 远早于 \(t_\text{impact}\)。决策者最早愿意依据信息采取行动的时刻记为 \(t_1\)——它在不同人、不同决策间差异很大。一位有 30 年经验的资深公共卫生官员对可接受不确定度的阈值通常高于新毕业的流行病学家；而同一位官员对"发布公共卫生警报"的可接受不确定度又通常高于"建议关停学校"。

复杂系统中的决策者通常有多种可选策略。为确定"哪个最好"，首先要考察跨预报视野的误差范围（相对于真值）：若预报误差不影响决策者会选 A 还是 B（误差在视野内相对均匀），那么不论其他特征如何，该预报都足以支撑判断。若误差可能让某一时刻的某一选择错（误差对不同决策、不同时刻不均匀），那么需要对预报行为做进一步刻画。风险评估取决于"错误决策的恢复成本"。

若误差幅度让"决策正确的概率"无法接受，下一步就要考虑预报随时间是否改善（即"我要等吗？"）。图 12.4 中，\(t_0\) 时刻预报不确定度太高，无法给出可靠决策建议；但不确定度曲线斜率表明它正在快速下降，且 \(t_\text{implement}\) 距离尚远，因此推迟决策是合适的。到 \(t_1\) 时刻不确定度降到可接受水平，决策者已具备所需的预报精度。可以再多等一会儿"更确定一点"，但前提是还没到 \(t_\text{implement}\)。

注意，可接受不确定度阈值会随情境上下文变化。例如单一学生颈部疼痛的报告通常不足以让校医向公共卫生部门报警；但若校医已知校园内有脑膜炎疫情，他会把阈值降低，做相应检查并向公共卫生部门"打个招呼"。类似的，对同一决策者，不同行动、不同规模的 \(t_\text{implement}\) 也不同（例如市内范围的公共卫生警报与全国范围的警报）。当可接受决策窗口较长时，不确定度曲线的斜率决定"等待"是否值得：在曲线陡降处等待可换取更准确的预报；在曲线接近水平处等待既无收益还可能付出显著成本。

回应这三个问题（"哪个策略？等不等？何时复盘？"）还要考虑预报的波动性。波动性低的预报让用户对"下一次预报与上一次相似"有信心，从而提供决策所需的信息稳定性。若波动性来自所预报过程本身的内在不可预测性（如快速演变的对流性雷暴），则决策者必须知道过程本就不可预测、需用短规划视野与频繁调整。若波动性来自预报模型本身设计拙劣或过于精细，则会让用户信心下降、对决策者价值有限。

某些情况下，环境中的关键变量可能根本无法以可接受精度预报。初始决策随着时间推移与情境演化未必仍是最优，因此需要渐进决策。

渐进决策被定义为：随新信息到来，定期复盘信息并相应调整战略决策。它包含两部分：(1) 做出在战略上稳健、且能为下游战术调整保留多种可选方案的决策；(2) 随信息更新复盘旧决策。渐进决策的程序与支持必须考虑未来的战略与战术调整（即可在预报视野不同节点执行的决策）以及在每个时步识别运行性显著变化的能力。军事决策文献中的"集成规划（integrated planning）"强调以"设计"复盘"概念"以缓解规划早期的不确定（[30]）；Davison Reynolds 等人讨论了如何把渐进决策框架应用到空中交通管理中（[31]）。

12.3 实施的系统视角（A Systems View of Implementation）

实施一个有效的决策支持系统是一个迭代过程（Figure 12.5）。理想的设计应从现场观察与运行数据分析开始，以理解运行场景与用户角色；设计者据此建立运行模型（operational model），从中提炼决策支持需求并定义具体要求；进而完成决策支持的设计与开发，形成程序、人机界面（HMI）与训练；将决策支持部署到环境中将影响运行，而其效果又可经运行数据分析与现场观察加以衡量。本节依次勾勒设计过程的各阶段，并在 Table 12.3 中给出针对实施的设计注意事项。

12.3.1 界面、训练与程序（Interface, Training, and Procedures）

设计一个决策支持工具时，通常先有一个核心想法，被翻译成至少一条功能级决策支持需求。该需求建立在对整个系统（人、运行、程序、约束）的运行模型之上。一旦确定决策支持的必要性，需求就被翻译成决策支持系统的设计。从广义上看，决策支持可以包括由 HMI 可视化承载的技术算法、新的程序、新增或修改的训练，或这三者的任意组合。决策支持手段（工具、程序、训练）的有效实施，应能影响运行系统的关键变量，给运行带来可度量的效益。

12.3.2 决策支持效果的度量（Measuring Decision Support Effectiveness）

设计过程的关键是确保决策支持系统真的带来运行效益、真的产生了影响。因此，设计者有责任回到现场评估工具的实际效果。该度量过程必须同时具备定量与定性两面。定量方面，要采集由决策改善所产生的运行数据。例如，若所设计的工具是空中交通避撞系统，则应采集空中相撞、濒危事件与一般间隔相关的运行数据。设计系统时所用的运行模型中包含一个假设："若飞行员有一个系统帮助其判断何时相撞迫近并给出避让建议，那么空中的事故、濒危事件与间隔违规应当减少。"这一假设对应于图 12.5 中的"预期运行问题"。部署系统并随后度量运行数据，让设计者得以检验这一假设；运行数据最终应揭示假设是否正确（对应图 12.5 中的"识别出的问题是真正的问题吗？"）。若数据表明决策支持确实把事故、濒危事件、间隔违规降到期望程度，则设计者可视为成功。然而，决策支持的初次部署就达到既定效益是罕见的。

决策支持未达预期的一种原因是设计者的假设错了，所识别的问题并非真正的问题。采集运行数据可以修正这一点。例如对 RAPT 而言，设计者最初认为运行问题是"在雷暴中帮管制员判断何时关闭离港航路"，于是花费大量精力设计针对管制员解读 RAPT 时间线模式与对应关闭时机训练的方案。然而即便经过深入的训练与运行评估，工具对恶劣天气下延误指标的改善仍然有限。

设计者回到分析中，重新审视延误指标的度量方式。在此过程中他们发现：相当一部分"非必要延误"并非管制员"在错的时刻关闭航路"造成的，而是管制员在风暴已过境之后"过晚重新开放航路"造成的。设计者对此深感意外。管制员实际上错过了那个简单决策——明明 RAPT 显示航路已是 GREEN，却没及时重新开放。在运行数据揭示真正问题之后，设计者可以"精准"地提供决策支持：他们调整了 RAPT 显示屏，加入了一个"PIG（post-impact GREEN）"计时器——它从一条原本是 RED 的航路转成全 GREEN 那一刻开始计时。该 HMI 调整让管制员能够看到自己是否错过了重新开放的时机。

设计者还在训练上做了配套调整——把"管制员未能尽快重新开放航路"的数据告知管制员，以此激励其使用 PIG 计时器。次年 RAPT 的效益相对前一年翻倍，达到了期望的运行效果。

决策支持未达预期的另一种原因可能是设计者的假设正确，但系统未达成目标。理解这一点需要定性度量。可用性方面的关键信息也可以在使用中（或不被使用的情况下）从用户那里采集。在运行现场，用户能直接指出决策支持为什么有用或没用。决策支持的位置、字号、照明等问题会在运行现场暴露得一清二楚。若这些基础需求得到满足，用户还会指向更微妙的问题——例如所给信息并不是其做决策所需，或决策支持虽好但自己根本不是决策者。在 RAPT 的现场评估中，设计者最初把 RAPT 交给交通管理单元（TMU）的交通管理员使用。评估中发现，交通管理员能用 RAPT 决定何时开放航路，但负责飞机间隔的扇区管制员没有 RAPT 工具，因此会拒绝开放。RAPT 监视器后来被安装到各个扇区，工具的影响才真正体现出来。

上述各例都对应图 12.5 中的迭代度量反馈环。顶部的定量环由运行数据分析支撑，通常以效益分析的形式存在，让设计者把决策支持带来的运行效益货币化。最难的部分往往是找到能反映"可度量的运行效益"的指标。第二环是定性环。定性反馈可通过问卷、正式访谈或更优的——运行现场观察采集。当用户指出决策支持"为何不好用"时，反馈最有价值。定性反馈还提供机会让用户向设计者提出自己的决策支持想法——若来自对系统具有广泛视角的"超级用户"，则极具洞察力。每次评估所采集的定性与定量数据都让人更了解决策支持所要植入的系统；运行模型随之更新，这对未来迭代中的设计改进至关重要。

12.3.3 组织因素对系统有效性的影响（Organization Influences on System Effectiveness）

前述反馈环在以"效益驱动"为主的系统里运行最优。FAA 是这类系统的例子——至少在纸面上，研究与采购项目都以"对空域系统带来明确的效率或安全效益"为前提推动。

然而系统的各个要素都是其所属组织的产物。用户可能受到优化整体系统功能之外的动机驱动。这些动机可能是个人动机，但更常见的是组织激励。例如 FAA 的典型交通管理员的激励是：调整其所在设施的航路需求，使其与该设施当时的可用容量匹配。若需求过高，扇区管制员被压垮、完全停流（且可能反过来对交通管理员不满）；若需求过低，远低于容量，设施次日会从 ATC 系统指挥中心或相邻设施受到施压。交通管理员的激励是"在自己设施内让需求与容量有效平衡"。这一激励看似直觉，但必须看到：航空系统并非由"孤岛"式的空管组成，而是各设施的需求与容量相互影响的网络。交通管理员的激励仅基于本设施的需求与容量，而非本设施决策对其他设施的影响。因此，要在整个空域范围内优化空中交通时，必须把激励因素作为有效实施解决方案的重要约束。设计时若能把组织因素对用户行为的影响纳入考量，就能为设计者构造一个高度发展的运行模型，从而产出更好的决策支持。

12.4 小结（Summary）

本章围绕"在决策支持中考虑人的能力与局限"讨论了若干方法。系统方法被作为脚手架，把训练与系统度量纳入到迭代设计中。信任被列为算法设计与系统可接受性的关键要素。最后强调：在自然主义情境中理解决策问题——包括其全部约束与不确定——会从根本上改变不同问题之间设计方法与考虑的取向。

总结下来最中肯的建议是：在设计决策支持之前，先真正理解问题、情境与涉及的人。这种理解是区分"真正支持决策的系统"与"反而阻碍运行或根本无人使用"的分水岭。

本章个人批注

本章主题是"把人机协同落到实处"，是全书的收束章节。读完后我有几条值得记下的感受。

第一，本章和前面章节的关系不像传统教科书的"理论→应用"那么线性。前 11 章都在讲算法、推断、优化，这些都被默认"装进某个系统"，本章讨论的就是"装进去之后会发生什么"。把 Chapter 12 放在最后是合理的——算法讨论完之后才有意义谈"如何让人信任并用好它"。

第二，"信任校准"这一节的设计考量比预期要工程化得多。Table 12.2、Table 12.3 都把建议落到很具体的层次（字号、颜色、不在阳光下看不清、噪声环境等）。这和 Chapter 8-10 里相对抽象的算法讨论风格不同——这是把工程化细节当主菜，算法细节是辅料。

第三，RAPT 这个例子贯穿 12.2.2 与 12.3.2 两节，对理解"渐进设计"特别有帮助。同一个工具迭代了十余年（2003 年起原型至今仍在迭代），从颜色编码、改 yellow 的训练、PIG 计时器、装到扇区等几次迭代才拿到真实效益。这印证了 12.3 强调的"度量是设计过程的关键"——光把算法做对还不够，必须确认"识别出的问题是真正的问题"。

第四，我对"故意性失调"（willful miscalibration of trust）和"滥用"（abuse）这两种信任失调的区分特别感兴趣。前者更多是从用户个体的认知局限/情绪出发的偏差，后者则来自系统设计中给用户留下的角色过于被动的结构性缺陷。两者在工程层面的对策完全不同——前者靠训练与反馈，后者必须改 HMI/任务分配。

第五，"渐进决策"那一节给的图 12.4（不确定度随预报视野下降）非常直观，且把"等待的价值"和"等待的成本"放在同一张图里权衡。我自己在做研究路线决策时经常遇到"再等等看"还是"先动手"的拉锯，这一节提供了一个相对清晰的决策框架——尽管把它直接套到科研决策上还嫌粗糙。

最后，本章虽提到一系列心理学经典结论（Miller 的 7±2、Kahneman-Slovic-Tversky 的启发式、Klein 的识别启动型决策、Muir 的信任定义），但每一处都嵌在具体工程情境中。我感受到本章不是教科书式的心理学综述，而是把认知科学的结论"工程化"——这是 MIT 这本教材一以贯之的风格。

与上下章的衔接（一段话）

第 12 章是全书最后一章，作者把视角从算法与推断模型拉回到"系统与人"。第 11 章讨论了多智能体规划下的持续监视——这是算法层面的进阶；本章则跳出了"算法能不能算出来"的视角，讨论"算出来后如何被人用好"。从 Ch1 的概率推理基础一路下来，每章都在为算法打基础并展示其能力，到本章作者承认了一个事实：再好的算法如果不被人恰当使用就是没用——人的能力、信任、训练、组织激励等"软件层面"的因素与算法本身同等重要。这种"以人为收束"的安排使全书形成一个完整的闭环：前 11 章讲"如何做决策"，本章讲"做出来的决策如何被用对"。