上个月团队里一个测试新人跑来找我表情有点委屈。“哥我在项目里放了一个 SKILL.md为什么 Claude Code 还是不会干活”我让他把文件打开。里面写着一段话“你是资深测试工程师请帮我生成测试用例覆盖正常和异常场景。”我看完就笑了。我说“你这不是 Skill是许愿。”他愣了一下“SKILL.md 不就是写提示词吗”这是大多数测试人刚接触 Agent Skills 时的第一个误解。SKILL.md 不是提示词。它是一份结构化的操作手册。你写“帮我生成用例”Agent 只会给你一段文本。你写清楚“第一步读什么、第二步拆什么、第三步输出什么格式、遇到异常怎么处理”Agent 才知道该怎么干活。今天这篇文章我把“从 PRD 到高质量测试用例”的完整链路拆开讲。不是讲概念是给你可以直接复制使用的模板和流程。一、为什么你写的 SKILL.md 总是不生效过去一年很多团队都在尝试用 AI 做测试。但真正跑起来的没几个。问题出在哪不是模型不行是你给它的东西不是一个“能力单元”。我们过去用 AI 做测试基本套路就是写一段系统提示词“你是资深测试工程师请按照以下步骤执行回归测试……”然后期待它自己搞定一切。这个思路有一个根本性缺陷LLM 是语言模型不是操作系统的内核。它可以告诉你“应该先登录再查询”但面对动态验证码、偶尔超时的 API、需要滑动解锁的按钮纯文本推理能力完全不够用。Prompt 是说明书告诉 Agent“拧开螺丝”。但真实任务执行需要知道螺丝刀在哪个抽屉、顺时针拧几圈、遇到滑丝怎么处理——这些确定性操作流程Prompt 给不了。Agent Skills 解决的就是这个问题。Anthropic 官方对 Skill 的定义很干脆一个 Skill 就是一个文件夹。里面必须有一个SKILL.md文件还可以放脚本、参考资料、静态资源。用大白话说Skill 就是把“资深测试工程师怎么做一件事”的完整经验封装成一个 Agent 能随时调用的能力包。它和 MCP 的区别是什么MCP 解决“模型能用什么工具”——连数据库、接 GitHub、操作浏览器。Skill 解决“模型该怎么用这些工具”——按什么步骤、什么格式、什么标准。MCP 给 Agent 提供手Skill 给 Agent 提供操作手册。没有 SkillAgent 有手也不知道怎么干活。二、全景总览生成测试用例需要哪几个 Skill测试用例设计的全流程本质上可以拆成四个环节。每个环节封装成一个独立的 Skill串起来就是一条从需求到用例的自动化流水线。阶段Skill核心职责输入输出需求拆解prd-to-test-map把 PRD 变成“测试地图”需求文档功能清单业务规则风险预判用例生成test-case-generator把测试地图变成结构化用例测试地图用例表格正常/异常/边界/权限场景补全test-scenario-completion基于历史 Bug 补充隐藏场景用例集历史Bug增强用例集质量评审test-case-reviewer给用例集打分并给出改进建议用例集评审报告改进项数量和不用记看分布有意思得多。活儿全压在两头前面把需求拆清楚后面把质量收干净。中间的用例生成反而是最“顺”的一环因为规则明确、格式固定。真正拉开差距的是需求拆解能不能识别出隐性业务规则和质量评审能不能发现用例集的盲区。三、逐个拆解每个 Skill 解决什么问题、怎么写、怎么用Skill ①需求拆解——把 PRD 变成“测试地图”解决什么问题拿到一份需求文档很多人第一反应是“从头开始读”。但 PRD 往往写得不够结构化——功能描述、业务规则、异常说明散落在不同章节。测试人员需要手动提取功能点、梳理业务规则、识别风险点这个过程高度依赖个人经验。SKILL.md 怎么写---name:prd-to-test-mapdescription:从PRD中提取功能点、业务规则、数据约束和风险预判生成结构化测试地图。当用户提到“分析需求”“拆解PRD”“梳理测试点”时触发。when_to_use:需求评审阶段需要将PRD转化为可执行的测试点清单时使用。---## 任务 将用户提供的需求描述或PRD内容转化为结构化的测试地图。 ## 输出格式 1. **功能清单**列出所有需要测试的功能点 2. **业务规则**状态流转、计算公式、权限控制、限制条件 3. **数据约束**输入数据的类型、格式、范围、必填性 4. **风险预判**基于经验判断哪些功能最容易出问题高/中/低 ## 规则 - 只从输入内容中提取信息不臆造不存在的功能 - 如果某项信息不明确标注“需确认”而不是猜测 - 风险预判基于通用测试经验并发场景、边界值、状态流转通常为高风险核心规则事实与猜测分离。每条输出标注证据来源需求依据/经验假设/待确认。需求没写的规则标注[待确认]不要编造。实测效果一份十来页的 PRDAgent 在几秒内输出功能清单、业务规则、数据约束、风险预判。功能清单列了 3 条已登录用户加入购物车、未登录触发登录引导、购物车数量上限校验业务规则列了 4 条上架校验、库存校验、数量累加、上限限制风险预判标出了 3 个高/中风险点。Skill ②用例生成——把“测试地图”变成“测试用例”解决什么问题有了测试地图接下来要把它“翻译”成具体的测试用例。传统方式是手动一条条写——前置条件、操作步骤、预期结果。这个过程步骤繁琐、规则固定、重复性极高。SKILL.md 怎么写---name:test-case-generatordescription:根据功能描述或需求文档生成覆盖正常流程、异常场景、边界条件和权限校验的结构化测试用例。当用户提到“生成测试用例”“编写测试”“测试覆盖”“测试场景”时自动触发。when_to_use:用户需要从需求文档或功能描述生成测试用例时使用。适用于功能测试、回归测试、接口测试的用例设计阶段。---## 任务 根据用户提供的功能描述或测试地图生成覆盖四大类场景的测试用例。 ## 执行步骤 ### 步骤1理解测试地图 读取功能清单、业务规则和数据约束。 ### 步骤2识别测试场景 - **正常流程**至少覆盖1条完整的Happy Path - **异常场景**参数缺失、格式错误、依赖服务超时 - **边界条件**数值边界、状态边界、时间窗口边界 - **权限校验**未授权访问、越权操作 ### 步骤3生成用例 每条用例包含用例编号、测试场景、前置条件、测试步骤、预期结果、优先级 ### 步骤4自检 - [ ] 每个功能点是否有至少1条正向用例 - [ ] 每个输入参数是否有异常场景覆盖 - [ ] 边界值是否覆盖了上下界 - [ ] 不同角色权限是否都有验证 ## 输出格式 Markdown表格可直接复制到Excel或测试管理工具。核心规则SKILL.md 控制在 500 行以内。Anthropic 官方推荐正文目标约 200 行最多 500 行。超过 500 行必须把详细内容移到references/目录。实测效果测试新人小陈接了一个“订单取消功能”的用例设计任务。按以往经验这活儿至少 3 天。他打开 Claude Code调了这个 Skill2 小时后交出了一份覆盖正常流程、异常场景、边界值、权限校验的完整用例集。测试组长看完之后沉默了一会儿问了一句“这是谁写的质量比我自己写还高。”Skill ③场景补全——把“没想到”的找出来解决什么问题Skill ② 生成的用例已经很全面了但 AI 毕竟不是人——它可能漏掉一些“只有业务老手才知道”的隐藏场景。比如并发下单时的库存扣减、优惠券和满减的叠加规则、异常状态下的回滚逻辑。SKILL.md 怎么写---name:test-scenario-completiondescription:基于历史Bug模式和业务知识补充AI生成的测试用例中遗漏的隐藏场景。当用户提到“补充场景”“查漏补缺”“完善用例”时触发。---## 任务 审查已有的测试用例集结合历史Bug数据和业务上下文识别并补充遗漏的测试场景。 ## 检查维度 1. **并发场景**多用户/多请求同时操作同一资源 2. **状态流转**异常状态下的操作如已取消订单再次操作 3. **数据一致性**跨模块的数据同步如订单取消→库存回滚 4. **边界组合**多个边界条件同时出现的情况 5. **历史故障**该模块历史上出过什么类型的Bug ## 输出格式 对每个补充的场景说明场景描述、补充理由、具体的测试步骤和预期结果。核心规则知识图谱不需要很复杂。一张 Excel 表格就够了——记录着“这个模块历史上出过什么类型的 Bug”。Agent 读取这张表就能识别出“AI 没想到但很可能出问题”的场景。Skill ④质量评审——给用例集“打分”解决什么问题用例写完了但质量怎么样覆盖全不全有没有冗余有没有逻辑矛盾传统方式是人工评审——开个会一群人对着 Excel 一条条看效率低下且依赖评审人的经验水平。SKILL.md 怎么写---name:test-case-reviewerdescription:对测试用例集进行自动化质量评审从覆盖完整性、规范性、一致性、优先级四个维度打分并给出改进建议。当用户提到“评审用例”“检查用例质量”“用例打分”时触发。---## 任务 审查测试用例集的质量输出结构化的评审报告。 ## 评审维度 1. **覆盖完整性**是否覆盖了正常流程、异常场景、边界条件、权限校验 2. **用例规范性**每条用例是否包含完整的“前置条件-步骤-预期结果” 3. **逻辑一致性**前置条件和预期结果之间是否存在逻辑矛盾 4. **优先级合理性**P0/P1/P2的划分是否合理 ## 输出格式 - 总体评分百分制 - 各维度评分 - 待改进项列表每条说明问题、位置、改进建议 - 评审结论通过/有条件通过/不通过核心规则让 AI 先做一轮“预审”。把明显的问题筛出来人工只需要关注 AI 搞不定的部分。比如 AI 会指出“TC-007 步骤描述过于简略”“TC-009 缺少同步后验证数据一致性的步骤”“TC-003 涉及核心业务流程建议从 P1 升级为 P0”。四、完整流水线四个 Skill 串起来怎么跑在 Claude Code 里按顺序调用第1步/prd-to-test-map → 输入PRD输出测试地图 第2步/test-case-generator → 输入测试地图输出用例初稿 第3步/test-scenario-completion → 输入用例集补充隐藏场景 第4步/test-case-reviewer → 输入用例集输出评审报告传统方式啃 PRD半天→ 梳理测试点半天→ 写用例1-2天→ 人工评审半天→ 修改半天——总计 3-4 天。Skill 流水线四个 Skill 依次触发——2 小时出初稿1 小时审核定稿。效率提升 10 倍以上。五、落地建议别一次全装拆解完四个 Skill 之后说几条务实的建议。第一只装你最痛的那一段。需求痛装需求拆解用例痛装用例生成质量痛装质量评审。全装一遍的结果通常是每个都跑过一次然后一个都没用起来。第二喂进去真东西。必须给项目真实的 PRD、真实的历史 Bug 表。用假数据跑出来的结果没有参考价值。第三打分只当提醒。评审 Skill 给你 72 分是让你去看哪条被扣分不是让你把那个数字抄进周报。六、踩坑提示三个最常见的坑坑一description 写得太空。“帮助生成测试用例”——这句话等于没说。Claude 会把所有 Skill 的 description 预加载进上下文用来判断该不该触发。你写“帮助测试”它永远不知道什么时候该用。你写“当用户提到生成测试用例、编写测试、测试覆盖、测试场景时触发”它就知道。description 是 Skill 的“门牌号”不是广告词。坑二SKILL.md 写成百科全书。超过 500 行就开始浪费 Token。把详细的用例模板、业务规则库、历史 Bug 模式放到references/目录SKILL.md 只留核心流程和导航。利用渐进式披露机制——平时只加载名字和描述等到真正使用时才加载完整内容。坑三Skill 粒度拆得太细。一个工作流拆成 10 个 SkillAI 不知道该用哪个。SkillsBench 的研究发现2-3 个模块的 Skill 表现最好。测试用例生成拆成四个 Skill 是极限拆成五个以上就开始反噬了。额外提醒这类 Skill 的名字和能力会跟着版本变装之前先看它自己那份说明。有些 Skill 要靠 MCP 或 API 接外部服务意味着浏览器、测试平台、缺陷系统的权限都得开出去。公司的 PRD、日志、用户数据要走这条路先问一句合规。七、认知升华从“工具切换者”到“工作流设计者”一条链路跑下来30 条用例变 70 条但每条都有出处、有覆盖方向、有风险等级。但比数字更重要的是你终于不用在“写用例、查覆盖、修脚本、拼报告”之间来回切换了。四个 Skill 可以独立工作也可以串联成矩阵。但“哪些场景必须覆盖”“哪些断言真正有价值”“失败之后该修脚本还是提 Bug”——这些判断只能人来做。以前你是“工具切换者”现在你是“工作流设计者”。测试人的经验值得被封装成 Skill。你今天花 30 分钟写一个“测试用例生成”的 Skill以后每一个项目都能复用。你今天花 20 分钟优化了 Skill 的规则以后每一次生成都会更精准。别只写提示词了。写一个 SKILL.md让 Agent 真正替你干活。本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容侧重测试实践、工具应用与工程经验整理。 
长河君 · 2026/10/13 23:17:53 · 阅读 1.2k 如何用 Agent Skills 自动生成测试用例？完整拆解
上个月团队里一个测试新人跑来找我表情有点委屈。“哥我在项目里放了一个 SKILL.md为什么 Claude Code 还是不会干活”我让他把文件打开。里面写着一段话“你是资深测试工程师请帮我生成测试用例覆盖正常和异常场景。”我看完就笑了。我说“你这不是 Skill是许愿。”他愣了一下“SKILL.md 不就是写提示词吗”这是大多数测试人刚接触 Agent Skills 时的第一个误解。SKILL.md 不是提示词。它是一份结构化的操作手册。你写“帮我生成用例”Agent 只会给你一段文本。你写清楚“第一步读什么、第二步拆什么、第三步输出什么格式、遇到异常怎么处理”Agent 才知道该怎么干活。今天这篇文章我把“从 PRD 到高质量测试用例”的完整链路拆开讲。不是讲概念是给你可以直接复制使用的模板和流程。一、为什么你写的 SKILL.md 总是不生效过去一年很多团队都在尝试用 AI 做测试。但真正跑起来的没几个。问题出在哪不是模型不行是你给它的东西不是一个“能力单元”。我们过去用 AI 做测试基本套路就是写一段系统提示词“你是资深测试工程师请按照以下步骤执行回归测试……”然后期待它自己搞定一切。这个思路有一个根本性缺陷LLM 是语言模型不是操作系统的内核。它可以告诉你“应该先登录再查询”但面对动态验证码、偶尔超时的 API、需要滑动解锁的按钮纯文本推理能力完全不够用。Prompt 是说明书告诉 Agent“拧开螺丝”。但真实任务执行需要知道螺丝刀在哪个抽屉、顺时针拧几圈、遇到滑丝怎么处理——这些确定性操作流程Prompt 给不了。Agent Skills 解决的就是这个问题。Anthropic 官方对 Skill 的定义很干脆一个 Skill 就是一个文件夹。里面必须有一个SKILL.md文件还可以放脚本、参考资料、静态资源。用大白话说Skill 就是把“资深测试工程师怎么做一件事”的完整经验封装成一个 Agent 能随时调用的能力包。它和 MCP 的区别是什么MCP 解决“模型能用什么工具”——连数据库、接 GitHub、操作浏览器。Skill 解决“模型该怎么用这些工具”——按什么步骤、什么格式、什么标准。MCP 给 Agent 提供手Skill 给 Agent 提供操作手册。没有 SkillAgent 有手也不知道怎么干活。二、全景总览生成测试用例需要哪几个 Skill测试用例设计的全流程本质上可以拆成四个环节。每个环节封装成一个独立的 Skill串起来就是一条从需求到用例的自动化流水线。阶段Skill核心职责输入输出需求拆解prd-to-test-map把 PRD 变成“测试地图”需求文档功能清单业务规则风险预判用例生成test-case-generator把测试地图变成结构化用例测试地图用例表格正常/异常/边界/权限场景补全test-scenario-completion基于历史 Bug 补充隐藏场景用例集历史Bug增强用例集质量评审test-case-reviewer给用例集打分并给出改进建议用例集评审报告改进项数量和不用记看分布有意思得多。活儿全压在两头前面把需求拆清楚后面把质量收干净。中间的用例生成反而是最“顺”的一环因为规则明确、格式固定。真正拉开差距的是需求拆解能不能识别出隐性业务规则和质量评审能不能发现用例集的盲区。三、逐个拆解每个 Skill 解决什么问题、怎么写、怎么用Skill ①需求拆解——把 PRD 变成“测试地图”解决什么问题拿到一份需求文档很多人第一反应是“从头开始读”。但 PRD 往往写得不够结构化——功能描述、业务规则、异常说明散落在不同章节。测试人员需要手动提取功能点、梳理业务规则、识别风险点这个过程高度依赖个人经验。SKILL.md 怎么写---name:prd-to-test-mapdescription:从PRD中提取功能点、业务规则、数据约束和风险预判生成结构化测试地图。当用户提到“分析需求”“拆解PRD”“梳理测试点”时触发。when_to_use:需求评审阶段需要将PRD转化为可执行的测试点清单时使用。---## 任务 将用户提供的需求描述或PRD内容转化为结构化的测试地图。 ## 输出格式 1. **功能清单**列出所有需要测试的功能点 2. **业务规则**状态流转、计算公式、权限控制、限制条件 3. **数据约束**输入数据的类型、格式、范围、必填性 4. **风险预判**基于经验判断哪些功能最容易出问题高/中/低 ## 规则 - 只从输入内容中提取信息不臆造不存在的功能 - 如果某项信息不明确标注“需确认”而不是猜测 - 风险预判基于通用测试经验并发场景、边界值、状态流转通常为高风险核心规则事实与猜测分离。每条输出标注证据来源需求依据/经验假设/待确认。需求没写的规则标注[待确认]不要编造。实测效果一份十来页的 PRDAgent 在几秒内输出功能清单、业务规则、数据约束、风险预判。功能清单列了 3 条已登录用户加入购物车、未登录触发登录引导、购物车数量上限校验业务规则列了 4 条上架校验、库存校验、数量累加、上限限制风险预判标出了 3 个高/中风险点。Skill ②用例生成——把“测试地图”变成“测试用例”解决什么问题有了测试地图接下来要把它“翻译”成具体的测试用例。传统方式是手动一条条写——前置条件、操作步骤、预期结果。这个过程步骤繁琐、规则固定、重复性极高。SKILL.md 怎么写---name:test-case-generatordescription:根据功能描述或需求文档生成覆盖正常流程、异常场景、边界条件和权限校验的结构化测试用例。当用户提到“生成测试用例”“编写测试”“测试覆盖”“测试场景”时自动触发。when_to_use:用户需要从需求文档或功能描述生成测试用例时使用。适用于功能测试、回归测试、接口测试的用例设计阶段。---## 任务 根据用户提供的功能描述或测试地图生成覆盖四大类场景的测试用例。 ## 执行步骤 ### 步骤1理解测试地图 读取功能清单、业务规则和数据约束。 ### 步骤2识别测试场景 - **正常流程**至少覆盖1条完整的Happy Path - **异常场景**参数缺失、格式错误、依赖服务超时 - **边界条件**数值边界、状态边界、时间窗口边界 - **权限校验**未授权访问、越权操作 ### 步骤3生成用例 每条用例包含用例编号、测试场景、前置条件、测试步骤、预期结果、优先级 ### 步骤4自检 - [ ] 每个功能点是否有至少1条正向用例 - [ ] 每个输入参数是否有异常场景覆盖 - [ ] 边界值是否覆盖了上下界 - [ ] 不同角色权限是否都有验证 ## 输出格式 Markdown表格可直接复制到Excel或测试管理工具。核心规则SKILL.md 控制在 500 行以内。Anthropic 官方推荐正文目标约 200 行最多 500 行。超过 500 行必须把详细内容移到references/目录。实测效果测试新人小陈接了一个“订单取消功能”的用例设计任务。按以往经验这活儿至少 3 天。他打开 Claude Code调了这个 Skill2 小时后交出了一份覆盖正常流程、异常场景、边界值、权限校验的完整用例集。测试组长看完之后沉默了一会儿问了一句“这是谁写的质量比我自己写还高。”Skill ③场景补全——把“没想到”的找出来解决什么问题Skill ② 生成的用例已经很全面了但 AI 毕竟不是人——它可能漏掉一些“只有业务老手才知道”的隐藏场景。比如并发下单时的库存扣减、优惠券和满减的叠加规则、异常状态下的回滚逻辑。SKILL.md 怎么写---name:test-scenario-completiondescription:基于历史Bug模式和业务知识补充AI生成的测试用例中遗漏的隐藏场景。当用户提到“补充场景”“查漏补缺”“完善用例”时触发。---## 任务 审查已有的测试用例集结合历史Bug数据和业务上下文识别并补充遗漏的测试场景。 ## 检查维度 1. **并发场景**多用户/多请求同时操作同一资源 2. **状态流转**异常状态下的操作如已取消订单再次操作 3. **数据一致性**跨模块的数据同步如订单取消→库存回滚 4. **边界组合**多个边界条件同时出现的情况 5. **历史故障**该模块历史上出过什么类型的Bug ## 输出格式 对每个补充的场景说明场景描述、补充理由、具体的测试步骤和预期结果。核心规则知识图谱不需要很复杂。一张 Excel 表格就够了——记录着“这个模块历史上出过什么类型的 Bug”。Agent 读取这张表就能识别出“AI 没想到但很可能出问题”的场景。Skill ④质量评审——给用例集“打分”解决什么问题用例写完了但质量怎么样覆盖全不全有没有冗余有没有逻辑矛盾传统方式是人工评审——开个会一群人对着 Excel 一条条看效率低下且依赖评审人的经验水平。SKILL.md 怎么写---name:test-case-reviewerdescription:对测试用例集进行自动化质量评审从覆盖完整性、规范性、一致性、优先级四个维度打分并给出改进建议。当用户提到“评审用例”“检查用例质量”“用例打分”时触发。---## 任务 审查测试用例集的质量输出结构化的评审报告。 ## 评审维度 1. **覆盖完整性**是否覆盖了正常流程、异常场景、边界条件、权限校验 2. **用例规范性**每条用例是否包含完整的“前置条件-步骤-预期结果” 3. **逻辑一致性**前置条件和预期结果之间是否存在逻辑矛盾 4. **优先级合理性**P0/P1/P2的划分是否合理 ## 输出格式 - 总体评分百分制 - 各维度评分 - 待改进项列表每条说明问题、位置、改进建议 - 评审结论通过/有条件通过/不通过核心规则让 AI 先做一轮“预审”。把明显的问题筛出来人工只需要关注 AI 搞不定的部分。比如 AI 会指出“TC-007 步骤描述过于简略”“TC-009 缺少同步后验证数据一致性的步骤”“TC-003 涉及核心业务流程建议从 P1 升级为 P0”。四、完整流水线四个 Skill 串起来怎么跑在 Claude Code 里按顺序调用第1步/prd-to-test-map → 输入PRD输出测试地图 第2步/test-case-generator → 输入测试地图输出用例初稿 第3步/test-scenario-completion → 输入用例集补充隐藏场景 第4步/test-case-reviewer → 输入用例集输出评审报告传统方式啃 PRD半天→ 梳理测试点半天→ 写用例1-2天→ 人工评审半天→ 修改半天——总计 3-4 天。Skill 流水线四个 Skill 依次触发——2 小时出初稿1 小时审核定稿。效率提升 10 倍以上。五、落地建议别一次全装拆解完四个 Skill 之后说几条务实的建议。第一只装你最痛的那一段。需求痛装需求拆解用例痛装用例生成质量痛装质量评审。全装一遍的结果通常是每个都跑过一次然后一个都没用起来。第二喂进去真东西。必须给项目真实的 PRD、真实的历史 Bug 表。用假数据跑出来的结果没有参考价值。第三打分只当提醒。评审 Skill 给你 72 分是让你去看哪条被扣分不是让你把那个数字抄进周报。六、踩坑提示三个最常见的坑坑一description 写得太空。“帮助生成测试用例”——这句话等于没说。Claude 会把所有 Skill 的 description 预加载进上下文用来判断该不该触发。你写“帮助测试”它永远不知道什么时候该用。你写“当用户提到生成测试用例、编写测试、测试覆盖、测试场景时触发”它就知道。description 是 Skill 的“门牌号”不是广告词。坑二SKILL.md 写成百科全书。超过 500 行就开始浪费 Token。把详细的用例模板、业务规则库、历史 Bug 模式放到references/目录SKILL.md 只留核心流程和导航。利用渐进式披露机制——平时只加载名字和描述等到真正使用时才加载完整内容。坑三Skill 粒度拆得太细。一个工作流拆成 10 个 SkillAI 不知道该用哪个。SkillsBench 的研究发现2-3 个模块的 Skill 表现最好。测试用例生成拆成四个 Skill 是极限拆成五个以上就开始反噬了。额外提醒这类 Skill 的名字和能力会跟着版本变装之前先看它自己那份说明。有些 Skill 要靠 MCP 或 API 接外部服务意味着浏览器、测试平台、缺陷系统的权限都得开出去。公司的 PRD、日志、用户数据要走这条路先问一句合规。七、认知升华从“工具切换者”到“工作流设计者”一条链路跑下来30 条用例变 70 条但每条都有出处、有覆盖方向、有风险等级。但比数字更重要的是你终于不用在“写用例、查覆盖、修脚本、拼报告”之间来回切换了。四个 Skill 可以独立工作也可以串联成矩阵。但“哪些场景必须覆盖”“哪些断言真正有价值”“失败之后该修脚本还是提 Bug”——这些判断只能人来做。以前你是“工具切换者”现在你是“工作流设计者”。测试人的经验值得被封装成 Skill。你今天花 30 分钟写一个“测试用例生成”的 Skill以后每一个项目都能复用。你今天花 20 分钟优化了 Skill 的规则以后每一次生成都会更精准。别只写提示词了。写一个 SKILL.md让 Agent 真正替你干活。本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容侧重测试实践、工具应用与工程经验整理。