关注 霍格沃兹软件测试开发 公众号回复「资料」, 领取人工智能测试开发技术合集上个月团队里一个测试新人问我“哥你总说 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.pySKILL.md 是说明书。 告诉 Agent 这块积木是干什么的、什么时候用、怎么用。references/ 是图纸。 放长文档——用例模板、业务规则库、历史 Bug 模式。SKILL.md 里只引用文件名Agent 只在需要时才去读。这样不会把上下文撑爆。scripts/ 是动作件。 放可执行代码——格式化用例、调用接口、生成报告。Agent 不看代码内容只看执行结果。一个简单判断需要执行才能得到结果 → 放 scripts/。只需要阅读参考 → 放 references/。四、怎么拼出第一套“测试积木”第一步写第一块积木30分钟从最核心的“用例生成”开始。SKILL.md 的 description 要写清楚触发条件name: test-case-generatordescription: 根据功能描述或需求文档生成覆盖正常流程、异常场景、边界条件和权限校验的结构化测试用例。当用户提到“生成测试用例”“编写测试”“测试覆盖”“测试场景”时自动触发。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小时审核定稿。五、一个真实的“拼积木”案例上个月团队接了一个电商购物车模块的改版。需求文档十来页。测试新人接了这个任务。他没有从头写用例而是调用了四个 SkillSkill ① 需求拆解PRD 进去测试地图出来。功能清单、业务规则、数据约束、风险预判一目了然。Skill ② 用例生成测试地图进去40 多条结构化用例出来。覆盖正常流程、异常场景、边界值、权限校验。Skill ③ 场景补全基于历史 Bug 模式补充了“并发加入同一商品”“跨设备购物车同步”“价格变更时加入购物车”三条隐藏场景。Skill ④ 质量评审给用例集打分指出三条待改进项。2 小时后他交了一份完整用例集。 测试组长看完沉默了一会儿问了一句“这是谁写的”他说“不是我写的是我拼的。”六、避坑指南坑一积木拆得太碎。 一个工作流拆成 10 个 SkillAI 不知道该用哪个。SkillsBench2026年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 测试等内容侧重测试实践、工具应用与工程经验整理。