1. 为什么给存储产品做AI体验走查1.1 存储产品的AI功能体验问题比表面看到的更严重去年年底我们团队接到一个任务系统性盘点火山引擎存储产品线里AI相关功能的用户体验。当时产品里已经上线了不少AI能力比如用自然语言创建存储桶、智能诊断存储异常、根据历史用量给出生命周期策略建议、成本优化提示等等。从功能列表上看这些能力都“有”但用户到底怎么用用得顺不顺信不信没人能拍胸脯打包票。于是我们做了一轮完整的AI体验走查。先说背景。存储这类云基础设施本质上是最讲究“确定性”的。用户上传一个文件就要求它原样躺在那里配置一条生命周期规则就要求规则在精确的时间点生效。可AI天生带概率性同一个问题换一种问法答案可能不一样同一个建议今天是这个明天数据一变又变成那个。这种“不确定性”跟存储用户的心智模型是冲突的。我们在走查里发现用户面对AI建议时最常说的三句话是这准不准为什么这么建议我要是点了出问题怎么办——这就不是单纯的交互问题而是信任问题。传统的UX走查往往盯着页面布局、按钮位置、文案表达但AI功能的体验走查需要再多看一层AI输出的内容是否可理解是否可验证是否给用户留了反悔的余地。这也是我们把这次走查命名为“AI体验走查”的原因——对象不是普通功能而是AI能力叠加在存储控制台上之后产生的那些“人机协作”断点。1.2 走查目标不是找茬而是找“决策断点”做走查之前我们内部先对了一遍目标。走查不是来挑UI刺的更不是为了写一份“问题清单”交差。核心目标是找到用户在关键任务流程中的“决策断点”哪个环节用户不知道该不该继续哪个环节用户无法判断AI靠不靠谱哪个环节用户操作到一半发现回不了头。举个例子。存储控制台里的智能诊断能扫描出桶内的异常状态比如跨区域复制失败、生命周期规则冲突、权限策略冗余。按说这是个提效功能但我们在走查中发现用户看到诊断结果后经常卡住结果里只写“检测到3条风险”点击去看到底是什么风险风险下面只有一句“请参考文档”。用户不敢点“一键修复”因为不知道这个修复到底改了哪些配置改完能不能撤销。风险列出来了决策链条却断了。这就是典型的决策断点。所以这次走查我们把重点放在“AI怎么帮用户做决策”上。云存储用户不一定都是资深工程师很多是业务侧的开发、运维、甚至是项目负责人。他们不关心底层是对象存储还是分布式存储只关心“我能不能放心地用”。AI体验走查的核心就是验证AI有没有帮用户降低决策成本。如果AI反而制造了更多不确定性那这个功能就算技术再准体验也是失败的。2. 走查前怎么搭框架从任务流到体验断点2.1 用“任务流拆解法”梳理核心场景走查不能漫无目的地到处点。我们先把火山引擎存储产品线上与AI相关的核心场景做了个拆解每个场景都对应一个用户具体要完成的任务。最终圈定了五个高频场景场景一创建与配置存储桶。用户用自然语言描述需求AI辅助生成配置参数。场景二数据迁移与上传加速。AI判断接入链路并推荐上传方式。场景三生命周期管理。AI根据数据访问频次建议冷热分层策略。场景四智能诊断与告警。AI扫描并解释存储桶、权限、同步规则中的异常。场景五成本优化建议。AI分析用量数据给出降本建议。每个场景都拆成“标准任务流”起点、操作路径、决策点、终态。比如场景三用户的目标是让不常访问的数据自动转入低频存储那么任务流就是进入生命周期管理确认需要设置规则看AI建议的转换时间了解费用影响确认保存过一段时间验证规则是否生效。这个过程中AI介入的环节是“建议转换时间”和“解释费用影响”这两个点就是我们重点走查的地方。走查时我们发现场景三里的AI建议其实做得很聪明能结合历史访问数据给出“90天后转归档”的推荐。但问题出在价值传达上——用户根本不知道这个推荐帮他省了多少钱页面只写了“建议转换”没有试算对比也没有“如果不转会多花多少钱”。任务流能走通但决策流走不通。这也是拆任务流的意义光看页面流程是看不出来的必须把“决策流”一并画出来。2.2 体验走查评估维度五维评分卡场景拆好之后我们定了五个评估维度做成一张评分卡。每走查一个场景都要对五个维度分别打分避免“整体还行”这种模糊判断。维度说明评分参考功能可达性AI功能是否容易被找到入口是否合理1-5分找不到1一眼可见5交互效率完成一个任务所需的步骤和等待时间1-5分步骤冗余严重1低摩擦5表达可理解性AI输出的话术是否看得懂是否使用用户语言1-5分满屏术语1清晰直白5结果可信度AI提供的建议是否有依据用户是否敢执行1-5分纯黑盒1可验证5异常恢复能力操作失败后能否知道原因能否自行恢复1-5分直接报错1明确引导5实际操作中关键不是那个总分而是五个维度之间的“短板”。有的场景总分看着还行但可信度只有2分。这种功能往往最危险——用户试了一次不信任后面再也不碰等于功能白做。我们这次走查下来几乎所有AI场景的短板都集中在“结果可信度”和“异常恢复能力”上反而是“可达性”这类传统体验指标做得不错。这也说明AI功能体验的问题不在表皮而在内里。2.3 准备基线好体验的“及格线”是什么走查不能没有参照物。我们定的基线是任何AI加持的操作其体验不能比传统控制台的手动操作更差。换句话说如果用户输入自然语言让AI建一个存储桶但AI绕了几个弯都没把桶建好用户还不如自己去表单里填参数快那这个AI功能就是负价值。为什么会强调这条因为我们发现一个普遍情况很多AI功能为了体现“智能”会把简单的事情复杂化。原本创建一个存储桶填写名称、地域、访问权限三步就完了。AI聊天助手引导了半天又是推荐配置又是解释权限模型用户还得一条条确认最后点创建。表面看是人机交互实际效率远低于传统表单。用户的好奇心撑不过两次之后就会绕开AI。所以我们给每个场景都设了一个“效率基线”同样的任务用传统路径完成需要几步、多长时间用AI路径完成需要几步、多长时间。AI体验走查里最重要的数据就是这两条路径的耗时对比。如果AI路径没有显著优势甚至反而更笨重那不管它的技术多先进都不应该被推到用户面前。3. 实测下来的核心AI交互问题3.1 自然语言操作看起来智能用起来断链第一个被重点走查的是火山引擎存储控制台里的AI助手——可以用自然语言描述意图AI试着理解并执行。我们的测试用例很简单输入“帮我查看一下北京地域所有存储桶的用量情况”。结果AI确实给出了一个用量列表但点列表里的桶名并没有跳转到对应的桶详情页列表下方也没有“前往控制台”的按钮。用户想知道某个桶的具体明细只能自己回列表里找。一个本该连贯的任务硬生生断成了两截。更典型的例子是输入“把最近30天没访问的文件转成归档存储”。AI回复了一段解释说“已为您生成生命周期规则请到生命周期页面确认”。但用户没有看到规则内容也没有确认按钮只能自己跳转页面查看。问题在于AI明明有能力解析用户意图、生成配置却没有把这个能力闭环成一次可执行的配置下发操作。“看起来懂了但没有完成交付”——这是自然语言操作最常见的断链问题。这个问题背后的原因是产品设计上对AI的能力边界没想清楚。如果AI只能“理解”和“跳转”那它就是个高级搜索框如果AI能“理解”和“执行”那就必须设计一套完整的操作确认、风险提示、结果反馈、可回滚机制。我们走查时发现当前大部分AI助手停留在了“高级搜索框”的层级却又让用户误以为它能执行操作导致期望落差。3.2 智能诊断只告诉“是什么”不告诉“怎么办”智能诊断是火山引擎存储里很亮眼的一个AI能力。它能主动扫描桶策略、跨区域复制规则、版本控制状态然后用自然语言罗列出风险项。走查时我们故意构造了几个异常场景私有读的桶里放了一个公共读的权限策略生命周期规则里同时配置了“转归档”和“删除”时间点有重叠开启了版本控制但没配置生命周期历史版本无限堆积。AI确实把这些风险都检测出来了列表里能看到“有3项风险待处理”。但点进去之后每项风险只有一句描述比如“生命周期规则中存在配置冲突”然后是一个“查看文档”的链接。用户看完之后依然不知道这个冲突会导致什么后果是该改A规则还是B规则改了之后对现有数据有什么影响。尤其是“配置冲突”这类问题必须给出可执行的处理建议否则风险提示就成了制造焦虑的机器。我们内部复盘时把这个问题概括为“诊断报告没有决策树”。好的智能诊断不应该只是罗列风险而应该针对每一个风险给出“为什么发生、影响范围、处理优先级、操作步骤、验证方式”。至少要告诉用户第一步做什么。否则用户只能截图发给售后或者干脆忽略掉。长此以往智能诊断功能的打开率一定会持续走低。3.3 成本优化建议数字不透明信任崩了成本优化是云存储AI能力里最直观的卖点。我们走查的场景是模拟一个有大量历史版本文件的存储桶AI分析后给出建议“删除7天前的历史版本预计每月节省约120元”。这个建议本身是合理的但点开详情只有一行“基于您的版本文件大小与数量估算”没有任何计算过程。用户如果是个严谨的工程师就会想这120元怎么算出来的删除后还能恢复吗万一误删重要版本怎么办问题在于页面没有提供侧边对比也没有“模拟执行”的入口。用户只能先接受建议执行删除然后月底看账单。这种“先做再验证”的模式对成本敏感型用户太不友好了。我们在走查时特意让一位团队同事扮演“谨慎型用户”。他的反馈是就算AI说能省120元我也不敢点因为我不知道它会不会多删除。如果页面能先让我预览“将被删除的文件清单”再让我选“保留最近3天”或“保留最近7天”最后给一个“预计节省XX元”的实时变化那我还有可能试一下。可现在这个功能只给结论不给依据信任完全建立不起来。这个案例暴露出一个核心问题AI建议类功能的体验设计必须把“解释性”和“可控性”放在第一位。存储数据的误删是不可逆的哪怕有回收站用户的心理门槛依然很高。AI要做的不是给出最优解而是给出“用户敢执行”的解。3.4 异常反馈装死不如说人话走查中还发现一类高频问题异常反馈过于敷衍。比如我们在测试AI创建存储桶时故意输入一个不支持的存储类型名称AI回复“暂不支持该操作”。但为什么不支持是能力没覆盖还是参数写错了支持的存储类型有哪些——完全没有交代。再比如有些操作权限不足时页面直接弹一个“Error: AccessDenied”。对于技术背景强的用户也许能看懂但对于业务侧操作者这串英文跟乱码差不多。用户不知道要去找谁开权限也不知道是账号问题还是策略问题。我们开玩笑说这样的报错信息等于“装了死”——用户问了一句话它回了一个句号然后就没有然后了。一个合格的AI交互遇到错误时应当主动提供三条信息发生了什么、为什么发生、怎么解决。如果AI能识别出是权限问题就应该直接提示“当前账号缺少cos:GetBucketPolicy权限请联系管理员在访问控制中授予”甚至附上对应的授权策略模板。这类细节不需要多复杂的算法纯粹是设计意识问题。但在用户体验里恰恰是这些“说人话”的细节决定了AI功能可不可用。4. 走查的实施方法从纸上推演到真实用户验证4.1 第一步桌面走查专家走查桌面走查是最基础的一步。我们按照之前拆好的五个场景逐条执行过程中记录所有体验问题。桌面走查由三个人并行做各自独立走查最后汇总去重。人员配置上建议有产品、设计、技术三种角色产品负责判断功能逻辑是否合理设计负责交互和视觉表达技术负责判断提示信息和错误信息是否准确。每个人走查时都要记录当前任务目标、操作步骤、页面反馈、卡点位置、问题类型。问题类型我们分为五类功能缺陷、流程断裂、表达不清、信息缺失、性能问题。最后汇总成一张问题清单每条问题都得标注所属场景、复现路径、严重等级。严重等级我习惯用P0-P3四级P0是阻断任务完成的P1是严重影响信任的P2是一般体验问题P3是优化建议。举个例子。某个场景下AI生成的生命周期规则无法手动编辑只能删除重建——我们标为P1严重级别。因为用户一旦想让规则微调就得先记住原来的参数删除后重来操作成本和心理负担都很大。这类问题不解决AI再聪明用户也不敢依赖。4.2 第二步AI辅助走查怎么用AI提效这次走查我们尝试了用AI工具辅助效率确实提升了不少。首先是任务话术生成。要给每个场景准备多组自然语言输入比如“把超过30天没访问的日志文件放到低频存储里”、“我这个桶为什么账单这么贵”、“帮我看下所有桶的权限是不是有风险”。以前这些要人肉去凑现在用大模型批量生成再人工筛选出符合用户真实口语习惯的句子十几分钟就能搞定。其次是走查记录整理。桌面走查会产生大量零散笔记我们把这些笔记丢给AI让它按场景、问题类型、严重级自动归类并初步提炼出共性问题。AI给出的总结不是全对但能帮我们快速建立全局视图省去了手动翻聊天记录的功夫。尤其是多个评审人员之间相似问题的合并AI做起来比人快得多。不过要特别提醒一句AI辅助走查不能替代真人的判断。AI生成的任务话术可能只覆盖“标准问法”但真实用户会问出各种千奇百怪的问题AI总结问题时也可能遗漏上下文。我们是拿AI当过滤器和初稿工具最终的优先级排序和定性分析必须靠人来拍板。4.3 第三步用户测试与小样本量化桌面走查只能代表专家视角真实用户怎么想必须做小样本测试。我们这次招募了7名有云存储使用经验的用户覆盖了开发、运维、技术经理三种角色每人完成4个关键任务总时长约60分钟。测试过程中不引导用户只观察他们怎么理解AI的回答操作到哪一步开始犹豫最终能否完成任务。测试结果比桌面走查更扎心。比如AI成本优化功能7个人里有5个人在“点击执行”步骤前犹豫了超过30秒甚至有两个人干脆退出不做了。问原因回答都是“怕删错东西”“不知道这个操作能不能反悔”。这种真实反应光靠专家走查是模拟不出来的。小样本测试不需要追求统计学显著但可以做一个简单的量化记录每个任务的成功率、平均耗时、犹豫点位置、用户主动提问次数。这些数据出来之后再跟桌面走查的问题清单对照能清楚看到哪些问题是真实用户感知最强的。我们最终把P0和P1级别的问题重新排了序优先级最高的不是技术实现难的恰恰是那些让用户“犹豫不敢点”的信任问题。5. 落地改进的优先级判断与避坑指南5.1 优先级矩阵影响面与严重度走查报告出来之后最难的不是发现问题而是决定先改什么。如果一口气把几十条问题全抛给开发结果大概率是被打回来“能不能先做最重要的”所以我们按“影响面”和“严重度”两个维度把所有问题放进了优先级矩阵。影响面是指这个问题会影响多少用户和多少使用频次。比如AI自然语言操作的断链问题几乎每个用户都会碰到影响面就极宽又比如某个冷门错误提示的英文报错影响面相对窄。严重度则是问题对完成任务和信任的影响程度。两个维度结合得到一个简单的四分法优先处理“高影响高严重”的问题其次是“高影响低严重”最后才是“低影响低严重”。按这个矩阵我们第一轮锁定了三个必须立刻改的P0项一是AI生成操作建议后必须增加“预览确认”环节二是所有成本优化建议必须附带明确的计算依据和试算对比三是报错信息必须改为结构化的原因解决办法。这三个问题都直接影响信任而且改动并不复杂主要靠产品逻辑和文案调整就能优化。反而是那些视觉层面的细节问题暂时搁置。5.2 从设计侧看容易踩的坑走查过程中我们发现了一些反复出现的“设计坑”写出来给各位避避雷。第一个坑是把AI做成了“聊天框里的NPC”。很多产品一提到AI顺手就塞一个对话框进去让用户像跟人聊天一样操作。但对于存储控制台这种工具属性极强的产品聊天框往往不是最高效的形式。很多时候用户要的是“一句话触发一个动作”而不是多轮对话。我们在走查中甚至发现有些用户宁愿点表单也不愿意跟AI聊天因为他们不知道该怎么“正确地”跟AI说话。设计上应当把AI能力嵌入到具体的业务页面中让AI以“辅助选项”的形式出现在用户最需要的位置而不是单独建个页面逼用户去找。第二个坑是追求对话拟人化忽略了操作安全感。AI回复里出现太多“好的呢”“马上为您处理”用户反而心里发毛。存储配置操作是有实际后果的用户需要的是确定、清晰、可回退的操作引导不是卖萌。我们在走查后的改进方案里明确了一条原则AI回复应当像一位严谨的工程师而不是热情的客服。第三个坑是只验证“AI能回答”不验证“用户能闭环”。一个AI功能上线前至少要拿真实用户的语言跑通一遍完整的任务流。很多团队只测试了“AI有没有给出正确回答”却没有测“用户拿到回答后能否完成任务”。回答正确但行动断链是最隐蔽的体验陷阱。5.3 从技术侧看可落地的改进方向给技术团队的改进建议也可以沉淀为几类。第一类AI生成的结构化输出必须能映射到可执行的操作。比如AI识别出“用户想设置30天转低频”不能只给一段文本而要返回一个结构化的JSON前端拿到之后直接渲染成配置表单让用户一键确认。这条链路打通了“自然语言操作”才真正落地。第二类所有AI建议都要带“置信度”和“依据”。置信度可以用来源范围、数据覆盖度等指标计算依据则要展示给用户。比如成本优化建议可以显示“基于近30天用量分析覆盖了92%的存储对象”让用户感到这个建议不是拍脑袋。第三类AI操作必须设计成可回滚的。凡是AI代替用户执行写操作都要默认开启“回收站”或“版本控制”操作后保留一定时间窗口的回滚能力。用户不一定要真回滚但“能回滚”这个事实本身就足以提升信任。我们在火山引擎存储的场景里特别建议把版本控制能力跟AI执行操作深度绑定。5.4 长线探索AI体验走查本身也可以被自动化走查做完之后我们内部有个更大的想法既然AI能辅助我们做体验走查那是否可以把走查规则沉淀成自动化巡检能力让系统每周自己跑一遍核心任务流自动识别出体验变化比如检测AI建议是否缺少计算依据、操作是否没有确认步骤、报错是否没有引导文案。这些检查点一旦固化成规则就能在版本上线之前自动触发回归。这个方向还处于探索阶段但我们已经开始搭建基础能力。初步思路是把“走查用例”变成自动化脚本脚本执行过程中采集AI的返回结果、页面元素、用户操作路径再用规则引擎判断是否存在走查问题。比如“页面出现Error字样且下方无比比2行的引导文案”就可以自动标记为一条异常。AI可以辅助生成更多类似这种判断规则甚至通过历史正反例学习。当然自动化不能完全替代人工走查尤其是那些需要共情、需要理解用户心理的信任问题。但它可以把重复性的检查工作扛起来让人类专家把精力集中在更有创造力的设计优化上。这也是我理解“AI体验走查”的下一站。我个人在实际操作中最大的体会是给存储这类基础云产品做AI体验设计要时刻记得用户的底线。用户愿意给AI一点信任但信任是有额度的用完一次就不敢再用了。走查不是走过场而是要把每一次“不敢点”“看不懂”“怕出错”都当成产品事故来对待。每次版本发布前我都会要求团队用真实用户的口气重新跑一遍最核心的三条任务流角色扮演一个刚入行的小运维手里只有文档和AI助手。只要有一次AI给出的回答让我不敢执行、不知道怎么执行这个功能就不许上线。把AI当成刚入职的实习生来带要求它每一步都“说清楚、给依据、能反悔”这个标准不高但真要做到路还很远。