01 概述

火山引擎存储技术团队驱动 AI 自主完成用户体验走查 / 可用性测试的执行与评价，帮助业务改善交互体验。

• 立项“故事走查”的背景诉求和 AI 机遇

• 如何搭建“AI 评价”能力，精准识别交互问题

• 让交互体验故事走查变为技术产品，讲解系统设计，包括流程、User Story 维护、框架和 AI 模型选型、Midscene.js 的集成技巧等

02 AI 体验走查，究竟是什么？

对于互联网产品，除了满足用户基本需求以外，使用过程中的交互体验也十分重要。为了优化用户体验，业务往往需要投入大量的精力来进行繁琐的走查与优化。

想象一下，如果无需投入人力，完全靠 AI 自身就能全面走查并发现用户体验问题，提升产品质量是怎样的体验。这正是火山引擎存储业务 AI 用户体验走查系统的探索方向。

先给大家看一些真实案例 Demo。

03 案例 1 - 简单任务

名称： 资源管理-创建日志项目

步骤：进入日志服务概览页，创建一个名称为 aiux_project_${uuid} 的日志项目

AI 执行过程

AI 分析与评价

发现问题：创建项目时，用户引导弹窗遮挡

04 案例 2 - 复杂流程

名称：监控告警-创建告警策略

步骤：

1. 创建一个名称为 aiux_alarm_policy${caseId} 的告警策略

2. 监控对象选择「勿删-ai 测试专用-有索引」

3. 查询语句填写为 httpStatusCode:500

4. 触发条件为 选择有数据时警告

5. 关联名称为 '勿删-ai 测试专用' 的通知组

6. 提交创建任务

AI 执行过程

AI 分析与评价

发现问题：创建告警策略中配额不足导致出错时，错误提示不友好，且没有给出相应的解决方案指引

如上所示，在我们的实际应用中，AI 体验走查系统发现了用户在使用系统时的多个交互痛点。包括视觉遮挡、表单验证不及时、错误提示不明确等问题。通过系统给出的这些分析和建议，团队优化了交互流程，使产品体验得到提升。

用 AI 对交互体验困境进行破局

05 为什么交互体验至关重要？

在云服务产品中，良好的交互体验不仅关系到用户满意度，更直接影响业务成功。

火山引擎存储业务线作为字节跳动旗下的云服务平台，其前端控制台是用户直接接触的操作入口，交互体验的优劣直接决定了用户对产品的印象和忠诚度。对于火山引擎存储这样的企业级产品，每一个交互细节都可能影响客户的采购决策。在业务经历了前期快速迭代功能的时期之后，我们面临的挑战也在变得艰巨：

用户体验

• 因历史原因，产品或多或少都有一些低级、“反人类”、交互体验差的种种问题。

• 开发同学没有站在用户的视角深度体验过（被质疑：“你们用过过自己的产品吗？”）

稳定性

• 测试左移的大背景下，要求我们在开发的同学同时要具备对问题自查的能力，这要才能放心交付和客户一个产品。

所以，我们之前定期通过人工故事走查 / 可用性测试的方式来模拟用户使用产品的情况，以不同的角度去发现平时可能忽略的缺陷、体验问题。

06 传统方法的痛点与挑战

然而随着火山存储业务的规模不断扩大，各产品线涵盖的需求场景也越来越多。以往人工主导的用户体验走查优化模式逐渐暴露出效率低、覆盖场景有限、主观性强等短板，难以满足快速迭代和精细化优化的需求。传统的人工走查模式面临着巨大挑战：

• 效率低下：每次故事走查需要数十名研发同学投入 1~2 小时，事后还需要 UX 同学逐个 Review，消耗大量人力

• 覆盖有限：随着用例增多，人力覆盖全部场景几乎不可能

• 主观性强：不同人员的体验评价标准不一致，难以形成统一衡量

• 自动化测试不适用：传统自动化测试需要预设路径和检查点，无法模拟真实用户的自由探索行为。而且自动化测试通过，并不代表过程中没有交互问题。

07 AI 如何彻底改变体验走查方式

幸好近年来 AI 相关技术迅猛发展，字节跳动开源的 Midscene.js 框架带来了通过自然语言驱动 AI 操作浏览器的能力，而 Doubao-1.5-thinking-vision-pro 视觉模型则提供了优秀的视觉内容理解分析能力。这两项技术的结合，让我们看到了用 AI 进行交互走查的可能性。

基于此我们打造了基于多 AI 协作的全自动交互体验故事走查系统，实现了：

• 完全自主执行：「用户 AI」能够像真实用户一样，完全由 AI 自主规划并执行用户故事

• 专业评价分析：「交互专家 AI」能够分析“用户”的执行过程，指出交互问题并给出改进建议

• 低维护成本：采用自然语言描述任务，因此系统不会因为产品迭代代码变动而失效，维护成本极低

该系统彻底解放了故事走查的人工成本，效果十分显著。与传统自动化测试相比，AI 在用户体验领域具有明显的优势：

 

架构设计与实现

08 流程图

 

 

09 AI 驱动下的 UI 评价标准设计

评价方式是整个系统的关键，如何在工程上对 UX 体验进行量化是一个很大的挑战。

我们最初想构建一个 UX 评价模型，对产品的交互体验进行量化打分。然而，我们很快意识到其中的挑战：UX 设计并非一套刻板的标准，它更依赖于设计师的经验、灵感和创意。相应的，对于交互体验的评价也比较偏主观性。这使得我们难以定义一个标准的量化表格来精确衡量产品的交互体验。

经过深入思考，我们转换了视角：不再执着于对产品进行笼统的打分，而是将重点放在发现具体的交互问题上。随着人机交互领域的多年发展，设计领域积累了大量约定俗成的准则。在业务的设计语言中，也存在许多规范。我们吸取这些宝贵经验，将其转化为可执行的检查项，从而能够系统地检查产品是否存在特定的交互问题。这种方式效果更好，也更容易实行。

具体实施上，我们采用了以下内容作为知识源来对「交互专家 AI」进行训练，并从中提取检查项：

1. Arco Design 设计指南[1]

火山引擎采用 Arco Design 作为设计语言，因此 Arco Design 的设计指南非常适合用来作为指导原则。对于其中的图片 Case 部分，我们采用豆包视觉模型，将其转换为了可理解的自然语言描述。

 

2. 交互设计师给出的专业检查点

Arco Design 聚焦于通用组件领域，粒度在原子组件级别。而在我们实际的产品中很多时候还需要考虑一些更大粒度的规范或是特定领域的规范。

 

3. 以往的 UX 验收问题记录、回归问题记录

这些记录是历史上真实存在的体验问题，很适合用来作为检查项进行回归

4. 交互设计领域的经典著作总结

为了吸收业界的经典经验，我们将从一系列经典 UX 书籍中总结的知识上传到了火山引擎方舟的知识库中，供 AI 模型调用

为确保模型能够高质量理解评价体系，我们还在火山引擎方舟平台上进行了大量的模型横向测评和 Prompt 调优，最终形成了一套能够客观评价用户体验的标准框架。

通过这套评价体系，最终「交互专家 AI」能够从“用户”的执行过程中识别出多种交互问题：

• 违反 Arco Design 设计规范的情况

• 违反常见交互规范的情况

• 国际化环境下出现中文

• 低分辨率下界面错乱

• 弹窗叠加不合理

• 控件内文字与布局不合理

• 错误帮助不规范

• ...

10 用例 Story 设计

用例 Story 是整个体系的基石，它决定了 AI 能够走查哪些用户场景，以及如何走查。

在设计 User Story 相关部分的过程中，我们总结了以下关键经验：

1. 使用 AI 辅助生成提高效率

为了提高 Story 生成的效率，我们训练了一个 Agent 用来辅助生成用例，用户只需要将以往的文本测试用例、PRD、设计稿等提交给 Agent，那么 Agent 就会自动生成符合规范的 Story 并更新到用例库中。

2. 通过自然语言与代码结合提升稳定性、增强能力

在一开始，我们寄希望于完全用自然语言描述 Story，以便让非技术同学也能参与用例的维护中。但实际过程中受限于业务的复杂度和模型的能力，需要消耗大量的时间来反复调整自然语言指令。

后来我们仔细思考了当前 AI 走查的重点在于观察执行过程、找出问题的评价阶段，为了能顺利执行，对于 Story 中模型实在理解不了的卡点，可以适当使用 Pro Code 编码进行辅助，因此不再追求完全自然语言。

这也符合 Midscene.js 官方的经验：

• https://mp.weixin.qq.com/s/RMR8omgjnkQW4_kDbGeftw

• # Introducing Instant Actions and Deep Think[2]

3. 断言失败是符合预期的

在常规 E2E 执行过程中，会添加较多的断言，并在执行过程中要求每一个断言都完美通过，以此来保障执行过程符合预期。然而在交互体验走查的执行过程中，我们并不需要追求每一步都准确无误。执行过程中的不符合预期也许恰恰揭示了产品设计过程中的不合理，正是这种不合理导致“用户”被阻碍 / 误导而无法完成任务。

这种情况对于我们发现 UX 问题的目标是“符合预期”的，因此无需中断任务执行，而是需要继续执行下去并完整记录执行流程，交给交互模块进行分析。所以我们尽量只在最后加一个断言（checkpoint），用来获取任务目标最终是否顺利达成，以便作为稍后「交互专家 AI」评价时的辅助信息。这个断言失败并不代表走查失败。

11 执行引擎设计：如何让 AI 像真实用户一样操作产品

执行引擎是系统的重中之重，对执行引擎的设计决定了 AI 在多大程度上接近真实用户的表现。

在一开始我们使用的是 Browser-use 框架，但随着用例不断编写，逐渐暴露出 Browser-use 速度慢、不稳定的特点。经过对比测试，最终我们选择了 Midscene.js 作为执行框架，它能够让用户通过自然语言来驱动 AI 使用浏览器执行操作，并且在执行过程中结合视觉模型来进行规划下一步行动，十分接近真实用户的操作方式。

Midscene.js 的即时操作 API、缓存、报告回放能力也极大的增强了我们的开发效率。

在 AI 模型选用上，经过测评比对，我们采用了 Doubao-1.5-thinking-vision-pro 大模型，它具有优秀的视觉理解和自然语言处理能力，能够准确理解界面元素和操作指令。

执行环境上则基于公司的持续集成流水线运行，它提供了完善的 API 触发、调度、WebHook 机制，使整个执行过程高效可靠。

12 信息抽取：让 AI 评测真正可行的关键

为了让「AI 对任务执行过程进行评价」这一动作真正经济可行，需要寻找一种恰当的信息表达方式

在「用户 AI」执行之后，为了让「交互专家 AI」能够对“用户”执行过程进行评价，我们需要给交互专家 AI 输入相关的上下文：

• 任务元信息：任务信息、预定任务步骤、评价侧重点（可选）

• 任务执行过程：截图、录屏

• 任务执行结果：成功 / 失败

这其中如何将任务执行过程传递给大模型十分关键。尽管各个视觉模型都声称能够“理解”视频，但实际上它们处理视频的方式是将其分解成一系列连续的图像帧，然后依次进行理解。帧的数量直接影响到 Token 的消耗（即计算成本）和模型理解的质量。因此，如何优雅且高效地将视频拆解成图像帧就比较重要了。

然而事实上我们的目的是为了表达用户的整体操作流程，那么其实不需要视频，一系列用户执行动作前后的截图就足够表达整个操作流程了。

我们从 Midscene.js 的回放报告中可以看到 Midscene.js 在动作的前后进行了记录（Before Action、After Action）

 

与此同时，Midscene.js 也提供了非常方便的 API 来获取这些信息（# API Reference[3]）。通过对应的 API，我们成功提取了每次用户操作前后的截图，为后续评价环节提供了完整的用户操作过程信息。

 

系统使用流程

经过以上的环节，我们顺利的上线了 AI 体验走查系统并在各业务落地。这里简单介绍下系统的使用方式：

1. 打开 AI 交互体验走查平台，选择一个走查计划进行执行

 

2. 此时平台会创建一条执行记录并触发走查流水线

 

3. 走查流水线开始运行，过程中会进行【执行用户故事、评价、更新执行记录】

4. 结束后，用户会收到一条飞书消息

 

5. 点击卡片，进入平台查看报告

 

这里我们可以看到有一条记录，从最终目标上来看是成功完成的，但过程中是存在交互问题的。这也证明了 E2E 自动化测试通过，不代表系统没有交互问题。

 

6. 点击查看详情，查看报告

 

可以发现 AI 成功的发现了过程中的交互问题

 

实际落地效果

通过在火山引擎存储业务线的多个产品落地，当下 AI 体验走查系统已经取得了如下效果：

• 完全节省了故事走查的人力成本：从每次需要数十名研发投入 1-2 小时，减少到几乎无需人工参与

• 提高了问题发现率：AI 能够轻松、高效的发现人类易忽略的细节问题

• 用户场景覆盖程度高：目前已在日志服务 TLS、对象存储 TOS、文件存储 vePFS、弹性极速缓存 EIC 等多个产品线落地，覆盖了 100+ 用户场景

• 帮助发现并解决了近 10 个交互体验问题：显著提升了产品质量，带给了用户更好的交互体验

未来展望

目前该方案已完全代替人工的故事走查，节约了大量的人力成本。但我们可以看到这个方案中仍然有很多可以改进的地方。另一方面，AI 在这个方案中展现出来的能力也带给人无尽的想象空间。在此我们提出一些未来展望，接下来会朝着这些方向继续努力。

13 自动生成用例：AI 自驱产生 Story

目前 AI 交互体验走查的执行与评价过程已全面自动化，但用例 Story 的生产还比较依赖人工介入。虽然已经可以借助 Agent 来辅助，但输入的素材（文本用例、以往的故事走查文档、需求的验收问题记录、回归问题记录）仍然是由人工生产的，并且在生产后，也还需要人工介入调整。

随着我们正在建设的业务知识库不断完善，未来 AI 将能够通过 RAG 等技术自主了解产品能力范围，自动生成全面覆盖的用户故事，进一步降低人工成本，提高测试覆盖率。

14 侧重易用性的 Story 中尽量减少辅助步骤

目前受限于模型能力，AI 还无法理解较泛化的任务指令，我们不得不对一些较复杂的 User Story 添加一些执行步骤说明或是代码来进行辅助决策。

但仔细思考，其实理想状态下应该尽量减少这些辅助。对于我们给出的任务目标，如果 AI 理解执行较为困难，一方面可能是模型问题，另外一方面也可能是我们的系统设计不够简洁易用，导致 AI 执行困难。为了发现这些问题，我们应该尽量减少辅助步骤。

我们计划将 Story 分为两类：一类是有具体步骤描述的 Story，用来评价特定过程的交互体验细节；另一类是只描述了目标的一句话 Story，让 AI 完全自主尝试完成目标，用来评价系统的易用性。这种分类将帮助我们更全面地评估产品体验，同时也能发现系统设计中的易用性问题。

15 智能用户分层：满足不同用户群体的体验需求

一个系统面对的用户可能是多种多样的，这其中可能有专家用户，也可能有完全小白的用户。这两种用户面对系统的操作思路和路径可能完全不同。我们正在开发用户分层功能，通过让接入业务知识库的 Agent 模拟专家用户，与普通用户行为形成对比，全面评估产品对不同用户群体的适用性。

16 Naughty User（顽皮用户）模式：探索边界场景的创新方法

当下的 Story 大多数都是对于特定任务目标或特定步骤正常路径的描述，然而现实世界中用户使用系统的方式可能多种多样，也不一定按照预期使用。因此我们希望能够基于该方案开发一个 AI 驱动的 Naughty User，让 AI 在产品中自由漫游，不设限地探索各种边界与异常场景，帮助我们发现更多潜在问题，提升产品的鲁棒性。

17 相关技术产品

• Midscene.js - AI 驱动的 UI 自动化 - https://midscenejs.com/zh/

• ArcoDesign 设计原则 - https://arco.bytedance.net/docs/spec/philosophy

• Doubao-1.5-thinkg-vision-pro 视觉深度思考模型 - https://www.volcengine.com/docs/82379/1554521

18 参考资料

[1] Arco Design 设计指南: https://arco.bytedance.net/docs/spec/introduce

[2] # Introducing Instant Actions and Deep Think: https://midscenejs.com/zh/blog-introducing-instant-actions-and-deep-think.html

[3] # API Reference: https://midscenejs.com/zh/api.html#agent_unstablelogcontent

19 往期阅读

• Midscene.js：AI 在前端测试领域的应用
• Midscene x UI-TARS，UI 自动化的开源模型方案
• Midscene.js - AI 驱动的 UI 自动化框架