1. 这套 Skill 体系到底解决了什么问题我日常跟 AI Agent 打交道的时间比跟真人同事说话的时间还长。从最早拿 Claude 做代码补全到后来用 Agent 跑自动化测试、写用例、做代码审查踩过的坑能填满一个中型会议室。今天要聊的这 25 个 Skill不是从哪个文档里抄来的清单是我自己每天在用的、经过实战检验的一套组合拳。先说清楚“Skill”在这个语境下指什么。你可以把它理解成给 AI Agent 装的一个个“技能插件”——每个 Skill 封装了一类特定任务的处理逻辑、提示词模板、工具调用链和输出规范。Agent 本身是个通用大脑Skill 就是让它变成专科医生的那套训练手册。没有 Skill 的 Agent就像一个刚毕业的医学生什么都知道一点但真让它上手术台手抖。装上 Skill 之后它才知道遇到什么症状该用什么工具、按什么流程走、输出什么格式的结果。这套东西适合谁如果你已经在用 Claude、Codex 或者任何 Agent 框架做开发、测试、运维相关的工作但总觉得“AI 给的答案差点意思”那这篇内容就是给你写的。如果你还没开始用 Agent但想看看这东西到底能干什么也可以从这里面挑几个场景先感受一下。我不讲虚的每个 Skill 都会说清楚它解决什么问题、怎么配、什么情况下会翻车。为什么是 25 个因为这是我实际高频使用的数量。网上那些“100 个 AI 工具”的清单大部分你点进去看一眼就关了。我筛选的标准很简单过去三个月里我每周至少主动调用一次。低于这个频率的要么是场景太窄要么是效果不稳定都被我砍掉了。剩下的这 25 个覆盖了测试开发、代码审查、文档生成、数据处理、环境诊断这几个核心场景。还有一个背景需要交代。现在 Agent 生态里有个很分裂的现象一边是各种框架层出不穷LangChain、AutoGPT、CrewAI 各领风骚另一边是真正落地的时候大家发现最靠谱的还是“一个强模型 一套精心设计的 Skill 库”。框架解决的是编排问题Skill 解决的是“每一步到底怎么做才对”的问题。我见过太多团队花两周搭了一套花哨的 Agent 工作流结果每个节点的输出质量都惨不忍睹最后还不如直接写个脚本调 API。问题就出在 Skill 层没做扎实。所以这套 Skill 体系的设计哲学就一句话把每个环节的输入输出标准化到极致让 Agent 在每一步都有明确的“操作手册”可循而不是靠模型自由发挥。下面我按场景分组把这 25 个 Skill 拆开讲。2. 测试开发场景的 8 个核心 Skill测试开发是我用得最多的场景也是 Skill 体系价值最明显的地方。原因很简单测试工作有大量重复性、模式化的任务但同时又需要一定的判断力纯脚本搞不定纯人工又太慢。Agent Skill 刚好卡在这个甜点区。2.1 用例生成 Skill从需求文档到可执行用例这个 Skill 我每天至少跑三次。输入是一段需求描述或者接口文档输出是结构化的测试用例包含用例编号、前置条件、操作步骤、预期结果、优先级。关键在于它的提示词模板里内置了一套“测试设计方法库”——等价类划分、边界值分析、场景法、错误推测Agent 会根据输入内容的特征自动选择合适的方法组合。配置上有个细节很重要必须给 Agent 提供你团队的用例模板格式。我试过让 Agent 自由发挥结果它生成的用例格式每次都不一样有的用表格有的用列表有的把前置条件写在步骤里。后来我把团队的标准模板作为 few-shot 示例塞进 Skill 的提示词里输出立刻稳定了。模板不需要很复杂一个包含 3 条示例用例的 Markdown 表格就够了。实测下来这个 Skill 生成的用例覆盖率大概能到人工的 70%-80%但速度是人工的 20 倍以上。我的用法是Agent 生成初稿人工做补充和调整。重点检查它容易漏的地方——异常流程、并发场景、数据依赖关系。这三类用例 Agent 经常考虑不全需要人工兜底。注意如果需求文档里有模糊表述比如“系统应该快速响应”Agent 会直接跳过或者生成一条很泛的用例。遇到这种情况先在输入里把模糊点明确化再喂给 Skill。2.2 接口自动化脚本生成 Skill这个 Skill 解决的是“用例写完了还要手动转成 pytest 脚本”的问题。输入是用例表格输出是可直接运行的 pytest 测试代码。它内置了几个关键约定使用 requests 库发请求、用 pytest.fixture 管理测试数据、用 assert 做断言、用 parametrize 做数据驱动。我在这个 Skill 上花了不少时间调优。最初的版本生成的代码能跑但风格很“AI”——变量命名随意、没有类型注解、异常处理缺失。后来我在提示词里加了一段“代码规范约束”明确要求变量名用蛇形命名、每个函数加 docstring、请求超时设为 10 秒、断言失败时输出响应体。改完之后生成的代码基本可以直接进代码库。有个坑要提前说Agent 生成的接口脚本默认不会处理鉴权。如果你的接口需要 token必须在 Skill 配置里加上鉴权信息的获取逻辑或者让 Agent 从环境变量里读。我一开始没注意这个生成的脚本跑一条挂一条排查了半天才发现是 401。2.3 测试数据工厂 Skill测试数据是测试开发里最烦人的事情之一。这个 Skill 的思路是你告诉它你要什么类型的数据、什么约束条件、多少条它生成对应的 SQL、JSON 或者 Python 工厂代码。比如“生成 100 条用户数据年龄在 18-65 之间邮箱唯一注册时间在过去一年内随机分布”它直接给你一段 Faker 库的代码或者 INSERT 语句。这个 Skill 的核心价值在于约束条件的表达。普通的随机数据生成工具只能做简单的范围限制但这个 Skill 能理解复合约束。比如“订单金额大于 100 且小于 1000且必须是 10 的倍数且不能和已有订单重复”它能生成满足所有条件的 SQL 或者 Python 代码。我常用的一个变体是“边界数据生成”——专门生成刚好在边界上的数据比如最大值、最小值、空字符串、超长字符串、特殊字符。这类数据在手工测试时很难构造但 Agent 几秒钟就能生成一批。2.4 失败用例智能分析 SkillCI 跑完一堆用例挂了以前要一个个看日志、定位原因。现在我把失败日志喂给这个 Skill它输出的是分类结果环境问题、数据问题、代码缺陷、用例本身有问题。每一条都附带判断依据和建议的下一步动作。这个 Skill 的提示词里内置了一套“失败模式库”是我从过去半年的失败记录里总结出来的。比如“Connection refused”大概率是服务没起来“AssertionError 且实际值为 None”大概率是数据没准备好“Timeout”可能是性能问题也可能是环境慢。Agent 根据日志关键词和上下文做匹配准确率我实测大概 85% 左右。剩下的 15% 怎么办人工复核。但这个 Skill 已经把最耗时的“分类”工作做完了人工只需要看它标记为“不确定”的那几条。整体排查效率提升非常明显。2.5 测试报告生成 Skill跑完测试要写报告这件事本身不难但很烦。这个 Skill 输入是测试结果数据通过率、失败列表、耗时统计输出是一份结构化的测试报告包含测试概况、失败分析、风险提示、建议。我在这个 Skill 上做了一个定制让它自动对比上一次的测试结果标出“新增失败”和“修复通过”的用例。这个对比逻辑其实很简单但手动做很费时间。Agent 做这个事情的准确率是 100%因为它就是做集合运算。报告的输出格式我建议用 Markdown方便直接贴到协作工具里。如果需要 Word 或者 PDF可以再加一个格式转换的 Skill但那是另一个话题了。2.6 环境诊断 Skill“在我机器上是好的”这句话的终结者。这个 Skill 输入是一段环境描述或者错误信息输出是可能的环境问题和排查步骤。它内置了常见环境的检查清单Python 版本、依赖包版本、环境变量、端口占用、文件权限、网络连通性。我把它做成了一个可执行的 Skill——Agent 不只是告诉你“检查 Python 版本”而是直接生成一段 shell 脚本去检查然后根据检查结果给出下一步建议。这个闭环很关键否则又变成了“AI 说了一堆我还得自己动手”。实测中这个 Skill 帮我解决过几次诡异的问题。有一次 CI 上某个用例间歇性失败本地永远复现不了。Agent 诊断后提示“检查 CI 环境的时区设置”一查果然是 UTC 和本地时区不一致导致的时间断言失败。2.7 代码覆盖率分析 Skill覆盖率报告出来了但“哪些没覆盖到的代码值得补测试”这个问题工具本身回答不了。这个 Skill 输入覆盖率数据和代码变更 diff输出的是“建议优先补测试的代码片段”列表按风险排序。排序逻辑综合考虑几个因素变更频率、代码复杂度、是否在核心路径上、是否有历史缺陷。这些数据 Agent 可以从 git log 和静态分析工具里获取。我试过让它纯粹根据覆盖率数字排序结果它建议给一堆 getter/setter 补测试毫无意义。加上变更频率和复杂度权重之后建议质量明显提升。2.8 测试用例评审 Skill写完用例之后让另一个 Agent 来评审。这个 Skill 输入是用例列表输出是评审意见遗漏的场景、冗余的用例、描述不清的步骤、预期结果不明确的地方。这个 Skill 的价值在于“第二双眼睛”。人工评审容易陷入思维定式Agent 没有这个问题。它会把每条用例都当成全新的内容来分析经常能发现一些“灯下黑”的问题。比如有一次它指出我的用例里所有异常场景都只测了一种异常类型建议补充其他异常分支。这个点我自己确实没注意到。3. 代码审查与质量保障的 6 个 Skill代码审查是另一个 Skill 体系能大幅提效的场景。人工审查代码一个 PR 看 15 分钟算快的复杂一点的半小时就没了。Agent 可以在 30 秒内完成初审人工只需要看它标记出来的重点。3.1 增量代码审查 Skill只审查本次变更的代码不翻旧账。这个 Skill 输入是 git diff输出是按严重程度分类的问题列表阻断性问题、建议修改、仅供参考。每个问题都附带具体的代码行号和修改建议。我配置这个 Skill 的时候加了一条规则必须给出修改后的代码示例。只指出问题不给方案的审查意见价值减半。Agent 一开始不太愿意给完整示例觉得“你自己改就行了”后来我在提示词里强制要求“每个建议必须附带可直接替换的代码块”输出质量立刻上了一个台阶。3.2 安全审查 Skill专门查安全问题的 Skill覆盖常见的注入、越权、敏感信息泄露、不安全的反序列化等。这个 Skill 的提示词里内置了 OWASP Top 10 的检查清单Agent 逐项对照。有个经验要分享安全审查 Skill 必须配合具体的代码上下文。只给一个函数Agent 很难判断是否有越权问题因为它不知道调用方的权限模型。我现在的做法是把相关的权限校验代码一起喂进去准确率明显提高。3.3 性能隐患识别 Skill这个 Skill 专门找性能问题N1 查询、循环里的数据库调用、没有分页的列表查询、大对象的内存拷贝、不必要的序列化。输入是代码片段输出是性能问题列表和优化建议。我印象最深的一次是它发现了一个“在循环里调用外部 API”的问题。那段代码逻辑上没问题测试也过了但生产环境数据量一大就超时。Agent 在审查时直接标红了建议改成批量调用。这种问题人工审查很容易漏因为单看代码逻辑是对的。3.4 代码风格统一 Skill团队代码风格不一致是常态。这个 Skill 输入代码片段输出是符合团队规范的改写版本。规范包括命名约定、注释格式、函数长度限制、导入顺序等。这个 Skill 的关键是规范要可配置。不同团队对“好风格”的定义不一样有的喜欢早返回有的喜欢嵌套 if。我把团队的规范写成一个配置文件Agent 读取后按规范改写。这样换团队或者换项目的时候只需要改配置不用改 Skill 本身。3.5 遗留代码理解 Skill接手老项目的时候最痛苦的是看不懂代码在干什么。这个 Skill 输入一段遗留代码输出是功能说明、调用关系图、潜在风险点、建议的重构方向。我最近用它分析了一个五年前的项目Agent 输出的功能说明比原文档还详细。它甚至推断出了几个“看起来没用但实际上有副作用”的函数——这些函数被注释掉了调用但内部有全局状态修改删掉会导致其他功能异常。这种隐藏逻辑人工排查要花很久。3.6 依赖升级影响分析 Skill依赖库要升级但不知道会影响哪些代码。这个 Skill 输入依赖变更信息和代码库输出是受影响的代码位置和风险评估。它的工作原理是分析新版本依赖的 API 变更然后在代码库里搜索所有调用点标记出可能受影响的代码。我试过用它分析一个主流框架的大版本升级它找出了 30 多处需要修改的地方人工排查至少需要半天。4. 文档与知识管理的 5 个 Skill写文档这件事大部分开发者都不喜欢但不得不做。这几个 Skill 的目标是让文档工作从“痛苦”变成“顺手”。4.1 接口文档生成 Skill输入代码里的路由定义和请求/响应模型输出标准的接口文档。支持 OpenAPI 格式也支持 Markdown 表格。我配置的是从 FastAPI 或 Flask 的代码里自动提取信息生成可直接导入 Postman 的文档。这个 Skill 有个很实用的变体从测试用例反推接口文档。有些老项目没有文档但有测试用例。Agent 可以从测试用例里提取出接口的输入输出格式生成文档。虽然不如从代码生成准确但比没有强。4.2 变更日志生成 Skill每次发版要写 changelog这个 Skill 输入 git log 和 PR 描述输出面向用户的变更日志。它会自动分类新功能、改进、修复、破坏性变更并且把技术性的 commit message 翻译成用户能看懂的语言。我给它加了一条规则破坏性变更必须放在最前面并且用加粗标注。这个细节很重要用户最关心的就是“这次升级会不会搞坏我的东西”。4.3 技术方案文档 Skill写技术方案的时候最怕漏掉关键章节。这个 Skill 输入需求描述和技术约束输出一份完整的技术方案模板包含背景、目标、方案对比、详细设计、风险评估、排期。它不是替你写方案而是给你一个结构化的框架你往里面填内容。我常用的方式是先让 Agent 生成框架然后我自己填充核心设计部分最后再让 Agent 检查有没有遗漏的章节。4.4 会议纪要整理 Skill会议录音转文字之后内容往往很散。这个 Skill 输入会议转录文本输出结构化的会议纪要讨论主题、关键结论、待办事项、负责人、截止时间。我实测下来它对“待办事项”的提取准确率很高但对“关键结论”的提取有时候会漏掉一些隐含的共识。我的做法是Agent 整理完之后人工快速过一遍补充它漏掉的结论。整体时间比人工整理节省 70% 以上。4.5 知识库问答 Skill把团队文档、Wiki、历史邮件都索引起来用户提问时 Agent 从知识库里找答案。这个 Skill 的核心是检索策略——先用关键词检索缩小范围再用语义检索精排最后让 Agent 基于检索结果生成答案。我踩过的坑是知识库里的内容质量参差不齐Agent 有时候会引用过时的文档。后来我在 Skill 里加了“文档时效性权重”越新的文档权重越高问题明显改善。5. 数据处理与运维的 6 个 Skill这类 Skill 的特点是“平时不用用的时候很救命”。数据处理和运维场景往往有严格的时间窗口Agent 的快速响应能力在这里价值最大。5.1 日志分析 Skill输入一大段日志输出是异常模式、错误统计、时间线、根因推测。我配置的是让它自动识别日志级别、提取错误堆栈、关联同一请求的多个日志条目。这个 Skill 最实用的功能是“异常聚类”——把相似的错误归为一类避免你在几百条错误里重复看同样的内容。实测下来一个包含 500 条错误的日志文件Agent 能在 10 秒内聚合成 5-8 个错误类别。5.2 SQL 生成与优化 Skill输入自然语言描述或者慢查询日志输出 SQL 语句或者优化建议。生成 SQL 的时候它会自动考虑索引使用、避免全表扫描、合理使用 JOIN。优化的时候它会分析执行计划建议加索引或者改写查询。我常用的场景是把一段复杂的业务逻辑描述给 Agent让它生成 SQL。准确率大概 80%剩下的 20% 需要人工调整。但即使需要调整也比从零开始写快很多。5.3 数据迁移脚本 Skill数据迁移是高风险操作写脚本的时候要特别小心。这个 Skill 输入源表和目标表的 schema输出迁移脚本包含数据转换逻辑、批量处理、回滚方案。我强制要求这个 Skill 的输出必须包含“干跑模式”——先不实际写入只打印将要执行的操作。这个模式救过我一次Agent 生成的迁移脚本里有一个字段映射错了干跑的时候发现了避免了一次生产事故。5.4 监控告警配置 Skill输入服务的关键指标和告警需求输出监控配置和告警规则。支持 Prometheus、Grafana 等主流工具的配置格式。这个 Skill 的价值在于“告警阈值建议”。它会根据历史数据分布建议合理的阈值——比如 P99 延迟超过 500ms 告警而不是拍脑袋定一个 1 秒。我试过让它分析一周的监控数据它给出的阈值建议比人工定的更合理误报率明显降低。5.5 故障排查 Skill线上出问题了输入错误信息和相关日志输出排查步骤和可能原因。这个 Skill 内置了一套“故障树”从症状出发逐层排查。我把它和监控系统做了集成告警触发时自动调用这个 Skill把排查建议发到值班群。值班同学反馈说有了这个 Skill 之后平均故障定位时间从 15 分钟降到了 5 分钟以内。5.6 容量评估 Skill输入当前资源使用数据和业务增长预期输出容量评估报告和扩容建议。它会计算当前资源能支撑多久、什么时候需要扩容、扩容多少合适。这个 Skill 的算法其实不复杂就是趋势外推加安全系数。但它的价值在于“自动化”——每个月自动跑一次生成报告不需要人工去拉数据做分析。6. 这些 Skill 怎么组合使用单独用某一个 Skill 已经能提效但真正的威力在于组合。我日常的工作流是这样的早上到公司先跑一遍“失败用例智能分析 Skill”看看昨晚 CI 的情况。如果有失败直接看 Agent 的分类结果环境问题找运维代码问题找开发数据问题自己处理。然后跑“增量代码审查 Skill”把昨天提交的 PR 过一遍标记出需要人工重点看的文件。下午写新功能的测试用例用“用例生成 Skill”出初稿人工补充边界场景再用“接口自动化脚本生成 Skill”转成代码。发版前用“变更日志生成 Skill”整理 changelog用“测试报告生成 Skill”出报告。这套流程跑顺之后我每天花在重复性工作上的时间减少了大概 60%。省下来的时间用来做更有价值的事情设计更复杂的测试场景、优化测试框架、研究新的测试方法。组合使用的时候有个原则每个 Skill 的输出格式要统一。比如用例生成 Skill 输出 Markdown 表格接口脚本生成 Skill 也接受 Markdown 表格作为输入这样两个 Skill 可以直接串联不需要人工转换格式。我在设计每个 Skill 的时候都会考虑“它的输出能不能直接喂给下一个 Skill”这个思路让整个体系的可组合性大大增强。还有一个经验不要试图用一个 Skill 解决所有问题。我见过有人写了一个巨大的提示词试图让 Agent 一次性完成“分析需求、生成用例、写脚本、跑测试、出报告”全流程。结果每个环节的质量都很差。正确的做法是把流程拆细每个 Skill 只做一件事做到极致然后通过组合来完成复杂任务。7. 实操中踩过的坑和排查技巧这部分是我最想分享的因为这些都是文档里不会写、只有实际用过才知道的东西。第一个坑Skill 的提示词太长会导致“指令遗忘”。我一开始把所有的规则、示例、约束都塞进一个提示词里结果 Agent 经常忘记后面的指令。后来我把 Skill 拆成“核心指令”和“补充规则”两层核心指令控制在 500 字以内补充规则按需加载。这样 Agent 的执行准确率明显提高。第二个坑Agent 对否定指令的理解不稳定。你告诉它“不要用某个库”它有时候还是会用。后来我改成正面指令“使用 requests 库不使用其他 HTTP 库”效果好很多。否定指令在提示词工程里一直是个难题能避免就避免。第三个坑输出格式的稳定性需要强制约束。我要求 Agent 输出 JSON它有时候会在 JSON 外面包一层解释文字。后来我在提示词里加了“只输出 JSON不要有任何其他内容”并且在代码里做了容错处理——如果解析失败用正则提取 JSON 部分。双保险。第四个坑Skill 的效果会随模型版本变化。同一个 Skill在模型升级之后效果可能变好也可能变差。我养成了习惯每次模型大版本更新后跑一遍回归测试看看哪些 Skill 的输出质量有变化。有变化的及时调整提示词。第五个坑不要过度依赖 Agent 的判断。有一次 Agent 把一个明显的代码缺陷标记为“仅供参考”我差点漏掉。后来我调整了策略Agent 标记为“阻断性”的问题必须人工确认标记为“建议”的问题可以抽样看。人工始终是最后一道防线。常见问题速查表问题现象可能原因排查方法Agent 输出格式不稳定提示词约束不够强加格式示例用“只输出...”句式Agent 漏掉关键步骤提示词太长导致遗忘拆分 Skill核心指令前置Agent 给出错误建议上下文不足补充相关代码或数据Skill 效果突然变差模型版本更新跑回归测试调整提示词Agent 拒绝执行任务指令有歧义或敏感改写指令明确意图8. 关于 Skill 体系的一些个人体会这套东西我用了大半年最大的感受是Agent 的能力上限取决于 Skill 的设计质量而不是模型本身。同一个模型配上精心设计的 Skill输出质量可以差出好几倍。我见过有人抱怨“AI 写的东西不能用”一看他的提示词就一句话“帮我写个测试用例”那能用才怪。另一个体会是Skill 需要持续迭代。我最早的用例生成 Skill 和现在的版本提示词改了十几版。每次遇到输出不理想的情况我就想“怎么改提示词能让它下次做对”然后改完跑一遍验证。这个过程很像训练一个新人——你不能指望说一次他就记住要反复纠正、反复强化。还有一点不要追求完美追求可用。有些 Skill 的输出准确率只有 70%但剩下 30% 人工改起来很快整体效率还是比纯人工高。如果非要追求 95% 的准确率可能需要投入大量时间调优边际收益递减。我的标准是只要 Agent 的输出能让我“改改就能用”而不是“重写一遍”这个 Skill 就值得保留。最后分享一个我最近在尝试的方向让 Skill 自己进化。具体做法是每次人工修改 Agent 的输出后把修改前后的对比作为反馈数据存下来定期用这些数据微调 Skill 的提示词。目前还在实验阶段但初步效果不错——几个高频 Skill 的准确率在两周内提升了 10% 左右。这套 Skill 体系不是终点是一个起点。随着 Agent 能力越来越强Skill 的设计空间也会越来越大。我现在已经在尝试一些更复杂的 Skill比如“自动修复测试失败”——Agent 不仅分析失败原因还直接生成修复代码并提交 PR。这个 Skill 目前准确率还不够高但方向是对的。等它成熟了再单独写一篇分享。