Combo ux to audit

UX 设计 → 审计放行

一句话定位

UX 设计完成后，用 RAX 评估风险、用信任分级验证设计、用渐进式披露检查引导——确保 UX 可以安全放行。

何时触发

• UX 设计完成，准备进入开发
• 需要验证 UX 设计是否满足审计要求
• 高风险场景上线前的最后检查
• 需要向合规/安全团队提供 UX 审计报告

输入

UX 设计方案 + 产品场景 + 风险等级。

示例输入：

产品: AI 医疗诊断助手
UX 设计: 医生输入症状 → AI 给出诊断建议 → 医生确认或修改
风险等级: 高

编排流程

输入: UX 设计方案
  ↓
【Step 1】RAX 风险评估 (p8a)
  → Risk: AI 出错时用户承担什么后果
  → Ambiguity: 用户能否理解 AI 在做什么
  → eXposure: 用户在多大程度依赖 AI 输出
  → 输出: RAX 矩阵评分
  ↓
【Step 2】信任度分级验证 (p8b)
  → 当前设计对应哪个信任等级
  → 信任等级是否匹配用户成熟度
  → 升级/降级路径是否设计
  → 输出: 信任分级评估
  ↓
【Step 3】渐进式披露检查 (p8c)
  → 功能披露是否符合渐进式原则
  → 新手引导是否充分
  → 高级功能是否在需要时展示
  → 输出: 披露合规检查
  ↓
【Step 4】放行建议生成
  → 综合 RAX + 信任分级 + 披露检查
  → 生成放行建议: go / conditional-go / no-go
  → 标注放行条件和监控指标
  ↓
输出: UX 审计报告 + 放行建议

综合输出格式

ux_audit_report:
  input:
    product: "产品名称"
    ux_design: "UX 设计方案"
    risk_level: "低/中/高/极高"
  
  rax_assessment:
    risk: { level: "低/中/高/极高", issues: ["问题"] }
    ambiguity: { level: "低/中/高", issues: ["问题"] }
    exposure: { level: "低/中/高", issues: ["问题"] }
    overall: "安全/可接受/需改进/危险"
  
  trust_tier:
    current_design_tier: "尝试/验证/委托/协作"
    user_maturity_tier: "尝试/验证/委托/协作"
    match: true/false
    upgrade_path: "升级路径"
    downgrade_trigger: "降级触发条件"
  
  disclosure_check:
    first_value_clear: true/false
    complexity_appropriate: true/false
    advanced_features_hidden: true/false
    expert_mode_available: true/false
  
  verdict:
    decision: "go / conditional-go / no-go"
    conditions: ["放行条件（如果是 conditional-go）"]
    blockers: ["阻塞项（如果是 no-go）"]
  
  monitoring:
    must_watch: ["上线后必须监控的指标"]
    warning_thresholds: ["告警阈值"]
    rollback_triggers: ["回滚触发条件"]

示例：AI 医疗诊断助手

检查项	结果	等级
RAX Risk	诊断错误可能导致误诊	高
RAX Ambiguity	医生不理解 AI 判断逻辑	中
RAX eXposure	AI 只是辅助，医生有最终决定权	中
信任分级	设计在"验证级"，但用户还在"尝试级"	不匹配
渐进式披露	首次使用缺少充分引导	需改进

放行建议: conditional-go 条件：

1. 增加诊断建议的可解释性（降低 Ambiguity）
2. 增加新手引导流程（匹配"尝试级"信任）
3. 设置异常检测告警（降低 Risk）

一句判断

UX 审计不是找设计的问题，而是确保设计在真实使用场景下安全可靠。

核心概念

概念一：UX 审计的本质——从"好不好看"到"安不安全"

传统 UX 评审关注的是"体验好不好"——导航是否清晰、交互是否流畅、视觉是否一致。AI Native UX 审计增加了一层：安不安全。

AI 产品的 UX 风险不同于传统软件：

• 传统软件的风险：用户找不到功能、操作太复杂
• AI 产品的风险：用户过度信任 AI、不理解 AI 在做什么、无法纠正 AI 的错误

UX 审计的终极问题不是"用户喜不喜欢"，而是"用户在真实使用场景下是否安全可靠"。

概念二：RAX 风险评估框架

RAX 是评估 AI 产品 UX 风险的核心框架：

维度	含义	评估问题
Risk (风险)	AI 出错时用户承担什么后果	出错的最坏结果是什么？可逆吗？
Ambiguity (模糊性)	用户能否理解 AI 在做什么	用户知道 AI 在做什么吗？知道为什么吗？
eXposure (暴露度)	用户在多大程度依赖 AI 输出	如果 AI 没了，用户还能完成任务吗？

RAX 评分矩阵：

Risk	Ambiguity	eXposure	综合风险
低	低	低	安全
低	低	中	可接受
低	中	中	可接受
中	中	中	需改进
高	中	中	需改进
高	高	中	危险
高	高	高	禁止上线

概念三：信任度分级体系

用户对 AI 的信任应该是渐进式的，而非一步到位：

信任等级	用户心态	设计策略
尝试级	"让我试试看"	低风险场景、充分引导、随时可退出
验证级	"看起来还不错"	展示来源和依据、允许验证和修改
委托级	"交给它应该没问题"	高置信度场景自动执行、异常时提醒
协作级	"它是我搭档"	深度协作、互相补充、共同决策

关键原则：信任等级必须匹配用户成熟度。设计在"委托级"但用户还在"尝试级"，会导致用户要么过度信任要么完全不信。

概念四：渐进式披露原则

AI 功能不应该一次性全部展示，而应该按用户成熟度逐步披露：

阶段	展示内容	隐藏内容
新手期	核心功能、基础引导	高级设置、自定义选项
进阶期	更多功能、快捷操作	底层配置、API 接口
专家期	全部功能、高级配置	无

渐进式披露的核心：让用户在需要时自然发现功能，而非在不需要时被功能淹没。

概念五：放行决策的三种结果

决策	条件	后续动作
go	RAX 评估安全 + 信任分级匹配 + 披露合规	上线 + 监控
conditional-go	部分风险可控 + 有条件满足	上线 + 强制监控 + 补充条件
no-go	风险不可控 + 信任不匹配	不上线 + 返回设计修改

分步执行

Step 1：RAX 风险评估

输入：UX 设计方案 + 产品场景

处理：

1. 评估 Risk：AI 出错时用户承担什么后果？可逆吗？
2. 评估 Ambiguity：用户能否理解 AI 在做什么？知道为什么吗？
3. 评估 eXposure：用户在多大程度依赖 AI 输出？如果 AI 没了会怎样？
4. 综合评分：安全/可接受/需改进/危险

输出：RAX 矩阵评分 + 风险清单

---

Step 2：信任度分级验证

输入：UX 设计方案 + 目标用户画像

处理：

1. 判断当前设计对应哪个信任等级
2. 判断目标用户的成熟度对应哪个信任等级
3. 检查是否匹配（设计等级 ≠ 用户等级 = 风险）
4. 设计升级/降级路径

输出：信任分级评估 + 匹配结果 + 升级/降级路径

---

Step 3：渐进式披露检查

输入：UX 设计方案

处理：

1. 首次使用价值是否清晰？（用户第一次打开就知道这个产品能帮自己什么）
2. 复杂度是否与用户成熟度匹配？
3. 高级功能是否在需要时才展示？
4. 是否有专家模式？

输出：披露合规检查结果

---

Step 4：纠偏机制检查

输入：UX 设计方案

处理：

1. 用户能否快速编辑 AI 输出？
2. 用户能否重新生成？
3. 用户能否完全拒绝？
4. 用户能否标记错误？
5. 用户能否升级到人工？

输出：纠偏机制完整性评估

---

Step 5：放行建议生成

输入：Step 1-4 的全部输出

处理：

1. 综合 RAX + 信任分级 + 披露检查 + 纠偏机制
2. 生成放行建议：go / conditional-go / no-go
3. 标注放行条件和监控指标
4. 定义回滚触发条件

输出：UX 审计报告 + 放行建议

---

Step 6：监控方案设计

输入：放行建议

处理：

1. 定义上线后必须监控的指标
2. 定义告警阈值
3. 定义回滚触发条件
4. 设计应急预案

输出：监控方案 + 应急预案

示例 1：AI 医疗诊断助手的 UX 审计

场景描述：AI 医疗诊断助手，医生输入症状 → AI 给出诊断建议 → 医生确认或修改。

Step 1 RAX 风险评估：

维度	评估	等级
Risk	诊断错误可能导致误诊，涉及患者生命安全	高
Ambiguity	医生不理解 AI 判断逻辑，不知道为什么给出这个建议	中
eXposure	AI 只是辅助，医生有最终决定权	中

综合风险：需改进

Step 2 信任度分级验证：

• 设计等级：验证级（AI 给建议，医生确认）
• 用户成熟度：尝试级（医生第一次用，还不信任 AI）
• 匹配结果：⚠️ 不匹配（设计在验证级，用户在尝试级）
• 建议：增加新手引导，让医生先在低风险场景下体验

Step 3 渐进式披露检查：

• 首次使用价值：⚠️ 不够清晰（医生不知道 AI 能帮自己什么）
• 复杂度匹配：⚠️ 功能过多，新手容易迷失
• 高级功能：✅ 在需要时展示
• 建议：简化首次使用流程，突出核心价值

Step 4 纠偏机制检查：

• 快速编辑：✅ 医生可以修改 AI 建议
• 重新生成：✅ 可以要求 AI 重新分析
• 完全拒绝：✅ 医生可以不参考 AI 建议
• 标记错误：⚠️ 缺少错误标记机制
• 升级人工：✅ 医生始终是最终决策者

Step 5 放行建议：

• 决策：conditional-go
• 条件：
  1. 增加诊断建议的可解释性（降低 Ambiguity）
  2. 增加新手引导流程（匹配"尝试级"信任）
  3. 增加错误标记机制
  4. 设置异常检测告警

Step 6 监控方案：

monitoring:
  must_watch:
    - "AI 建议采纳率（目标 >60%）"
    - "医生修改率（目标 <30%）"
    - "误诊事件数（目标 = 0）"
  warning_thresholds:
    - "采纳率 <40% → 启动用户研究"
    - "修改率 >50% → 检查 AI 质量"
  rollback_triggers:
    - "发生误诊事件"
    - "医生满意度 <50%"

---

示例 2：AI 客服 Copilot 的 UX 审计

场景描述：AI 客服协同工作台，AI 生成候选回复 → 客服审核 → 发送/修改。

Step 1 RAX 风险评估：

维度	评估	等级
Risk	回复错误可能导致客户投诉，但有人工兜底	中
Ambiguity	客服能看到 AI 引用的来源和依据	低
eXposure	客服可以不采纳 AI 建议，独立回复	低

综合风险：可接受

Step 2 信任度分级验证：

• 设计等级：验证级（AI 给建议，客服确认）
• 用户成熟度：尝试级→验证级（客服逐步熟悉后可提升）
• 匹配结果：✅ 基本匹配
• 升级路径：使用 50 次后解锁"高置信度自动填充"

Step 3 渐进式披露检查：

• 首次使用价值：✅ "AI 帮你快速生成回复"
• 复杂度匹配：✅ 新手只看到基础功能
• 高级功能：✅ 快捷模板、批量处理在进阶后展示
• 专家模式：✅ 可自定义回复模板

Step 4 纠偏机制检查：

• 快速编辑：✅ 行内编辑
• 重新生成：✅ "换个说法"按钮
• 完全拒绝：✅ "不需要"按钮
• 标记错误：✅ "反馈问题"按钮
• 升级人工：✅ 可转人工处理

Step 5 放行建议：

• 决策：go
• 放行条件：已满足
• 建议优化：增加推荐解释（"因为订单 #12345，推荐了这个回复"）

Step 6 监控方案：

monitoring:
  must_watch:
    - "AI 建议采纳率（目标 >70%）"
    - "客服修改率（目标 <20%）"
    - "客户满意度（目标 >90%）"
  warning_thresholds:
    - "采纳率 <50% → 检查 AI 质量"
    - "修改率 >30% → 收集修改原因"
  rollback_triggers:
    - "客户投诉率上升 >20%"
    - "客服满意度 <60%"

UX 审计不是终点，而是上线前的最后一道安全检查。审计通过不等于没有风险，而是意味着风险已被识别、量化和管控。