1. 这套 Skill 体系到底解决了什么问题日常跟 AI Agent 打交道多了你会发现一个很尴尬的现象模型本身能力不差但一到具体任务上就开始“飘”。让它写个测试用例格式每次都不一样让它分析日志它给你来一段散文让它生成接口测试脚本跑起来一堆语法错误。问题不在模型在于我们没给它一套稳定的“操作手册”。我管这套操作手册叫Skill。你可以把它理解成给 Agent 装的“技能插件”——一段结构化的指令告诉它在特定场景下应该怎么思考、按什么步骤执行、输出什么格式。跟传统的 Prompt 最大的区别是Skill 是可复用、可组合、可版本管理的。你今天调好一个“接口测试用例生成”的 Skill明天换个项目直接拿来用不用重新调 Prompt。我目前日常在用的有 25 个左右覆盖了测试开发的大部分环节需求分析、用例设计、接口测试、UI 自动化、性能测试、日志排查、测试报告生成。这套东西用下来最直观的感受是——Agent 的输出从“每次都要改”变成了“八成直接能用”。剩下两成微调一下就行。这篇文章适合几类人看一是已经在用 Claude、Agent 类工具做测试开发但觉得输出不稳定的二是想搭建自己测试平台需要一套标准化指令体系的三是刚接触 AI 辅助测试不知道从哪里入手的。我会把每个 Skill 的设计思路、关键参数、实操踩坑都讲清楚你照着改改就能用。注意Skill 不是万能的。它解决的是“输出稳定性和可复用性”问题不解决模型本身的能力边界。复杂逻辑推理该翻车还是翻车别指望一个 Skill 就能让模型变聪明。2. Skill 的核心设计逻辑与分类体系2.1 为什么是 Skill 而不是 Prompt很多人第一次听到 Skill 会觉得“不就是 Prompt 吗”。我一开始也这么想直到被现实教育了几次。普通 Prompt 的问题在于它是对话式的、一次性的、上下文强依赖的。你这次写了一段很长的指令模型表现很好下次换个对话窗口同样的指令效果就打折了。因为模型对指令的理解受上下文影响很大前面聊了什么、用什么语气聊的都会干扰输出。Skill 的做法不一样。它把指令结构化成了几个固定模块角色定义这个 Skill 扮演什么角色具备什么领域的知识输入规范用户需要提供什么信息格式是什么执行步骤按什么顺序做什么事每步的产出是什么输出格式最终结果长什么样用什么结构呈现约束条件什么不能做什么必须做边界在哪里这五个模块固定下来之后输出稳定性会有质的提升。我实测过同一个测试用例生成任务用普通 Prompt 的格式一致率大概在 60% 左右用结构化 Skill 能到 90% 以上。2.2 25 个 Skill 的分类框架我把日常用的 25 个 Skill 分成了五大类按使用频率从高到低排列分类数量典型 Skill使用频率需求与用例6 个需求拆解、用例生成、边界分析每天接口与自动化7 个接口脚本生成、断言设计、数据构造每天UI 与端到端4 个元素定位、流程编排、截图对比每周性能与稳定性4 个场景设计、指标分析、瓶颈定位每周报告与排查4 个日志分析、报告生成、缺陷归因每天这个分类不是拍脑袋定的是按测试工作流的实际顺序来的。从拿到需求开始到用例设计、脚本编写、执行、排查、出报告每个环节都有对应的 Skill 覆盖。2.3 Skill 的粒度控制原则这是踩坑最多的地方。一开始我写的 Skill 特别细比如“生成登录接口的测试用例”这种结果发现复用性极差换个接口就得重写。后来调整成“生成 RESTful 接口的测试用例”输入参数改成接口定义复用性一下就上来了。粒度控制的核心原则是Skill 应该对应一类任务而不是一个具体任务。判断标准很简单——如果你写 Skill 的时候发现里面出现了具体的接口名、字段名、页面元素那说明粒度太细了应该把这些抽成输入参数。但也不能太粗。我试过写一个“测试全流程”的 Skill结果模型根本执行不了因为步骤太多、依赖太复杂。后来拆成了需求分析、用例生成、脚本编写、执行排查四个独立 Skill每个都能单独用也能串起来用。实操心得Skill 的粒度控制在“一个 Skill 解决一个明确问题输入输出清晰”这个程度最合适。如果一个 Skill 需要超过 5 个输入参数或者执行步骤超过 8 步就该考虑拆分了。3. 高频 Skill 的详细拆解与实操配置3.1 需求拆解 Skill从 PRD 到测试点这是整个流程的起点。产品丢过来一份 PRD你要快速提取出可测试的点。人工做这件事大概要一两个小时用 Skill 能压缩到十几分钟。这个 Skill 的核心逻辑是三层拆解业务目标层、功能模块层、测试点层。第一层搞清楚这个需求要解决什么问题第二层拆出涉及哪些功能模块第三层针对每个模块列出具体的测试点。关键配置如下角色资深测试分析师擅长从产品需求文档中提取可测试点 输入PRD 文本或截图描述 执行步骤 1. 识别业务目标用一句话概括 2. 列出涉及的功能模块每个模块标注优先级 3. 针对每个模块按正常流、异常流、边界值三个维度列出测试点 4. 标注测试点之间的依赖关系 输出格式Markdown 表格包含模块、测试点、类型、优先级、依赖 约束不臆测 PRD 未提及的功能对模糊描述标注“需确认”这个 Skill 我用了大半年最大的价值是强制模型按结构输出。以前直接问“这个需求有哪些测试点”模型给的东西东一榔头西一棒子现在至少结构是清晰的漏测率明显下降。3.2 接口测试用例生成 Skill这是使用频率最高的一个。输入是接口定义Swagger 或手写描述输出是完整的测试用例集。核心设计思路是参数组合 场景覆盖。接口测试的本质是验证不同参数组合下接口的行为所以 Skill 里内置了一套参数组合策略必填参数缺失参数类型错误参数边界值最大、最小、空、超长参数组合冲突业务规则约束角色接口测试专家 输入接口定义URL、方法、请求参数、响应结构、业务规则 执行步骤 1. 解析接口定义列出所有参数及其约束 2. 按参数组合策略生成测试用例 3. 为每个用例设计预期结果 4. 标注用例优先级P0/P1/P2 输出格式表格包含用例编号、用例描述、请求参数、预期结果、优先级 约束每个参数至少覆盖 3 种异常情况业务规则相关的用例标 P0实测下来一个中等复杂度的接口5-8 个参数这个 Skill 能生成 30-50 条用例覆盖度比人工设计高不少。但要注意生成的用例需要人工审核特别是业务规则相关的模型有时候理解不到位。3.3 自动化脚本生成 Skill这个 Skill 解决的是“用例写完了脚本懒得写”的问题。输入是用例描述输出是可直接运行的测试脚本。我配置了两个版本一个生成 pytest 脚本一个生成 JavaScript 脚本。核心差异在输出格式和断言风格上。pytest 版本的配置要点角色Python 测试开发工程师 输入测试用例描述、接口定义 执行步骤 1. 分析用例确定测试数据需求 2. 生成 fixture 用于数据准备和清理 3. 编写测试函数使用 parametrize 处理多组数据 4. 添加断言覆盖状态码、响应字段、业务逻辑 输出格式完整的 pytest 脚本包含 import、fixture、测试函数 约束使用 requests 库断言要具体不用 assert response.status_code 200 这种笼统写法这里有个坑要提醒模型生成的脚本经常忘记处理测试数据清理。比如创建了一条记录测试完不删除跑几次数据库就脏了。所以我在 Skill 里强制要求生成 fixture用 yield 做 teardown。3.4 日志分析与缺陷归因 Skill线上出问题了丢过来一堆日志人工翻要半天。这个 Skill 的作用是快速定位关键信息。核心逻辑是分层过滤先按日志级别过滤出 ERROR 和 WARN再按时间窗口聚合最后提取异常堆栈和关键上下文。角色运维排查专家 输入日志文本可分段 执行步骤 1. 统计各级别日志数量识别异常峰值 2. 提取所有 ERROR 和 WARN 日志 3. 按异常类型聚类找出高频异常 4. 提取异常堆栈定位到具体代码行 5. 关联时间窗口内的其他日志还原现场 输出格式分析报告包含异常概览、高频异常、根因推测、建议排查方向 约束不臆测根因只基于日志内容推断标注不确定的地方这个 Skill 我一般在线上告警之后第一时间用能快速判断是代码问题、数据问题还是环境问题。3.5 测试报告生成 Skill测试跑完了要出报告。人工写报告大概要半小时用 Skill 五分钟搞定。输入是测试执行结果JUnit XML 或 JSON输出是结构化的测试报告。关键是要把通过率、失败用例、失败原因、趋势变化这几个核心信息突出出来。角色测试负责人 输入测试执行结果文件 执行步骤 1. 统计总体通过率、各模块通过率 2. 列出所有失败用例及其失败原因 3. 对比历史执行结果标注新增失败和修复用例 4. 按失败原因分类给出改进建议 输出格式Markdown 报告包含概览、失败详情、趋势分析、建议 约束失败原因要具体到断言失败还是异常抛出趋势分析要有数据支撑4. Skill 的组合使用与工作流编排4.1 串联多个 Skill 的实战流程单个 Skill 好用但真正的效率提升来自组合使用。我日常的工作流是这样的拿到 PRD用需求拆解 Skill 提取测试点把测试点丢给用例生成 Skill产出测试用例用例丢给脚本生成 Skill产出自动化脚本脚本跑完结果丢给报告生成 Skill产出测试报告如果有失败日志丢给排查 Skill定位问题这条链路跑通之后一个中等规模的需求从分析到出报告大概两三个小时。以前纯人工做至少两天。4.2 Skill 之间的数据传递格式组合使用的关键问题是数据格式要统一。我踩过的坑是需求拆解 Skill 输出的表格格式用例生成 Skill 不认还得手动转一道。后来我定了一套内部标准所有 Skill 的输入输出都用 Markdown 表格或 JSON。表格适合人看JSON 适合程序处理。具体用哪个看下一个 Skill 的输入要求。比如需求拆解输出测试点表格用例生成 Skill 的输入就配置成“接受 Markdown 表格格式的测试点列表”。这样直接复制粘贴就能用不用转换。4.3 用 Agent 编排 Skill 的注意事项如果你用的是支持 Agent 的工具比如 Claude 的某些模式可以把多个 Skill 注册成 Agent 的工具让它自动编排。但这里有个坑Agent 自动编排的稳定性不如手动串联。因为 Agent 会自己决定什么时候调用哪个 Skill有时候会跳步或者顺序搞错。我的做法是关键流程手动串联非关键流程让 Agent 自动跑。实操心得Skill 组合使用的时候建议在每个 Skill 的输出里加一个“下一步建议”字段告诉使用者接下来该用哪个 Skill。这样即使是 Agent 自动编排也有个参考。5. 常见问题与排查技巧实录5.1 Skill 输出不稳定的排查思路这是最常见的问题。同一个 Skill有时候输出很好有时候一塌糊涂。排查思路如下现象可能原因解决方法格式偶尔跑偏输入内容格式不统一严格规范输入格式加校验步骤内容深度不够角色定义太泛细化角色加上领域经验描述漏掉关键步骤执行步骤描述模糊每步加上明确的产出要求输出太长/太短缺少长度约束在约束条件里加字数或条目数限制我遇到最多的是输入格式不统一导致的问题。比如同样是接口定义有时候是 Swagger JSON有时候是手写表格模型处理起来效果差异很大。后来我强制要求所有输入先转成统一格式问题就少多了。5.2 Skill 复用时的适配问题换项目的时候Skill 不能直接拿来用需要适配。适配的主要是领域知识部分。比如接口测试用例生成 Skill在电商项目和金融项目里业务规则完全不同。我的做法是把业务规则抽成独立的“知识库”文件Skill 里只写“参考知识库中的业务规则”用的时候把对应的知识库挂上去。这样 Skill 本身不用改换知识库就行。5.3 模型能力边界与 Skill 的配合有些任务模型确实做不好比如复杂的并发场景分析、涉及多系统交互的链路追踪。这种时候 Skill 也救不了得靠人工。我的判断标准是如果这个任务需要跨多个系统做因果推理模型大概率搞不定。这时候 Skill 的作用就退化成“辅助整理信息”而不是“直接给答案”。认清这个边界很重要不然你会花大量时间调 Skill最后发现方向错了。5.4 常见问题速查表问题排查方向快速解决Skill 不生效检查角色定义是否清晰加上“你是一名资深XX专家”输出格式乱检查输出格式描述给出具体的 Markdown 模板内容太浅检查执行步骤每步加上“至少列出X个”遗漏关键点检查约束条件加上“必须覆盖XX场景”复用性差检查输入参数把具体值抽成参数6. 我个人的一些实操体会这套 Skill 体系我打磨了大半年最大的体会是Skill 的质量取决于你对任务本身的理解深度。如果你自己都没想清楚这个任务应该怎么做写出来的 Skill 肯定是模糊的。另一个体会是不要追求一次写完美。我最早的几个 Skill 现在回头看简直没法看但就是那些粗糙的版本让我跑通了流程然后在用的过程中不断迭代。先跑起来再优化比憋大招强。还有一点Skill 要跟着工具走。不同模型对指令的理解能力不一样同一个 Skill 在 A 模型上表现好换到 B 模型可能就要调。所以我会给每个 Skill 标注“适配模型”换工具的时候心里有数。最后分享一个小技巧给 Skill 加版本号。我现在的命名规则是“skill名称_v版本号_日期”比如“api_case_gen_v3_20241201”。这样迭代的时候不会搞混回滚也方便。