Human-AI Interaction Guidelines 与 AI 产品交互设计

配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是 docs/AI_HUMAN_AI_INTERACTION_PRODUCT_DESIGN_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。

Source Anchors

核心导读

Human-AI Interaction 的核心不是让界面看起来更像人，而是让人能够正确理解、校准信任、控制、纠错、拒绝、升级和追责。Amershi 等人的 HAI Guidelines 和 Google PAIR 的设计方法共同说明：AI 失败常常不是模型完全无能，而是系统没有说明它能做什么、证据在哪里、什么时候不确定、错误如何恢复、人工何时接管。

高风险 AI 交互不能把 capability boundary、evidence layer、uncertainty handling、recoverability、feedback loop 和 human escalation 当作界面文案补丁。它们必须进入系统结构，决定输出如何被使用、错误如何被修正、责任如何被保留，以及哪些动作必须停在人工控制点之前。

核心问题

AI 产品的许多失败不是来自模型完全不能工作，而是来自人和系统之间的错误关系。用户以为 AI 能做正式判断，但它只能做信息检索。员工以为 Copilot 摘要已经验证过事实，但它只是生成了一个可读草稿。客户把聊天机器人回答理解成银行承诺，但系统没有表达适用边界。分析师看到模型建议后不再检查反证，automation bias 让错误变得更隐蔽。高风险任务中，用户找不到撤销、申诉、人工升级或纠错入口。这些问题不是单纯 UI 问题。它们涉及能力边界、风险分层、证据呈现、不确定性表达、人工流程、反馈治理和审计记录。Human-AI Interaction 要回答的核心问题是：当 AI 输出不是确定、完整、永远正确时，产品系统如何让人以合适的方式使用它。金融零售场景尤其敏感。客户服务、信贷解释、欺诈拦截、AML 调查、投诉处理和财富建议都涉及权益、资金、合规、信任和责任。界面上一个“智能建议”标签，可能在实际流程中被当成事实。一句“你应该”可能被理解成正式建议。一个缺失的人工升级入口，可能让客户错过申诉或补救。因此，HAI 不是美化 AI 体验。它是把 AI 能力安全接入人类决策和业务流程的设计方法。

方法贡献

Microsoft 的 Human-AI Interaction Guidelines 将 AI 交互分成四个阶段。第一，用户开始使用前，系统应帮助用户理解 AI 能力、限制和适用情境。第二，交互过程中，系统应让用户知道 AI 正在做什么、依据是什么、输出有多可靠。第三，当 AI 错误时，系统应支持纠错、撤销、反馈和恢复。第四，长期使用中，系统应学习用户偏好，同时保持一致性、可控性和可理解性。Google PAIR 的 People + AI Guidebook 强调从人的任务出发，而不是从模型能力出发。它要求团队先理解用户要完成什么工作、AI 在任务中承担什么角色、数据如何影响输出、反馈如何进入系统、错误会造成什么后果。这两套方法共同改变了 AI 产品设计的起点。传统设计经常问：模型能生成什么。HAI 要问：人在什么场景下需要 AI，AI 的输出会如何影响人的判断和行动，人如何知道该信还是该停。这对金融零售很关键。客户服务系统不能只追求回答自然。AML Copilot 不能只追求摘要完整。信贷解释助手不能只追求语言清晰。它们都必须处理责任边界和错误恢复。

机制原理：信任校准

HAI 的核心机制是 calibrated trust。目标不是让用户更信任 AI。目标是让用户在 AI 可靠时适当依赖，在 AI 不确定或越界时保持怀疑，在高影响动作前保留控制。

trust when evidence is strong
doubt when uncertainty is high
control when action is high impact
escalate when responsibility must be human

信任校准失败有两个方向。过度信任会导致 automation bias。用户接受错误建议、跳过检查、复制不可靠内容、忽视例外和反证。信任不足会导致 AI 无法产生价值。用户拒绝所有建议、重复手工工作、无法形成稳定工作流。HAI 的设计目标不是制造“可信感”，而是让信任与证据强度匹配。这需要系统提供几个信号：

• 能力边界。
• 证据来源。
• 不确定性。
• 可操作控制。
• 错误恢复路径。
• 人工责任边界。

如果这些信号缺失，用户只能根据语气、流畅度和界面权威感判断 AI。这在金融场景非常危险。

阶段一：设定能力边界

AI 产品一开始就要让用户知道系统能做什么，不能做什么。能力边界不是免责声明。它是任务设计。客服 RAG 可以回答费用政策、账户服务步骤和常见操作说明。它不能做正式信贷决定、投诉裁定、个性化投资建议或未经授权的退款承诺。AML Copilot 可以聚合交易事实、列出 typology 线索和生成调查草稿。它不能替代 analyst 判断，也不能自动提交 SAR。信贷员工助手可以解释政策依据和生成客户沟通草稿。它不能发明 adverse action reason，也不能覆盖受控决策记录。能力边界应以任务语言表达，而不是模型语言表达。弱表达是：

This AI may be inaccurate.

更有效的表达是：

This assistant can summarize current fee policy and account service steps.
It does not make credit decisions, resolve formal complaints, or authorize refunds.
For those cases it will route to a specialist workflow.

这类边界应进入系统逻辑。如果用户输入属于禁止范围，系统不能只在页面底部放免责声明，而应澄清、拒答或升级人工。

阶段二：交互中呈现证据与不确定性

AI 输出的可信度不能靠自信语气表达。金融零售 AI 尤其不能用虚假的精确百分比制造确定性。例如，显示“92.7% confident”通常没有帮助，除非这个数字有校准含义、用户理解它并且它能改变行动。更有用的是把证据和适用范围展示出来。

This answer is supported by the current fee schedule, effective 2026-05-01.
It applies to personal checking accounts.
It does not apply to business accounts or credit limit decisions.

证据呈现要回答：

• 信息来自哪个系统、文档或记录。
• 版本和生效日期是什么。
• 哪些关键 claim 被证据支持。
• 哪些内容是推断、建议或待确认。
• 输出不适用时用户能做什么。

不确定性处理也要具体。如果 RAG 没有找到权威来源，应拒答或转人工，而不是猜。如果 AML case 缺少受益人资料，应标注 missing information，而不是补全叙事。如果信贷解释缺少 decision code，应停止生成客户解释。如果欺诈风险信号冲突，应进入人工 review，而不是给出确定结论。不确定性不是产品瑕疵。它是高风险系统应当暴露的状态。

阶段三：错误发生时可恢复

AI 一定会错。HAI 关注的是错误发生后用户能否恢复控制。Recoverability 包括撤销、编辑、反馈、申诉、人工升级、保存证据和回滚流程。不同场景需要不同恢复能力。客户收到错误政策回答，需要人工升级、投诉记录和补救路径。员工看到错误摘要，需要能编辑、标记错误原因，并保留原始 AI 输出与最终人工版本的差异。风控系统错误拦截交易，需要申诉、人工复核、客户通知和模型/阈值复盘。AML Copilot 生成遗漏关键事实的 narrative，需要 QA 标注和训练数据治理，而不是让错误静默进入案件库。可恢复性必须在工作流中实现。一个“thumbs down”按钮不足以支持高风险恢复。反馈应进入 QA queue，有分类、有 owner、有复盘、有阈值触发。错误严重时应触发 incident 或 release freeze。

阶段四：长期使用中的学习和一致性

AI 产品会随使用而变化。用户会形成习惯，团队会调整 prompt，知识库会更新，模型会升级，反馈会进入改进流程。长期 HAI 需要解决两个矛盾。第一，系统应从反馈中改进，但不能让未经治理的反馈直接改变高风险行为。客服人员标记“回答不满意”，不应自动变成训练样本。AML analyst 的编辑也不应无审查地训练模型，因为编辑可能受模型建议影响。第二，系统可以个性化，但不能让行为变得不可预测。员工助手可以记住格式偏好，却不应记住客户敏感数据或绕过正式政策。长期使用中的一致性需要：

• change notice。
• prompt and model versioning。
• feedback taxonomy。
• QA sampling。
• training data governance。
• behavior regression eval。
• user education。

用户应该知道系统行为何时发生重大变化。高风险场景中，员工培训和 SOP 更新应与 AI 版本同步。

HAI 系统架构

HAI 不是前端单点能力。一个可运营的人机交互架构通常包含：

user intent
  -> risk tier classifier
  -> capability boundary
  -> AI pattern: RAG / model / workflow / agent
  -> evidence layer
  -> uncertainty and answerability layer
  -> UX policy renderer
  -> user control and feedback
  -> human escalation workflow
  -> monitoring and learning loop

各组件的职责不同。

没有这些后端能力，前端文案无法稳定地表达边界。例如，如果系统不知道知识来源版本，就无法可靠显示“当前政策”。如果系统没有 risk tier classifier，就无法在高风险意图上自动转人工。如果系统没有 feedback governance，就无法把用户纠错变成改进。

为什么有效

HAI 有效，是因为它承认 AI 产品的核心风险来自人机协作，而不只是模型输出。同一个模型输出，在不同界面和流程中会造成不同后果。一句“建议冻结账户”如果显示在 investigator queue 中，可能只是线索。如果显示在自动执行 workflow 中，就可能造成客户伤害。如果显示在客服系统中，员工可能把它当成正式解释。HAI 通过能力边界、证据、不确定性、控制和升级，把同一个 AI 输出放在合适的责任结构中。它还降低 automation bias。当系统要求用户确认关键证据、区分事实和建议、提供反证入口、显示不适用范围时，用户更不容易把 AI 当成权威。它也能提升有效采用。如果用户知道 AI 擅长什么、证据在哪里、如何修改和如何升级，他们更愿意在适合场景使用 AI。

局限和误用

第一类误用是把 HAI 变成免责声明堆叠。免责声明可以降低误解，但不能替代系统控制。如果高风险意图仍然让模型自由回答，页面底部写“仅供参考”没有太大意义。第二类误用是把 confidence 当万能解决方案。未校准的置信度会制造虚假确定性。很多 LLM 场景更应展示证据、适用范围、冲突和缺失信息，而不是百分比。第三类误用是把用户反馈直接当训练数据。反馈首先是质量和风险信号。是否进入训练，需要标签治理、去偏、审查和版本控制。第四类误用是把人工升级当兜底万能按钮。人工团队需要容量、SOP、上下文、权限和 SLA。没有这些，升级只是把失败转移给运营。第五类误用是过度拟人化。金融零售 AI 不需要表现得像一个懂你的人。它需要清楚表达它在执行哪类任务、依据是什么、责任在哪里。第六类误用是把 HAI 限定为客户界面。员工 Copilot、分析师工具、后台审批、风险 dashboard 和客服系统同样需要 HAI。员工过度信任 AI 造成的风险往往更隐蔽。

架构和产品价值

HAI 的产品价值是把 AI 从“会回答”变成“可被安全使用”。它要求产品需求包含：

• 任务边界。
• 风险意图分类。
• 输出证据。
• 不确定性处理。
• 用户控制。
• 错误恢复。
• 人工升级。
• 反馈治理。
• 行为变化通知。

HAI 的架构价值是把这些需求落成服务和工作流。一个成熟系统不会只在 prompt 中写“如果不确定就说不知道”。它会建立 answerability 判断、source authority、policy renderer、refusal routing、case handoff、feedback queue 和 monitoring。产品与架构之间的连接可以这样理解：

interaction requirement
  -> system capability
  -> evidence and control
  -> user-visible behavior
  -> monitoring signal

例如，“用户应能理解答案依据”对应 citation service、document version、claim grounding eval 和引用点击监控。“高风险场景应升级人工”对应 risk classifier、case creation、warm handoff、SLA 和 escalation precision。“员工可以纠错”对应 editable draft、override reason、diff record、QA review 和 regression sample。

金融零售系统案例

客户服务 RAG

客户服务 RAG 的风险不只是答错。更常见的是答对一部分，但让客户误解适用范围。系统回答费用政策时，应显示政策来源、产品范围、生效日期和不适用情况。如果客户询问信贷额度、投诉结果、争议交易裁定或补偿承诺，系统应进入人工流程。客户应能标记“不适用”“需要人工”“我要投诉”。这些反馈不能只进入满意度统计，而要进入 QA 和风险监控。监控指标包括 unsupported answer、citation precision、escalation precision、complaint rate、task completion 和 recovery time。

AML Analyst Copilot

AML Copilot 的 HAI 重点是防止 analyst 把模型叙事当事实。输出应分层：

observed evidence
supporting typology signals
contradicting evidence
missing information
suggested next steps

系统应要求 analyst 确认关键证据，而不是一键提交 narrative。所有 AI 草稿、引用和人工编辑都应保留 provenance。高风险 case 应限制自动生成最终结论。HAI 在这里的价值不是让摘要更顺，而是让调查责任保持在人类流程中。

信贷员工助手

信贷员工助手可以帮助员工解释政策和准备客户沟通。但正式 adverse action reason 必须来自受控决策记录。AI 不能根据客户资料自由生成拒绝原因。界面应明确：

• 哪些内容来自 decision record。
• 哪些内容是政策解释。
• 哪些内容是员工可编辑草稿。
• 哪些话术禁止发送。
• 客户如何申诉或补充资料。

如果 AI 找不到受控 reason code，应停止生成，而不是猜测。

欺诈拦截与客户通知

欺诈系统常常需要向客户解释为什么交易被阻止或需要验证。这里的 HAI 难点是既要减少客户焦虑，又不能泄露风控规则。合理设计不是展示模型分数，而是提供可行动解释：

为了保护账户安全，这笔付款需要额外确认。
原因包括新收款人和异常金额组合。
请在 app 中完成验证，或联系支持团队。

客户应能完成 step-up、取消交易、联系人工或提交误拦截反馈。系统应监控 false positive complaints、verification completion、abandonment 和 vulnerable customer impact。

财富顾问助手

财富/投顾场景需要严格区分教育性解释、产品信息、组合摘要、一般性市场内容和个性化投资建议。HAI 的核心是任务分层。教育性内容可以更自动化。个性化建议需要受监管流程、适当性、风险承受能力、产品披露和人工确认。界面不能让用户把一般信息误解成个性化建议。能力边界和人工升级必须非常明确。

评测设计

HAI 评测不能只看用户满意度。用户可能喜欢一个流畅但错误的系统。评测需要覆盖正确使用、错误恢复和信任校准。

适当依赖需要专门设计实验。评测集应包含 AI 正确、AI 错误、证据不足、规则冲突、高风险越界和旧知识案例。如果用户在 AI 错误时仍大量接受输出，说明界面没有校准信任。如果用户在 AI 正确且证据充分时仍拒绝使用，说明系统可解释和控制不足。

学习验证

读完这一篇后，应能完成以下验证任务：

1. 为客户服务 RAG 设计 capability boundary，明确可回答、必须澄清、必须拒答和必须人工升级的意图。

2. 为 AML Copilot 设计输出 schema，区分 observed evidence、hypothesis、missing information、suggested action 和 analyst decision。

3. 为信贷解释助手设计 evidence display，说明 decision code、policy version、evidence field、approved wording 和 appeal path 如何呈现。

4. 设计一个 automation bias eval，包含 AI 正确、AI 错误、证据不足和高风险越界样本，观察用户是否适当依赖。

5. 为客户错误回答设计 recovery flow，包含用户反馈、人工升级、case record、补救、QA 复盘和控制更新。

6. 画出 HAI 系统架构，包含 risk classifier、capability boundary、evidence layer、uncertainty layer、policy renderer、feedback queue 和 escalation workflow。

7. 设计一组 HAI production metrics，覆盖 task success、appropriate reliance、override、complaint、escalation、recovery time 和 workload。

关键结论

Human-AI Interaction 的本质是让人能安全、有效、可控地使用不完美的 AI。它关注的不是界面是否有 AI 感，而是用户是否理解能力边界、证据、不确定性、控制权、恢复路径和责任归属。金融零售 AI 的 HAI 设计必须从任务风险出发，把 capability boundary、evidence layer、uncertainty handling、recoverability、feedback governance 和 human escalation 做成系统能力。掌握 HAI 的标志，不是能列出交互原则，而是能为一个具体金融 AI 场景说明：用户何时应信任 AI、何时应怀疑、错误如何恢复、人工如何接管，以及这些行为背后需要哪些架构和监控支持。

---

SOTA 状态标注 (2026-07-01)

本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。