一个需求 ID 换一份完整测试用例，我让 AI 替测试同事省掉半天

本文首发于公众号「技术落地手记」，一个国企技术管理者的实战笔记。关注回复「落地」获取更多技术管理实践。

测试同事每接到一个新需求，流程基本是固定的：读需求文档 → 翻代码改动 → 手写一份覆盖正向、逆向、边界的测试用例。一个需求至少半天，赶上版本忙的时候，光写用例就能干一整天。

我最近做了个东西，把这一套压到了几十秒。

测试同事只报一个需求 ID，AI 自己去拉需求详情、扒 git 提交、把两份信息合起来生成一张完整测试用例表。更关键的是，输出不是一段临时回答，而是一个独立、可反复调用的 skill 文件------下次回归测试，原封不动调出来再跑一遍就行。行话叫"元 skill"------生成 skill 的 skill。听起来绕，落到实处就是一个简单工厂：你给一个需求 ID，它给你一个针对这个需求的、自包含的、可以反复调用的测试用例 skill。

如果你看过上一篇《 $[两个skill文件撑起了我们整个AI测试链路](https://juejin.cn/post/7641442631296761902 "https://juejin.cn/post/7641442631296761902")$ 》，这次这个就是在那条链路前面装了个"自动出卷子"的环节；没看过也不影响往下读。

先说结论

一个元 skill，输入是需求 ID + 源码 git 仓库路径 ，输出是一个新的、命名为 test-case-req-{需求ID} 的子 skill，里面装着这个需求的完整测试用例表格。

所有产出的子 skill 统一放在 rdm-test-cases/ 目录下，不污染顶层 skills 列表。

测试同事不用懂 git，不用懂代码，只需要给一个需求 ID。

为什么是"元 skill"，不是"通用 skill"

上次那个生成测试用例的 skill，本质是通用的。我把项目的业务规则和踩坑点写在里面，AI 拿到任意一个需求都能往里面套。

但用了一段时间，发现一个问题：每次跑都要重新拉需求、重新读代码、重新生成。如果我下周要回归测试，那个需求的用例又要从头跑一遍。

更麻烦的是，需求改了之后，老用例就不对了。但你不知道哪些不对了------因为用例从来没"沉淀"下来过，每次都在临时生成。

所以我换了个思路：不要生成"用例"，要生成"装着用例的 skill"。

把每次生成的结果，固化成一个独立 skill。需求 ID 是 3146，就生成一个叫 test-case-req-3146 的 skill，里面写死这个需求的所有用例。下次回归，直接调用这个 skill，输出的还是同一份用例表。

测试用例从"每次现生成"，变成了"一次生成、永久可调用"。

两个输入源是怎么对齐的

元 skill 的两个输入： 1. RDM 需求详情------通过我们 RDM 系统的 markdown 接口拿，URL 形如：

bash 复制代码

http://<内网RDM域名>/rdm/requirement-md?id={需求ID}

返回的就是结构化的需求描述、验收标准、业务规则。

2. 相关源码------这一步是关键。

我们团队有个约定：每条 git commit 的信息以"需求ID:"开头。比如：

makefile 复制代码

3146:产品详情增加分类管理入口

所以拿到需求 ID 之后，元 skill 先去 git 仓库里跑：

ini 复制代码

git log --grep="^3146:" -n 50

把所有相关提交捞出来，再 git show 看每个提交的 diff，从里面提取：

改动的接口、入参出参
改动的数据库字段、枚举
改动的 UI 入口、表单字段、权限点

这两份输入合在一起，AI 才有完整上下文。光看需求，AI 不知道实际代码改了哪些字段；光看代码，AI 不知道这次改动想解决什么业务问题。

为什么这个 commit 约定能用？因为我们去年就让所有人这么提交了。当时是为了在 RDM 上做需求-代码的反向追踪。当时纯粹是规范，没想到一年后变成了 AI 测试链路的输入源。

写规范的时候多想一步，后面捡现成的。

输出格式：固定 7 列

每个生成的子 skill，输出都是同一张表格：

复制代码

| 用例ID | 场景描述 | 前置条件 | 测试步骤 | 预期结果 | 优先级 | 覆盖类型 |

为什么是这 7 列、不是上次那个 11 列？

因为目的不一样。上次那个 11 列是给测试同事手写格式对齐用的，列得很全。这次的 7 列是 AI 生成完直接给执行 skill 用的，留了最关键的字段。

字段越多，AI 越容易把次要字段填得花里胡哨，反而稀释了核心内容。能少则少。

覆盖类型固定 4 个值：

正向流程------验收标准的端到端正常流程
逆向流程------非法输入、未授权、必填缺失、状态冲突
边界条件------长度上下限、空值、最大集合、日期边界
业务规则组合------决策表、角色 × 状态 × 数据

这四个维度是从测试方法论里挑的最小集。多了会重复，少了会盲区。

统一目录结构这件事

第一版没考虑这个，每个生成的 skill 都直接扔在 skills 顶层目录，跑了几个需求之后，顶层目录就十几个 skill 散在那里，找都找不到。

第二版改成统一进 rdm-test-cases/ 这个父目录：

objectivec 复制代码

.qoder/skills/
└── rdm-test-cases/
    ├── test-case-req-3146/
    │   └── SKILL.md
    ├── test-case-req-3147/
    │   └── SKILL.md
    └── ...

这种小事一开始不当回事，等到目录乱了再去改，迁移成本就上来了。规范要在第一天就立。

测试同事实际怎么用

整个流程从测试同事的视角看：

拿到需求 ID（比如 3146）
跟 AI 说："为需求 3146 生成测试用例 skill"
等几十秒，AI 拉需求、扒 git、生成表格
看一眼前几条用例，没问题就保存
后续这个需求的回归测试，直接调 test-case-req-3146 这个 skill

测试同事不用打开 git，不用看代码，不用记 RDM 接口怎么调。门槛压下来了，整个团队都能用。

给想做类似事情的人

元 skill 比通用 skill 更值得做。通用 skill 每次都在重新生成，没法沉淀；元 skill 产出的是固定 skill，是资产。
commit 信息一定要带需求 ID 。这是把代码和需求关联起来最便宜的方式。比起搞 commit hook、写 webhook，git log --grep 简单粗暴。
目录结构第一天就规划好。等乱了再改，是迁移成本最高的事。
覆盖维度别贪多。四个就够了，再多 AI 会重复造轮子。
生成的 skill 必须自包含。别让它每次跑都去拉需求接口，否则需求改了之后老用例直接被覆盖，没法对比变更。

下一步打算：把这套元 skill 接到 RDM 的需求评审环节。需求一通过，自动跑一遍 → 生成测试 skill → 测试同事直接看 → 评审通过测试用例。

需求-代码-测试三段闭环，慢慢就出来了。

完整的元 skill 文件，需要的可以找我要。月底如果跑顺了，再写一篇说说踩了哪些坑。