前言

近期了解到大多数同学会使用 AI 来完成测试用例和自动化测试代码的生成工作，但后续如何让 AI 再前进一步时会陷入一时间的迷茫。不知道还有什么工作是可以让 AI 来做的。 所以这里分享一下大厂的常见 AI 提效思路。

为什么需要数字分身

其实在工程效能领域一直有一个理念：凡是需要人来沟通和协作的，都是影响效率的卡点。比如开发同学提测，需要发提测邮件或者在企微上通知测试人员。 而等到测试人员 “看到” 这条消息，可能已经过去了一段不短的时间，等到测试人员有时间来开始跑 P0 自动化测试用例（用作门禁，验证开发的提测没有老功能的主流程，这是提测的条件之一，如果不满足要打回提测。）可能就又过去了一段时间。 所以等到测试人员运行测试用例，提交了 bug 就又过去了一段时间。 而等开发同学收到了 bug 开始处理还需要时间。 “测试” 与 “开发” 一来一回，或者说几来几回。沟通，扯皮，bug 复现等等。 时间就这么消耗出去了。 尤其有时候测试人员忘了抓问题的 traceid 了， 忘了附上报错信息或者日志截图了。开发就会找来要你提供， 或者干脆他也不看 bug 单的步骤，而是直接让你共享屏幕，直接演示一下 bug 怎么触发的。

或者我们再换一个场景，产品同学发起需求评审。 但我们一定经常遇到一种情况， 就是产品经理会在很多很基础地方犯错误，或者有疏忽。导致在需求评审的会议上花大量的时间进行沟通。 拿我们的智能体产品为例，我们有一个模块叫模型广场，它可以提供不同的模型让用户使用。 当产品经理添加了一个新的模型（比如就说 deepseek 4 pro 吧），但这个模块其实影响了相当多的其他模块的功能，但这些是产品经理没有注意到，或者说他不清楚的，毕竟一个大型产品有很多产品经理，大家各自负责各自的东西，互相都不太了解。 于是产品经理可能会忘记：

• 该模型是否应该支持深度思考开关，是否支持 high，low, media 的思考级别
• 该模型应该打上什么标签，是否支持作为 agent 思考模型，工作流模型，qa 问答生成模型， 检索模型，rerank 模型。。。。。（等等一切其他场景）
• 该模型的操作是否进入审计日志。
• 该模型的权限位要如何设计。
• 该模型是否计费，如果计费它的 tpm 和 qpm 限制策略要怎么设置。
• 等等等等。。。。

其实以上这些都是咱们测试或者开发人员关心的，也是一些基础项。但大多数产品经理都会忽略，导致在需求评审会议上花费大量时间在去补充这些基础设定。

还是那句话，凡是需要人来沟通和协作的，一定是低效的。 那要如何解决这些问题呢。 那 AI 时代下，数字分身就比较重要了。如果我们能把测试这个角色设计成一个智能体，把我们自己一些基础的常用能力赋予这个智能体。那么就可以减少很多的协作问题。 比如大家还记得我分享的需求分析和用例生成的 skill 么？ 如果我们提供一个智能体，它有一个需求分析的 skill，这个 skill 里的知识库有上述说的模型广场和其他模块的知识库，有做需求分析的工作流。那么产品同学在发起需求评审之前，用这个智能体先分析一波。就可以在需求评审之前解决很多问题。这样在需求评审会上，就是一个较为成熟的需求文档了。 这样就节省了很多的无效沟通。 同样如果有一个智能体能让开发同学说一句话就能触发门禁自动化测试用例， 跑完后也能一句话针对报错的 case 进行归类分析，抓取 traceid，通过 traceid 抓取日志，并到代码仓库分析代码做初步的 bug 定位。这样也就不用开发人员和测试人员一来一回的沟通协作很多次。

这样的模式还可以发展到性能测试，容灾测试，环境管理等多个反向。总之就是把我们测试人员自身的一些稳定的，基础的能力，AI 化以及数字分身化。开发同学修复了 bug 后，要验证下，就艾特测试人员的数字分身跑一下用例。 我刚才正好用我的分身跑了一下门禁，我来截取一下我的分身分析失败 case 的片段信息：

130556 存储挂载失败（数量：157，占比：82.2%）
 ⦁关键报错： failed to mount "/dev/vdb" to "/run/blk-cube/vdb", with error: EINVAL: Invalid argument，ret_code=130556
 ⦁判定依据：该错误发生在 CreateSandbox 阶段（156 个）和 ResumeSandbox 阶段（1 个），覆盖 CBS/CosFS/NFS/TCBS/TurboCFS/State/Lifecycle/Probe/Freeze/Unfreeze/Snapshot/Net/Vol/Cfg/Lc/Sched/Snap/Err/Res/Sec/Sp/Iv/DelSnap/EdTmp/Av/Uc/Multi/Merge/Legacy/TempV1/TempV15/TempV2 等几乎所有模块。报错特征高度一致—— /dev/vdb 设备挂载至  /run/blk-cube/vdb 时 EINVAL 参数无效。经验库中 130556 条目（virtiofs resume 限制）与本场景无关，本次是创建阶段的存储挂载失败，非 resume 阶段。判断为环境问题（节点存储设备/驱动层面异常）。
 ⦁代表用例： TcbsP1040PauseResumeNoSandboxIdTest
 ⦁测试目标：TCBS(system_disk rootfs) 写文件 → pause → resume（不传 sandbox_id，仅 checkpoint_id）→ 文件可读 → 删除。
 ⦁详细步骤：
 1. 创建沙箱（2期 writer erofs 镜像）：system_disk rootfs(TCBS)，等 RUNNING + /health
 2. 向 /data 写入探针文件（内容含本次运行唯一 uuid），回读确认写入成功
 3. pause（POST /v2/cube/pause，内联 create body），等 checkpoint SUCCESS，取 checkpoint_id
 4. resume 时不传 sandbox_id（body 里 sandbox_id 为空串），仅传 pause 返回的 checkpoint_id，等 RUNNING + /health → resume 成功并返回新 sandbox_id
 5. resume 后回读探针文件，内容与写入一致（TCBS rootfs 重挂载正常，数据持久）
 6. 删除探针文件并确认已删除
 7. 清理：删除 resume 后的沙箱（原沙箱已被 pause 销毁）
 ⦁失败步骤：创建沙箱（1.5期 writer）+ system_disk rootfs(TCBS)（落点 ins_ip=10.128.2.19）
 ⦁定位信息：
 ⦁sandbox_id=未创建沙箱，无 sandbox_id
 ⦁request_id=CreateSandbox:88a2e73e-8a02-4a9d-ab6c-e729ccb1d514

以上测试失败了大量的 case， 但是 AI 分析出其中 157 个其实都是同类型的问题， 占比 82.2% ，抓到关键报错和分析，代表用例步骤，以及 traceid。 接下来就可以用这个 traceid 去用智能体查看日志和分析代码做 bug 定位。 这里需要说一句，很多时候开发同学刚刚提测，我们跑自动化测试可能会失败大几百的 case（因为可能是由于某几个主流程逻辑失败导致大量 case 失败）这时候要一个一个看是很麻烦的，我们用 AI 进行失败聚类和分析，也是一个非常节省时间的操作。

于是，我用公司的智能体平台，构建了自己的数字分身（其实就是一个智能体），我把编写用例的能力， 对接测试平台跑自动化测试的能力， 分析失败 case 的能力，抓取日志分析开发代码的能力，环境检查和部署的能力，故障注入的能力（容灾测试），性能测试的能力，镜像和沙箱构建的能力，等等等等都写成 skill。 然后对接企微机器人，就这样我的数字分身就实现了。 开发要找测试做什么事， 都可以先让我的数字分身来搞一波，不用等我抽出时间才能跟他对接。

结尾

目前数字分身方案已经在大厂之间流行了起来，一些中小厂也开始跟进。也算是属于 AI 提效的阶段化成果。各位没有思路的同学可以适当参考。