绝代小李传统可用性测试在AI产品面前失效的瞬间，我印象特别深。做过一次AI客服的评估，实验室里完成率接近完美，用户按照脚本走，该问的问，该答的答。上线两周，真实用户一句"我要退订单但保留积分"，系统直接给了一长串会员积分规则说明，用户骂了一句就跑了。那一刻我发现，问题不是提示词写得不够好，而是当时的测试方法论压根没有把"真实场景"当成测试对象。那个项目之后，我把场景化测试引入了可用性评估流程，前后做了几十个AI产品项目，这里把整个方法拆开讲一遍，包括它解决的问题、设计流程、执行细节和那些只有在实践中才会踩到的坑。
1. 传统可用性测试为什么管不住AI产品——一段翻车复盘
1.1 复盘中的三个失效点
刚才那个AI客服案例，我团队做了完整复盘，三个问题非常典型。
第一，输出不可穷举。传统可用性测试的任务基本是封闭式的，比如"找到商品并加入购物车"，预期路径明确，通过与否一眼判定。但生成式AI产品永远在接受开放式输入，测试脚本写的"用户询问退换货政策"在真实对话里能演化出上百种问法，脚本只能覆盖其中少数几种。你在实验室里给出的是"我想退货"，真实用户说的是"这东西昨天还能用今天坏了你们管不管"。不是同一种语言。
第二，上下文高度敏感。传统软件的用户操作是离散动作，点错按钮撤销就行。AI对话产品是连续的，前面聊了三轮关于颜色的偏好，第四轮用户问"那这个呢"——系统能不能接住这个指代，完全依赖上下文保持能力。传统可用性测试把用户当离散操作者，AI产品里用户是对话参与者，测试方法必须跟着变。
第三，失败是概率性的。传统软件同样的操作产生同样的结果，AI产品同样的输入可能时好时坏。旧测试框架里"任务完成"是一个布尔值，但对AI产品来说，同一个任务可能第一轮答对了、第二轮答偏了、第三轮又绕回来了。你需要的不是"是否完成"，而是"在什么条件下完成、稳定性如何、偏差有多大"。
1.2 从静态检查到动态推演
这三个失效点指向同一个结论：传统可用性评估本质上是对界面元素和交互路径的静态检查，而AI产品需要的是对体验的动态推演。
场景化测试的出发点就是把评估单元从"任务"换成"场景"。任务是什么？"查询订单状态"。场景是什么？"一个明天要出差的女用户，昨晚下单了出差要用的小型充电宝，显示今天下午送到但她告诉前台代收，她想在出门前确认配送情况，如果来不及她想改成公司地址"。注意区别——后者自带人物的动机、处境、前置信息链和情绪压力，这些恰恰是触发AI产品暴露问题的环境要素。
一个更重要的事实是，AI产品的可用性问题绝大多数不是界面层的，而是认知层的。用户误解了系统能力边界、系统误解了用户输入、对话过程中上下文悄悄丢了一段——这些只有把人放进一个足够完整的叙述性场景里才会暴露。你给用户一个干巴巴的"测试任务"，用户会进入"测试模式"去操作，那个状态下他的表达方式、容错意愿、期望值都和平常完全不一样，测出来的数据自然失真。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 构建场景化测试的核心配方：从用户故事到场景矩阵
2.1 场景表达的六要素模板
场景化测试的第一步不是写问题，而是搭场景。我推荐用一段式故事而不是结构化字段，原因是叙述性表达能让评估员和用户同时建立情境感。每个场景必须包含六个要素。
- 用户身份：年龄、角色、和相关背景。"32岁市场专员，习惯用语音输入"比"一位用户"有效得多。
- 目标意图：这个用户带着什么问题来？要得到一个什么结果？
- 当前状态：进入对话前，用户已经做过哪些事、知道哪些信息、有什么情绪？
- 环境约束：时间压力？设备限制？网络不佳？这些看似外围的条件会显著影响表达方式。
- 阻碍条件：设计一个不顺畅的状态，逼出用户的真实诉求。比如"她翻了官网帮助页没找到答案，已经有点不耐烦了"。
- 成功预期：用户认为问题的正确解法大概是什么样子？这个要素容易被忽略，但它是事后评判AI回答质量的关键参照。
把它们串起来，一个场景的样子就是："小雨，35岁，设计师，平时很少用AI产品（身份）。她刚把一份需求文档粘贴进AI写作助手，要求输出一份演示文稿大纲，但AI输出的结构太散了（状态）。她希望大纲能按照'问题背景—解决方案—落地计划'三段组织，而且要能直接在PPT工具里套用的风格（目标+成功预期）。她赶着傍晚的项目汇报，只剩四十分钟（环境约束）。过程中她不明白为什么AI一直在问技术术语（阻碍条件）。"——这就是一个完整的测试场景，评估员只需要把这段场景讲给用户，然后说一句"现在请你开始吧"。
2.2 从高频到边界的场景矩阵分级策略
任何产品都不可能穷举场景，所以必须分级。我在项目中通用四层矩阵。
- P0高频主干：用户每天都会碰到的核心链路，比如AI助手的写作生成、AI客服的订单查询。这类场景决定产品的基本体验基线，占比建议50%。
- P1低频高损：使用频率低但出错代价大，比如账单退款、数据导出、账号迁移。这类场景一次糟糕体验就可能流失用户，占比30%。
- P2边界与风险：输入极端长文、多意图混杂、专业术语密集这类边界情况，还包含安全和合规相关的敏感输入，占比15%。
- P3对抗性误用：用户恶意或半恶意地试图绕过约束、套取系统底层指令、诱导生成违规内容。这类是AI产品特有的评估维度，占比5%。
注意P2和P3不是可选项。很多AI产品在正常场景下表现都不错，一到多意图和边界输入就崩，因为训练数据里几乎没有这类样本。对抗性测试则关系到内容安全和产品底线，即使只跑一轮也要覆盖。
2.3 场景数据准备是决定成败的一环
场景定完，接下来准备数据。这是新手最容易糊弄、但决定测试成败的环节。
每一条测试语境都需要配套数据，包括用户在进入场景前已经产生的对话历史、当前输入的内容文本、关联的外部系统状态。以AI客服为例，用户说"我想取消这单"之前，可能已经聊过物流、退过上一单，这些历史记录如果不提供给用户扮演者，他进入场景后根本没办法说出符合场景的话。
真实数据的获取优先级是：线上日志的真实脱敏样本大于由产品经理根据用户访谈撰写的样板对话，大于由测试人员凭空编造的对话。凭空编造的最大风险是同质化，写出来的输入文本干净、规整、正中要害，真实用户不会那么说话。我见过太多场景库里的输入文本长这样，"请帮我规划一份三天的北京行程"，可真实用户的表达是"我想去北京玩几天，别太累的那种，住的地方别太贵"。差距很大。
3. 执行一场场景化测试的完整流程
3.1 招募与分组：人、场景之间的配对逻辑
场景化测试的招募目标和传统可用性测试基本一致，覆盖目标用户群，但有一个AI产品特有的要求：必须同时覆盖新手和资深用户两个极端群体。
新手用户带来的是"初始心智模型测试"，他第一次用这个产品，能不能快速理解能力边界？他说出口的问题往往是模糊的、口语化的、信息不完整的，这最能检验系统理解力。资深用户带来的则是"路径依赖测试"，他过去用别的大模型产品的习惯、快捷键记忆、交互预期，都会投射到你当前的产品上，哪里符合预期、哪里产生断裂，一目了然。
一个人测多少个场景？我的经验是六到八个封顶。AI对话产品测试非常消耗精力，持久的任务会显著降低扮演质量，超过八个场景后用户基本进入机械应答状态，数据就不真实了。
分组上建议按用户特征做矩阵，比如"新手低频、新手高频、老手高频、老手低频"四格，保证每个格子里至少有三名用户。AI产品对话输出方差大，样本少了压根分不清是系统问题还是用户发挥问题。
3.2 任务脚本设计的三个自然段结构
场景化测试的任务脚本不是传统列表式的"请完成以下步骤"，而是分三个自然段讲给用户听。
第一段是热身，大概两到三分钟，用来建立场景代入感。比如："小美，你在一个建筑事务所工作，今天下午要和甲方开线上方案会。你之前把一份概念文本交给了AI设计助理，让它整理成汇报稿，但你还没看过它生成的内容。"这个阶段什么都不做，只是让用户在心里住进这个角色。
第二段是启动，给用户一个明确但开放的动作指令。注意不能给操作步骤，只能给动机。"请你现在打开产品，把这份整理好的汇报稿要过来，然后按你的需要在会上展示。"用户自己决定从哪句话开始、怎么追问、怎么表达自己的要求。
第三段是干预与追问。当用户在场景中明显卡壳、走了歪路、或者表现出困惑时，评估员可以适度干预，但干预方式只能是追问式的，比如"你现在在想什么？""你觉得它为什么这么回答？"——目的是挖出决策过程，而不是把用户拉回所谓正轨。真实用户遇到问题时不会有人帮他"拉回正轨"，AI产品也等不到用户的温柔矫正。
3.3 采集什么数据，怎么记录
场景化测试的数据采集比传统测试多两个维度：对话过程数据和信任度变化数据。
对话过程数据包含几个层面：用户每一轮的输入文本和修饰次数（用户会不会反复修改提问？改了什么？这能看出他期望的表达成本有多高）；AI回复后用户的响应时滞（沉默的那几秒是不可用性的直接证据）；用户对AI回答的后续行为（直接采用、要求重写、换表达方式、放弃当前话题）。
信任度变化数据是场景化测试特有的。方法是在场景里埋两个"信任检查点"，一个在场景途中，一个在场景结束时，各问一句："到目前为止，你愿意在多大程度上相信这个产品给出的答案？"百分制即可。场景前问一次基线值，场景中问一次变化值，三个数据点就能画出一条粗略的信任曲线。AI产品的可用性不只看任务能不能完成，还要看完成后用户还信不信它，这个指标直接关联留存。
记录方式上，全程录制屏幕、对话文本、面部表情视频三轨同步。分析时以对话文本为主线，用户表情和响应时滞作为情绪注释叠加。我强烈建议用一个统一的时间戳基准对齐这三路数据，否则后期找"用户突然犹豫的那一刻到底AI回复了什么"会非常崩溃。
4. 场景化测试结果怎么读：从平均分到模式识别
4.1 五个统计口径，不能只看完成率
传统的完成率口径在场景化测试里不够用，我日常看五个统计口径。
- 场景完成率：用户是否达到了场景定义的"成功预期"。标准不是"AI给出了答案"，而是"用户拿到了能直接用的产出"——判断权在用户手里。
- 单次交互达成率：不重试、不追问的情况下，第一轮AI回复是否满足用户的当前意图。这个指标反映的是系统的单轮理解力，对对话产品来说几乎是最核心的引擎能力指标。
- 对话轮次效率：用户完成任务消耗的总轮次与"理想最低轮次"的比值。比值越接近1越好，比值超过2说明用户在大量纠偏、解释、兜圈子。
- 求助率与放弃率：多么频繁地需要评估员提示功能方法，以及在什么场景下直接放弃或绕过产品去用别的工具。放弃率是硬指标。
- 信任意愿变化率：前文说的信任检查点前后的差值，差值为正说明体验加分，为零顶多是无功无过，为负则意味着产品在消耗用户的耐心和信任。
这五个口径放到一起，能划出一张基本的体验画像：完成率高但轮次效率低的，是"能给答案但费劲"型；完成率低但信任正向的，是"能力不足但诚实可靠"型——后者其实有救，前者会默默流失。
4.2 从结果里识别失败模式
比统计数据更重要的是识别失败模式，因为AI产品的可用性问题往往不是孤立的，而是同一类根因在不同输入上的反复发作。
我在实践中归纳过五类高发模式，大家可以拿来做参照。
- 上下文断裂：用户在第N轮提到的信息，到第N+3轮被系统完全遗忘。典型表现是用户说"我刚才不是说了吗"，然后被迫重新陈述。
- 过度承诺：AI对自身能力给出了超出实际可执行范围的保证。"我可以帮您完成退款"——但它根本没有退款的操作权限。这是信任崩坏的速效药。
- 过度追问：用户给了一句话描述意图，AI回敬五个澄清问题。适度澄清是好的，过度追问是把认知负担全部转嫁给用户。
- 幻觉与迷糊：一本正经给出看似合理实则错误的信息。这个有专门评测手段，但场景化测试能补上一个特殊角度：用户在被误导后有没有能力识别错误。多数用户没有，这才是最可怕的。
- 死循环与绕圈：产品反复给出相同结构的回答，用户换三四种表达方式依然得到相似回应。
4.3 结果分层：产品性问题、模型能力问题、人设与风格问题
识别出模式之后，必须做分层归因，否则测试结论会变成一个笼统的"体验不好"，研发拿到也不知道该改哪里。
第一层是产品性问题，包括交互引导缺失、功能入口太深、状态反馈不清、提示语有歧义。这类问题不需要换模型，改交互逻辑就能解决，通常优先级最高，因为改动成本低、见效快。
第二层是模型能力问题，包括语义理解偏差、上下文保持上限太低、逻辑推理链断裂、知识库召回不准。这类问题需要调整数据策略、检索策略乃至换基座模型，周期长、成本高，必须在报告中和产品性问题严格分开，否则产品经理会拿同一个badcase同时催前端改样式和算法团队换模型——两边都不动。
第三层是人设与风格问题，语气不符、角色一致性漂移、表达风格不稳定。这类是打磨阶段的问题，不是上线阻塞项，但长期影响品牌感。
我个人的惯例是，产出报告时把每一条badcase先打上这三分层的标签，再标注关联的测试场景ID、复现条件、用户行为证据和心理证据。研发拿到一个badcase包时，按标签分流处理，效率比贴一段对话记录高得多。
5. 我在实践中的五个高频坑——每一条都是真金白银换来的
5.1 坑一：把场景写成了功能用例
这是新手最容易犯的错。写出来的"场景"是"用户询问订单状态并确认签收地址"，这仍然是功能用例，不是场景。真实的场景应该有情绪、有前情、有目标，用户的输入应该是"我明天不在家，快递能让物业代收吗"这样的自然表达，而不是"查询订单配送状态"这样标准化的操作指令。
一个判断标准：当你把场景文本给一个完全不了解产品的人看，他能不能在脑海里浮现出一个具体的人在具体环境中做具体事的画面？如果浮现不出来，场景就没写到位。
5.2 坑二：对话历史造假
做AI产品场景测试时，为了让输入足够复杂、上下文足够长，测试设计者常会直接粘贴一长段编造的对话历史作为输入。这个做法非常危险，因为真实用户从不会在第一次接触时就给出那么长的前序文本，他们顶多打两句背景就开始提要求。用这种方式测出来的只是极端输入的处理能力，不是可用性。
正确做法是动态加载：把对话历史交给用户扮演者，让他在实际对话中一段一段地表达出来。虽然耗时更长，但数据形态才是真实的。
5.3 坑三：只测单轮交互
很多AI产品测试还在用传统的"一问一答"模式，每个问题独立评测，看回答对不对、快不快。这完全绕开了对话产品的最核心体验维度——多轮的状态保持和上下文利用。我见过一个产品单轮评测分数极高，多轮场景测评连续三轮后开始失忆，到第五轮直接自相矛盾。单轮只测出了"引擎点火能力"，多轮才测出"持续行驶能力"，两个都必须测。
5.4 坑四：把"偶然正确"当"可用"
AI输出的方差导致同一个场景可能出现"A回答完全正确、B回答出现幻觉、C回答答非所问"的情况。只看最佳表现会高估产品，最稳妥的姿势是同一场景至少让不同背景的用户各跑三到五次，或同一用户重复测试取分布而非取极值。如果产品在某个标准场景成功率只有六成，你该如实写成六成，而不是挑那个最好的一次写进报告。掩盖方差就是给上线埋雷。
5.5 坑五：评估员带题意测试
评估员太熟悉目标场景，很容易在用户迷茫时给出暗示性引导："你再想想，刚才我们说到什么来着？"这等于作弊。正确做法是评估员尽量只做转述场景原文、记录行为、追问感受这三件事。追加追问时用"你现在是怎么想的"代替"你试试这样操作"，就能把提示性降到最低。
6. 场景库的沉淀——让场景化测试成为持续资产
6.1 场景库的分层结构
场景化测试最大的价值不是单次评估，而是场景库的持续积累。我建议把场景库分成三个层次来组织。
- 场景主题域：大类，比如"售前咨询""售后处理""内容创作""编程辅助"。
- 标准场景：一个用户故事级的场景描述，包含六要素，同一个主题域下通常有三个到五个标准场景。
- 场景变体：每个标准场景下的具体变体，包括输入表达方式变体（口语化、书面化、有错别字）、情绪状态变体（平静、焦虑、着急）、目标复杂度变体（单目标、多目标）。
这样组织的意义在于，当研发迭代时，你可以快速pick同一标准场景下的不同变体进行回归测试，而不是每次都推倒重来。
场景库每个条目都要标注创建日期、来源（真实日志、用户访谈、产品稿）、最后更新时间、关联功能模块。起源于真实日志的条目要打上加急优先级——那些已经被用户真实踩过一次的雷，应该排在所有未来场景的最前面。
6.2 与研发和算法团队的协作机制
场景化测试的结果如果能顺利指导研发迭代，测试的ROI才会真正体现。我的协作节奏是：
- 测试结束后24小时内输出badcase快报：不做完整报告，只列模式清单、失败场景ID、复现概率，让研发今天就能开排查。
- 一周内输出完整评估报告：包含五个统计口径的数值、分层归因结论、信任曲线变化、场景覆盖率说明。
- 每个迭代周期跑一轮"关键场景回归"：从场景库中挑P0和P1的标准场景，每场景至少两个变体，作为每次发版前的体验质量门禁。
另外，我强烈建议把场景化测试的原始对话数据开放给算法团队做fine-tune的数据筛选。场景测试产生的真实用户输入，比凭空构造的训练数据质量高得多。有一次我们把测试失败的badcase整理成训练样本补充进模型后，下一轮测试里相同模式的失败率直接降了三成——这是场景化测试的隐性红利。
最后的几点体会
关于场景化测试，我在实践中最深的一点感受是：它的核心不是一套规程，而是一种思维方式。当你养成了习惯，看任何AI产品第一反应都是"真实用户带着自己的处境和情绪，会怎样进入这个产品、提出什么话、希望获得什么结果"——而不是"这里有几个功能点要验证"。这种思维转换说起来容易，真正建立要泡在测试现场，看用户录屏、听用户吐槽、逐帧观察用户犹豫时刻的表情。测试工具能帮你采集数据，但判断力只能来自反复看真实用户在场景中的挣扎与惊喜。场景库建起来之后，也别停在原地，每次新项目结束都往里补新场景、删过期场景——它跟AI产品本身一样，需要持续迭代。用一句话总结我的立场：没有真实场景的AI可用性评估，就像没有路试的汽车测评，再漂亮的参数都说明不了问题。