我最近一直在做AI产品类的可用性评估有个感受特别明显传统那套针对网页、App打磨体验的方法论放到AI产品上经常失灵。以前我们测一个表单、测一个电商下单流程用户跑不通就是跑不通问题定位一清二楚。现在换成一个带大模型能力的产品功能用户往往会先夸一句“它挺聪明”但再问两句就发现他其实根本不知道这个AI能做什么、该以什么方式配合它更别提在出错之后怎么自救。这篇文章不准备讲空泛的理论而是把我自己的评估思路、一次完整的案例复盘以及实际操作中沉淀下来的最佳实践都摊开说清楚。内容主要适用于正处在“从有人用到用得好”阶段的AI产品设计团队、用户体验研究员和产品经理。如果你团队里正在做智能助手、智能推荐、AI创作这类功能并且被“怎么衡量它好不好用”这件事卡住了那这篇文章大概率能给你一些直接的参考。1. 传统可用性评估方法在AI产品上的尴尬为什么“确定性思维”会失灵先说一个比较反直觉的观察我们在传统软件上积累的可用性评估经验越是成熟搬到AI产品上越容易“瞎忙”。不是方法本身错了而是我们默认的一个前提根本不成立——传统评估假设产品行为是确定的、边界是清晰的、成功是有唯一标准的。可AI产品恰恰在这三点上全部不满足。1.1 传统评估体系的基石预定义任务与确定性结果传统的可用性测试核心是“任务驱动”。选几个典型用户给他们几条明确的任务路径比如“完成账单支付”“筛选出符合条件的高潜客户”然后观察用户什么时候迷路、哪里点错、哪里停顿太久。分析师手里有一张明确的完成路径图用户偏离路径就能被标记为“可用性问题”。完成率、任务时长、错误率这三个指标一出来功能好不好用基本就有定论了。这套逻辑在AI产品上会遇到一个非常直接的问题AI产品的正确行为不是一条路径而是一个分布。举个例子你让用户在智能客服里问一句“我上个月退货的钱什么时候到账”系统可能给出完全不同的几种回应方式也许直接调出了订单状态也许反问用户退款单号甚至可能在检索不到准确上下文时给出一段泛泛的说明。没有哪个路径是官方定义的“唯一正确路径”。那评估人员就难办了到底算用户完成了任务还是没完成用户停顿三秒是在思考怎么措辞还是因为不理解AI的回答传统可用性测试里那种“十个用户测完问题清单列出来按严重级别排优先级”的做法在AI产品上经常排不出有效优先级因为我们连“什么算坏”都还没有统一口径。1.2 AI系统的三大特性让旧标准失效非确定性、模糊性、学习性我把AI产品对旧评估体系的挑战提炼成三个本质特性理解了它们后面所有方法调整都可以从这里推导出来。第一个是非确定性。同一个问题同一个用户在同一天换一种问法系统输出可能完全不一样。这不是bug而是大模型类产品的本质属性。既然系统输出是概率性的那评估就不能再看“单次回答对不对”而要看“多次交互中系统是否稳定地帮用户解决问题”。可很多团队还在用“每次点开结果必须一致”的确定性产品标准去要求AI功能得出的结论自然是又困惑又挫败。第二个是模糊性。传统软件的任何按钮、字段、状态提示都是可以被精确描述的用户明白“保存按钮点了就是存了”。AI产品不一样用户对AI能力的期望边界天然是模糊的。一个AI写作助手到底能不能理解“帮我写得更有说服力一点”一种商务场景下的说服和一种学术上的说服是同一件事吗用户自己都说不清楚产品就更难定义“做到什么程度算做好了”。第三个是学习性。好的AI产品用户会越用越顺因为它依据上下文反馈动态调整自己。可这也意味着用户在第1次和第20次使用时的体验是完全不同的。传统评估测的是“用第一次的感受”而AI产品评估必须考虑“用了一段时间后的感受”这导致评估周期拉长执行难度明显提升。传统可用性评估默认“产品是死的用户去适应它”而AI产品的可用性评估必须意识到“产品也在适应人”。这一层认知不转变所有后续操作都会拧巴。2. AI产品可用性评估应该关注什么从“好不好用”到“信不信得过”既然旧的“任务完成率思维”撑不住了那AI产品可用性评估到底该看什么我这几年的体感是可以将评估颗粒度从“功能好不好用”转向“用户信不信得过”这是AI产品可用性评估与传统产品在内部逻辑上最显著的分野。2.1 可理解性是AI可用性的第一道门槛“信不信得过”的第一件事是用户能不能理解AI在做什么以及为什么这么做。传统产品的理解成本很低按钮叫“保存”点了就保存。AI产品不是这样。用户给出一个模糊意图系统反馈一长串生成结果这个过程在用户眼里是个黑箱。用户不知道系统是依据什么逻辑生成这个答案也不知道这个答案的可信程度如何这就是许多“用户觉得AI没用”的核心来源。去年我参与评估一个智能文档助手功能的早期版本用户问“把第二章的结论放进摘要里”系统真的做了这件事但从结果看自然不足以让用户满意。问题在于用户看到新的摘要出现时并不知道“第二章结论”是否真的被准确纳入也不知道原文里其他重要内容是不是被丢弃了。功能本身没错但用户缺失对AI工作的显性化支撑就失去了进一步使用它的勇气。所以现在做AI产品可用性评估我第一个看的设计要素必然是系统是否用自己的表达方式帮助用户理解“我是谁、我当时怎么想、我操作了什么信息”。产品可以藏住技术细节但不能藏住决策过程。那种“一上来就丢答案”的交互模式从可用性角度看是标准的反面教材。2.2 可控性、容错机制与信任循环比可理解性更进一步的两个维度是可控性和容错机制。可控性指的是用户能否对AI行为进行干预。输出结果里能不能编辑、要不要允许用户否定AI的判断、用户能不能按自己的偏好校正参数和口径。设计上多一个“可编辑”“可终止”“可重答”的出口可用性就会上一个台阶。我见到过不少团队把大量精力花在优化模型输出上但忽略了输出结果之后用户没有任何抓手去调整等于是把用户按在椅子上等着看AI的表演这种失控感对可用性破坏力极大。容错机制更关键它关系到信任的建立与崩解。传统软件的容错是“报错弹窗告知操作无效”用户处理起来很直接。AI产品的错往往是有礼貌地答错它自信地输出了一篇流畅但建立在错误信息上的方案。用户如果没有意识去核实就会把错误信息当作正规信息继续使用——这种错误比弹窗报错可怕得多。评估AI产品时我会把系统是否具备“承认不确定性”的能力视为核心指标。能够对低置信度结果直接表态能够允许用户追回上下文重新提问能够清晰标识出信息出处这些设计细节直接影响整个产品的可信度边界。我认为可以把AI产品的可用性建立在一个“信任循环”模型上用户理解系统—用户尝试使用—系统回应并给出反馈口径—用户判断反馈质量并决定是否叠加干预—系统调整行为—用户进一步理解系统。评估的要点就是检查这个循环在每个环节上是否存在断点。中断越频繁用户流失越快。3. 一个真实案例智能客服知识库系统的评估复盘理论说得再多不如一个具体案例。挑一个我觉得最有代表性的项目讲透某B2B平台的智能客服知识库系统底层是大模型检索增强生成架构面向客户企业的运营人员。这个系统在立项初期更多考虑的是“回答准确率”和“知识库覆盖度”但上线一个月后客户反馈极其两极分化一部分人觉得“很不错比以前靠人工翻文档痛快多了”另一部分人直接用“不好用”“也说不清哪里不对”来形容。团队一开始也很困惑后台数据显示知识命中率已经达到了一个比较好看的数字为什么还有大量客户不满意的声音后来我们介入做了一次系统性可用性评估问题才真正暴露出来。3.1 项目背景与为什么重新做评估先交代一下这产品的实际形态。客户企业的运营人员需要在系统里向AI提问比如“帮我查一下某商品在华东区这周的库存周转率”系统会去检索后台知识库里同步过来的业务数据基于企业私有语料库生成一串回答。传统客服机器人的经验在这里直接套用了一大半包括欢迎语、快捷问题按钮、转人工入口等。但系统上线后收到的自然语言提问五花八门远超出了预设快捷问题的覆盖范围。更麻烦的是很多客户问题本质上不是一个“标准问题”而是一个场景化需求比如“我做了一份月度促销计划能不能先帮我看看有没有和库存冲突的风险”这种问题。传统客服问答案的方式在这个场景里根本不适用。重新做评估的核心原因是单一维度的“回答准确率”无法解释客户体验为什么分裂。准确率只回答了“系统输出是否命中知识却没有回答“输出结果用户能否理解”“交互过程用户是否感到顺畅”“出错之后用户能否恢复”。对一个存在模糊目标的任务场景这三项的重要性完全不亚于准确率。3.2 评估设计与关键发现这次评估我们采用了两阶段设计。先做专家评审完成后又找12名真实客户运营人员做用户测试每人四种任务类型三类问法总计约48个测试场景全程录音并记录线下操作路径。对AI产品的评估这里特别想把其中一个关键设计点拿出来说一说我们要求每个任务都必须同时以“用户发起提问”和“用户继续追问/要求修正”两个动作来观察而不是做完一次问答就算任务结束。这才触到了传统评估没到过的场景。最终暴露出的问题可以整理成三类每一类都有具体的案例支撑。第一类是目标锚定缺失。大量用户在提问时只是输入了一个很模糊的意图比如“库存情况怎么样”系统惯性地给出一段库存汇总数据但用户看后根本不知道数据是否覆盖了自己关心的维度。用户没有渠道告诉系统“我想要的是华东区、A类商品、只看周转率”。很多用户就在这一步选择了放弃他们没有理解系统是需要更具体的条件才能获得高质量回应产品也没有给出任何提示引导用户补充必要信息。第二类是结果缺乏可复核性。系统给出的汇总数据没有标注数据统计时间范围和信息来源的文档。用户对关键数字抱有天然不信任的态度因为没有依据可查他们不敢直接把AI生成的结果放进正式报告里。这个环节当时对我们的冲击很大准确率明明有90%以上但用户在可用性层面由于无法自行复核所以就等于把可信度折半了。第三类是错误恢复渠道严重不足。当系统对某个问题回答错误或者不完整时用户能做的操作几乎只有“重新提问”或者“转人工”。而整个界面没有任何“修改查询条件”“历史对话回顾”“对回答质量进行标记”之类的出口。测试里有一个用户连续问了三次都没拿到想要的字段数据最后放弃了全程没有尝试任何纠偏措施。在我们回放录音时用户在第三次提问后的沉默和叹气非常值得研究。这类沉默在传统的“任务完成率”体系里不构成问题但它恰恰是AI交互里最珍贵的信号。系统不提供反馈通道本质上是把AI默认设置的错误判断成本全部转嫁给了用户这在可用性层面几乎等于在劝退。3.3 修复后的变化数字说明问题在拿到问题清单后的部门协作中我们重点做了四项修复第一在提问界面增加“结构化追问引导区”当用户问题包含条件模糊词时通过复选框提醒用户补充时间范围、品类、区域等筛选条件第二在每次生成结果底部固定展示“数据统计口径”说明入口用户点开就能查看当前回答所引用的字段和时间范围第三把“调整查询条件”升级为核心操作视觉层级接近提问框保证修改路径触手可及第四增加“回答质量追评”功能允许用户以预期的方式对每条回答做出标记这组数据会回流成产品迭代依据。修复后过了一个月我们复测了同一批任务场景一组变化的数字比较有说服力。用户的平均交互轮次从3.2次下降到2.2次这意味着很多问题用户能在更少的来回之间解决提问后不进行任何操作直接离开的比例下降了31%说明“一次性提问得不到有效反馈就走人”的情况明显减少转人工率从27%降至11%系统自主解决问题的比例大幅提升。最有意思的是用户开始主动使用“修改查询条件”功能之后系统里沉淀下来的高质量追问数量越来越多知识库的利用效率也随之显著提升。这个案例给我留下的最大认知是AI产品可用性评估真正要解决的问题往往不在模型层和自己设计的应答质量上而在交互层——用户能不能理解系统、系统能不能向用户提供反馈机制这些“非模型因素”才是决定体验生死的关键。4. 可落地的评估方法组合从专家评审到用户测试的实操细节讲完案例回到方法论和落地操作。我会按照自己实际执行时的顺序把一套对AI产品有效的评估方法组合拆开讲。这套组合以“先借助分析再以测试验证”的思路贯穿适合大多数中小团队直接复用。4.1 “AI诊断式”专家评审针对AI特性的检查清单常规专家评审是拿着尼尔森十大可用性原则逐项对照界面。这套做法在AI产品上仍然有意义但需要先做一次“预期转换”。我在实践里把评审清单重新定义成了三组问题。第一组用户能否建立准确的AI能力心智模型——这个产品是干什么的、边界在哪里、哪些问题适合问它是否能通过开场引导文案和示例问题在30秒内传达清楚。第二组交互过程中AI的状态和行为是否处于近似透明的状态系统在“思考中”“检索中”“生成中”有没有给予足够的显式反馈用户能否判断当前结果是何时基于哪部分信息生成的。第三组错误情境下的恢复效率“AI被用户问倒”几乎是必然事件需要检查有没有足够显性的纠偏手段和兜底路径。这三组问题可以形成一张内部评审打分卡1到5分制每个维度二至三个考察点。这个阶段的优势是成本低、速度快通常半天内就能覆盖核心界面和主要对话路径为后面的正式用户测试铺好路。但必须提醒专家评审不能替代真实用户测试它只能帮你优先圈定测试重点区域因为专家本身对系统的理解远远高于真实用户会系统性低估用户的理解门槛。4.2 认知走查与会话测试让用户与AI“自然对话”而不是“完成任务”常规可用性测试最喜欢设计的“任务脚本”在AI产品里最容易水土不服。因为设计脚本的人如果对用户如何使用AI预设有偏差脚本本身就变成一种干扰因素。现在做AI产品测试更建议采用两种方法组合。第一种是认知走查法。让用户在测试过程中出声思考把他的即时想法、预期、判断依据全部口语化表达出来测试人员不干预只记录。传统产品里我们用这个方法看页面信息是否容易被理解AI产品里更适合用它看用户在对话过程中的心智博弈——对方这句话是什么意思、顺着往下该怎么表达、系统给出的回答是否满足他自己的预期。要特别关注“这AI怎么会觉得……”这一类的言语信号每一次都是系统心智模型与真实用户认知之间的天然样本。第二种我更愿意称之为自然对话测试。不再为每个用户下发固定任务清单而是给出一个场景目标让用户用自己的话去操作。比如场景目标设定为“你月底需要提交一份区域销售复盘请使用这个AI产品尽可能高效地准备数据材料”用户具体怎么提问、怎么追问、怎么使用界面辅助功能完全交给他自己发挥。最后通过分析完整对话的轮次数量、用户的追问逻辑、用户在哪个阶段产生了放弃念头来判断可用性状态。这种测试脚本上的“刻意松弛”才能还原AI产品在真实环境中最常见的开放性使用方式。很多通用性很强的发现就是在这种开放式测试里被挖掘出来的。4.3 弹窗访谈与回溯式测试捕捉“肉眼不可见”的信任问题用户测试里有一个很容易被忽略的现象AI产品里大量可用性问题表现为“用户说不出来但我正在悄悄放弃”。传统产品里用户点错按钮后通常会嘀咕一句“怎么没反应”AI产品里用户自己也没意识到问题只觉得“可能我不会用”“这个工具大概不适合我”然后静默流失。要想捕捉这类“不可能的可用性问题”我自己试下来最有效的是两种轻量工具。一是弹窗访谈。在测试界面上设计一个交互反馈点当用户完成一次提问后系统弹出一个简短询问“刚才的回答对你有帮助吗选择‘有帮助’或‘没帮助’如果选择‘没帮助’可以告诉我们可能的原因”。这个动作成本极低但回收的是用户在真实使用场景中第一时间最接近真实感受的主观反馈。无论他对答案的评价是否与实际质量一致这种“主观可用性数据”本身就很有参考价值。二是回溯式测试。把用户与AI交互的全过程录屏测试后在用户面前逐段回放请他解释每一步操作背后的思考以及在看到结果输出时他内心发生了什么。这种方式特别适合挖掘对话系统中那些“没有明确报错但信任逐渐流失”的细微信号。比如用户在得到回答后没有点击任何按钮就切换了页面回放时让他解释原因他可能会说“这个结果看起来不太可靠我打算自己重新去后台查”。这种隐性不信任在传统的数据埋点里完全看不到回溯式测试经常会给研发团队带来不小的认知冲击。5. 一堆踩过的坑和最终沉淀下来的最佳实践后面这部分内容我原本打算写成标准流程指南后来想了想还是把实操中踩过的坑和最值得带走的心得放在一起讲对正在做AI产品评估的人应该更有参考价值。5.1 那些让评估失去意义的做法先说我踩过的最大的坑用准确率代替可用性。项目早期做评估汇报时我说的最多的一个数据是“模型回答准确率达到87%”那时觉得有了这个数字就万事大吉。但在用户真实场景中用户最需要的那个回答如果恰好落在错误的13%里对用户而言准确率就是0。准确率是模型维度指标可用性是用户维度指标两者之间不能画等号。更合理的做法是把准确率当成辅助诊断数据与任务完成率、用户置信度、交互轮次效率交叉分析。第二个坑是测试任务设计过于“正式”。早期我们写任务脚本会自然写成“请通过系统查询华东区上周库存周转率并判断是否存在补货风险”这话没问题但问题在于真实用户不会这么说话。他们可能会直接说“帮我看看华东是不是快断货了”。这种语法组织上的微小差异可能导致AI系统完全不同的检索效果。如果给用户的测试任务语句过于规整测试结果会严重高估系统在真实场景中的表现。现在我在设计任务时总会加上一条要求所有测试任务描述必须口语化研究团队不给用户示范“标准提问句式”这一点对自然语言交互型产品极其重要。第三个坑是要特别提醒大型语言模型的“印象管理效应”。在用户测试中一组对话任务接一组对话任务地做用户很容易对系统整体能力形成一个“它似乎挺会聊”的良好印象但在具体的深度任务中依然无法完成目标。这类印象分数如果直接作为可用性结果呈现会掩盖很多真实问题。解决方法是把“整体满意度”和“任务成功率”分开分析并重点向团队汇报两者的差距差距越大说明系统在表层交互上越具备迷惑性深层的对话目标达成能力可能越弱。5.2 从团队协作角度分享的三条关键经验第一个经验要无条件把“评估结果”翻译成“设计变更”。AI产品团队里模型算法工程师和设计师常常因为语言体系不同发生鸡同鸭讲的局面。做评估的人不应该只丢出一份“可用性问题清单”而是帮助其成长为“交互建议”。这次智能客服项目里我们发现用户不会主动补充筛选条件于是给出的建议就不是“提示用户提供更多条件”而是具体到了哪些条件下在界面哪个区域展示哪类筛选控件。评估若不做这一步翻译往往可能得不到团队的足够重视。第二个经验用“用户测试的轮次间隔”主动适应AI的迭代节奏。AI产品迭代速度快传统产品半年做一次大版本测试在AI产品领域基本不可行。现在我的做法是“每周一测、每轮二十到三十分钟、每次聚焦一个交互层改动点”。把可用性测试从阶段性冲刺变成持续的小步快跑才能在模型更新的同时让交互设计同步验证保持体验的稳定性。第三个经验是要在团队内部建立一个统一的“体验争议仲裁机制”。AI产品天然存在不确定性针对一个功能做A/B实验时产品经理觉得效果提升用户体验研究员发现另一个维度的信任感下降这类争执几乎无可避免。我们最后沉淀下来的做法是任何争议都以“用户在与系统完成一次完整任务后的可复述性”作为最终裁决参考。用户结束测试后如果能清晰说出系统做了什么、为什么这么做、对自己的业务有什么帮助就认定这次交互是有效的反之哪怕数据面成功但用户复述不出来一律按可用性缺陷处理。这个方法看似朴素实际操作中却能有效拉齐团队的验收口径。5.3 适合重点关注的度量指标和个人建议最后给同样在构建AI产品可用性评估体系的朋友们列一个小的指标清单。常规的完成率、任务时长、错误率继续沿用但建议补充四个对AI产品更有针对性的指标首次交互成功率用户第一次提问即获得满意结果的比例不依赖追问修偏、追问修正率用户在初次得到不满意结果后愿意继续追问的比例、交互轮次效率每个任务所需的平均对话轮数轮数太多说明系统理解能力存在断层、用户信心分用户在完成任务后自评对结果的信任程度1到5分评分低通常意味着结果不可复核或缺少可信度证明。回顾这段经历我在AI产品可用性评估这条路上最大的转折点是接受“AI产品允许有缺陷”这个前提。传统产品经理总在追求零缺陷但AI产品的用户其实更能接受一个会犯错的助手他们真正无法接受的是“错了之后连补救的抓手都没有”。评估工作的重点与其花大量精力纠结如何让模型永远答对不如好好检查产品是否在每一个可能的失败点上都布置了松弛的恢复通道。多准备几条安全绳远比强迫模型变成超人更有利于可用性的真实提升。