任务描述里提功能名与操作步骤，测的就不是可用性了。
用五个任务测"能不能用起来"
不是测 AI 的准确率 ✗，而是测用户能否用它完成任务 ✔ ——
这是可用性测试 ✔，比指标更接近真实体验 ✔。
五个任务、五个人、一小时 ✔，就能得到非常有用的结论 ✔。
一、把任务写成"用户的目的话"
```
✗ 不好：测试问答功能的准确性
✓ 好： 你刚拿到一份 30 页的会议纪要，需要 10 分钟内知道"有哪些待办、谁负责"
```
要点：任务描述里不要提功能名与操作步骤 ✗（否则测的是"照做能力" ✔）。
二、五个任务怎么选
1. 首次成功（新用户能否做出一个结果 ✔ —— 见首次成功那篇 ✔）；
2. 典型高频（日常最常用的一件事 ✔）；
3. 边界/困难（长文档、模糊问题 ✔）；
4. 失败恢复（出错后能否重试或换路 ✔）；
5. 接管场景（需要人工时，转接是否顺畅 ✔ —— 见转人工那篇 ✔）。
三、观察什么（不只看结果）
· 卡在哪里（犹豫、反复改问法 ✔）；
· 误解了什么（把功能当成别的东西 ✔ —— 这是文档与引导的问题 ✔）；
· 说了什么原话（"我以为它会自动保存" ✔ —— 这类原话最有价值 ✔）；
· 放弃时的反应（直接关页面？找人帮忙？✔）。
要点：不要引导 ✗（"你试试右上角" ✔ 会让测试失去价值 ✔）。
四、五个人的样本够吗
够发现主要问题 ✗→✔：可用性测试的目标不是统计显著性 ✔，而是发现严重问题 ✔。
前 3~5 人通常能暴露大部分阻塞性问题 ✔；如果五个人的问题完全不同 ✔，
说明问题很多，先修最严重的再测 ✔。
五、测完做什么
```
① 按"严重程度 × 出现人数"排序 ✔
② 阻塞性问题（做不下去）优先修 ✔
③ 每条问题对应一个具体改动（改文案/改默认值/改引导 ✔）
④ 改完再测同一批任务（对比能否完成 ✔）
```
一条判据
> 最近一次可用性测试里，有没有一个阻塞性问题被改掉 ✔ 并复测通过 ✔？
> 没有，说明测试只是"看过" ✗。
本文由云枢 AI导航整理，内容以官方来源为准。
相关文章
顺序阅读
← 上一篇：把检索日志用起来：从查询分布发现内容缺口
下一篇：把模型输出接进报表：结构化数据的流转 →
第 131 / 171 篇