从 PM / 测试的 4 类 12 项，到「旅程阶段 × 质量原则」矩阵；并定义每个维度的四级成功标准
UX Team · 2026-09-04 · 信源：内部 Confluence 4 页 + 外部 10 项一手来源，全部可回溯
PM / 测试已有的框架、20 条共性问题、663 单工单数据 → v0 标准
NN/g、Dartmouth、IEEE、Matter、Amazon FFS、Apple HIG、ISO 9241-110 → 12 个缺口
7 阶段 × 8 原则矩阵，v0 的 35 条 + 新 21 条全部落格
维度制定 5 步法、四级成功标准、严重度、打分汇总、报告结构
引用代号：S1 OB优化框架 · S2 OB安装问题专项 · S3 OB优化-技术支持反馈 · S4 OB优化-汇报思路（内部，E4）；X1–X10 外部来源（附录页）
目标句（S4 原文）：让用户从「打开 App」到「绑定成功」，每一步都走得通、走得快、看得懂、心里有底
来源：S1「三、问题归类 - 外部」评估项 / 评估要点原文（Emma，v14，2026-07-21）；S2 测试部 20 条共性问题含研发评估结论（v30，2026-07-01）
S3 · Tapo Cam · UK · 邮件 + App 渠道 · 2026-04-01～07-01 · 663 单，其中首次配置咨询 75%
更换路由器 / 网络后重连失败；App 静默沿用旧 WiFi 凭据是「换网陷阱」（S3 结论 1、2c）
「pairing failed」可能是 App 未及时发现设备，也可能是设备连路由器超时，用户反复重试（S3 结论 3）
iOS 本地网络权限 FAQ 363 被忽略；SN 在 App 内查不到，室外机要爬梯子看标贴（S3 FAQ 频次）
权重只来自 Camera UK 一个季度 · S1「换网 84 单 12.7%」与 S3 阶段表对不上，以 S3 为准 · 耗时无埋点基线 · 竞品最佳实践只有 S2 零散几句 · 「走查记录」页为空
结论：PM 框架「合适但不完整」——四类与 ISO 原则对得上、权重有数据；但旅程范围窄，有 12 个缺口，且四类之间不正交
只从 App 内「添加设备」开始。X2 把旅程分为准备 → App 与账号 → 配对 → 配置；S3「不会开始」12.7% 有一部分发生在进 App 之前
X1「Treat reconnection like first-time setup」；X7 Simple Reconnect 改密码后自动保持连接。v0 只有一条排错子项
返回 / 取消 / 中途退出 / 失败回滚。X9 第 5 原则；X5 Matter fail-safe 协议级回滚。v0 只有「中断可续」
X1 要求告诉用户设备会有什么反馈（闪灯 / 蜂鸣）。v0 只评「灯状态文案」，不评灯语本身与 App 是否同步
X1 用户原话：假进度条走两分钟然后失败。v0 要求「有进度」，没要求「进度真实、超时快速失败」
X1：具体 / 可行动 / 流程内求助 / 从失败点重试。v0 只有前两条；S3 案例用户「自己 Google 解决」
X4 Matter 1.4.1 把 T&C 同意放进流程；X2 账号注册是主要时间坑；Camera 是隐私敏感品类
X8 Apple：先走系统 setup 再做自家 post-setup；X6 三种 commissioning flow。Tapo 部分机型支持 Matter，框架默认单 App
X7 Zero-Touch 上电即完成、Light-Touch 一次确认；X2 建议凭据存账号。v0 只到「带入当前手机 WiFi」
X10：设置者 ≠ 日常使用者 ≠ 受限用户。绑定完没有「分享家人」入口
一条没有。S3 原文 LED「红绿闪烁」——红绿色盲直接不可辨，是现成反例；UK 工单显示地区路由器差异
纯定性，agent 输出对不上漏斗；X7 Amazon 以退货率和评价做 FFS 结果指标；S1 埋点「进行中」
结构性症状：v0 里 C2「不用选」全是「= 其他项」，D2「安全感」并入 A3——说明 4 类不正交，单轴分类撑不住完整框架
PM 框架是修 bug 清单长出来的：对现有流程病灶抓得准，但评不出「本来就不该有这一步」。矩阵的好处：空格会自己暴露盲区。
S3 工单 ②③④⑤ 四个阶段全落在 P3，合计 32%，加上 ①「不会开始」共 45% 的可归因卡点；P3 列 ×3，P2 / P5 ×2
对应缺口 G1 / G2 / G7 / G8 / G9 / G10。P0 只在有实物或说明书样本时评；P6 Matter 分支只对支持机型评
每段有明确「进入事件」和「退出事件」（如 P3 从「点选 WiFi」到「App 显示设备在线」），agent 才能把截图归到唯一阶段
前置条件够、路径存在
v0 走得通 A1/A2 · X9 #1
步骤少、等待短、不重复输入
v0 走得快 B · X2 · X7
每步不看说明也知道要干什么、系统在干什么
v0 C1 · X9 #2 · X1
跨机型、跨平台、App 与设备灯语一致
新增 · X9 #3 · X8 · X1
可返回、跳过、取消、安全退出、失败回滚
新增 · X9 #5 · X5
报错具体、可行动、流程内求助、从失败点重试
v0 A3 · X1 · X9 #6
进度真实、时间可估、状态不撒谎、不假完成
v0 D1 强化 · X1
隐私同意清楚、品牌一致、完成后有首次价值
v0 D3 · X9 #7 · X4 · X8
teal 顶边 = v0 完全没有的原则。Q6 / Q7 两行 ×2，对应 S3 最大卡点与 S4 P0「错误码体系」「进度与状态感知」
| P0 准备 | P1 账号 | P2 发现 | P3 入网 ×3 | P4 首用 | P5 重连 ×2 | P6 扩展 | |
|---|---|---|---|---|---|---|---|
| Q1 可达 | P0.1 扫码直达 | P1.3 权限前置 | A1.1 A1.2 A2.1 | A2.2 A2.3 A2.4 | — | P5.1 离线提醒 | P6.3 Matter 路径 |
| Q2 高效 | — | P1.1 注册 ≤2 屏 | B1.1 B1.3 | B3.1 A3.5 B2.1 | B1.4 B1.5 B1.6 B3.2 | P5.3 批量更新 | P6.1 零输入 |
| Q3 看得懂 | P0.2 SN 可查 | — | C1.1 P2.2 灯语 | C1.2 C1.4 | C1.3 | P5.2 = 首配详尽 | — |
| Q4 一致 | P0.1 与 App 一致 | — | B1.2 P2.1 | 通用.2 双平台 | D3.1 图标 | — | P6.3 系统流程优先 |
| Q5 可控 | — | P1.1 不阻断 | A2.1 重选 | P3.3 回滚 C3.1 | P4.2 可跳过 | — | — |
| Q6 可恢复 ×2 | — | — | A3.6 重试 | A3.1–A3.4 P3.2 | — | A3.4 换网 | — |
| Q7 诚实 ×2 | — | — | D1.1 步骤器 | D1.2 D1.4 P3.1 | D1.3 不假完成 | — | — |
| Q8 信任 | P0.3 安装可回看 | P1.2 同意 A1.6 | — | — | P4.1 首次价值 | — | P6.2 分享家人 |
A/B/C/D 编号 = v0 已有 35 条；P/通用 编号 = 新增 21 条；「—」= 当前无检查点的格子，是下一轮要确认「真不需要」还是「还没想到」的地方。深浅色 = 列权重
写出每个阶段的进入 / 退出事件与品类分支（Camera / IoT / 蓝牙 / Matter）。产出：阶段定义表。依据 X2 四阶段 + S3 卡点阶段
原则来自 ISO / NN/g（不随产品变），权重来自工单 / 埋点（随产品变）。两者分开，框架才能跨产品线复用。产出：原则表 + 权重表
「S2 #15」或「X1 报错四要素」级别的定位，不接受「业界惯例」。没有引用的检查点先进候选池。产出：检查点清单（当前 56 条）
不通过 / 通过 / 好 / 优秀 各一句可观察的描述（下页）。「优秀」必须能指向一个外部标杆；「通过」= 满足内部已定需求。产出：评分 rubric
≥2 名评估者独立打分 → 合并 → 分歧项改写 rubric（NN/g：单人只能发现约 1/3 的问题）。产出：校准记录 + v1.1
阻断任务或违反原则；用户需要外部帮助才能继续。对应 Nielsen 严重度 3–4（major / catastrophe）
S3 工单里有对应卡点 = 直接判 0
满足内部已定需求（S1 需求池 / S2 研发认可项），无 major 问题；可能有 cosmetic / minor（严重度 1–2）
= 「做了该做的」
达到外部指南（NN/g / 平台 HIG / Matter 规范）的明确要求；用户不看说明书也能一次过
必须能指向 X1–X10 某条
超过行业指南：把步骤消除而非优化（零输入、系统替用户判断、失败前预防）
对标 Amazon ZTS / Apple 系统流程级
四级没有「中间值」，逼评估者表态；0 与 1 的界线借 Nielsen 0–4 严重度（频率 × 影响 × 持续性）已有 30 年共识；2 与 3 的界线用「内部需求 vs 外部标杆 vs 消除步骤」三层锚点，可解释
➖ 不适用：该机型无此环节，不计分母 · 🔒 研发已否：S2 判定不可实现，记录现状不计分，但进「待技术解锁」清单——避免 audit 反复骂设计
| 检查点 | 0 不通过 | 1 通过 | 2 好 | 3 优秀 |
|---|---|---|---|---|
| P3.1 进度诚实 Q7 × P3 · X1 · S2 #8/#11 | 无限转圈或进度条与真实状态无关；超时后才报失败 | 有阶段文字（连接中 / 注册云端）+ 超时上限 ≤ 设定值即失败 | 显示预估时长；接近超时前倒计时；进度只在有真实进展时前进 | 失败前预判并提前告知（信号弱 / 频段不符），把「等到失败」变成「提前改正」 |
| A3.1 报错分支 Q6 × P3 · X1 · S2 #9 · S4 P0 | 通用「连接失败，请重试」；无错误码 | 有错误码 + 对应排错页；区分连不上路由器 / 配对失败 | 报错四要素齐：具体 / 可行动 / 流程内求助入口 / 从失败点重试 | App 自动诊断并一键修复（切频段 / 改 DNS / 连回原 WiFi），用户只按确认 |
| B3.1 WiFi 凭据 Q2 × P3 · X2 · X7 · S3 2b | 每台设备手输 SSID + 密码；旧凭据静默沿用导致换网失败 | 默认带入手机当前所连 WiFi；密码有 64 位上限与空格提示 | 账号内已配设备的凭据可选复用；换网后明确提示「凭据已过期」 | 第二台设备零输入（Amazon LTS 级）；改密码后批量更新全部设备（Simple Reconnect 级） |
写法规则：每格只写「能截图证明」的事实；「0」引用工单或测试问题编号；「2」引用外部指南条目；「3」引用行业上限实例。写不出「3」的检查点 → 说明它是合规项而非体验项，权重降为 ×1
≥2 人独立评 → 不讨论 → 合并去重 → 分歧 ≥1 级的格子回看截图重议 → 严重度在合并后单独问卷打分（Nielsen 建议评估时不打严重度，事后集中打）
Agent 负责：按矩阵归类截图、比对 rubric 给初评、附引用、找空格。人负责：0 / 1 边界的最终判断、严重度、「研发已否」是否解锁。Agent 初评 ≠ 结论
矩阵说「哪里应该有问题」，指标说「哪里实际有问题、多严重」，两者交叉才算发现
证据等级 E0–E4：E4 内部一手文档 · E3 官方 / 权威一手 · E2 二手转述或仅摘要 · 全文与检查点清单见 projects/ux-audit-agent/