1. 为什么我把 AI 测试 Skill 当成日常工具箱来攒这两年测试圈子里聊得最多的话题已经从“你会不会写自动化脚本”变成了“你手里有多少个能直接调用的 Skill”。我自己是从传统自动化测试一路走过来的Selenium、Pytest、接口自动化、性能压测这些活都干过后来接触到 Agent 和 Claude 这类工具之后慢慢意识到一件事真正拉开效率差距的不是你 Prompt 写得多花哨而是你有没有把高频测试动作沉淀成一个个可复用、可组合的 Skill。所谓 Skill说白了就是把一段固定的工作流程、判断逻辑、输出格式封装起来让 AI 在需要的时候直接调用。它跟普通的提示词不一样提示词是你每次都要重新描述一遍需求而 Skill 更像是一个带参数的函数你告诉它输入什么它就按既定规则吐出结果。我日常在用的这 25 个 Skill覆盖了用例生成、接口校验、日志分析、缺陷归因、测试报告整理、环境巡检、数据构造这些环节基本把测试工作里重复度最高的部分都包住了。这篇文章适合两类人看一类是刚接触 AI 测试、想知道 Skill 到底能干什么的测试同学另一类是已经在用 Agent 做测试、但手里工具零散、想系统化整理一套工具箱的从业者。我不会只列名字而是把每个 Skill 的设计思路、关键参数、实操步骤和踩过的坑都讲清楚你照着搭就能用。核心关键词 AI、测试、Skill、Agent、Claude 会贯穿全文因为它们本来就是这套东西的骨架。先说清楚一个前提Skill 不是万能的它解决的是“重复劳动”和“标准化输出”不是“替你做决策”。我见过太多人一上来就想搞一个全自动测试 Agent结果连最基本的用例评审逻辑都没理清最后做出来的东西没人敢用。所以我的思路一直是先把单个动作做扎实再谈组合和编排。2. 25 个 Skill 的整体设计与分类思路2.1 按测试生命周期划分的四层结构我攒这 25 个 Skill 不是拍脑袋凑数而是按测试工作的生命周期分了四层。第一层是需求与用例层负责把模糊的需求描述转成结构化用例第二层是执行与校验层负责跑接口、比对响应、检查数据第三层是分析与归因层负责看日志、定位失败原因、聚类缺陷第四层是报告与协作层负责整理结果、生成周报、同步给相关方。这样分层的好处是每个 Skill 的职责边界很清楚组合的时候不会互相打架。为什么强调边界清楚因为我早期犯过一个错把一个 Skill 设计成“既能生成用例又能执行测试还能出报告”结果参数一多就失控AI 经常搞混输入输出的格式。后来我把它拆成三个独立 Skill每个只干一件事反而稳定得多。这跟写代码是一个道理单一职责原则在 Skill 设计里同样适用。下面这张表是我对 25 个 Skill 的分类概览你可以先有个整体印象后面再逐个展开。层级Skill 数量典型代表核心价值需求与用例层6需求拆解、边界用例生成、等价类划分把模糊需求转成可执行用例执行与校验层8接口断言、响应比对、数据一致性检查自动化执行与结果判定分析与归因层7日志聚类、失败归因、缺陷去重快速定位问题根因报告与协作层4测试报告生成、缺陷摘要、进度同步标准化输出与协作2.2 为什么选择 Skill 而不是纯 Prompt很多人问我直接用 Prompt 不就行了为什么要费劲封装成 Skill。我的回答是Prompt 适合一次性任务Skill 适合高频重复任务。你想想你每天要生成十几条接口用例如果每次都重新写一遍“请根据以下接口文档生成正常、异常、边界三类用例输出格式为表格包含用例编号、前置条件、步骤、预期结果”这本身就是浪费。封装成 Skill 之后你只需要传入接口文档剩下的格式和规则都是固定的。另一个原因是可维护性。Prompt 散落在各个聊天记录里改一次要翻半天Skill 是集中管理的你改一处所有调用它的地方都生效。而且 Skill 可以带参数校验比如你传入的接口文档格式不对它会直接报错而不是硬着头皮生成一堆垃圾用例。这一点在团队协作里特别重要因为不是每个人都清楚你的 Prompt 该怎么写。还有一个容易被忽略的点Skill 可以组合。比如“接口断言”这个 Skill 的输出可以直接作为“失败归因”Skill 的输入形成流水线。纯 Prompt 很难做到这种稳定的衔接因为每次输出的格式可能都有细微差异。Skill 通过固定输出结构让上下游能够可靠对接。2.3 工具选型Claude、Agent 框架与本地模型的取舍在工具选型上我主力用的是 Claude 系列模型原因是它在长文本理解和结构化输出上比较稳尤其是处理接口文档、日志这类半结构化内容时不容易丢信息。Agent 框架我用的是比较轻量的方案核心就是任务编排和 Skill 调用没有上太重的框架因为测试场景往往需要快速迭代框架太重反而拖慢节奏。本地模型我也试过通过 Claude Code 调用本地模型跑一些敏感数据的测试。这里要说明的是本地模型在简单任务上够用比如日志关键字提取、格式转换但涉及复杂推理的归因分析还是得用能力更强的模型。我的建议是混合使用敏感数据走本地复杂分析走云端中间用统一的 Skill 接口隔开这样切换成本最低。提示Skill 的模型依赖要解耦。不要把模型名称硬编码在 Skill 里而是通过配置传入这样换模型的时候不用改 Skill 本身。3. 需求与用例层的 6 个 Skill 拆解3.1 需求拆解 Skill把一段话变成测试点清单这个 Skill 是我用得最频繁的一个。输入是一段需求描述输出是结构化的测试点清单包含功能点、约束条件、依赖项、风险点。它的核心逻辑是先识别需求里的名词和动词名词通常是操作对象动词通常是操作行为然后围绕“对象行为”组合出测试点。关键参数有三个requirement_text需求原文、domain业务领域用于补充领域知识、granularity粒度可选粗、中、细。粒度这个参数很关键粗粒度只输出功能模块级别细粒度会拆到具体字段和边界。我一般先用粗粒度过一遍确认大方向没错再对重点模块用细粒度拆。实操中我发现一个坑需求描述里经常有隐含条件比如“用户登录后可以查看订单”隐含了“未登录不能查看”“登录态过期不能查看”这些反向场景。所以我在 Skill 里加了一条规则强制输出反向场景和异常场景避免遗漏。这条规则是我踩过坑之后加的之前漏测过一个登录态过期的场景上线后出了问题。3.2 边界用例生成 Skill等价类与边界值的自动化边界用例是测试里最容易漏也最容易出问题的地方。这个 Skill 的输入是字段定义包括类型、取值范围、是否必填输出是边界值用例集合。它的原理就是经典的等价类划分和边界值分析但用 AI 来做的好处是它能自动识别一些不那么明显的边界比如字符串长度、特殊字符、编码问题。我给它设的参数包括field_type字段类型、min_value、max_value、nullable是否可空、special_chars是否允许特殊字符。输出会覆盖最小值、最大值、最小值减一、最大值加一、空值、超长值、特殊字符值这几类。对于数值型字段还会额外生成精度边界比如小数位数。这里有个经验不要完全信任 AI 生成的边界值尤其是涉及业务规则的字段。比如“年龄”字段技术上范围是 0 到 150但业务上可能只允许 18 到 65。所以我在 Skill 里加了一个business_rule参数让使用者显式传入业务约束AI 会优先遵循业务约束而不是纯技术边界。3.3 等价类划分 Skill减少冗余用例等价类划分的目的是用最少的用例覆盖最多的场景。这个 Skill 的输入是一组输入条件输出是划分好的等价类表每个等价类标注有效或无效并给出代表值。它的价值在于帮你砍掉重复用例我实测下来一个中等复杂度的功能用这个 Skill 能把用例数量压缩 30% 到 40%同时覆盖率不降。参数方面input_conditions是输入条件列表constraints是条件之间的约束关系。约束关系这块是难点因为很多条件不是独立的比如“用户类型”和“折扣力度”是联动的。我在 Skill 里用了一个简单的规则引擎来处理约束先让 AI 识别条件之间的依赖再据此合并等价类。注意等价类划分完成后一定要人工复核一遍。AI 有时候会把两个看似等价但实际有细微差别的类合并这种差别在特定场景下可能就是缺陷来源。3.4 用例优先级排序 Skill把有限时间花在刀刃上测试时间永远不够所以优先级排序很重要。这个 Skill 的输入是用例列表输出是按优先级排序后的列表并标注排序理由。它的排序逻辑综合了三个维度业务影响面、出错概率、修复成本。业务影响面看这个功能有多少用户在用出错概率看这个模块历史缺陷密度修复成本看一旦出问题要多久能修好。我用impact_score、probability_score、cost_score三个参数来量化每个维度 1 到 5 分最后加权求和。权重可以按项目阶段调整比如上线前更看重业务影响面迭代中期更看重出错概率。这个 Skill 帮我解决了一个老问题以前排优先级全靠拍脑袋现在至少有了一套可解释的规则。3.5 测试数据构造 Skill造出像真实业务的数据测试数据构造是个体力活尤其是需要关联多张表的时候。这个 Skill 的输入是表结构定义和关联关系输出是一批符合业务规则的测试数据。它的核心能力是理解外键关联保证造出来的数据在表之间是一致的不会出现订单表里有用户 ID 但用户表里没有这个用户的情况。参数包括schema表结构、relations关联关系、row_count数据量、data_style数据风格如正常、边界、异常。我一般会造三批数据一批正常数据用于主流程一批边界数据用于边界测试一批异常数据用于容错测试。这个 Skill 配合数据清理 Skill 一起用效果最好。3.6 用例评审 Skill提前发现用例本身的问题用例写完不代表就对了评审环节经常能发现遗漏、冗余、描述不清的问题。这个 Skill 的输入是用例集合输出是评审意见包括缺失场景、重复用例、步骤不清晰、预期结果不可验证这几类问题。它的判断依据是一套我总结的用例质量检查清单比如每条用例是否只有一个明确的验证点步骤是否可独立执行预期结果是否可观测。我给它设了checklist参数可以自定义检查项。默认清单包含 12 项检查覆盖完整性、独立性、可执行性、可验证性。实测下来这个 Skill 能发现大约 70% 的人工评审能发现的问题剩下 30% 需要结合业务上下文判断AI 暂时还替代不了。4. 执行与校验层的 8 个 Skill 实操4.1 接口断言 Skill从响应里自动提取校验点接口测试的核心是断言但手写断言很繁琐。这个 Skill 的输入是接口响应和预期规则输出是断言结果。它的聪明之处在于能自动识别响应里的关键字段比如状态码、业务码、数据体里的核心字段然后根据预期规则生成断言。我给它设了response、expected_rules、strict_mode三个参数严格模式下任何未预期的字段变化都会报警宽松模式只校验指定字段。实操中我发现接口响应里的时间戳、随机 ID 这类字段不能直接比对所以 Skill 里内置了动态字段识别规则遇到这类字段会自动跳过或做模式匹配。这个细节很关键不然每次跑断言都会因为时间戳不同而失败。4.2 响应比对 Skill新旧版本接口的差异检测做接口重构或者版本升级时需要比对新旧接口的响应差异。这个 Skill 的输入是两个响应体输出是差异清单标注新增、删除、修改的字段。它的比对是递归的能深入到嵌套结构里。参数包括old_response、new_response、ignore_fields忽略字段列表。我一般用它来做回归测试把上一个版本的响应存下来新版本跑完后自动比对。这里有个技巧忽略字段要配置好像request_id、timestamp这种每次都变的字段必须忽略否则差异清单里全是噪音。4.3 数据一致性检查 Skill跨表跨库的数据校验数据一致性是很多缺陷的根源。这个 Skill 的输入是校验规则比如“订单表的用户 ID 必须在用户表里存在”输出是一致性检查结果。它支持跨表、跨库的校验核心是把规则翻译成查询语句然后比对结果。参数包括rules校验规则列表、data_sources数据源配置、sample_rate抽样比例。全量校验太慢的时候可以设置抽样比例先抽 10% 看看有没有问题。我踩过的坑是抽样校验通过不代表全量没问题所以关键规则还是要全量跑非关键规则可以抽样。4.4 环境巡检 Skill上线前的基础设施检查每次上线前我都会跑一遍环境巡检。这个 Skill 的输入是环境配置输出是巡检报告检查项包括服务是否可达、依赖是否正常、配置是否一致、磁盘空间是否充足。它的价值在于把零散的检查动作标准化避免漏检。参数包括env_config环境配置、check_items检查项列表、timeout超时时间。我一般会配置两套检查项一套是基础检查每次上线都跑一套是深度检查大版本上线才跑。基础检查控制在 2 分钟内完成深度检查可以跑 10 分钟。4.5 日志关键字监控 Skill实时捕捉异常信号测试执行过程中日志里会冒出各种异常信号。这个 Skill 的输入是日志流输出是异常事件列表。它的核心是关键字匹配加模式识别关键字包括 ERROR、Exception、Timeout、Failed 这些模式识别则用于捕捉一些没有明确关键字但明显异常的情况比如响应时间突然飙升。参数包括log_stream、keywords、patterns、alert_threshold告警阈值。我一般设置成 5 分钟内出现 3 次同类异常就告警避免偶发噪音干扰。4.6 接口性能基线 Skill建立性能参考线性能测试不是每次都做但基线要一直维护。这个 Skill 的输入是接口列表和基线数据输出是当前性能与基线的对比。它的作用是快速发现性能退化比如某个接口响应时间从 200ms 涨到了 500ms虽然还没到告警线但已经偏离基线了。参数包括api_list、baseline_data、deviation_threshold偏差阈值。我一般设置偏差超过 20% 就标记出来人工确认是不是有问题。4.7 测试数据清理 Skill用完即清避免污染测试数据造出来容易清理起来麻烦。这个 Skill 的输入是数据标识输出是清理结果。它的核心是识别测试数据的特征比如特定的前缀、特定的时间范围然后批量清理。参数包括data_pattern、clean_scope、dry_run试运行。我强烈建议开启dry_run模式先看看会清理哪些数据确认无误再真正执行。我早期有一次没开试运行把一批生产数据误删了虽然最后恢复了但教训很深刻。4.8 断言结果聚合 Skill把零散结果汇总成结论跑完一堆断言后结果往往是零散的。这个 Skill 的输入是断言结果列表输出是聚合结论包括通过率、失败分类、失败趋势。它的价值在于让你一眼看清整体质量状况而不是淹没在细节里。参数包括assertion_results、group_by分组维度、trend_window趋势窗口。我一般按模块分组看哪个模块失败最多趋势窗口设成最近 7 天看失败率是在上升还是下降。5. 分析与归因层的 7 个 Skill 深度用法5.1 日志聚类 Skill把海量日志压缩成几类问题日志分析最头疼的是量大。这个 Skill 的输入是日志集合输出是聚类结果把相似的日志归为一类并标注每类的出现次数和代表样本。它的聚类依据是日志模板把变量部分抽象掉只保留固定结构。参数包括logs、similarity_threshold相似度阈值、min_cluster_size最小聚类大小。相似度阈值我一般设 0.8太低会把不同问题混在一起太高又会把同一问题拆散。5.2 失败归因 Skill从失败现象倒推根因这是我最喜欢的一个 Skill。输入是失败用例和对应的日志、响应输出是可能的根因列表按可能性排序。它的推理逻辑是先看失败现象比如超时、断言失败、连接拒绝再结合日志里的线索推断是环境问题、数据问题、代码问题还是用例问题。参数包括failure_info、context上下文如最近变更、history历史相似失败。我给它加了历史相似失败这个参数后归因准确率明显提升因为很多失败是重复出现的历史记录里有现成的答案。5.3 缺陷去重 Skill避免重复提单同一个问题被不同人提了多次是测试协作里的常见浪费。这个 Skill 的输入是新缺陷描述和已有缺陷列表输出是重复判定结果。它的判断依据是缺陷标题、复现步骤、错误信息的相似度。参数包括new_defect、existing_defects、similarity_threshold。我一般设 0.75这个阈值下误判率比较低。如果拿不准Skill 会输出“疑似重复”让人工确认。5.4 缺陷严重程度评估 Skill统一评级标准不同人评严重程度的标准不一样导致优先级混乱。这个 Skill 的输入是缺陷描述输出是建议的严重程度等级并给出理由。它的评估维度包括影响用户数、功能可用性、数据安全性、是否有绕过方案。参数包括defect_desc、impact_scope、workaround是否有绕过方案。我把它接入缺陷管理系统后新缺陷会自动带上建议等级评审时只需要确认或调整效率提升不少。5.5 测试覆盖率分析 Skill找出没测到的地方覆盖率不只是代码覆盖率还有需求覆盖率和场景覆盖率。这个 Skill 的输入是需求列表和用例列表输出是覆盖率报告标注哪些需求没有对应用例哪些场景没有覆盖。参数包括requirements、test_cases、coverage_type。我一般会同时看需求覆盖率和场景覆盖率前者看有没有漏功能后者看有没有漏场景。5.6 回归范围推荐 Skill精准圈定要回归的用例每次发版都要回归但全量回归太慢。这个 Skill 的输入是变更内容和用例库输出是推荐的回归用例集合。它的逻辑是根据变更影响的模块找出关联的用例再结合历史缺陷密度优先推荐高风险用例。参数包括changes、test_case_library、risk_weight。我实测下来这个 Skill 能把回归用例数量压缩到全量的 20% 到 30%同时漏测率控制在可接受范围内。5.7 质量趋势分析 Skill从数据里看质量走向质量不是某一个时间点的快照而是趋势。这个 Skill 的输入是历史测试数据输出是质量趋势报告包括缺陷发现率、缺陷修复率、用例通过率的变化趋势。它的价值在于提前发现质量下滑的信号。参数包括historical_data、time_window、metrics。我一般看最近 4 周的趋势如果缺陷发现率持续上升说明代码质量在下降需要提前介入。6. 报告与协作层的 4 个 Skill 与组合玩法6.1 测试报告生成 Skill从数据到报告的一键转换这个 Skill 的输入是测试执行数据输出是结构化测试报告包含测试概况、通过率、失败分析、风险提示、建议。它的模板可以自定义我一般用两套模板一套是日常迭代的简版一套是版本发布的详版。参数包括test_data、template、audience受众。受众这个参数很实用给开发看的报告侧重技术细节给产品看的报告侧重业务影响给管理层看的报告侧重风险和结论。6.2 缺陷摘要 Skill把长描述压缩成一句话缺陷描述往往很长同步给相关方时需要摘要。这个 Skill 的输入是缺陷详情输出是一句话摘要包含问题现象、影响范围、当前状态。参数包括defect_detail、max_length、focus关注点。我一般把摘要控制在 50 字以内方便在群里快速同步。focus 参数可以指定关注现象、影响还是进度不同场景用不同关注点。6.3 进度同步 Skill自动生成站会发言每天站会都要说昨天做了什么、今天做什么、有什么阻塞。这个 Skill 的输入是任务列表和状态输出是站会发言稿。参数包括tasks、date、style风格简洁或详细。这个 Skill 帮我省了不少时间以前站会前要花 10 分钟整理现在一键生成稍微改改就能用。6.4 知识沉淀 Skill把测试经验变成可复用文档测试过程中积累的经验如果不沉淀就浪费了。这个 Skill 的输入是测试记录和问题解决过程输出是知识文档包含问题描述、排查过程、解决方案、预防措施。参数包括records、doc_type、tags。我一般把这类文档按模块和问题类型打标签方便后续检索。这个 Skill 配合前面的归因 Skill 一起用能把一次性的排查经验变成团队资产。6.5 组合玩法把 Skill 串成流水线单个 Skill 好用组合起来更强。我常用的一个流水线是需求拆解 → 边界用例生成 → 用例评审 → 接口断言 → 失败归因 → 测试报告生成。这条流水线跑下来从需求到报告基本能自动化 60% 到 70% 的工作量。组合的关键是接口对齐也就是上一个 Skill 的输出格式要能被下一个 Skill 直接消费。我在设计每个 Skill 的时候都会预留标准化的输出结构比如用例统一用 JSON 格式包含 id、title、steps、expected 这几个字段。这样组合的时候不需要额外转换。提示组合流水线不要一上来就搞太长先从两三个 Skill 串起来跑通了再逐步加长。我见过有人一上来就串了十个 Skill结果中间任何一个环节出问题整条线就断了排查起来很痛苦。7. 实操中踩过的坑与常见问题排查7.1 Skill 输出不稳定的三种典型原因第一种是输入格式不统一。同一个 Skill你这次传的是纯文本下次传的是 JSON输出自然不一样。解决办法是给每个 Skill 定义严格的输入 schema传之前先校验。第二种是参数缺失。有些参数看起来可选但实际上不传会导致 AI 自由发挥。我的做法是把关键参数设为必填宁可多填几个也不要让 AI 猜。第三种是模型版本变化。同一个 Skill换个模型版本输出风格可能就变了。所以我在 Skill 配置里锁定了模型版本升级前先跑回归测试。7.2 常见问题速查表问题现象可能原因排查方向解决办法输出格式错乱输入格式不统一检查输入 schema增加输入校验结果偏离预期参数缺失或错误检查参数配置关键参数设为必填输出风格突变模型版本变化检查模型配置锁定模型版本组合流水线断裂上下游格式不匹配检查接口对齐统一输出结构归因准确率低上下文不足补充历史数据增加 history 参数执行超时数据量过大检查数据规模分批处理或抽样7.3 独家避坑技巧第一个技巧给 Skill 加“自检”步骤。在输出最终结果前让 AI 自己检查一遍格式和逻辑发现问题就重试。这个自检步骤能过滤掉大部分低级错误。第二个技巧保留 Skill 的调用日志。每次调用的输入、输出、耗时都记下来出问题的时候能快速定位。我用这个日志发现过好几次参数配置错误。第三个技巧定期回归测试 Skill。模型会更新业务会变化Skill 也要跟着调整。我一般每个月跑一次 Skill 回归确保它们还在正常工作。第四个技巧不要过度依赖单一 Skill。再好的 Skill 也有边界关键决策还是要人工把关。我见过有人完全信任 AI 生成的用例结果漏了核心场景上线后出了大问题。8. 我个人的一些实际体会这套 Skill 工具箱我攒了大概半年多从最开始的三五个慢慢加到现在的 25 个。最大的感受是Skill 的价值不在于数量而在于你能不能把它们真正用起来。我见过有人收集了几百个 Prompt但日常还是手动干活因为那些 Prompt 没有形成工作流。另一个体会是Skill 的设计要跟着业务走不能为了技术而技术。我早期设计过一个很复杂的归因 Skill用了很多推理链结果实际用的时候发现大部分失败原因就那么几类简单的规则匹配就够了。后来我把它简化了反而更好用。还有一点Skill 是需要维护的。业务变了、接口变了、模型变了Skill 都要跟着更新。我现在每个月会花半天时间做 Skill 维护检查有没有失效的、有没有需要优化的。这个投入是值得的因为一旦 Skill 失效而你没发现它产生的错误结果可能比不用还糟糕。最后分享一个小技巧新手不要一上来就追求大而全的 Skill先从最小的动作开始比如“把这段日志里的错误提取出来”跑通了再逐步加功能。Skill 的成长是迭代出来的不是设计出来的。我现在这 25 个 Skill每一个都经历过至少三次改版才变成现在稳定可用的样子。