为什么说 Agent Skills 是 AI 测试的“乐高积木”？

关注 霍格沃兹软件测试开发 公众号，回复「资料」, 领取人工智能测试开发技术合集

上个月，团队里一个测试新人问我：“哥，你总说 Agent Skills 是乐高积木，到底什么意思？”

我没解释，从桌上拿了一盒乐高递给他：“你拼个东西试试。”

他随手拿了几块，拼了个小车。我说：“你再拼个房子。”他又拿了几块，换了个拼法。

我说：“你看，同样的积木，能拼出完全不同的东西。每块积木都是标准化的，有凸点、有凹槽，能跟任何其他积木咬合。Agent Skills 就是这个逻辑。”

他愣了一下：“所以 Skill 就是一块一块的能力单元？”

对。每个 Skill 是一块标准积木，单独能用，组合起来能拼出复杂的测试工作流。

一、以前用 AI 做测试，为什么总在“重新造轮子”？
过去一年，很多团队都在尝试用 AI 做测试。但真正跑起来的没几个。

问题出在哪？每次都在从零写 Prompt。

今天要生成用例，写一段“你是资深测试工程师，请覆盖正常异常边界……”；明天要分析失败日志，又写一段“你是测试专家，请分析以下报错……”；后天要生成测试数据，再写一段。

每个项目、每个任务，都在重复造轮子。

更麻烦的是，这些 Prompt 散落在各个聊天窗口里。你调好了一个好用的 Prompt，换个人、换个项目，又得从头调。团队的经验没法沉淀，个人的调优没法复用。

这就是没有“积木”的后果——你有一堆散装的塑料，但拼不出一个稳定的东西。

二、Skill 为什么像乐高？三个特征一一对应
特征一：标准化接口
乐高积木最牛的地方是什么？任何一块积木都能跟任何一块咬合。 不管它是红色的还是蓝色的，是2×4还是1×2，凸点和凹槽的尺寸是统一的。

Skill 的标准接口就是 SKILL.md 的 description 字段。

Claude 会把所有 Skill 的 description 预加载进上下文，用来判断该不该触发这个 Skill。你写“帮助测试”，它永远不知道什么时候该用。你写“当用户提到生成测试用例、编写测试、测试覆盖时触发”，它就知道。

description 是 Skill 的“凸点”，决定了它能不能被 Agent 准确识别和调用。

特征二：功能独立
乐高积木每一块都有明确形状和功能。2×4 的板子就是 2×4，不会今天当轮子明天当窗户。

Skill 也一样。一个 Skill 只做一件事。

“需求拆解”Skill 负责把 PRD 变成测试地图。“用例生成”Skill 负责把测试地图变成结构化用例。“场景补全”Skill 负责基于历史 Bug 补充隐藏场景。“质量评审”Skill 负责给用例集打分。

每个 Skill 职责单一，接口清晰。不会出现“这个 Skill 又生成用例又做评审”的混乱。

特征三：可组合
乐高真正的威力不在单块积木，在组合。几块积木能拼小车，几十块能拼城堡。

Skill 的威力也在组合。四个测试 Skill 串起来，就是一条完整的用例生成流水线。

📄 需求文档
↓
[Skill ① 需求拆解] → 测试地图
↓
[Skill ② 用例生成] → 用例初稿
↓
[Skill ③ 场景补全] → 用例增强
↓
[Skill ④ 质量评审] → 评审报告
↓
✅ 高质量用例集
每个 Skill 单独可用，组合起来就是一套自动化工作流。

三、一块“乐高积木”里面有什么？
拿“测试用例生成”这块积木举例。目录结构是这样的：

.claude/skills/test-case-generator/
├── SKILL.md ← 说明书（必需）
├── references/ ← 图纸（可选）
│ └── test-case-template.md
└── scripts/ ← 动作件（可选）
└── format_cases.py
SKILL.md 是说明书。 告诉 Agent 这块积木是干什么的、什么时候用、怎么用。

references/ 是图纸。 放长文档——用例模板、业务规则库、历史 Bug 模式。SKILL.md 里只引用文件名，Agent 只在需要时才去读。这样不会把上下文撑爆。

scripts/ 是动作件。 放可执行代码——格式化用例、调用接口、生成报告。Agent 不看代码内容，只看执行结果。

一个简单判断：需要执行才能得到结果 → 放 scripts/。只需要阅读参考 → 放 references/。

四、怎么拼出第一套“测试积木”？
第一步：写第一块积木（30分钟）
从最核心的“用例生成”开始。SKILL.md 的 description 要写清楚触发条件：

name: test-case-generator
description: 根据功能描述或需求文档生成覆盖正常流程、异常场景、边界条件和权限校验的结构化测试用例。当用户提到“生成测试用例”“编写测试”“测试覆盖”“测试场景”时自动触发。
when_to_use: 用户需要从需求文档或功能描述生成测试用例时使用。

正文写清楚四步：理解需求 → 识别场景 → 生成用例 → 自检。

关键原则：步骤要具体可执行。 不要写“验证数据是否正确”，要写“调用 GET /api/order/{id}，检查返回的 status 字段是否为‘已取消’”。

第二步：拼第二块积木（20分钟）
写“需求拆解”Skill。输入是 PRD，输出是功能清单、业务规则、数据约束、风险预判。

第三步：拼第三块和第四块（各20分钟）
“场景补全”Skill——基于历史 Bug 模式补充隐藏场景。“质量评审”Skill——从覆盖完整性、规范性、一致性、优先级四个维度打分。

第四步：把它们串起来
在 Claude Code 里，依次调用四个 Skill。需求文档进去，高质量用例集出来。

传统方式：啃 PRD（半天）→ 梳理测试点（半天）→ 写用例（1-2天）→ 人工评审（半天）——总计3-4天。

Skill 流水线：四个 Skill 依次触发——2小时出初稿，1小时审核定稿。

五、一个真实的“拼积木”案例
上个月，团队接了一个电商购物车模块的改版。需求文档十来页。测试新人接了这个任务。

他没有从头写用例，而是调用了四个 Skill：

Skill ① 需求拆解：PRD 进去，测试地图出来。功能清单、业务规则、数据约束、风险预判，一目了然。

Skill ② 用例生成：测试地图进去，40 多条结构化用例出来。覆盖正常流程、异常场景、边界值、权限校验。

Skill ③ 场景补全：基于历史 Bug 模式，补充了“并发加入同一商品”“跨设备购物车同步”“价格变更时加入购物车”三条隐藏场景。

Skill ④ 质量评审：给用例集打分，指出三条待改进项。

2 小时后，他交了一份完整用例集。 测试组长看完，沉默了一会儿，问了一句：“这是谁写的？”

他说：“不是我写的，是我拼的。”

六、避坑指南
坑一：积木拆得太碎。 一个工作流拆成 10 个 Skill，AI 不知道该用哪个。SkillsBench（2026年2月，Amazon、CMU、Stanford、Oxford 联合发布）发现：2-3 个模块的 Skill 表现最好。测试用例生成拆成 4 个是极限，拆成 5 个以上就开始反噬了。

坑二：description 写得太空。 “帮助测试”——这等于没写。要写清楚触发条件，让 Agent 知道什么时候该调用这块积木。

坑三：SKILL.md 超过 500 行。 每次加载都浪费 Token。把详细内容移到 references/ 目录，SKILL.md 只留核心流程。

坑四：建完不迭代。 业务在变、需求在变，Skill 也需要更新。每次使用后记录“哪里漏了场景”“哪里判断错了”，定期更新 SKILL.md。

坑五：忽略 Skill 的回归测试。 模型版本一变，Skill 行为可能漂移。阿里开源的 skill-up 就是干这个的——用声明式 YAML 写评测用例，跨引擎跑评测，发现退化及时修复。

最后
Agent Skills 之所以是 AI 测试的“乐高积木”，是因为它把测试经验变成了标准化、可复用、可组合的能力单元。

以前你写 Prompt，是一次性的。今天调好了，明天换个项目又得重来。

现在你写 Skill，是永久性的。今天花 30 分钟封装一个“用例生成”Skill，以后每一个项目都能复用。你今天拼好的四个 Skill，明天可以拆开重新组合，拼出新的工作流。

测试人的经验，不再散落在聊天窗口里，而是沉淀成一块一块的积木。

下次你面对一个新项目的时候，别从头写 Prompt 了。打开 Skill 目录，看看手头有哪些积木，拼起来。

你不需要每次重新造轮子。你只需要学会拼积木。

本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。