with one click
combo-ux-to-audit
// UX 设计 → 审计放行 组合 Skill。将 RAX 风险评估、信任度分级、渐进式披露 与审计放行流程打通,输出 UX 审计报告 + 放行建议。
// UX 设计 → 审计放行 组合 Skill。将 RAX 风险评估、信任度分级、渐进式披露 与审计放行流程打通,输出 UX 审计报告 + 放行建议。
[HINT] Download the complete skill directory including SKILL.md and all related files
| name | combo-ux-to-audit |
| description | UX 设计 → 审计放行 组合 Skill。将 RAX 风险评估、信任度分级、渐进式披露 与审计放行流程打通,输出 UX 审计报告 + 放行建议。 |
UX 设计完成后,用 RAX 评估风险、用信任分级验证设计、用渐进式披露检查引导——确保 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: ["回滚触发条件"]
| 检查项 | 结果 | 等级 |
|---|---|---|
| RAX Risk | 诊断错误可能导致误诊 | 高 |
| RAX Ambiguity | 医生不理解 AI 判断逻辑 | 中 |
| RAX eXposure | AI 只是辅助,医生有最终决定权 | 中 |
| 信任分级 | 设计在"验证级",但用户还在"尝试级" | 不匹配 |
| 渐进式披露 | 首次使用缺少充分引导 | 需改进 |
放行建议: conditional-go 条件:
UX 审计不是找设计的问题,而是确保设计在真实使用场景下安全可靠。
传统 UX 评审关注的是"体验好不好"——导航是否清晰、交互是否流畅、视觉是否一致。AI Native UX 审计增加了一层:安不安全。
AI 产品的 UX 风险不同于传统软件:
UX 审计的终极问题不是"用户喜不喜欢",而是"用户在真实使用场景下是否安全可靠"。
RAX 是评估 AI 产品 UX 风险的核心框架:
| 维度 | 含义 | 评估问题 |
|---|---|---|
| Risk (风险) | AI 出错时用户承担什么后果 | 出错的最坏结果是什么?可逆吗? |
| Ambiguity (模糊性) | 用户能否理解 AI 在做什么 | 用户知道 AI 在做什么吗?知道为什么吗? |
| eXposure (暴露度) | 用户在多大程度依赖 AI 输出 | 如果 AI 没了,用户还能完成任务吗? |
RAX 评分矩阵:
| Risk | Ambiguity | eXposure | 综合风险 |
|---|---|---|---|
| 低 | 低 | 低 | 安全 |
| 低 | 低 | 中 | 可接受 |
| 低 | 中 | 中 | 可接受 |
| 中 | 中 | 中 | 需改进 |
| 高 | 中 | 中 | 需改进 |
| 高 | 高 | 中 | 危险 |
| 高 | 高 | 高 | 禁止上线 |
用户对 AI 的信任应该是渐进式的,而非一步到位:
| 信任等级 | 用户心态 | 设计策略 |
|---|---|---|
| 尝试级 | "让我试试看" | 低风险场景、充分引导、随时可退出 |
| 验证级 | "看起来还不错" | 展示来源和依据、允许验证和修改 |
| 委托级 | "交给它应该没问题" | 高置信度场景自动执行、异常时提醒 |
| 协作级 | "它是我搭档" | 深度协作、互相补充、共同决策 |
关键原则:信任等级必须匹配用户成熟度。设计在"委托级"但用户还在"尝试级",会导致用户要么过度信任要么完全不信。
AI 功能不应该一次性全部展示,而应该按用户成熟度逐步披露:
| 阶段 | 展示内容 | 隐藏内容 |
|---|---|---|
| 新手期 | 核心功能、基础引导 | 高级设置、自定义选项 |
| 进阶期 | 更多功能、快捷操作 | 底层配置、API 接口 |
| 专家期 | 全部功能、高级配置 | 无 |
渐进式披露的核心:让用户在需要时自然发现功能,而非在不需要时被功能淹没。
| 决策 | 条件 | 后续动作 |
|---|---|---|
| go | RAX 评估安全 + 信任分级匹配 + 披露合规 | 上线 + 监控 |
| conditional-go | 部分风险可控 + 有条件满足 | 上线 + 强制监控 + 补充条件 |
| no-go | 风险不可控 + 信任不匹配 | 不上线 + 返回设计修改 |
输入:UX 设计方案 + 产品场景
处理:
输出:RAX 矩阵评分 + 风险清单
输入:UX 设计方案 + 目标用户画像
处理:
输出:信任分级评估 + 匹配结果 + 升级/降级路径
输入:UX 设计方案
处理:
输出:披露合规检查结果
输入:UX 设计方案
处理:
输出:纠偏机制完整性评估
输入:Step 1-4 的全部输出
处理:
输出:UX 审计报告 + 放行建议
输入:放行建议
处理:
输出:监控方案 + 应急预案
场景描述:AI 医疗诊断助手,医生输入症状 → AI 给出诊断建议 → 医生确认或修改。
Step 1 RAX 风险评估:
| 维度 | 评估 | 等级 |
|---|---|---|
| Risk | 诊断错误可能导致误诊,涉及患者生命安全 | 高 |
| Ambiguity | 医生不理解 AI 判断逻辑,不知道为什么给出这个建议 | 中 |
| eXposure | AI 只是辅助,医生有最终决定权 | 中 |
综合风险:需改进
Step 2 信任度分级验证:
Step 3 渐进式披露检查:
Step 4 纠偏机制检查:
Step 5 放行建议:
Step 6 监控方案:
monitoring:
must_watch:
- "AI 建议采纳率(目标 >60%)"
- "医生修改率(目标 <30%)"
- "误诊事件数(目标 = 0)"
warning_thresholds:
- "采纳率 <40% → 启动用户研究"
- "修改率 >50% → 检查 AI 质量"
rollback_triggers:
- "发生误诊事件"
- "医生满意度 <50%"
场景描述:AI 客服协同工作台,AI 生成候选回复 → 客服审核 → 发送/修改。
Step 1 RAX 风险评估:
| 维度 | 评估 | 等级 |
|---|---|---|
| Risk | 回复错误可能导致客户投诉,但有人工兜底 | 中 |
| Ambiguity | 客服能看到 AI 引用的来源和依据 | 低 |
| eXposure | 客服可以不采纳 AI 建议,独立回复 | 低 |
综合风险:可接受
Step 2 信任度分级验证:
Step 3 渐进式披露检查:
Step 4 纠偏机制检查:
Step 5 放行建议:
Step 6 监控方案:
monitoring:
must_watch:
- "AI 建议采纳率(目标 >70%)"
- "客服修改率(目标 <20%)"
- "客户满意度(目标 >90%)"
warning_thresholds:
- "采纳率 <50% → 检查 AI 质量"
- "修改率 >30% → 收集修改原因"
rollback_triggers:
- "客户投诉率上升 >20%"
- "客服满意度 <60%"
UX 审计不是终点,而是上线前的最后一道安全检查。审计通过不等于没有风险,而是意味着风险已被识别、量化和管控。