能用、好用、有人用
三层验证，各自要看的东西不一样。
验证分三层。每一层要回答的问题不同，用的方法也不同，混在一起就什么都验不清楚。验证也不是上线前的仪式——它是每写完一段功能就发生一次的判断。
你会遇到的现象：
- 上线了，但不知道该看哪个数，只能看每天有多少人打开
- 数据不好，说不清是功能有 bug、体验太绕，还是根本没人需要
- 验收全靠自己点几下，点的还都是自己熟悉的那条路
三层各看什么
| 层 | 要回答 | 怎么验 | 不通过的表现 |
|---|---|---|---|
| 能用 | 功能对不对，异常情况会不会崩 | 走查清单、真实数据压测、安全检查 | 白屏、报错、数据丢失 |
| 好用 | 陌生人能不能自己走完 | 五秒测试、找三五个人试用并观察 | 他卡在某一步、需要你在旁边解释 |
| 有人用 | 他们会不会回来、愿不愿意付钱 | 埋点、留存曲线、转化漏斗 | 用了一次再也不来 |
「好用」这一层最容易被跳过，因为它要找人，比较麻烦。但三五个人、每人二十分钟，能发现的问题比你自己点一百遍都多。可用性测试本来就是评估产品能不能被真人顺利使用的标准方法。usability
三层分别回答三组问题：能不能跑、好不好用、有没有人用。前两层靠走查和观察，第三层靠埋点和数据——工具完全不同，混在一起就会用错方法看错层。另外，「能用」这一层不是上线前做一次就完：每次改动都可能引入回归，状态清单加真实数据压测是写完一个功能就要跑一遍的固定动作。
顺序不能乱
三层是有依赖的。下一层不成立，上一层的结论就没有意义。
- **能用不过关，就别看留存。**用户走到一半崩了，留存低是必然的，跟需求真不真没关系。
- **好用不过关，就别急着投放。**把人拉进来卡在第二步，等于花钱买流失。
- **有人用不成立，前两层做得再精也白搭。**没人需要的东西，做得再顺手也不会有人回来。
- **但发现顺序常常是反的。**数据不好 → 找人试用 → 发现某一步走不通 → 查代码发现是个 bug。所以三层要都会——你从哪一层发现问题，就从哪一层往下追。
知识工作多一层：过程可信
三层验证都默认一件事：**你看到的结果是可信的。**但当你验证的是 AI 生成的知识工作——分析、方案、模型、文案——这个前提不再成立。代码可以用测试验证输出，知识工作不行：一份 deck 里的数字再漂亮，也证明不了背后的推理是对的。你必须能检查过程、输入和引用，才能相信结果。这一层叫过程可信，是 AI 知识工作产品额外需要的一层验证。具体怎么看，见知识工作怎么验证。
判断 AI 产品时，把这一层记在心里：它有没有让你看到进行中的工作、引用和输入、推理过程？给不了这三样，它只交付结论——你永远无法验证它。三层之外加这一层，验证才算完整。
一个人怎么做
一个人做产品，三层正好对应一张时间表，每一行都是一次可以完成的检查：
| 时机 | 做什么 |
|---|---|
| 写完一个功能 | 对着状态清单逐条过；用零条数据和超长内容各跑一遍 |
| 上线前 | 走查清单全过一遍，含安全那几条；用全新账号完整走一次 |
| 上线时 | 埋点必须已经在了。没埋点的功能，上线等于没上 |
| 上线后第一周 | 找三五个真实用户看他们怎么用，别在旁边指导 |
| 上线后一个月 | 看留存曲线走不走平，这决定了要不要继续投入 |
观察用户时最难的是忍住不说话。他卡住的那十秒钟，是整个测试里信息量最大的十秒——你一开口解释，这十秒就没了。三层之间是联动的：写完一个功能做第一层，上线前做第二层，上线后做第三层。每一层都过了，才算真正交付。