最近看到一篇介绍 AI 数字分身的文章，作者展示了一个挺有意思的场景。

开发人员可以直接通过企微找测试人员的数字分身，让它执行自动化测试、分析失败用例、查询日志、定位代码问题，甚至处理环境部署和性能测试。

乍一看，这个东西确实挺吸引人。

以前开发要找测试人员，测试人员要打开测试平台、执行用例、看报告、查日志，现在似乎只需要跟一个 AI 聊天，就能把这些事情安排下去。

我当时就在想，这是不是意味着我们终于可以把一个测试人员的工作能力复制出来了？

假设一个人的业务经验、分析习惯、问题处理方式都可以被 AI 学习，那么以后是不是每个人都可以拥有一个自己的数字分身？

带着这个想法，我开始研究它究竟是怎么实现的。

研究完之后，发现事情好像没有最初想象的那么神秘。

一、先不管概念，看看它到底需要什么

我先把文章描述的功能拆开看了一下。

所谓的数字分身，大概具备这些能力：

• 能够理解开发人员的自然语言请求。
• 根据任务选择不同的 Skill。
• 调用测试平台执行自动化用例。
• 分析失败用例和异常日志。
• 查询代码仓库，辅助定位问题。
• 调用其他工具完成环境管理等工作。

再往下拆，发现这些能力都有对应的技术实现。

大模型负责理解自然语言，Agent 负责任务调度，Skill 负责定义具体工作方法，工具负责连接外部系统，知识库负责提供业务背景。

大概就是这样一套东西：

          开发人员
              |
         企业微信机器人
              |
           AI Agent
              |
         识别任务和意图
              |
         选择对应 Skill
              |
  +-----------+-----------+
  |           |           |
测试执行    日志分析    代码分析
  |           |           |
pytest      日志API     Git API
  |           |           |
  +-----------+-----------+
              |
           结果整理
              |
           返回消息

看到这里，我突然觉得有点熟悉。

这不就是把以前的自动化测试平台、接口调用、日志查询、脚本执行等能力，统一交给一个 AI 入口进行调度吗？

以前是人自己打开平台、选择工具，现在是 AI 根据任务选择工具。

当然，这个改变还是有实际意义的。特别是当工具越来越多、任务越来越复杂时，能够通过自然语言把它们串联起来，确实方便不少。

但这好像还没有到复制一个人的程度。

于是我决定拿自己比较熟悉的 pytest + Allure 接口自动化场景，看看实际实现需要做哪些事情。

二、动手拆解：先给自己做一个测试分身

我没有一上来就研究复杂的多 Agent 架构，也没有给大模型做微调。

先选择一个简单的场景：

开发人员通过自然语言，让 AI 执行指定的接口自动化测试，并返回 Allure 测试结果。

这个场景比较典型，基本可以覆盖 Agent、Skill、工具调用和任务编排。

1. 先把平时的工作流程整理出来

假设手头已经有一套 pytest + Allure 接口自动化框架。

平时开发提测之后，测试人员要做的事情大概是：

接收提测通知
    |
确认测试环境和版本
    |
选择对应的测试集
    |
执行pytest
    |
查看Allure报告
    |
检查失败用例
    |
分析异常原因
    |
反馈测试结果

看起来并不复杂。

那么，能不能把这套流程交给 AI？

于是我开始尝试把它拆成几个可以独立执行的能力。

2. 编写 Skill，把工作规则告诉 AI

首先建立一个目录：

qa-agent/
|
+-- skills/
|   |
|   +-- run-p0-test/
|       |
|       +-- SKILL.md
|
+-- tools/
|   |
|   +-- test_runner.py
|   +-- allure_reader.py
|
+-- reports/

然后编写一个简单的 SKILL.md：

---
name: run-p0-test
description: 执行指定环境的P0接口自动化测试
---

# P0自动化测试执行规范

## 触发条件
用户要求执行P0接口自动化测试。

## 执行前检查
1. 确认测试环境。
2. 确认测试集是否存在。
3. 确认用户是否具有执行权限。
4. 不允许默认使用生产环境。

## 执行步骤
1. 调用测试执行工具。
2. 获取测试任务ID。
3. 查询测试执行状态。
4. 获取Allure测试结果。
5. 提取失败用例。
6. 输出测试报告。

## 输出要求
1. 测试总数
2. 通过数量
3. 失败数量
4. 跳过数量
5. 失败用例名称
6. Allure报告地址

写完之后，我发现这件事挺像以前做测试平台时编写操作规范。

只不过以前是写给人看的，现在是写给 Agent 看的。

Skill 不负责执行测试，它只是告诉 Agent 在什么情况下应该使用什么工具，以及怎样完成任务。

真正执行测试的，还是后面的 Python 程序。

3. 将原来的自动化框架封装成工具

这一步反而比较容易理解。

原来执行测试的命令：

pytest tests/api/p0/   --alluredir=reports/allure-results

现在只需要用 Python 包装一下，让 Agent 可以调用。

例如：

import subprocess
import uuid
from pathlib import Path


def run_test(environment, suite):

    # 环境白名单
    allowed_env = ["test", "staging"]

    # 测试集白名单
    allowed_suite = {
        "P0": "tests/api/p0",
        "P1": "tests/api/p1"
    }

    if environment not in allowed_env:
        raise ValueError("不支持的测试环境")

    if suite not in allowed_suite:
        raise ValueError("不存在的测试集")

    run_id = uuid.uuid4().hex
    report_dir = Path("reports") / run_id
    report_dir.mkdir(parents=True, exist_ok=True)

    cmd = [
        "pytest",
        allowed_suite[suite],
        f"--alluredir={report_dir}"
    ]

    # 实际项目中应由后台任务执行，
    # 并通过run_id查询执行状态。
    result = subprocess.run(
        cmd,
        capture_output=True,
        text=True,
        timeout=1800,
        check=False
    )

    return {
        "run_id": run_id,
        "exit_code": result.returncode,
        "report_dir": str(report_dir)
    }

这里有个细节。

我并没有让大模型直接生成 Shell 命令并执行，而是把环境、测试集限制在白名单中。

大模型只负责理解任务和传递参数，真正的执行规则由 Python 控制。

这样既能避免模型随意执行命令，也方便以后做权限管理。

4. 让 Agent 调用 Skill 和工具

现在有了 Skill，也有了 Python 工具。

接下来就是把工具注册到 Agent。

假设开发人员发送：

开发说 “帮我执行一下测试环境的 P0 接口自动化。”

大模型需要理解出：

{
    "environment": "test",
    "suite": "P0"
}

然后调用对应的 Python 工具。

工具执行完成后，将真实结果返回给 Agent，再由大模型组织成自然语言：

P0接口自动化测试已完成。

测试结果：
总数：100
通过：95
失败：5

失败用例：
1. 用户登录接口
2. 设备数据上传接口
3. 血压数据查询接口

Allure报告：
报告地址

这里的测试数字应该从真实报告中提取，而不是让大模型自己编。

至此，一个简单的测试 Agent 就有了雏形。

开发人员不需要知道 pytest 是什么，也不必知道测试框架的目录结构，只需要说清楚自己要做什么。

从这个角度看，确实比原来的操作方式方便不少。

但真正开始整理规则之后，我发现事情并没有想象中那么简单。

三、分身还没做出来，Skill 就已经开始折腾人了

最初我以为，Skill 无非就是把平时的工作习惯写成 Markdown 文件。

真正开始整理规则后，发现这件事并不是写几句话就能解决的。

比如开发说 “跑一下核心用例”。

AI 应该执行 P0，还是执行核心业务模块？

开发说 “帮我看看昨天的测试结果”。

昨天是按照哪个时区？查询哪个版本？从哪个测试平台获取？

开发说 “自动化失败了，帮忙重新跑一下”。

是直接重新执行，还是先判断上一次任务是否还在运行？

这些问题，人可能凭经验就能处理，但 AI 不一样。

你不把规则、参数和判断条件交代清楚，它就可能按照自己的理解处理。

于是 Skill 开始不断增加内容：

• 什么情况下触发。
• 什么情况下不触发。
• 必须提供哪些参数。
• 缺少参数时如何处理。
• 工具调用失败怎么办。
• 测试执行超时怎么办。
• 结果不完整时如何处理。
• 哪些操作需要人工确认。

原本几行说明，慢慢变成了一份需要不断完善的操作规范。

更有意思的是，写完也不代表就能正常工作。

还需要反复调试。

规则写得太宽泛，AI 可能理解偏差；写得太严格，又可能导致正常请求无法触发。

多个 Skill 的描述比较相似，还可能出现选错技能的情况。

有时候你刚调整好触发条件，又发现执行步骤存在问题。修改了执行步骤，又发现异常处理不完整。

这让我想起以前维护自动化测试框架的过程。代码写出来只是开始，真正耗时间的是后面各种兼容、调试和维护。

Skill 其实也差不多。

Anthropic 的官方 Agent Skills 最佳实践也建议通过测试场景验证 Skill 的触发情况和执行表现，并根据实际结果持续调整。

所以，Skill 并不是写完就可以扔在那里的说明书。

对于简单的查询任务，可能几句话就够了；但对于涉及业务判断、多系统交互和异常处理的复杂任务，前期整理规则和后续调试的工作量并不小。

这时候我开始有了另一个疑问：

原本是希望 AI 替我减少工作量，现在为了让它能够可靠地工作，我还得先花时间教它怎么工作？

四、真正麻烦的，可能不是写 Skill，而是后续维护

假设终于把 P0 自动化测试的 Skill 调试好了，能够正常执行。

是不是就可以结束了？

显然不是。

测试框架升级了，执行命令可能发生变化。

测试平台改造了，API 参数可能发生变化。

Allure 报告结构调整了，结果解析程序可能失效。

业务规则调整了，原来的判断条件也可能过期。

甚至更换一个大模型，原来表现正常的 Skill，也可能出现不同的工具选择和参数理解。

这意味着 Skill 不仅需要编写，还需要版本管理、回归测试和持续维护。

随着 Skill 数量增加，事情会更复杂。

run-test
analyze-failure
query-log
analyze-code
check-environment
deploy-service
performance-test

每个 Skill 都有自己的规则和工具依赖。

当它们组合起来使用时，还要考虑调用关系、权限边界、参数传递和执行顺序。

这已经不只是整理几份 Markdown 文件了，而是在维护一套 AI 工作流系统。

当然，这也不全是坏事。

如果这些 Skill 可以被整个测试团队复用，那么最初整理规则的成本就可以分摊。以后新人也不用从头摸索，有些重复性工作甚至可以直接交给 Agent。

但如果只是为了某个测试人员偶尔执行的几项工作，专门花大量时间建设和维护一套分身，可能还不如直接写几个自动化脚本来得实在。

所以，我觉得这里还有一笔账需要算：

AI 替人节省的时间，能不能覆盖 Skill 建设、工具开发、调试和后续维护的总成本？

不能只看它每天执行了多少次任务，还得看为了让它完成这些任务，背后又投入了多少工作。

五、再往下研究，发现它似乎也没有真正复制一个人

前面这些事情解决之后，一个能够调用自动化、分析日志、查询代码的 Agent 确实就能运行了。

但这时候又出现一个很有意思的问题。

如果我把这些 Skill 分享给另外一个测试人员，他是不是也能使用这个所谓的数字分身？

答案显然是可以。

只要有权限，其他人同样可以调用执行自动化、查询测试报告、分析失败用例、查询日志等能力。

那么，这个东西究竟复制了谁？

如果这些能力是所有测试人员都能使用的，那么它更像是一个测试岗位的 AI 助手，而不是某个人的数字分身。

换一个行业也是一样。

开发人员可以把代码检查、代码生成、单元测试封装成 Skill。

产品人员可以把需求分析、PRD 检查、原型生成封装成 Skill。

运维人员可以把服务巡检、日志查询、故障处理封装成 Skill。

每个人都可以拥有一套 AI 工作流。

但这是不是意味着每个人都拥有了自己的数字分身？

我觉得还不能这么简单地下结论。

我理解至少存在三个不同层次：

第一层，工作流程自动化。

把平时需要人工执行的操作整理成 Skill，再通过 Agent 自动调用。

第二层，岗位经验数字化。

除了操作流程，还把业务规则、常见问题、处理经验和技术规范沉淀下来。

第三层，个人能力数字化。

除了会做什么，还能体现特定个体的知识体系、判断逻辑、经验偏好，以及面对不同问题时的分析路径。

举个例子。

两个测试人员面对同一个数据库连接超时问题。

A 习惯先从连接池、并发模型和数据库负载入手。

B 则习惯先从业务调用链、请求数据和异常路径分析。

两个人可能选择不同的排查方法，也可能得出不同的判断。

如果一个数字分身能够沉淀某个人的历史决策、知识结构和判断依据，在遇到新问题时也能体现这种个人特征，那才更接近我原本理解的数字分身。

当然，这并不意味着一定要重新训练一个属于个人的大模型。长期记忆、个人知识库、历史决策案例、反馈机制和评估体系，都可以参与其中。

但这显然不是写几个 SKILL.md 文件就能解决的问题。

六、最后的一点感受

研究到这里，我倒不觉得这个方案有什么问题。

反而觉得 Agent + Skill 这种方式挺实用。

以前我们做效能建设，喜欢把工作流程标准化，把重复劳动自动化，把个人经验沉淀成规范。

现在有了大模型，这些原本分散的能力可以通过 Skill 组织起来，再由 Agent 按照任务需要进行调用。

以前是人打开十几个平台，现在可以让 AI 帮忙打开十几个平台；以前需要记住一堆操作步骤，现在可以把它们交给 Skill 管理。

这确实是一种挺有意思的玩法

但还有一个问题，之前研究的时候我也考虑过，就是安全性。

如果这个 Agent 只是帮忙查查文档、整理报告，那问题可能还不大。

但如果它已经接入了测试平台、代码仓库、数据库、部署系统，甚至具备修改数据、执行部署和故障注入的能力，情况就不一样了。

AI 理解错了一句话，可能只是回答错一个问题；但如果它理解错了一个操作指令，就有可能真的执行错误的操作。

比如：

• 原本只想执行测试环境的用例，却错误地调用了其他环境。
• 查询日志时访问了不该访问的数据。
• 测试超时后反复重试，导致重复执行。
• 根据错误的分析结果执行了不合适的操作。
• 在没有充分确认的情况下触发部署或数据修改。

这时候就不能简单地认为，给 Agent 写好 Skill，它就会严格按照规则办事。

大模型本身具有一定的不确定性，工具调用也可能出现参数错误、判断偏差和重复执行。

所以还需要额外建设权限隔离、操作白名单、人工审批、执行审计、幂等控制和异常回滚等机制。

说到底，AI 可以负责理解和调度，但涉及有实际影响的操作，还是得给它划清边界。

然后我又算了一笔账。

原本测试人员每天可能只需要花半小时执行一批用例、整理一下报告，现在为了让 AI 替自己完成这件事，需要整理经验、编写 Skill、开发工具接口、反复调试、建立回归测试，还得考虑权限和安全问题，后期系统变化了又要继续维护。

如果这些能力能够被整个团队长期复用，当然值得投入。

但如果只是为了自动化一些低频、简单的日常工作，前期建设和后期维护的投入，很可能比原来的工作本身还大。

这也是我觉得这类方案不能只看演示效果的原因。

能不能跑起来是一回事，能不能长期稳定运行、有没有安全保障、投入产出是否划算，又是另外一回事。

所以，这次研究下来，我的收获倒不是学会了怎么给自己做一个分身，而是发现了一种挺值得尝试的 AI 工作方式。

只是我觉得，技术方案本身已经不错了，没必要非得往数字分身上靠。

工作流自动化就是工作流自动化，岗位助手就是岗位助手，把它们叫作数字分身，确实更容易让人产生期待，但如果真正复制的只是工作流程，那离个人能力的复制还有一段距离。

而且，分身也不是装上 Skill 就能自己长大的，前期要教，过程中要调，后期还得维护，真正放手让它干活之前，还得先给它划好安全边界。

原本是想找个分身替自己干活，结果分身还没干多少活，自己倒先多了一份教它、管它、盯着它的工作。

当然，这不代表方向不值得做，只是投入之前最好先算算账。

分身没看到，Skill 倒是装了一堆。

不过也算没白研究，至少以后再看到类似的概念，我大概会先问一句：

你这个分身，到底复制的是一个人，还是只是复制了这个人每天打开的那几个工具？