AI 扩展计划 / Playbooks
AI Human-AI Interaction Product Design Playbook
以下来源是本文的设计锚点。本文把它们转成产品、交互、架构、风险、运营和证据要求，不把任何来源简化成单一检查项。访问日期按 2026-06-29 记录。
766 行AI_HUMAN_AI_INTERACTION_PRODUCT_DESIGN_PLAYBOOK.md
AI Human-AI Interaction Product Design Playbook
定位：面向高级 AI PM / AI BA / Product Architect / Enterprise Architect / UX Lead / Model Risk / Compliance，把 Human-AI Interaction 从“更好用的 AI 界面”升级为受监管金融零售 AI 的 mental model、控制权、不确定性、恢复、反馈、角色交接、例外处理和可审计信任校准体系。
适用边界：本文面向 customer-facing AI、employee-facing copilot、agent assist、credit / fraud / AML / KYC / collections / complaints / wealth / branch / contact center 场景。重点不是基础 BA 需求写法，而是把人机交互设计转成产品架构、风险控制、eval 指标、运营 SOP 和作品集证据。
重要说明：本文是学习、作品集和内部方案训练材料，不构成法律意见、合规结论、审计意见、模型验证报告或监管解释。正式项目必须由 Legal、Compliance、Risk、Model Risk、Fair Lending、Privacy、Security、Accessibility、Business Owner、Operations Owner、Customer Experience 和管理层结合机构类型、司法辖区、客户影响和内部政策确认。
Source Anchors
以下来源是本文的设计锚点。本文把它们转成产品、交互、架构、风险、运营和证据要求，不把任何来源简化成单一检查项。访问日期按 2026-06-29 记录。
| Anchor | Official / primary source | 本文使用方式 |
|---|---|---|
| Microsoft Guidelines for Human-AI Interaction | https://www.microsoft.com/en-us/research/publication/guidelines-for-human-ai-interaction/ | 用 18 条 HAI guidelines 组织 expectation setting、context-aware support、uncertainty、correction、dismissal、feedback、control、learning、adaptation 和 change notification。 |
| Microsoft HAX Toolkit | https://www.microsoft.com/en-us/haxtoolkit/ | 用 HAI patterns 和 failure mode thinking 把原则转成可评审的 interaction requirement、design review checklist 和 product acceptance criteria。 |
| Google People + AI Guidebook | https://pair.withgoogle.com/guidebook/ | 用 mental model、trust calibration、feedback and control、explainability、graceful failure 和 user value lens 设计 AI 体验。 |
| NIST AI Risk Management Framework | https://www.nist.gov/itl/ai-risk-management-framework | 用 Govern / Map / Measure / Manage 把 HAI 体验纳入 AI 风险治理、上线门禁、监控、事件处置和持续改进。 |
| NIST AI RMF Playbook | https://airc.nist.gov/airmf-resources/playbook/ | 用 playbook 思路把交互风险转成可执行 action、owner、evidence 和 review cadence。 |
| NIST AI RMF Generative AI Profile | https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence | 用于 GenAI 特有 HAI 风险：hallucination、over-reliance、content provenance、misuse、data leakage、prompt injection、excessive agency 和 incident response。 |
| ISO 9241-210 Human-centred design | https://www.iso.org/standard/77520.html | 用人本设计生命周期约束 AI 体验：理解用户、任务、环境，定义可用性目标，迭代评估，并覆盖全生命周期。 |
Standards-to-artifacts：
| Source lens | 可以产出的 artifact | 高级面试表达 |
|---|---|---|
| Human-AI Interaction Guidelines | HAI principles matrix、interaction state machine、control inventory、feedback loop spec | “我会按用户接触 AI 的阶段设计预期、证据、控制、纠错和恢复，而不是只做聊天 UI。” |
| Google PAIR | Mental model canvas、trust calibration journey、graceful failure patterns | “我关注用户如何理解 AI，而不是只关注模型能不能给出答案。” |
| NIST AI RMF | HAI risk register、release gate、monitoring dashboard、incident loop | “我把交互体验当成 AI 风险管理的一部分，用 Govern / Map / Measure / Manage 管起来。” |
| NIST GenAI Profile | Over-reliance control、content provenance spec、agent action review、abuse and misuse test cases | “我会把自动化偏差、过度代理和来源不完整转成可测试、可监控、可升级的产品控制。” |
| ISO 9241-210 | User context research、usability risk eval、accessibility review、iterative validation plan | “我会验证真实用户、任务压力和渠道环境，而不是在会议室里判断 AI 是否好用。” |
1. One-Sentence Positioning / 一句话定位
Human-AI Interaction for regulated AI 的核心不是让 AI “像人一样自然”，而是：
HAI Product Design =
让客户、员工和监督者在正确的时间形成正确 mental model，
看见足够证据和不确定性，
拥有可执行的控制、纠错、升级、恢复和退出路径，
并让组织能证明这种交互降低了错误采纳、过度信任、低信任、越权自动化和客户伤害。
在金融零售里，HAI 不是 UX polish，而是控制平面：
| 交互能力 | 受监管含义 | 金融零售失败后果 |
|---|---|---|
| Mental model | 用户知道 AI 是什么、能做什么、不能做什么、由谁负责 | 客户把 AI 回复当成正式承诺，员工把草稿当成已验证结论 |
| Uncertainty communication | 系统能表达缺证据、来源冲突、低置信、越界和需人工判断 | AI 猜测信贷原因、费用政策、投诉结果或投资建议 |
| Controllability | 人可以暂停、编辑、拒绝、覆盖、撤销、转人工和关闭自动化 | AI 工具动作进入下游系统后无法挽回 |
| Recoverability | 出错后有 case、补救、回滚、申诉、复盘和客户通知 | 客户在 chatbot 循环里无法投诉，员工无法修正错误记录 |
| Feedback | 用户反馈进入 eval、知识、流程、模型和治理闭环 | thumbs up/down 只是 UI 装饰，同类错误反复发生 |
| Calibrated trust | 信任程度与能力、证据、风险和可逆性匹配 | 员工 rubber stamp，客户过度依赖，管理层误判 adoption |
| Role transition | AI、员工、专家、主管、合规和客户之间责任清楚交接 | 人工接管不知道上下文，责任在 AI / 人 / 系统之间漂移 |
| Exception handling | 系统能识别并处理边界、异常、冲突、失败和高风险意图 | 特殊客户、投诉、欺诈、KYC、AML、困难援助被当成普通 FAQ |
高级 AI PM / BA / Architect 要能回答四个问题：
- 用户在每个阶段应该相信 AI 到什么程度？
- 用户如何知道 AI 可能错、为什么错、错了能怎么办？
- 人和 AI 的角色如何在正常、异常、高风险和失败场景中切换？
- 生产环境如何证明交互控制真实运行并持续改进？
2. HAI Design Principles / HAI 设计原则
下面把 Amershi 等人的 Human-AI Interaction Guidelines 转成金融零售可落地的产品语言。重点不是背原则，而是把原则映射到 requirement、UI state、architecture control、eval 和 audit evidence。
2.1 交互生命周期原则
| Phase | HAI principle | 受监管产品要求 | 金融零售实现 |
|---|---|---|---|
| 初次接触 | Make clear what the system can do | 首屏说明 AI 能处理的任务、不能处理的任务、人工入口和正式流程边界 | 客服 AI 标明可解释费用、查询状态、创建服务请求；不能生成正式信贷结论或投资建议 |
| 初次接触 | Make clear how well the system can do what it can do | 展示能力限制、来源范围、更新频率、覆盖区域和不可用场景 | “回答基于当前账户系统和 2026-06-01 生效政策；复杂投诉会转人工。” |
| 正常交互 | Time services based on context | AI 只在用户任务需要时出现，不用无关推荐打断高风险流程 | 客户申诉交易时不插入信用卡销售建议 |
| 正常交互 | Show contextually relevant information | 在主任务处展示证据、来源、下一步和影响，不让用户跨系统找依据 | 信贷 copilot 展示正式 reason code、政策条款、缺失材料和审核状态 |
| 正常交互 | Match relevant social norms | 语气、身份和责任边界符合金融服务场景，不假装真人或过度亲密 | 投诉、困难援助、欺诈损失使用克制、清晰、同理但不承诺的表达 |
| 正常交互 | Mitigate social biases | 交互不放大刻板印象、语言障碍、脆弱客户或渠道差异 | 对低金融素养客户使用简明解释，避免用复杂免责声明转嫁风险 |
| 调用与退出 | Support efficient invocation | 用户能在合适位置主动调用 AI，但高风险动作不被自动触发 | 员工在 case 页面生成摘要，不能在未授权状态下自动发送客户通知 |
| 调用与退出 | Support efficient dismissal | 用户能忽略、关闭、隐藏或转人工，且不会受到惩罚 | 客户可随时转人工；员工可关闭 AI 建议并记录原因 |
| 纠错 | Support efficient correction | 用户能纠正事实、标签、意图和草稿，系统记录修正并更新流程 | 客户指出交易不属于本人时进入 dispute 流程，而不是继续普通 FAQ |
| 不确定 | Scope services when in doubt | AI 不确定时缩小范围、澄清、拒答或升级，而不是流畅猜测 | RAG 无权威政策来源时回答“无法确认”，并创建人工查询 |
| 解释 | Make clear why the system did what it did | 输出附带来源、规则、证据强度、缺失信息和动作原因 | Fraud queue 显示主要风险信号、非决定性说明和人工审核建议 |
| 记忆 | Remember recent interactions | 在同一会话中保留用户已确认信息，减少重复，但不跨目的滥用 | 投诉转人工时带上已确认交易、时间、客户诉求和 AI 已回复内容 |
| 学习 | Learn from user behavior | 从反馈中改进知识、路由和 eval，但不隐性改变客户权益 | 客服纠错进入 QA 和知识库更新，不能直接训练个性化销售模型 |
| 适应 | Update and adapt cautiously | 个性化、模型升级和策略变更要可解释、可回滚、可审计 | Prompt / model / retriever 变更必须经过回归 eval 和 release gate |
| 反馈 | Encourage granular feedback | 反馈要结构化到错误类型、来源、任务、影响和期望处理 | “来源错误”“遗漏关键信息”“语气不合规”“应转人工”“客户影响高” |
| 后果 | Convey consequences of user actions | 用户在确认、覆盖、发送、冻结、退款、拒绝、关闭 case 前知道后果 | “确认后将创建 dispute case，不会立即退回资金。” |
| 全局控制 | Provide global controls | 组织和用户有偏好、权限、停用、数据使用、自动化范围和通知控制 | 业务 owner 可关闭某类 AI 建议；客户可选择非 AI 服务路径 |
| 变更通知 | Notify users about changes | 能力、范围、数据使用、模型行为和自动化级别变化要通知相关用户 | 员工 copilot 新增自动填表能力前必须提示、培训并记录接受 |
2.2 八条金融零售 HAI 原则
| 原则 | 高级判断 | 设计红线 |
|---|---|---|
| AI identity clarity | 用户清楚自己面对的是 AI、AI-assisted human 还是人工 | 用头像、名字、打字延迟或话术让 AI 像真人 |
| Evidence before eloquence | 金融场景优先来源、证据、政策和系统事实，其次才是流畅表达 | 没有来源的自然语言解释替代正式原因 |
| Calibrated confidence | 不显示虚假精确概率，而显示任务相关的证据强度和下一步 | “我有 92% 把握”用于信贷、投诉或投资建议 |
| Human control by risk tier | 客户影响越高，人的控制、复核和撤销越强 | 高影响动作默认一键自动执行 |
| Exception-first design | 投诉、欺诈、困难援助、合规、脆弱客户和越界请求优先识别 | 所有用户意图先走普通问答，失败几轮后才升级 |
| Reversible where possible | 可逆动作可适度自动化，不可逆或高影响动作必须强控制 | AI 自动拒贷、冻结、关闭投诉、发送正式通知 |
| Feedback becomes governance | 反馈进入 eval、知识、流程和风险报告 | 只收集满意度，不分析过度依赖、纠错和升级质量 |
| Trust is measurable | 信任校准、控制使用、错误恢复和人工交接都有指标 | 只看 adoption、CSAT、处理时长，忽略客户伤害和控制失效 |
2.3 反模式
| 反模式 | 看起来像好体验 | 实际风险 |
|---|---|---|
| Confident chatbot voice | 回答流畅、语气自然 | 掩盖检索不足、政策冲突和模型猜测 |
| Invisible AI assist | 员工效率提升，客户体验一致 | 客户不知道关键内容由 AI 起草，事故时责任和证据不清 |
| Always-on proactive AI | 系统主动帮用户推荐下一步 | 在投诉、困难援助、信贷和财富场景可能变成诱导或越界 |
| One-click accept | 员工更快处理 case | automation bias、rubber stamping、证据未读 |
| Generic confidence badge | UI 有“高/中/低”标识 | 不知道 confidence 来自模型、检索、规则还是人工审核 |
| Feedback sink | 有 thumbs up/down | 没有结构化错误类型、owner、SLA 和 eval 回流 |
| Handoff theater | 页面有“联系人工”按钮 | 无 SLA、无上下文传递、无 case ID、无责任人 |
3. Interaction Architecture / 交互架构
受监管 AI 的交互架构应把 UI、policy、evidence、human control、audit 和 monitoring 串成一个系统，而不是把 AI widget 嵌进页面。
3.1 HAI control stack
User / employee task
-> AI identity and scope disclosure
-> intent and risk classification
-> entitlement, consent and data boundary check
-> evidence retrieval / system-of-record lookup / model inference
-> uncertainty and answerability assessment
-> decision policy
- answer
- clarify
- recommend
- draft
- refuse
- escalate
- request human approval
- block action
-> interaction renderer
- explanation
- uncertainty signal
- controls
- feedback
- recovery path
-> human / customer action
-> audit event and telemetry
-> eval, monitoring, incident and improvement loop
3.2 关键组件
| Component | 责任 | 典型 owner | 证据 |
|---|---|---|---|
| Intent and risk classifier | 判断任务类型、客户影响、监管触点和自动化边界 | AI PM + Risk + CX | Intent taxonomy、risk tier matrix、confusion report |
| Policy and boundary engine | 决定能否回答、是否需披露、是否需人工、是否允许工具动作 | Product Architect + Compliance | Policy rule set、decision log、approval record |
| Evidence layer | 连接系统事实、政策、知识库、模型输出和来源元数据 | Data / Platform / Knowledge Owner | Source ID、effective date、retrieval trace、API response |
| Uncertainty layer | 评估证据强度、来源冲突、模型置信、OOD、缺失信息和 answerability | EvalOps + Model Risk | Calibration report、answerability score、drift alert |
| Interaction renderer | 根据风险层级展示解释、不确定性、控制、下一步和反馈入口 | UX + PM | UI spec、accessibility review、copy review |
| Human control gateway | 管理 approve、edit、reject、override、escalate、rollback、stop switch | Operations + Business Owner | Override log、handoff record、rollback log |
| Feedback and learning loop | 把用户纠错、员工反馈、投诉、QA 和 incident 转成改进任务 | PM + Ops + EvalOps | Feedback taxonomy、triage SLA、eval update |
| Audit and observability | 记录谁看见什么、AI 说了什么、来源是什么、谁改了什么、结果如何 | Architecture + Risk + Audit | Trace schema、dashboard、evidence binder |
3.3 交互状态机
| State | 用户可见体验 | 系统必须判断 | 可用控制 |
|---|---|---|---|
| Discover | 知道 AI 能帮什么 | 渠道、用户类型、权限、语言、无障碍需求 | 关闭 AI、转人工、查看范围 |
| Ask / invoke | 用户提出问题或员工调用 AI | 意图、风险等级、是否客户可见、是否高影响 | 澄清、取消、选择人工 |
| Ground | AI 收集证据和上下文 | 来源是否权威、是否过期、是否冲突、权限是否足够 | 查看来源、补充信息 |
| Respond / draft | 系统回答、建议或草拟 | 是否允许自动输出、是否需模板、是否需审核 | 编辑、拒绝、复制受控内容 |
| Decide / act | 进入决策或工具动作 | 动作影响、可逆性、审批要求、限额 | 确认、二次审批、阻止 |
| Exception | 出现低置信、越界、投诉、欺诈、脆弱客户或系统失败 | 是否强制升级、暂停自动化、创建 case | 转专家、建单、保存记录 |
| Recover | 错误、投诉、申诉或撤销 | 是否需要客户通知、记录更正、补救和 incident | 撤销、回滚、申诉、重新打开 case |
| Learn | 反馈进入改进闭环 | 是否训练、是否更新知识、是否触发模型变更 | 反馈分类、QA、变更审批 |
3.4 Customer-facing vs employee-facing 架构差异
| 维度 | Customer-facing AI | Employee-facing AI |
|---|---|---|
| 交互目标 | 帮客户完成安全、清楚、可升级的服务任务 | 帮员工更快理解、判断、撰写、复核和处理 |
| 主要风险 | 误导客户、阻断人工、越界建议、隐私泄露、正式承诺错误 | automation bias、证据未读、错误写入系统、合规话术不一致 |
| 不确定性表达 | 简明、可操作、避免虚假精确和内部术语 | 更细粒度：来源、模型版本、conflict、missing field、review status |
| 控制权 | 客户能转人工、退出 AI、纠错、投诉、申诉 | 员工能 edit / reject / override / escalate / rollback / stop |
| 证据 | 客户看到必要来源和下一步，不暴露内部敏感规则 | 员工看到完整可授权证据、政策、日志和差异 |
| 审计 | 记录披露、客户输入、输出、升级、投诉和补救 | 记录 AI 建议、员工采纳、修改、拒绝、原因和下游动作 |
3.5 Role transition architecture
AI self-service
-> AI-assisted human
-> specialist review
-> supervisor / maker-checker
-> risk / compliance consultation
-> formal decision system
-> complaint / appeal / remediation
| Transition | 触发条件 | 必须传递的上下文 | 成功标准 |
|---|---|---|---|
| AI to frontline human | 客户要求人工、低置信、投诉、欺诈、复杂账户问题 | 用户问题、已验证身份状态、AI 已回答内容、来源、未解决点 | 客户不用重复核心信息，人工知道 AI 边界 |
| Frontline to specialist | 财富、信贷、AML、KYC、困难援助、法律威胁 | case summary、证据包、风险标签、客户影响、SLA | 专家收到足够信息并可追溯 |
| Specialist to supervisor | override、高金额、脆弱客户、政策例外 | 决策理由、替代方案、客户影响、相关政策 | 审批不是行政盖章 |
| Human to system-of-record | 人确认后写入正式系统 | 批准人、时间、版本、字段差异、客户通知状态 | 下游记录可复现 |
| System to recovery team | 错误、投诉、申诉、事故 | 原始 transcript、AI trace、人工动作、影响范围 | 可以补救、回滚和改进 |
4. Risk/UX Matrix / 风险体验矩阵
HAI 设计不能按“功能复杂度”定强度，而要按客户影响、自动化程度、可逆性、证据质量和用户能力定强度。
4.1 风险分层
| Tier | 客户 / 员工影响 | 例子 | 默认 HAI 策略 |
|---|---|---|---|
| Tier 0: Public information | 公开、低风险、非个性化 | 营业时间、普通产品 FAQ、公开费率入口 | AI 身份披露、来源链接、基础反馈 |
| Tier 1: Account service | 涉及账户事实、状态、费用、服务请求 | 账单解释、交易查询、卡片状态、争议进度 | 强认证、系统事实优先、缺证据转人工 |
| Tier 2: Regulated guidance | 涉及产品选择、资格、风险、权益和客户理解 | 信用卡比较、贷款条件解释、投资教育、困难援助说明 | 边界披露、合规话术、证据强度、人工可达 |
| Tier 3: High-impact decision support | 影响信贷、欺诈、AML、KYC、投诉、催收、财富建议 | 信贷 memo、fraud block review、AML narrative、complaint root cause | 员工复核、完整 evidence、override reason、QA sample |
| Tier 4: Automated high-impact action | AI 直接触发权益变化、资金动作、账户限制或正式通知 | 自动拒贷、自动冻结账户、自动关闭投诉、自动发出正式通知 | 默认禁止或强审批；需要可撤销、申诉、停机和风险接受 |
4.2 UX 控制矩阵
| Risk signal | UX / product control | Architecture control | Evidence |
|---|---|---|---|
| AI 不确定 | 澄清问题、显示缺失信息、提供人工入口 | answerability threshold、abstention policy | uncertainty reason、route decision |
| 来源冲突 | 展示冲突并停止给结论 | source conflict detector、policy precedence | conflicting source IDs、effective dates |
| 高影响动作 | 二次确认、审批、说明后果 | tool gateway、maker-checker、limit check | approval log、action diff |
| 用户纠错 | 允许改正事实和意图 | correction capture、case state update | correction type、before / after |
| 员工拒绝 AI | 要求结构化 reason code，但不增加过高负担 | override taxonomy、feedback queue | override reason、review outcome |
| 客户要求人工 | 明显入口、warm handoff、case ID | routing service、context package | handoff timestamp、SLA |
| 脆弱客户或困难援助 | 简明语言、减少销售、人工优先 | vulnerability signal、safe response policy | route reason、special handling |
| prompt injection / malicious input | 安全拒答、保护系统指令和数据 | instruction hierarchy、tool confirmation | security event、blocked action |
| 自动化偏差上升 | 降低默认采纳、随机挑战、强制证据阅读 | acceptance analytics、QA sampling | accept rate、read time、error catch rate |
| 模型 / prompt 变更 | 通知员工、重跑关键 eval | change gate、version routing | release note、regression report |
4.3 Automation bias controls
| Bias pattern | 行为信号 | 产品设计 | 评估方法 |
|---|---|---|---|
| Default acceptance | 员工高比例直接点 accept | 不默认选中 AI 建议；关键字段要求查看证据 | accept-without-edit rate、evidence-open rate |
| Authority halo | 员工认为 AI 分数就是事实 | 文案标明“建议 / 草稿 / 风险信号”，不是结论 | reviewer interview、scenario test |
| Time pressure reliance | 队列 SLA 压力下盲采纳 | 高风险 case 保护审核时间，减少批量批准 | SLA vs error catch correlation |
| Under-correction | 员工只改语气不改事实 | 提供事实字段 diff 和 reason code | material edit rate、QA defect |
| Automation complacency | 员工不再主动查政策 | 随机 evidence challenge、spot check | policy lookup rate、challenge pass rate |
4.4 Calibrated trust controls
| Trust state | 风险 | HAI 设计目标 | 观测指标 |
|---|---|---|---|
| Over-trust | 用户过度采纳错误 AI | 增加证据、边界、不确定性、强制复核 | wrong acceptance rate、complaint rate |
| Under-trust | 用户不用有价值 AI | 明确能力范围、展示可靠来源、提升可预测性 | qualified adoption、dismissal reason |
| Mistrust after failure | 出错后完全放弃 | 提供恢复、补救、解释和改进通知 | return usage after recovery、CSAT by incident |
| Blind trust in human handoff | 认为人工一定知道上下文 | warm handoff 和完整 case context | repeat-information rate、handoff resolution |
| Misplaced trust in metrics | 管理层只看准确率和节省时间 | 把 trust metric 接入客户影响和控制有效性 | control dashboard、risk committee review |
5. Financial Retail Examples / 金融零售案例
5.1 客户可见：信用卡拒绝原因解释助手
| 设计维度 | 好设计 | 风险控制 |
|---|---|---|
| Mental model | 说明 AI 可解释正式通知含义，不能生成或替代正式 adverse action notice | 区分 FAQ、申请状态、正式 reason pipeline |
| Evidence | 只引用正式 reason code、客户已收到通知、公开政策和系统状态 | 禁止 LLM 猜测“可能因为收入不足” |
| Uncertainty | 如果没有正式原因，回答“当前无法在聊天中确认”，转人工或正式渠道 | answerability gate |
| Control | 客户能请求人工解释、补充材料、申诉或重新申请路径 | handoff + case ID |
| Recovery | 若解释错误，能更正 transcript、通知客户并更新知识库 | complaint / remediation workflow |
示例交互：
客户：为什么我的提额申请没有通过？
AI：我可以解释你收到的正式通知中的主要原因和下一步。当前聊天不能替代正式通知，也不能生成新的审批结论。请确认你要查看最近一次申请的通知摘要，或转人工客服。
5.2 客户可见：交易争议与欺诈报告
| 阶段 | HAI 要求 | 金融零售实现 |
|---|---|---|
| 意图识别 | 把“我不认识这笔交易”识别为争议 / 欺诈高优先级 | 不继续普通交易 FAQ |
| 不确定性 | 未认证或缺交易 ID 时要求补充信息 | 不暴露账户明细 |
| 控制 | 客户确认后创建 dispute case，清楚说明不会立即退款 | consequence disclosure |
| 人工升级 | 大额、老年客户、重复欺诈、情绪激烈时 warm handoff | specialist queue |
| 恢复 | 错误分类可重新打开 case | appeal / reopen path |
5.3 客户可见：财富产品教育与建议边界
| 用户意图 | AI 可做 | AI 不应做 | HAI 控制 |
|---|---|---|---|
| “什么是货币基金？” | 解释概念、风险、费用、流动性 | 说“最适合你” | 教育来源 + 边界说明 |
| “我有 5 万美元半年后买房，买什么？” | 识别个性化建议请求，转正式适当性流程 | 直接推荐具体基金 | advice boundary gate |
| “帮我买这个产品” | 跳转正式交易流程和风险披露 | 在聊天里直接下单 | tool isolation |
| “你们是不是保证收益？” | 明确风险和不保证收益 | 模糊承诺 | approved disclosure |
5.4 员工可见：AML narrative copilot
| 设计维度 | 好设计 | 风险控制 |
|---|---|---|
| Mental model | 明确 AI 生成的是调查草稿，不是 SAR 决策 | employee disclosure |
| Evidence | 展示交易模式、客户资料、规则触发、历史 case、来源时间 | evidence bundle |
| Uncertainty | 标注缺失 KYC 字段、来源冲突、异常但未证实的信号 | missing info flag |
| Controllability | Analyst 可编辑、拒绝、补充证据、升级、标记不应训练 | edit diff + reason |
| Recoverability | 如果草稿错误，能撤回下游 narrative、更新 case note | versioned narrative |
| Automation bias | 不允许一键提交 SAR；关键结论需人工确认 | maker-checker |
5.5 员工可见：信贷 underwriting copilot
| 交互点 | HAI 要求 | 验收标准 |
|---|---|---|
| Application summary | 摘要覆盖收入、负债、信用历史、抵押品、缺失材料 | 与系统字段一致率、遗漏率 |
| Recommendation | 只提供 decision support，不替代正式审批 | UI 标明 recommendation，不默认 accept |
| Reason | reason 必须来自正式 reason code pipeline | unsupported reason rate 为 0 |
| Override | Underwriter 可覆盖 AI 建议并记录业务理由 | override reason taxonomy |
| Escalation | 边界 case、fair lending signal、高金额进入 senior review | escalation precision / recall |
5.6 员工可见：Contact center agent assist
| 场景 | 交互风险 | HAI 控制 |
|---|---|---|
| 实时话术建议 | 员工照读错误或越界话术 | 合规锁定片段、事实来源、禁止自动发送 |
| 客户投诉识别 | 投诉被当成普通不满 | complaint trigger classifier + forced case creation |
| 通话总结 | 漏掉客户承诺、困难援助、威胁、欺诈信号 | structured summary + QA sampling |
| Next best action | 销售建议压过客户服务需求 | context-sensitive suppression |
| 人工转专家 | 上下文丢失导致客户重复说明 | warm handoff package |
6. Product Requirement Patterns / 产品需求模式
6.1 HAI requirement grammar
合格的 HAI requirement 不写“AI 要解释清楚”，而写成：
For [user role] performing [regulated task],
when [AI capability / uncertainty / exception condition] occurs,
the product shall [disclose / explain / control / recover / escalate],
using [evidence / policy / UI state / workflow],
so that [risk reduction / user outcome / audit evidence] is achieved,
measured by [eval metric / monitoring signal / acceptance threshold].
示例：
For a contact center agent handling a billing dispute,
when the AI drafts a customer-facing response,
the product shall display the supporting policy source, effective date, account-system fact and review state,
and shall require the agent to edit, approve or reject before sending,
so that unsupported claims and automation bias are reduced,
measured by unsupported-claim rate, material-edit rate, evidence-open rate and QA defect rate.
6.2 Requirement patterns
| Pattern | 需求写法 | 验收重点 |
|---|---|---|
| Capability disclosure | AI must state task scope, limitations and handoff path at the first meaningful interaction | 用户能准确复述 AI 能做和不能做什么 |
| Evidence display | AI answer must show authoritative source, freshness and missing information when output affects account, policy or decision support | 来源可追溯，缺失信息不被隐藏 |
| Uncertainty-to-action | If answerability is below policy threshold, AI must clarify, abstain or escalate based on risk tier | 不确定时不猜测 |
| Human correction | User or employee correction must update case state and be recorded with correction type | 纠错不是自由文本黑洞 |
| Dismissal and opt-out | User can dismiss AI, choose human path or disable non-essential proactive AI | 不用 AI 不损害服务可得性 |
| Consequence confirmation | Before any tool action, UI must explain what will change and whether it is reversible | 用户知道确认后果 |
| Role handoff | Handoff must include summary, evidence, unresolved issue, risk tier and prior AI output | 人工接管不丢上下文 |
| Feedback triage | Feedback must be categorized by error type, severity, customer impact and owner | 反馈进入治理闭环 |
| Recovery | Incorrect AI output must support correction, customer notification, reopening and remediation where applicable | 出错后能补救 |
| Change notification | Material change in AI capability or automation level must be communicated to affected users and reviewers | 用户 mental model 不被静默改变 |
6.3 User story examples
| Story | Acceptance criteria |
|---|---|
| As a customer asking about a fee, I want to see whether the answer comes from my account record or a general policy, so that I know whether it applies to me. | The response labels account fact vs general policy; shows effective date; offers human escalation when source is missing or conflict exists. |
| As an underwriter, I want AI-generated summaries to expose missing data and source conflicts, so that I do not approve based on incomplete evidence. | Summary includes missing field list, conflict indicator, source links and review status; approval disabled for unresolved required evidence. |
| As a complaint specialist, I want AI to preserve the customer’s words and not over-normalize complaints, so that regulatory complaint classification is not weakened. | AI summary includes verbatim key phrases under approved quotation length, complaint trigger tags, and reviewer confirmation. |
| As an operations manager, I want to monitor accept-without-edit and override patterns, so that I can detect automation bias and under-trust. | Dashboard cuts metrics by team, product, risk tier, model version, language and queue pressure. |
6.4 Non-functional requirements
| NFR | HAI interpretation | Evidence |
|---|---|---|
| Accessibility | AI disclosure, uncertainty, controls and handoff are perceivable and operable across channels | WCAG review、screen reader test、plain-language review |
| Latency | Controls do not create hidden pressure to accept AI blindly | latency budget by risk tier、queue capacity model |
| Security | AI cannot reveal restricted evidence or execute hidden tool actions | RBAC retrieval、tool allowlist、audit log |
| Privacy | Feedback and transcript use respects purpose limitation and retention | data use register、retention policy、masking |
| Reliability | Handoff, escalation and recovery work during model outage | fallback runbook、service health dashboard |
| Explainability | Explanations map to source, rule, model or human review state | explanation schema、citation validation |
| Auditability | Organization can reconstruct interaction and control operation | trace ID、version、source、actor、action、outcome |
7. Eval Metrics / 评估指标
HAI eval 必须同时覆盖模型输出、用户理解、控制使用、人工交接、恢复效果和风险结果。
7.1 HAI metric taxonomy
| Metric family | 指标 | 说明 |
|---|---|---|
| Mental model | task scope comprehension、limitation recall、AI identity recognition | 用户是否知道 AI 的能力、边界和身份 |
| Evidence | citation support rate、source freshness、unsupported claim rate、missing info disclosure rate | 输出是否有足够来源支撑 |
| Uncertainty | abstention precision、clarification success、false certainty rate、conflict handling rate | 不确定时是否正确降级 |
| Controllability | dismiss rate、edit rate、override rate、control discoverability、tool confirmation completion | 人能否有效控制 AI |
| Recoverability | recovery success rate、case reopen rate、wrong-output remediation time、appeal path completion | 出错后能否恢复 |
| Feedback | actionable feedback rate、feedback-to-eval conversion、time to fix repeated error | 反馈是否进入改进 |
| Automation bias | accept-without-evidence rate、accept-without-edit rate、incorrect acceptance rate、evidence-open-before-approve rate | 员工是否盲采纳 |
| Calibrated trust | qualified adoption、over-trust defects、under-trust dismissals、trust calibration survey | 信任是否与能力匹配 |
| Handoff | warm handoff success、repeat-information rate、handoff SLA、handoff resolution quality | 角色切换是否真实有效 |
| Risk outcome | complaint rate、customer harm incidents、QA critical defects、policy violation rate | 交互是否降低风险 |
7.2 Offline eval
| Eval set | 样本来源 | 测什么 |
|---|---|---|
| Golden task set | 专家标注的典型客户问题、员工 case、政策问题 | 正确性、来源、边界、语气 |
| Exception set | 投诉、欺诈、困难援助、脆弱客户、法律威胁、越权建议 | 异常识别和强制升级 |
| Uncertainty set | 来源冲突、缺少证据、过期政策、身份未验证 | abstain / clarify / escalate |
| Automation bias drill | 故意放入错误 AI 建议让员工审核 | 错误捕捉率、证据查看率 |
| Role transition set | AI 到人工、专家、主管、申诉的多阶段 case | handoff context completeness |
| Recovery set | 错答、误分类、错误工具动作后的补救流程 | rollback、reopen、notification |
7.3 Online monitoring
| Dashboard view | 必看切片 | 异常信号 |
|---|---|---|
| Interaction quality | product、channel、language、risk tier、model version | unsupported claim 上升、clarification failure |
| Control usage | team、role、queue、case type、SLA pressure | accept-without-evidence 上升、override 下降 |
| Handoff | source state、target team、SLA、customer segment | repeat-information rate 高、handoff abandonment |
| Feedback | error type、severity、owner、fix age | 同类错误反复出现 |
| Customer impact | complaint、appeal、remediation、vulnerable segment | 投诉集中在某渠道或语言 |
| Change release | prompt、model、retriever、policy version | 新版本上线后 false certainty 上升 |
7.4 Threshold examples
以下是训练用阈值示例，正式项目应按业务风险、样本量、法规要求和机构政策校准。
| Use case | Release gate example |
|---|---|
| Customer fee explanation | unsupported claim rate below 1%; source freshness displayed for 100% policy-based answers; human handoff available in 2 clicks or less |
| Complaint chatbot | complaint intent recall above 95% on seeded test set; no complaint-blocking pattern in usability test; case ID issued for qualifying complaints |
| Underwriting copilot | formal reason code hallucination rate equals 0 on golden set; evidence-open-before-approve above 90%; senior review triggered for policy exceptions |
| AML narrative draft | critical omission rate below 2%; analyst material-edit captured for 100% submitted narratives; SAR decision not auto-submitted |
| Agent assist | compliance-locked phrase alteration blocked 100%; call summary QA critical defect below agreed threshold; warm handoff context completeness above 95% |
8. Templates / 模板
本节提供可直接放入作品集的 filled pattern。使用时把示例场景替换成自己的金融零售 use case，并保留字段结构、证据要求和 metric 连接。
8.1 HAI Product Canvas
| Field | Example: Credit decline explanation assistant |
|---|---|
| User and task | 信用卡客户希望理解提额申请结果，并知道下一步 |
| AI role | 解释正式通知和一般流程，不生成审批结论 |
| Human role | 客服解释、信贷 specialist 处理复杂争议、合规确认话术 |
| Regulated boundary | Adverse action、fair lending、客户沟通、投诉 |
| Mental model promise | “AI 可以解释已生成的正式信息；不能替代正式通知或人工复核。” |
| Evidence sources | Decision system reason code、notice copy、public policy、customer account status |
| Uncertainty signals | 无正式 notice、reason code 缺失、客户身份未验证、来源冲突 |
| User controls | 转人工、创建 case、上传补充材料、申诉路径、退出 AI |
| Recovery path | 错误解释触发投诉 case、话术更正、客户通知、知识库修复 |
| Metrics | unsupported reason rate、handoff success、complaint escalation accuracy、customer comprehension |
8.2 Mental Model Design Card
| Design decision | Example |
|---|---|
| AI identity | “你正在使用本行 AI 助手；复杂问题可转人工。” |
| Capability statement | “我可以解释账单费用、交易状态和常见政策。” |
| Limitation statement | “我不能在聊天中批准贷款、生成正式拒绝原因或提供个性化投资建议。” |
| Evidence promise | “涉及账户或政策的问题会显示来源或转人工确认。” |
| Control promise | “你可以随时转人工、要求建单或关闭 AI 回复。” |
| Change promise | “如果 AI 能力或自动化范围发生重要变化，系统会在使用前提示。” |
8.3 Uncertainty Communication Pattern
| Condition | Customer-facing wording | Employee-facing wording |
|---|---|---|
| Missing source | “我没有找到足够资料确认这个费用，我可以帮你转人工查询。” | “No authoritative source found; answer blocked. Route to billing SME.” |
| Source conflict | “资料显示不一致，需要人工确认后再答复。” | “Policy A and account record disagree; show both sources and require escalation.” |
| Low confidence intent | “你是想报告未授权交易，还是查询一笔已知交易？” | “Intent confidence below threshold; require classification before draft.” |
| High-impact boundary | “这个问题涉及正式审批或账户限制，需要进入人工流程。” | “High-impact decision support; AI may summarize but cannot decide or execute.” |
| Tool consequence | “确认后会创建争议交易申请，不会立即退回资金。” | “Tool action creates case only; no credit issued. Approval log required.” |
8.4 Control Inventory
| Control | Applies to | UI behavior | Audit event |
|---|---|---|---|
| Dismiss AI | Customer and employee | AI panel collapses; task remains available | ai_dismissed with reason if provided |
| Edit draft | Employee | Diff shown before submission | draft_edited with changed fields |
| Reject suggestion | Employee | Suggestion removed from case flow | suggestion_rejected with reason code |
| Escalate | Customer and employee | Warm handoff with context package | handoff_created with target queue |
| Override | Authorized employee | Requires policy reason and approval tier | override_submitted / override_approved |
| Rollback | Operations / supervisor | Reverts or reopens impacted workflow | rollback_started / rollback_completed |
| Stop automation | Business owner / incident lead | Disables route, tool or model version | automation_stopped with scope |
8.5 Exception Handling Runbook
| Exception | Detection | Immediate response | Owner | Evidence |
|---|---|---|---|---|
| Customer says “I want to complain” | Complaint intent trigger | Create complaint case or transfer to complaint team | Complaint Ops | transcript、case ID、handoff time |
| Possible fraud | Fraud keyword + transaction context | Authenticate, limit disclosure, route to fraud workflow | Fraud Ops | intent、transaction ID、customer confirmation |
| Vulnerable customer signal | Age proxy, hardship language, accessibility need, scam concern | Use plain language, avoid sales, offer human support | CX + Compliance | route reason、support offered |
| AI gives unsupported claim | Citation validator or QA finding | Suppress answer, correct customer-facing content, create defect | Product + EvalOps | source trace、bad output、fix ticket |
| Employee accepts wrong AI advice | QA or challenge drill | Coach reviewer, update pattern, adjust UI if systemic | Ops Lead | QA defect、training record |
| Tool action misfire | Monitoring or user report | Freeze route, rollback if possible, notify owner | Incident Lead | tool trace、impact scope |
8.6 HAI Audit Event Schema
| Field | Example value |
|---|---|
| trace_id | hai-2026-06-29-credit-000184 |
| user_role | customer / agent / underwriter / analyst |
| channel | mobile / web / branch / contact_center / back_office |
| ai_identity_disclosed | true |
| task_intent | credit_decline_explanation |
| risk_tier | Tier 3 |
| model_version | regulated-chat-v7 |
| prompt_policy_version | credit-boundary-2026-06 |
| evidence_sources | notice_123、reason_code_pipeline、policy_credit_limit_2026 |
| uncertainty_reason | source_missing / source_conflict / low_intent_confidence / none |
| ai_output_type | answer / draft / recommendation / refusal / escalation |
| human_control_used | edit / reject / approve / escalate / rollback / none |
| outcome | answered / handed_off / case_created / blocked / remediated |
| feedback_type | unsupported_claim / missing_info / wrong_tone / correct |
| customer_impact_flag | low / medium / high |
| retention_class | customer_service_record / model_risk_evidence / complaint_record |
9. 30-Day Training Plan / 30 天训练计划
目标：把 HAI 从概念学习转成可面试、可设计、可评审、可作品集展示的能力。每天产出一个小 artifact，30 天结束形成一个完整 case package。
| Day | 主题 | 训练任务 | 输出 |
|---|---|---|---|
| 1 | HAI source reading | 阅读 Microsoft HAI Guidelines，按 18 条原则写金融零售翻译 | 18-guideline mapping |
| 2 | Google PAIR lens | 用 mental model / feedback / control 重写一个 chatbot 体验 | mental model critique |
| 3 | NIST RMF lens | 用 Govern / Map / Measure / Manage 拆解一个 HAI 风险 | HAI risk map |
| 4 | Use case selection | 选择 customer-facing 和 employee-facing 各一个案例 | use case brief |
| 5 | Journey mapping | 画客户或员工任务旅程，标出 AI 触点 | HAI journey map |
| 6 | Mental model | 写 AI identity、capability、limitation、handoff promise | mental model card |
| 7 | Risk tiering | 按客户影响、可逆性、自动化程度分层 | risk tier matrix |
| 8 | Evidence design | 定义来源、有效期、冲突、缺失信息和引用规则 | evidence display spec |
| 9 | Uncertainty design | 把低置信、来源冲突、缺资料转成 clarify / abstain / escalate | uncertainty-to-action matrix |
| 10 | Control design | 定义 dismiss、edit、reject、approve、override、rollback、stop | control inventory |
| 11 | Automation bias | 设计防盲采纳 UI 和员工 challenge drill | automation bias test |
| 12 | Feedback loop | 设计结构化反馈 taxonomy 和 triage SLA | feedback ops spec |
| 13 | Role transition | 设计 AI to human / specialist / supervisor handoff | handoff package |
| 14 | Exception handling | 写投诉、欺诈、脆弱客户、越权建议的处理规则 | exception runbook |
| 15 | Customer-facing script | 写 5 个客户可见交互样例 | approved response patterns |
| 16 | Employee copilot script | 写 5 个员工 copilot 审核样例 | employee review patterns |
| 17 | Tool action boundary | 设计工具调用确认、限额、审批和回滚 | tool gateway spec |
| 18 | Audit schema | 定义 trace、source、version、human action、outcome 字段 | audit event schema |
| 19 | Offline eval | 设计 golden、exception、uncertainty、handoff eval set | eval data plan |
| 20 | Usability eval | 设计 5 个用户任务和理解度测试问题 | HAI usability protocol |
| 21 | Metrics | 建立 mental model、uncertainty、control、handoff、recovery dashboard | metric dictionary |
| 22 | Release gate | 定义上线门槛、阻断项和 sign-off | HAI release gate |
| 23 | Monitoring | 定义生产监控、报警、切片和 review cadence | monitoring dashboard plan |
| 24 | Incident response | 写 unsupported claim 或 tool misfire 的处理流程 | incident runbook |
| 25 | Accessibility | 检查披露、控制、不确定性和 handoff 的无障碍 | accessibility checklist |
| 26 | Privacy and retention | 定义 transcript、feedback、audit 的使用和保留边界 | data use matrix |
| 27 | Executive memo | 写一页给风险委员会的 HAI 上线摘要 | governance memo |
| 28 | Portfolio case | 整理前 27 天 artifact 成 case study | portfolio draft |
| 29 | Interview practice | 准备 8 个 HAI 面试答案 | interview answer pack |
| 30 | Capstone review | 做一次 20 分钟汇报和 10 分钟追问 | final case package |
10. Interview Answers / 面试答案
Q1: 你如何解释 Human-AI Interaction 在受监管 AI 中的价值？
30 秒版本：
Human-AI Interaction 不是让 AI 更会聊天，而是让用户在正确 mental model 下使用 AI：知道 AI 的能力和边界，看见证据和不确定性，能控制、纠错、升级和恢复。对金融零售来说，它直接影响客户权益、员工判断、合规证据和自动化风险。
2 分钟版本：
我会把 HAI 作为 AI 产品架构的一层。第一层是 expectation setting，让客户或员工知道 AI 在流程中扮演什么角色。第二层是 evidence and uncertainty，让输出有来源、有效期、缺失信息和不确定时的处理。第三层是 controllability，人可以 edit、reject、override、escalate、rollback 或 stop。第四层是 feedback and recovery，错误能进入投诉、补救、eval 和知识更新。最后用指标监控 automation bias、handoff success、unsupported claims、control usage 和 customer harm。
Q2: 如何防止员工过度依赖 AI copilot？
30 秒版本：
我不会只靠培训，而会用产品控制降低 automation bias：不默认采纳 AI、关键建议必须展示证据、记录 accept-without-edit、设计错误建议 drill、要求高风险 case 结构化 override 和 QA 抽样。
2 分钟版本：
员工过度依赖通常来自时间压力、权威光环和 UI 默认值。我会先按风险层级识别哪些输出会影响客户权益，例如信贷、AML、投诉和欺诈。然后在 UI 上把 AI 输出标成 draft 或 recommendation，不让它看起来像正式结论；关键字段旁边展示证据和缺失信息；高风险动作前需要人确认后果；accept、edit、reject、override 都要记录。生产上监控 evidence-open-before-approve、accept-without-edit、material edit rate、QA critical defect 和队列压力的关系。如果某团队采纳率异常高但纠错率低，我会触发 coach、UI 调整或临时降低自动化。
Q3: 你会如何表达 AI 不确定性？
30 秒版本：
我通常不用“87% 置信度”作为主要表达，而是把不确定性转成用户能行动的信号：来源不足、资料冲突、身份未验证、问题不清、超出范围。然后按风险决定澄清、拒答、转人工或允许低风险回答。
2 分钟版本：
金融零售里，概率数字很容易制造虚假精确感。我的做法是建立 uncertainty-to-action matrix。比如账户费用解释要显示政策来源和生效日期；如果找不到来源，就不能猜，要转人工。信贷原因必须来自正式 reason pipeline，不允许 LLM 推测。员工 copilot 可以看到更细的 internal signal，例如 source conflict、missing field、OOD、model version 和 answerability；客户侧则用简明语言说明“资料不足，需要人工确认”。不确定性表达必须连接到行动，而不是只做提示。
Q4: Customer-facing AI 和 employee-facing copilot 的 HAI 设计差异是什么？
30 秒版本：
客户侧重点是披露、边界、人工可达、可理解和救济；员工侧重点是证据、复核、纠错、override、审计和防 automation bias。两者都需要校准信任，但展示的信息深度和控制方式不同。
2 分钟版本：
客户面对 AI 时不一定知道系统限制，所以必须清晰说明 AI 身份、能做什么、不能做什么、如何转人工，以及回答依据。客户可见输出不能泄露内部规则，也不能用复杂免责声明转嫁风险。员工 copilot 的用户经过培训，可以看到更多证据、模型信号、来源冲突和内部政策；但员工面临队列压力，所以更需要防止一键采纳和隐藏自动化。架构上，客户侧要强身份验证、权限过滤、投诉和人工入口；员工侧要 edit diff、override reason、QA sampling、maker-checker 和 audit trace。
Q5: 如何设计 AI 到人工的 handoff？
30 秒版本：
好的 handoff 不是一个“联系客服”按钮，而是带上下文、责任、SLA 和证据的角色切换。人工应知道用户问题、AI 已做什么、证据来源、不确定点、风险等级和需要完成的下一步。
2 分钟版本：
我会定义 handoff trigger、target queue、context package 和 success metric。触发条件包括用户要求人工、投诉、欺诈、困难援助、低置信、来源冲突、高影响动作和系统失败。上下文包至少包括用户意图、身份验证状态、AI 输出、来源、缺失信息、风险标签、客户情绪或脆弱客户信号、已创建的 case ID。指标看 warm handoff success、repeat-information rate、handoff SLA、first-contact resolution 和投诉升级。这样 handoff 才是有效监督和服务恢复，而不是体验装饰。
Q6: 如何把 HAI 写进 PRD？
30 秒版本：
我会在 PRD 里单独写 HAI requirements：mental model、evidence、uncertainty、control、feedback、handoff、recovery、audit 和 metrics。每条都要有验收标准和监控指标。
2 分钟版本：
普通 PRD 常写“AI 给出清晰解释”，这不可验收。我会改成可测需求：在某角色执行某任务时，如果 AI 给出某类输出，必须展示哪些来源、限制和控制；不确定时必须如何澄清或升级；用户或员工如何纠错；动作前如何说明后果；错误后如何恢复。然后把它连接到 eval：unsupported claim rate、source freshness、false certainty rate、control discoverability、accept-without-edit、handoff success、recovery time。这样 HAI 从设计原则变成上线门禁。
Q7: 你如何处理 AI 体验中的 trust？
30 秒版本：
目标不是提高信任，而是校准信任。用户该信任时敢用，不该信任时能识别，高风险时能转人、要求证据或停止自动化。
2 分钟版本：
我会先定义 trust promise：AI 在这个场景里被允许承担什么任务，不被允许承担什么任务。然后通过证据、不确定性、边界、控制和恢复建立 calibrated trust。比如客户问投资建议时，AI 可以做教育解释但不能直接推荐；员工看 AML 草稿时，AI 可以总结证据但不能替代 SAR 决策。指标上不只看 adoption，还要看错误采纳、过度拒用、纠错率、证据查看率、投诉和 incident。信任不是品牌文案，而是持续运行的产品控制。
Q8: 如何向架构评审委员会汇报 HAI 设计？
30 秒版本：
我会用一页图展示交互控制链：intent/risk classification、evidence、uncertainty、policy decision、UI controls、human handoff、audit trace、monitoring 和 incident loop，并说明每个高风险动作的 owner、控制和证据。
2 分钟版本：
架构评审关心的不只是页面，而是系统能否执行控制。我会先说明 use case 风险等级和客户影响，再展示 AI 在流程中的边界。接着讲证据层连接哪些系统，uncertainty 如何进入 policy engine，哪些情况下 answer、clarify、refuse、escalate 或 block。对于工具动作，我会说明 confirmation、maker-checker、limit、rollback 和 stop switch。最后给出 trace schema、monitoring dashboard 和 release gate，证明上线后可以复盘、审计和持续改进。
11. Portfolio Package / 作品集包
一个高级 HAI 作品集不应只展示漂亮界面，而要展示你能把人机交互、风险治理、产品架构和运营落地串起来。
11.1 推荐 case 题目
| Case | 适合展示的能力 |
|---|---|
| Credit decline explanation assistant | regulated boundary、adverse action reason、uncertainty、human escalation |
| Complaint and dispute chatbot | complaint detection、handoff、case creation、recovery、customer harm control |
| AML narrative copilot | employee-facing copilot、evidence、automation bias、maker-checker、audit trace |
| Wealth education and advice boundary assistant | suitability boundary、customer disclosure、role transition、tool isolation |
| Contact center agent assist | real-time suggestions、compliance phrase lock、warm handoff、QA monitoring |
11.2 Artifact checklist
| Artifact | 内容 | 评审者会看什么 |
|---|---|---|
| One-page executive brief | use case、risk tier、customer impact、control summary、release decision | 是否抓住业务价值和风险边界 |
| HAI journey map | 用户任务、AI 触点、不确定性、控制、handoff、recovery | 是否懂真实流程 |
| Mental model card | AI identity、capability、limitation、evidence、control promise | 是否能设计正确预期 |
| Risk/UX matrix | 不同风险层级对应披露、证据、控制和人工复核 | 是否能按风险分层 |
| Interaction state machine | states、transitions、exception、recovery | 是否具备架构思维 |
| Evidence display spec | source、freshness、missing info、conflict、citation support | 是否能防幻觉和虚假解释 |
| Control inventory | dismiss、edit、reject、approve、override、rollback、stop | 是否把控制权产品化 |
| Handoff runbook | trigger、target、context package、SLA、metrics | 是否理解人机角色切换 |
| Eval plan | golden set、exception set、automation bias drill、usability test | 是否能把 UX 变成 eval |
| Monitoring dashboard | mental model、uncertainty、control、feedback、handoff、risk outcome | 是否能上线后运营 |
| Audit schema | trace、version、source、actor、action、outcome、retention | 是否能满足审计和复盘 |
| Interview narrative | 背景、选择、权衡、控制、指标、结果 | 是否能讲成 PM / 架构师故事 |
11.3 Case study storyline
1. Business problem
客户或员工在哪个高价值、高风险任务中需要 AI。
2. Regulated boundary
哪些输出可能影响客户权益、正式决策、投诉、销售或账户动作。
3. HAI design thesis
本案例的核心不是让 AI 更自然，而是校准信任、保留控制和保证恢复。
4. Interaction architecture
风险识别、证据、不确定性、policy decision、UI controls、handoff、audit。
5. Key design decisions
为什么这样披露、为什么这样表达不确定性、为什么某些动作必须人工。
6. Eval and release gate
如何用 golden set、exception set、usability test 和生产指标证明可上线。
7. Operational governance
feedback、QA、incident、model / prompt change 和 management reporting。
8. Portfolio insight
你从金融零售、AI 产品和架构角度得到的可复用原则。
11.4 一页作品集摘要示例
| Section | Example content |
|---|---|
| Case name | Regulated complaint and dispute AI assistant |
| User problem | 客户在移动银行中报告未授权交易、费用争议或投诉时，常被普通 FAQ 阻断，重复说明问题 |
| AI capability | 意图识别、政策解释、case 创建辅助、warm handoff summary |
| Design risk | 错误分类投诉、泄露账户信息、虚假承诺退款、阻断人工、无法复盘 |
| HAI controls | AI 身份披露、强认证、uncertainty-to-action、人工入口、case ID、evidence trace、feedback loop |
| Architecture | intent/risk classifier + policy engine + evidence layer + handoff service + audit trace + monitoring |
| Eval | complaint recall、unsupported claim rate、handoff success、repeat-information rate、recovery time |
| Business value | 提升服务可达性和处理效率，同时降低投诉阻断和错误承诺风险 |
| Interview angle | “我把客服 AI 从 chatbot 设计成受监管服务控制系统。” |
12. Final Operating Checklist
上线前，HAI 设计至少要回答以下问题：
| Question | Good answer looks like |
|---|---|
| 用户是否知道 AI 在哪里参与？ | 有明确 AI identity、AI-assisted human、人工接管状态和能力边界 |
| 用户是否知道 AI 可能错在哪里？ | 有来源、有效期、缺失信息、冲突和越界说明 |
| 用户能否控制 AI？ | 可 dismiss、edit、reject、override、escalate、rollback、stop |
| 不确定时系统做什么？ | 按风险 tier clarify、abstain、refuse、escalate 或 block |
| 高风险动作是否可逆或可审批？ | 有 consequence disclosure、maker-checker、limit、rollback 和 audit |
| 人工接管是否真实有效？ | 有 warm handoff context、target queue、SLA、case ID 和责任人 |
| 反馈是否进入改进？ | 有 feedback taxonomy、triage owner、eval update 和 release gate |
| 是否监控 automation bias？ | 有 evidence-open、accept-without-edit、wrong acceptance、QA defect 指标 |
| 是否能证明控制运行？ | 有 trace schema、version、source、human action、outcome 和 retention |
| 变更是否影响 mental model？ | 模型、prompt、能力和自动化范围变更有通知、培训和回归 eval |
一句话收束：
好的 Human-AI Interaction 不是让人感觉 AI 更聪明，
而是让人在有证据、有边界、有控制、有恢复路径的条件下，
把 AI 用在该用的位置，并在不该信任时及时停下来。