1. 这套 Skill 体系到底解决了什么问题我日常跟 AI Agent 打交道的时间比跟真人同事说话的时间还长。从最早的 prompt 拼贴到后来的 function calling再到现在以 Claude Code、Codex 为代表的 Skill 机制中间踩过的坑能写一本小册子。今天要聊的这 25 个 Skill是我过去大半年里反复筛选、淘汰、重构之后留下来的“常驻编制”。它们覆盖了测试开发、代码审查、文档生成、数据处理、环境巡检、接口验证等场景基本构成了我日常工作的自动化底座。先说清楚一个概念免得新手被各种名词绕晕。Skill 本质上是一段可被 Agent 按需加载的结构化能力描述它通常包含三部分触发条件什么时候用、执行指令怎么做、输出约束做成什么样。你可以把它理解成给 AI 装的一个“插件”但这个插件不是二进制程序而是一份写得极其精确的自然语言说明书外加可选的脚本、模板和参考文件。Agent 在运行时根据当前任务上下文自动判断该调用哪个 Skill然后按照 Skill 里定义的流程去执行。那它跟 prompt 有什么区别区别大了。随手写的一段 prompt 是一次性的、上下文强绑定的、不可复用的而 Skill 是持久化的、可版本管理的、可组合的。我试过把同一个测试任务分别用 prompt 和 Skill 跑prompt 方案每次都要重新描述背景输出格式飘忽不定Skill 方案第一次写好之后后面几十次调用输出结构几乎一致稳定性完全不是一个量级。这套体系适合谁三类人收益最明显。第一类是测试开发工程师日常要写大量重复的用例、报告、巡检脚本Skill 能把这类工作压缩到原来的三分之一时间。第二类是独立开发者和小团队没有专职测试靠 Skill 把质量兜底做起来。第三类是技术管理者需要把团队里老师傅的经验沉淀成可复用的资产Skill 就是最好的载体。哪怕你只是刚接触 Agent 的新手从这篇文章里挑三五个 Skill 照着搭也能立刻感受到效率差异。下面我会按“设计思路—核心细节—实操过程—问题排查”这条主线展开中间穿插具体的 Skill 配置片段和参数说明。所有内容都是我在真实项目里跑通的不是纸上谈兵。2. 整体设计思路为什么是这 25 个而不是别的2.1 筛选标准高频、可验证、低耦合我一开始收集了将近 80 个 Skill从各种社区、仓库、朋友分享里扒来的都有。但真正留下来的只有 25 个淘汰率接近七成。淘汰的原因集中在三点触发条件模糊Agent 根本不知道该不该用、输出无法验证跑完了不知道对不对、依赖过重要装一堆环境才能跑。留下来的这 25 个全部满足三个硬指标。第一是高频至少每周会用到的才留一个月用一次的果断砍掉。第二是可验证每个 Skill 的输出都有明确的检查点比如测试报告必须包含通过率、失败用例列表、耗时统计这三项缺一项就算失败。第三是低耦合单个 Skill 不依赖其他 Skill 的存在可以独立调用这样组合起来才灵活。提示新手最容易犯的错是一上来就追求“大而全”的 Skill恨不得一个 Skill 干完整个项目。实测下来粒度越细的 Skill 复用率越高维护成本越低。2.2 分层架构从原子能力到复合工作流这 25 个 Skill 不是平铺的我按能力层级分成了四层这样在 Agent 调度时逻辑更清晰。层级定位典型 Skill 数量举例L1 原子能力层单一动作输入输出极简8 个文件读取、命令执行、格式转换L2 领域能力层特定领域的专业操作9 个用例生成、接口断言、日志解析L3 工作流层编排多个 L2 完成完整任务5 个全量回归、环境巡检、报告汇总L4 元能力层管理和优化其他 Skill3 个Skill 自检、效果评估、版本对比这个分层的好处在于当我要新增一个能力时先判断它属于哪一层然后决定是独立成 Skill 还是挂到已有 Skill 下面。比如“生成边界值用例”这个能力它属于 L2因为它依赖 L1 的文件读取但本身是一个完整的领域动作。而“跑完整个测试套件并出报告”属于 L3它内部会调用多个 L2。2.3 命名与触发让 Agent 一眼看懂Skill 的命名和触发描述直接决定了 Agent 会不会在正确的时机调用它。我踩过的最大坑就是命名太文艺比如把一个接口测试 Skill 命名为“守门人”结果 Agent 十次有八次不知道该用它。后来全部改成动词对象场景的直白结构命中率立刻上来了。比如差代码卫士好扫描Python代码安全漏洞差数据管家好校验CSV字段完整性与类型触发描述里我会明确写出“当用户提到 X、Y、Z 时使用本 Skill”并且列出反例告诉 Agent 什么情况下不要用。这个反例特别重要能大幅减少误触发。我实测过加了反例之后误触发率从 30% 降到了 8% 左右。3. 核心细节解析25 个 Skill 里最值得深挖的几个3.1 用例生成 Skill从需求文本到可执行用例这是我用得最频繁的一个几乎每天都要跑。它的输入是一段需求描述或者接口文档输出是结构化的测试用例包含用例编号、前置条件、步骤、预期结果、优先级。核心难点在于需求里的隐含边界。比如需求写“用户名长度 6 到 20 位”新手 Skill 只会生成 6 位和 20 位两个用例但实际要覆盖的是5 位下边界外、6 位下边界、7 位边界内、19 位边界内、20 位上边界、21 位上边界外再加上空值、纯空格、特殊字符、中文、emoji 这些等价类。我在 Skill 里内置了一套边界值推导规则让 Agent 自动补齐这些。skill: 生成边界值测试用例 trigger: 当用户提供数值范围、长度限制、时间区间等约束条件时 steps: - 提取所有数值约束 - 对每个约束生成下界-1、下界、下界1、上界-1、上界、上界1 - 补充等价类空、null、超长、特殊字符、类型错误 - 按优先级排序边界值 等价类 异常值 output: format: table columns: [用例编号, 前置条件, 步骤, 预期结果, 优先级]这里有个经验优先级排序规则一定要写死在 Skill 里不要让 Agent 自由发挥。我早期没写死结果 Agent 有时候把异常值排在边界值前面导致回归时先跑了一堆低价值用例浪费时间。3.2 接口断言 Skill让响应校验不再靠肉眼接口测试最烦的是断言写得随意今天校验三个字段明天校验五个字段最后没人知道到底该校验什么。我的做法是把断言规则固化到 Skill 里按接口类型分模板。对于查询类接口强制校验HTTP 状态码、业务 code、数据条数、关键字段类型、分页字段。对于写入类接口强制校验状态码、业务 code、数据库落库结果、幂等性重复调用结果一致。对于删除类接口强制校验状态码、业务 code、删除后查询为空、重复删除的返回。# Skill 内置的断言模板片段 ASSERT_TEMPLATES { query: [status_code, biz_code, data_count, field_types, pagination], create: [status_code, biz_code, db_record, idempotent], delete: [status_code, biz_code, query_empty, repeat_delete] }注意幂等性校验一定要加超时重试因为有些接口第一次调用和第二次调用之间有时间窗口直接连续调用可能误判。我一般设置 500ms 间隔重试两次。3.3 日志解析 Skill从海量日志里捞出真问题线上出问题的时候日志动辄几十万行肉眼根本看不过来。这个 Skill 的作用是输入日志文件路径和关键词输出异常摘要、出现频次、时间分布、关联堆栈。关键设计点是异常聚类。同样的错误可能因为参数不同产生几百条日志如果不去重报告就没法看。我在 Skill 里加了一步归一化把日志里的数字、UUID、时间戳、IP 替换成占位符然后再聚类。这样几百条日志能压缩成几条模式。# 归一化处理示例 sed -E s/[0-9]{4}-[0-9]{2}-[0-9]{2}/DATE/g; s/[0-9a-f]{8}-[0-9a-f]{4}/UUID/g; s/[0-9]\.[0-9]\.[0-9]\.[0-9]/IP/g app.log实测下来一个 50 万行的日志文件归一化加聚类之后异常模式通常不超过 15 条排查效率提升非常明显。3.4 环境巡检 Skill上线前的最后一道闸每次上线前我都会跑一遍环境巡检检查项包括依赖服务连通性、数据库连接池状态、磁盘剩余空间、关键配置项是否被误改、证书有效期、定时任务是否正常注册。这个 Skill 的价值在于检查项可配置。不同项目关注点不一样有的项目特别在意磁盘有的项目特别在意证书。我把检查项做成配置文件Skill 读取配置后逐项执行输出通过/失败/警告三态报告。检查项阈值失败动作磁盘剩余 20% 警告 10% 失败阻断上线证书有效期 30 天警告 7 天失败阻断上线数据库连接获取连接超时 3s阻断上线配置项校验与基线不一致警告并列出差异3.5 Skill 自检元能力层的关键一环这个 Skill 比较特殊它不干具体业务而是检查其他 Skill 的健康度。检查内容包括触发描述是否清晰、输出格式是否明确、是否有反例说明、最近调用成功率、平均耗时。我每周跑一次自检把成功率低于 80% 的 Skill 挑出来重构。有一次发现一个“生成测试报告”的 Skill 成功率只有 55%排查后发现是输出格式描述太模糊Agent 每次生成的报告结构都不一样导致下游解析失败。把输出格式改成严格的 JSON Schema 之后成功率直接拉到 96%。4. 实操过程从零搭起你的第一个 Skill4.1 环境准备与目录结构不管你用的是哪套 Agent 框架Skill 的存放逻辑都差不多。我习惯的目录结构是这样的skills/ ├── l1-atomic/ │ ├── read-file/ │ │ ├── SKILL.md │ │ └── scripts/ │ └── run-command/ ├── l2-domain/ │ ├── gen-testcase/ │ │ ├── SKILL.md │ │ ├── templates/ │ │ └── rules/ │ └── assert-api/ ├── l3-workflow/ │ └── full-regression/ └── l4-meta/ └── skill-health-check/每个 Skill 一个目录核心是SKILL.md里面写触发条件、执行步骤、输出约束。如果有脚本或模板放在同级子目录里。这样版本管理的时候一个 Skill 的变更范围很清晰不会互相污染。4.2 写一份能用的 SKILL.md很多人写 SKILL.md 像写作文堆了一堆形容词结果 Agent 读不懂。我的写法是结构化、命令式、带示例。下面是一个真实在用的模板--- name: 生成接口测试用例 trigger: 当用户提供接口文档、Swagger 链接或接口描述文本时 anti-trigger: 当用户只是询问接口含义、不要求生成用例时不要使用本 Skill --- ## 执行步骤 1. 解析接口定义提取路径、方法、请求参数、响应结构 2. 对每个参数生成等价类和边界值用例 3. 对响应结构生成字段校验用例 4. 补充异常场景超时、鉴权失败、参数缺失、类型错误 5. 按优先级排序输出 ## 输出格式 必须输出 Markdown 表格列固定为 | 用例编号 | 用例名称 | 前置条件 | 请求参数 | 预期结果 | 优先级 | ## 示例 输入GET /user/{id}id 为整数范围 1-99999 输出 | 用例编号 | 用例名称 | 前置条件 | 请求参数 | 预期结果 | 优先级 | | TC-001 | 正常查询 | 用户存在 | id1 | 200返回用户信息 | P0 | | TC-002 | 下边界 | 用户存在 | id1 | 200 | P0 | | TC-003 | 下边界外 | 无 | id0 | 400 | P1 | ...注意anti-trigger这一项它明确告诉 Agent 什么情况下不要用这个 Skill。这一项是我踩坑之后加的之前没有它的时候用户随便问一句“这个接口什么意思”Agent 也会触发用例生成浪费 token 还答非所问。4.3 参数计算边界值到底怎么取边界值取法看起来简单但实际项目里经常出问题。我总结了一套计算规则写进了 Skill 的 rules 目录。对于整数范围 [a, b]下边界外a - 1下边界a下边界内a 1上边界内b - 1上边界b上边界外b 1对于浮点数范围还要额外考虑精度。比如范围是 [0.01, 99.99]精度两位小数那么边界值要取 0.00、0.01、0.02、99.98、99.99、100.00。对于字符串长度 [m, n]长度 m-1、m、m1、n-1、n、n1内容类型纯数字、纯字母、字母数字混合、中文、特殊字符、空格、emoji提示emoji 的长度计算在不同语言里不一样Python 里一个 emoji 可能算 1 个字符但数据库里可能算 4 个字节。这个坑我在一个国际化项目里踩过导致长度校验在数据库层失败。Skill 里要明确标注字符集和编码。4.4 跑通第一个工作流全量回归单个 Skill 跑通之后就可以组合成工作流了。全量回归这个 L3 Skill 内部会依次调用环境巡检、用例生成、接口断言、日志解析、报告汇总。skill: 全量回归测试 steps: - call: 环境巡检 fail_action: 阻断并输出巡检报告 - call: 生成接口测试用例 input: 从接口文档目录读取 - call: 执行接口测试并断言 input: 上一步生成的用例 - call: 解析测试日志 input: 测试执行日志 - call: 汇总测试报告 input: 断言结果 日志摘要 output: 回归报告.md这个工作流跑一次大概 8 到 15 分钟取决于用例数量。我一般放在 CI 里每次合并到主分支自动触发。跑完的报告会包含总用例数、通过数、失败数、通过率、失败用例详情、异常日志摘要、耗时分布。5. 常见问题与排查技巧实录5.1 Skill 不触发或者乱触发这是最高频的问题。排查思路分三步。第一步检查触发描述里有没有明确的关键词如果描述太抽象Agent 匹配不上。第二步检查有没有anti-trigger没有的话 Agent 容易过度触发。第三步看 Agent 的日志确认它实际匹配到了哪个 Skill有时候是别的 Skill 抢了触发。我遇到过一个典型案例一个“生成测试报告”的 Skill 总是被“生成测试用例”抢触发原因是两个 Skill 的触发描述里都有“测试”这个词。解决办法是在用例 Skill 的 anti-trigger 里明确写“当用户要求生成报告、汇总结果时不要使用本 Skill”。5.2 输出格式不稳定Agent 生成的内容结构飘忽是第二大问题。根因通常是输出格式描述不够严格。我的做法是能用 JSON Schema 就用 JSON Schema不能用的话至少给一个完整的示例输出并且明确写“必须严格遵循示例的字段和顺序”。还有一个技巧是加校验步骤。在 Skill 的最后一步加一个自检让 Agent 检查自己的输出是否符合格式要求不符合就重新生成。这个自检步骤会增加一点耗时但能把格式错误率降到 5% 以下。5.3 执行超时或卡死有些 Skill 内部会调用外部命令或接口如果对方不响应整个 Skill 就卡住了。解决办法是在 Skill 里明确设置超时时间并且定义超时后的动作。场景建议超时超时动作文件读取10s报错并跳过接口调用30s重试 2 次仍失败则标记为失败命令执行60s终止进程并记录日志解析120s分片处理注意超时时间不要设得太短尤其是接口调用网络抖动很常见。我一般设 30s重试两次实际成功率比设 10s 不重试高很多。5.4 常见问题速查表问题现象可能原因排查动作解决方案Skill 不触发触发词不明确查看 Agent 匹配日志补充关键词和示例Skill 乱触发缺少 anti-trigger检查触发描述增加反例说明输出格式乱格式描述模糊对比输出与预期改用 JSON Schema 或加示例执行卡死无超时设置检查外部调用设置超时和重试结果不准规则不完整抽样验证补充边界规则耗时过长步骤冗余分析各步骤耗时合并或跳过非必要步骤5.5 独家避坑技巧第一个技巧Skill 要小步快跑。不要一次写一个巨大的 Skill先写最小可用版本跑通之后再逐步加规则。我早期写了一个 500 行的 Skill结果调试的时候根本不知道哪一步出了问题后来拆成 5 个小 Skill问题定位时间从半小时降到 5 分钟。第二个技巧给 Skill 加版本号。每次修改都在 SKILL.md 的 frontmatter 里加 version 字段这样出问题的时候可以快速回滚。我现在的习惯是任何 Skill 改动都先复制一份旧版本确认新版本稳定运行一周后再删旧的。第三个技巧定期清理僵尸 Skill。有些 Skill 一开始有用后来业务变了就没人用了。我每月跑一次调用统计三个月没被调用过的 Skill 直接归档。这样能保持 Skill 库的精简Agent 匹配的时候干扰也少。第四个技巧用真实数据测试 Skill。不要用构造的完美数据测试要用生产环境脱敏后的真实数据。我踩过的坑是Skill 在测试数据上跑得好好的一上真实数据就崩因为真实数据里有各种脏值、空值、超长值。后来我固定用一批真实脱敏数据做回归稳定性大幅提升。6. 几个让我印象深刻的实战案例6.1 一次线上故障的快速定位有天晚上收到告警某个核心接口错误率飙升。我第一时间跑了日志解析 Skill输入最近一小时的日志。Skill 输出显示95% 的错误都是同一个模式数据库连接超时。进一步看时间分布发现是从某个时间点开始突增的。顺着这个线索查下去发现是另一个服务在那个时候开始跑批量任务把连接池占满了。整个过程从收到告警到定位根因不到 10 分钟。如果没有日志解析 Skill光靠肉眼翻日志至少半小时起步。6.2 用例覆盖率从 60% 提到 92%有个老项目历史用例覆盖率一直上不去手工补用例效率极低。我用量例生成 Skill 把接口文档全部跑了一遍生成了 800 多条用例然后人工筛选去重最终补充了 300 多条有效用例。覆盖率从 60% 提到了 92%而且边界值覆盖比人工写的还全。这里有个经验Skill 生成的用例不要直接用一定要人工过一遍。Agent 有时候会生成一些逻辑上不可能的场景或者重复的场景。人工筛选的比例大概是 30% 到 40%也就是生成 100 条留 60 到 70 条。6.3 环境巡检拦住了一次事故有次上线前跑环境巡检发现某个配置项和基线不一致。查了一下是有人为了调试临时改了配置忘了改回来。如果没拦住上线后这个配置会导致部分功能异常。巡检 Skill 在这件事上直接体现了价值后来我把它的检查项从 12 项扩到了 20 项。7. 后续可以怎么扩展这套体系这套 Skill 体系目前主要覆盖测试开发场景但底层逻辑是通用的。我接下来打算往两个方向扩展。一个是往左延伸到需求分析做一个 Skill 把需求文档转成测试点这样从需求到用例的链路就打通了。另一个是往右延伸到线上监控做一个 Skill 定期巡检线上指标发现异常自动触发日志解析和根因分析。另外我还在试验多 Agent 协作的模式让不同的 Agent 分别负责不同的 Skill 层L1 和 L2 由一个 Agent 管L3 和 L4 由另一个 Agent 管通过消息传递协调。初步跑下来复杂工作流的稳定性比单 Agent 好一些但协调开销也上去了还在调优。如果你刚开始搭我的建议是先从 L1 和 L2 里挑三五个最高频的场景做起来跑顺了再往上加。不要一上来就搞大工作流容易挫败。等单个 Skill 用顺手了组合是水到渠成的事。最后分享一个我最近的小发现把 Skill 的触发描述写得越具体Agent 的表现越稳定。我有个 Skill 的触发描述从两行扩到了十行加了五个正例和三个反例触发准确率从 70% 提到了 95%。这个投入产出比非常高值得每个 Skill 都花时间打磨触发描述。
