AI 底层逻辑 / 经典论文
AI Service Blueprint：客户旅程与信任体验
AI Service Blueprint 把 AI 体验从“一个对话框”扩展成完整服务系统: 客户动作、前台 AI、前台人工、后台流程、数据/知识/模型、控制证据和运行指标共同决定信任。金融零售场景中, 客户是否信任 AI, 取决于系统是否能在正确时刻解释能力边界、展示依据、承认不确定、交接人工、纠正错误并留下证据。
202 行ai-foundations/papers/76-service-blueprint-ai-customer-journey-trust.md
AI Service Blueprint / Customer Journey / Trust 解读
配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是
docs/AI_SERVICE_BLUEPRINT_CUSTOMER_JOURNEY_TRUST_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。
本篇为经典框架精读（历史回顾/经典打底定位）：机制正文以 NN/g Service Blueprints（2017-08）与 Microsoft Guidelines for Human-AI Interaction（CHI 2019-05）等经典来源为锚点；最新进展见文末「SOTA 检查」。
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| NN/g Service Blueprints | https://www.nngroup.com/articles/service-blueprints-definition/ | 参考 service components、touchpoints、frontstage/backstage 和服务设计结构（原文发布 2017-08，Sarah Gibbons） |
| NN/g Customer Journey Mapping | https://www.nngroup.com/articles/customer-journey-mapping/ | 参考客户旅程、用户目标、痛点与体验证据（访问日期: 2026-07-01） |
| Microsoft Guidelines for Human-AI Interaction | https://www.microsoft.com/en-us/research/publication/guidelines-for-human-ai-interaction/ | 参考 human-AI interaction、uncertainty、feedback、correction 和 handoff 设计（论文 CHI 2019-05，Amershi et al.） |
| Google PAIR Guidebook | https://pair.withgoogle.com/guidebook/ | 参考以人为中心的 AI 产品设计和用户信任校准（访问日期: 2026-07-01） |
| NIST AI RMF | https://www.nist.gov/itl/ai-risk-management-framework | 将体验设计和风险治理、监控、证据连接（访问日期: 2026-07-01） |
核心导读
AI Service Blueprint 把 AI 体验从“一个对话框”扩展成完整服务系统: 客户动作、前台 AI、前台人工、后台流程、数据/知识/模型、控制证据和运行指标共同决定信任。金融零售场景中, 客户是否信任 AI, 取决于系统是否能在正确时刻解释能力边界、展示依据、承认不确定、交接人工、纠正错误并留下证据。
这篇的核心判断是: AI 客户旅程的失败常常不是模型能力不足, 而是 frontstage 和 backstage 没有被一起设计。
问题定义
普通 customer journey map 主要回答:
- 客户在每个阶段想完成什么。
- 客户看到什么、感受什么、遇到什么痛点。
- 哪些 touchpoint 影响体验。
AI service blueprint 还必须回答:
- 哪些步骤由 AI 解释、建议、判断或执行。
- 哪些步骤必须人工接手, 接手条件和 SLA 是什么。
- AI 使用哪些知识源、模型、工具和客户上下文。
- 何时展示引用、不确定性、拒答、升级和申诉。
- 后台哪些系统、队列、审计和控制支持前台承诺。
- 失败后如何纠错、补偿、复盘和更新知识。
AI 体验不是屏幕上的回答, 而是端到端服务承诺。只设计对话, 不设计后台, 会得到一个看起来聪明但不可运营、不可审计、不可纠错的服务。
核心原理/方法
AI service blueprint 至少包含七条 lane:
| Lane | 设计问题 | 金融零售示例 |
|---|---|---|
| Customer action | 客户想完成什么, 情绪和风险是什么 | 查询拒贷原因、申请费用减免、投诉交易争议 |
| Frontstage AI | 客户直接看到的 AI 行为 | 解释、总结、建议下一步、收集资料、拒答 |
| Frontstage human | 一线人员如何参与 | 客服接手、审批复核、合规解释、特殊处理 |
| Backstage workflow | 看不见但支撑服务的流程 | case routing、SLA、审批、队列、知识更新 |
| Data / knowledge / model | AI 用什么上下文做判断 | RAG 知识库、CRM、交易记录、policy、模型 |
| Controls / evidence | 如何控制风险并证明发生了什么 | consent、permission、logging、human approval、audit trail |
| Metrics | 如何判断体验有效且安全 | containment、CSAT、escalation、error、appeal、risk breach |
关键是 line of visibility:
- 客户看得到: AI 披露、解释、引用、下一步、人工交接、申诉入口。
- 客户看不到: 检索、模型路由、权限过滤、风险规则、队列分派、审计日志。
成熟设计会把“客户看不到但决定信任”的后台能力显性化为产品要求和架构控制。
系统/架构模型
AI service blueprint 可映射为系统架构:
Customer channel
-> AI interaction layer
-> capability framing / disclosure / uncertainty / citation
-> Orchestration layer
-> journey state / handoff / escalation / case routing
-> Knowledge and model layer
-> source registry / RAG / model gateway / policy version
-> Control layer
-> consent / permission / advice boundary / risk tier / approval
-> Operations layer
-> human queue / SLA / training / QA / incident response
-> Evidence and learning layer
-> trace / feedback / correction / appeal / knowledge update
产品问题和架构问题应一一对应:
| Service Design Question | Product Requirement | Architecture Requirement |
|---|---|---|
| 用户何时知道这是 AI | disclosure、capability framing | UI state、session metadata、model identity |
| AI 依据什么回答 | citation、source、evidence | RAG pipeline、permission filter、source registry |
| AI 何时不回答 | refusal、escalation policy | policy engine、confidence signal、intent classifier |
| 谁接手异常 | handoff route、SLA、case owner | workflow engine、queue、CRM integration |
| 如何纠错 | feedback、correction、appeal | feedback store、audit log、review workflow |
| 如何监控信任 | trust metrics、complaint trends | telemetry、event schema、dashboard、alert |
关键机制与取舍
AI 旅程中的信任时刻决定自动化边界:
| Trust Moment | 设计目标 | 失败信号 |
|---|---|---|
| Capability framing | 让用户知道 AI 能做什么、不能做什么 | 用户把建议当承诺或专业意见 |
| Uncertainty display | 低置信或证据不足时表达不确定 | AI 过度自信, 用户无法判断可靠性 |
| Citation / evidence | 展示依据和来源 | 用户无法追溯政策、条款、数据 |
| Human handoff | 高风险或异常场景平滑转人工 | 客户被困在 AI 循环里 |
| Correction | 允许用户纠错并改善结果 | AI 错了但没有反馈入口 |
| Appeal / complaint | 影响权益时提供申诉 | 客户只能接受自动化结论 |
| Memory consent | 用户控制记忆和个性化 | 用户不知道信息被保存和复用 |
| Advice boundary | 区分信息、建议、推荐和决策 | AI 越界给金融、法律或信贷承诺 |
取舍不是简单提高 containment。自动化拦截更多客户可能降低短期成本, 但如果高风险、低置信和情绪升级场景不能顺畅转人工, 投诉、申诉和品牌风险会抵消收益。
证据与控制
AI service blueprint 要支持 failure-mode walkthrough:
| Failure Mode | 因果路径 | 控制 |
|---|---|---|
| Hallucination | stale policy -> confident answer -> customer acts on wrong information | source freshness、citation、low-confidence refusal、policy update trigger |
| Wrong policy boundary | explain-only capability -> user asks recommendation -> AI recommends action | intent classifier、approved language、licensed handoff、breach monitoring |
| Automation bias | AI summary -> human trusts it -> contradictory evidence missed | show snippets、missing evidence flags、review calibration、QA sampling |
| Handoff overload | uncertainty threshold too conservative -> queue grows -> SLA breach | escalation budget、triage rules、capacity model、threshold review |
| Correction failure | user flags error -> no owner -> same error repeats | feedback workflow、knowledge owner、fix SLA、regression eval |
Blueprint 的 evidence 不能停在图上, 需要进入运行数据:
- source version and citation。
- handoff reason and queue aging。
- user correction and appeal outcome。
- policy breach and wrong advice signal。
- repeat contact and complaint trend。
- AI containment with no recontact。
- human override reason and downstream QA result。
AI产品/金融零售场景
信用卡争议客服
旅程:
发现异常交易
-> 联系客服
-> AI 收集事实
-> AI 判断 dispute 类型
-> AI 解释下一步和时限
-> 人工复核高风险案件
-> 客户收到结果
-> 客户可补充材料或申诉
关键设计:
| Lane | 设计 |
|---|---|
| Customer action | 上传交易截图、描述商户、确认是否授权 |
| Frontstage AI | 总结 dispute 类型、提示材料、解释时限, 不承诺结果 |
| Frontstage human | 高金额、老年客户、疑似欺诈、情绪升级转人工 |
| Backstage workflow | dispute case 创建、SLA、证据收集、chargeback 流程 |
| Data/knowledge/model | 交易数据、商户类别、dispute policy、监管披露文本 |
| Controls/evidence | consent、case notes、source citations、manual approval |
| Metrics | first-contact resolution、repeat contact、appeal rate、error rate、complaint rate |
核心边界: AI 可以帮助收集事实、总结材料、解释流程和时限; 不能承诺 chargeback 成功, 不能替代争议裁决, 不能隐藏人工复核和申诉入口。
信贷补件助手
AI 可解释缺失材料、校验格式、提示下一步, 但不能暗示审批概率。服务蓝图必须显示: 哪些信息来自政策, 哪些来自客户上传材料, 哪些由人工审核, 客户如何纠错, adverse action 相关解释如何与真实决策链保持一致。
反模式
| 反模式 | 表现 | 修正 |
|---|---|---|
| Chatbox-only design | 只设计对话界面 | 画出后台流程、控制、证据和运营 |
| Containment obsession | 只追求减少人工接触 | 加信任、申诉、错误和客户伤害指标 |
| Hidden uncertainty | AI 永远自信回答 | 设计不确定性、拒答和升级 |
| Handoff as escape hatch | 转人工按钮存在但队列不可运营 | 定义触发、路由、SLA、容量和反馈 |
| Citation decoration | 引用看起来存在但不可追溯 | 绑定 source registry、版本和权限过滤 |
| Feedback dead end | 用户纠错不进入知识和 eval 更新 | 建立 correction owner 和 learning loop |
最终心智模型
AI service blueprint 的最终心智模型是:
信任不是由一句提示语建立的,
而是由前台体验、后台流程、数据/模型控制、人工交接、
纠错申诉和运行证据共同建立的。
金融零售 AI 客户旅程的关键不是让 AI 显得像真人, 而是让客户在每个关键时刻知道: 这是 AI, 它依据什么, 它有多确定, 它何时不能继续, 谁会接手, 出错后如何纠正, 组织如何证明和改进这次服务。
SOTA 检查 (2026-07-01)
- 「disclosure / capability framing」信任时刻已从 UX 最佳实践升级为法律义务：EU AI Act (Regulation (EU) 2024/1689) Article 50 透明度义务自 2026-08-02 起适用——与人直接交互的 AI 系统（chatbot/虚拟助理）必须在首次交互之前或开始时告知用户「这是 AI」；欧盟委员会已于 2026-05-08 发布配套透明度指引草案（Article 50 全文、Covington 解读 2026-05）。注意区分：Annex III 高风险义务已被 Digital Omnibus（2026-05）推迟至 2027-12-02，但 Article 50 透明度不受推迟影响。本篇的 disclosure lane 在欧盟落地时需按此排期做合规映射。
- 本篇「反 containment obsession」的结论被 2026 行业共识强化：2026 年调研显示约 95% 的客服负责人计划把人工坐席作为运营模型的永久部分（"digital first, but not digital only"），Gartner 预测到 2027 年 50% 的客服组织采用 AI+人工混合模型（Gleap 2026、BlueTweak 2026）。纯自动化拦截率叙事已过时，混合运营是现役主线。
- Human handoff 的 2026 现役标准是「上下文保留式交接」：交接时传递完整对话历史、已提取实体、AI 已尝试的动作和建议下一步，并在交接后继续给人工坐席实时辅助与自动摘要；「让客户向人工重述一遍问题」被反复确认为流失的首要驱动因素（Fini Labs 2026 评测）。这正是本篇 Backstage workflow / Handoff as escape hatch 反模式的运行时证据。
- Service blueprint 方法本身仍成立，但正被扩展到 agentic AI：Forlizzi（CMU，Medium 2025）论证 service blueprint / conceptual model 等服务设计工具在 agentic AI 服务中仍适用，但需修改——设计者、客户与 AI 共同构建（co-construct）服务交付；Microsoft 于 2026-02-26 发布银行业 agentic AI 客户体验 blueprint（Forlizzi 2025、Microsoft Cloud Blog 2026-02）。对本篇的含义：七条 lane 需为自主编排、跨系统任务执行和 agent 记忆/consent 增加显性泳道，而不是被替代。
- 不随版本过时的框架性结论：七泳道 blueprint 结构、line of visibility、八个 trust moments、failure-mode walkthrough、以及「产品问题↔架构要求一一对应」表，都是与具体模型/平台无关的方法论骨架；会随版本演化的是实现层（RAG/model gateway/policy engine 的具体选型）。实现层的现役取舍见库内配套笔记：
docs/aipa/day78-ux-pattern-selection.md（Agent UX 七模式与金融 HITL 适配）与docs/aipa/day5-sar-narrative-hitl-agent-ux.md（SAR 叙述 + HITL 复核设计，2026-06-19）。