combo-ux-to-audit

---
name: combo-ux-to-audit
version: 1.0.0
description: UX 设计 → 审计放行 组合 Skill。将 RAX 风险评估、信任度分级、渐进式披露 与审计放行流程打通，输出 UX 审计报告 + 放行建议。
author: Max
tags: 编排器, UX到审计
- book-skill
- combo
- ux
- audit
- risk
- trust
- ai-product
requires:
- p8a-rax-risk-assessor
- p8b-trust-tier-designer
- p8c-progressive-disclosure
- ai-native-audit-release
homepage: https://github.com/gmaxxxie/ai-native-product-agent-skills/tree/main/skills/combo-ux-to-audit
stage: combo
source_book: AI Native 产品方法论
source_chapter: 编排器

---


# 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 审计报告 + 放行建议
```

## 综合输出格式

```yaml
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 监控方案**：
```yaml
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 监控方案**：
```yaml
monitoring:
  must_watch:
    - "AI 建议采纳率（目标 >70%）"
    - "客服修改率（目标 <20%）"
    - "客户满意度（目标 >90%）"
  warning_thresholds:
    - "采纳率 <50% → 检查 AI 质量"
    - "修改率 >30% → 收集修改原因"
  rollback_triggers:
    - "客户投诉率上升 >20%"
    - "客服满意度 <60%"
```

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