1. 为什么“每次从头教 AI”是个必须解决的问题如果你最近半年高频使用各类 AI 编程助手、写作助手或者 Agent 工具大概率经历过这种场景新开一个对话窗口AI 又变回了一张白纸。你不得不把项目背景、代码规范、命名习惯、输出格式、避坑要点重新讲一遍。讲完一轮十分钟过去了真正干活的时间反而被压缩。更糟的是每次讲的内容还不完全一样AI 的输出质量忽高忽低最后你干脆放弃回到手动改代码、手动写文档的老路上。这个问题的本质不是 AI 不够聪明而是你的经验没有被沉淀成可复用的资产。你脑子里的“这个项目用 pnpm 不用 npm”“接口返回统一包一层 Result”“日志必须带 traceId”“注释用中文但变量名用英文”这些隐性知识每次都要靠临时提示词重新灌输。提示词工程解决的是“单次对话怎么问得更好”但它解决不了“跨对话、跨项目、跨工具的经验复用”。我自己的转折点发生在去年底。当时同时维护三个项目一个是 Java 多商户商城一个是嵌入式数据采集脚本还有一个是给运营团队做的 AI 辅助内容工具。每天在三个 AI 窗口之间来回切换重复解释三套完全不同的规范整个人被拖得极其疲惫。后来我开始系统性地把常用规范、流程、检查清单写成结构化的 Skill 文件放在项目仓库里AI 工具直接读取。效果立竿见影新对话的冷启动时间从十分钟压缩到十几秒输出一致性大幅提升团队新人也能直接复用我沉淀下来的这套东西。所以这篇内容想聊的就是如何用 12 个开源 Skill 的思路把你脑子里的经验变成可复用、可版本管理、可跨工具迁移的资产。这里说的 Skill不是某个特定平台的专有功能而是一种通用的组织方式把“在什么场景下、按什么步骤、遵守什么约束、产出什么格式”写成结构化文档让 AI 能读懂、能执行、能复用。适合谁看适合所有已经在用 AI 干活、但还在靠临时提示词硬撑的人尤其是开发者、测试、技术写作者、以及需要批量产出内容的小团队。2. 先搞清楚 Skill 到底是什么和提示词有什么本质区别2.1 从“一次性提示词”到“可复用工作手册”的认知转变很多人第一次听到 Skill 这个词会下意识觉得“不就是把提示词存起来吗”。这个理解只对了一半。提示词是对话级的Skill 是资产级的。区别在于三个维度生命周期、结构化程度、可组合性。提示词的生命周期通常是一次对话最多是一个会话窗口。你关掉窗口它就散了。Skill 的生命周期是跟着项目走的它存在仓库里跟着代码一起提交、一起 review、一起迭代。结构化程度上提示词往往是一段自然语言而 Skill 通常包含元信息名称、适用场景、触发条件、执行步骤、约束条件、输出格式、示例。可组合性上提示词很难被另一个提示词调用但 Skill 可以被主流程引用比如一个“代码审查 Skill”可以调用“命名规范 Skill”和“日志规范 Skill”。打个生活化的比方提示词像是你每次做饭前临时跟厨师口述菜谱Skill 像是你把菜谱写成标准卡片贴在厨房墙上厨师照着做新来的厨师也能照着做而且卡片还能不断修订。2.2 Skill 的四个核心组成要素一个能真正跑起来的 Skill我实测下来至少要包含四块内容缺一块就会导致 AI 执行时“跑偏”。第一块是触发描述。用一两句话说明这个 Skill 在什么情况下被使用。比如“当用户要求生成单元测试时使用本 Skill”。这块写不清楚AI 就不知道该不该调用它。第二块是执行步骤。把你要它做的事拆成有序的、可验证的步骤。注意步骤要写成“动作 对象 约束”而不是模糊的“处理好”。比如“读取目标类的 public 方法列表为每个方法生成一个测试方法测试方法名遵循 methodName_condition_expectedResult 格式”。第三块是约束与禁忌。这是最容易被忽略但价值最高的一块。明确告诉 AI 什么不能做。比如“禁止使用 System.out.println 输出日志”“禁止在测试中使用 Thread.sleep”“禁止修改被测类的可见性”。第四块是输出格式与示例。给出一个期望输出的样例AI 的稳定性会提升一个档次。样例不用长但必须真实、可运行。2.3 为什么开源 Skill 比自己从零写更划算自己从零写 Skill 当然可以但成本不低。你要反复调试触发词、补充边界条件、验证输出格式一个成熟的 Skill 往往要迭代十几版。开源 Skill 的价值在于它已经经过了别人的实战检验你拿过来改改就能用省掉大量试错时间。更重要的是开源 Skill 往往覆盖了你没想到的场景。比如你可能只想到写“代码生成 Skill”但开源社区里还有“代码审查 Skill”“提交信息规范 Skill”“接口文档生成 Skill”“故障排查 Skill”。这些 Skill 组合起来才构成一个完整的工作流。单独一个 Skill 的价值有限成体系的 Skill 集合才是真正的资产。3. 12 个开源 Skill 的分类与选型思路3.1 按使用场景分成四大类我把常见的开源 Skill 按使用场景分成四类这样你在选型时能快速定位自己需要哪一类。类别典型 Skill解决的核心问题适合人群代码生产类代码生成、单元测试生成、重构建议减少重复编码统一代码风格后端、前端开发者质量保障类代码审查、静态检查规则、边界用例生成提前发现问题降低返工测试、技术负责人文档与协作类接口文档、提交信息规范、变更日志降低沟通成本沉淀知识技术写作者、团队负责人流程与运维类故障排查、部署检查清单、环境初始化标准化操作减少人为失误运维、SRE、全栈这个分类不是绝对的很多 Skill 会跨类。比如“提交信息规范 Skill”既属于文档协作也影响代码审查流程。分类的目的是帮你在选型时有个抓手先确定自己最痛的场景再从对应类别里挑。3.2 选型时优先看这三个指标开源 Skill 质量参差不齐我踩过几次坑之后总结出三个优先看的指标。第一个是触发条件是否明确。好的 Skill 会写清楚“什么时候用、什么时候不用”。如果一个 Skill 的触发描述含糊其辞比如“用于提升代码质量”那它大概率不好用因为 AI 根本判断不了该不该调用。第二个是约束是否具体。约束越具体AI 执行越稳定。比如“禁止使用魔法数字”就比“注意代码规范”强得多。你可以快速扫一眼约束部分如果全是空话直接跳过。第三个是是否有真实示例。示例是检验 Skill 质量的试金石。一个 Skill 如果连一个完整的输入输出示例都给不出来说明作者自己可能都没跑通过。3.3 组合使用比单个 Skill 威力大得多单独用一个 Skill效果是线性的。组合使用效果是指数级的。我自己的常用组合是代码生成 Skill 命名规范 Skill 单元测试 Skill 提交信息 Skill。写一个新功能时先让代码生成 Skill 产出骨架命名规范 Skill 自动校正变量和方法名单元测试 Skill 补齐测试最后提交信息 Skill 生成规范的 commit message。整条链路下来我只需要做最终 review效率提升非常明显。组合的关键是Skill 之间不能冲突。比如两个 Skill 对日志格式的要求不一致AI 就会左右为难。解决办法是抽出一个“基础规范 Skill”把命名、日志、异常处理这些底层约定统一放进去其他 Skill 引用它。这样改一处全局生效。4. 从零搭建你的第一个 Skill完整实操流程4.1 准备工作确定场景和边界动手写之前先花十分钟想清楚三件事这个 Skill 解决什么具体问题、在什么条件下触发、产出什么。我建议你拿一张纸写下这三个问题的答案。如果写不出来说明场景还没想清楚先别急着写。以“生成单元测试”为例。具体问题是“新写的 Service 方法缺少测试手动写太慢”。触发条件是“当用户要求为指定类生成单元测试时”。产出是“一个可运行的测试类文件覆盖所有 public 方法包含正常和异常用例”。边界也要明确。比如“只处理 Service 层不处理 Controller”“只生成 JUnit 5 风格的测试”“不修改被测类”。边界越清晰Skill 越稳定。4.2 编写 Skill 文件的标准结构我习惯用 Markdown 写 Skill因为可读性好AI 也容易解析。一个标准结构如下# Skill 名称 ## 触发条件 描述什么时候使用本 Skill。 ## 前置检查 执行前需要确认的事项。 ## 执行步骤 1. 第一步做什么 2. 第二步做什么 3. ... ## 约束与禁忌 - 禁止... - 必须... ## 输出格式 描述期望的输出结构。 ## 示例 给出一个完整的输入输出示例。这个结构不是死的你可以根据场景增删。但“触发条件”“执行步骤”“约束与禁忌”这三块建议保留它们是 Skill 能跑起来的最小集合。4.3 参数与约束的写法越具体越稳定写约束时我总结了一个原则能用数字就用数字能用枚举就用枚举能用否定句就用否定句。比如“日志要详细”就是模糊的。“日志必须包含 traceId、userId、方法名、耗时格式为 [traceId][userId] methodName costxxms”就是具体的。再比如“注意异常处理”是模糊的。“捕获异常后必须记录 error 级别日志并抛出业务异常 BusinessException禁止吞掉异常”就是具体的。否定句特别有用因为 AI 对“禁止”的敏感度高于“应该”。你可以把踩过的坑都写成禁止项。比如“禁止在循环中查询数据库”“禁止使用 select *”“禁止在测试中使用真实网络请求”。这些禁止项就是你经验的直接沉淀。4.4 验证 Skill 是否生效的三种方法写完 Skill 不代表就能用必须验证。我常用三种方法。第一种是正向测试。给一个符合触发条件的输入看 AI 是否按步骤执行、输出是否符合格式。比如给一个 Service 类要求生成测试看它是否覆盖了所有 public 方法。第二种是反向测试。给一个不符合触发条件的输入看 AI 是否拒绝调用。比如给一个 Controller 类要求生成测试如果 Skill 边界写的是“只处理 Service”那它应该提示不适用。第三种是边界测试。给一个极端输入看 AI 是否稳定。比如给一个空类、一个只有私有方法的类、一个方法名超长的类。边界测试最容易暴露 Skill 的漏洞。提示验证时建议固定 AI 工具的版本和参数。不同版本对同一 Skill 的执行效果可能差异很大固定环境才能判断问题出在 Skill 本身还是工具变化。5. 12 个 Skill 的落地细节与避坑经验5.1 代码生产类 Skill 的实操要点代码生产类 Skill 最容易上手但也最容易产出“看起来对、跑起来错”的代码。我的经验是在 Skill 里强制要求 AI 先输出接口签名和调用关系再输出实现。这样你能在实现之前就发现设计问题。另外代码生成 Skill 一定要绑定项目的实际依赖版本。比如你的项目用 Spring Boot 3.x那 Skill 里就要写明“使用 Jakarta 命名空间禁止使用 javax”。这个细节不写AI 很可能给你生成旧版本的代码编译直接报错。还有一个坑是过度生成。AI 很容易帮你生成一堆你用不上的方法、配置、注释。解决办法是在约束里加一条“只生成被明确要求的内容禁止添加未要求的辅助方法”。这条加上之后输出会干净很多。5.2 质量保障类 Skill 的检查清单设计质量保障类 Skill 的核心是检查清单。清单设计得好AI 就是一个不知疲倦的审查员设计得差AI 就是一个只会说“看起来不错”的应声虫。我的清单设计原则是分层。第一层是硬性规则比如“是否有未处理的异常”“是否有硬编码的密钥”“是否有 SQL 拼接”。这些是必须报错的。第二层是建议规则比如“方法是否过长”“是否有重复代码”“命名是否清晰”。这些是提示性的。第三层是上下文规则比如“这个改动是否影响其他模块”“是否需要更新文档”。这些需要结合项目背景判断。分层的好处是AI 输出时能区分严重程度你 review 时也能按优先级处理。我见过很多审查 Skill 把所有问题混在一起输出结果真正严重的问题被淹没在几十条建议里。5.3 文档与协作类 Skill 的格式统一技巧文档类 Skill 最大的价值是格式统一。团队里每个人写文档的风格都不一样有人喜欢先写背景有人喜欢先写结论。用 Skill 把格式固定下来文档的可读性会大幅提升。我的做法是在 Skill 里定义一个模板模板包含固定的章节和每章的字数范围。比如“背景不超过 200 字”“方案对比至少列出三个维度”“结论放在最前面”。AI 按模板填充产出自然统一。提交信息 Skill 也是同理。我要求 commit message 必须包含“类型、范围、简述、详情、关联 issue”五部分类型从 feat、fix、docs、refactor、test、chore 里选。这样生成的提交历史非常清晰回溯问题时效率很高。5.4 流程与运维类 Skill 的安全边界流程与运维类 Skill 涉及实际操作安全边界必须卡死。我的原则是只读操作可以自动化写操作必须人工确认。比如“环境初始化 Skill”可以自动检查依赖版本、生成配置文件、输出检查报告但涉及删除文件、修改系统配置、重启服务的操作必须停下来等人工确认。这条规则我写进了所有运维类 Skill 的约束里避免 AI 误操作。故障排查 Skill 也要注意。它应该输出“排查步骤和可能原因”而不是直接执行修复命令。因为故障现场往往很复杂AI 的判断不一定准确直接执行可能让问题更糟。让 AI 做分析助手人做决策者这个分工比较稳妥。6. 常见问题与排查技巧实录6.1 Skill 不生效的五个典型原因现象可能原因排查方法AI 完全不调用 Skill触发条件描述不清检查触发描述是否包含具体场景关键词AI 调用了但输出跑偏执行步骤太模糊把步骤拆成可验证的动作输出格式不稳定缺少输出示例补一个完整的输入输出示例多个 Skill 冲突约束互相矛盾抽出基础规范 Skill 统一底层约定换工具后失效工具解析方式不同用纯 Markdown避免平台专有语法这张表是我踩坑之后整理的基本覆盖了八成以上的问题。遇到 Skill 不生效先按表排查比盲目改内容效率高得多。6.2 我踩过的三个印象深刻的坑第一个坑是触发词太宽泛。我早期写了一个“代码优化 Skill”触发条件写的是“当代码需要优化时”。结果 AI 几乎每次写代码都会调用它然后自作主张地改我的代码结构。后来我把触发条件改成“当用户明确要求优化指定方法时”问题才解决。教训是触发条件要窄宁可手动触发不要自动误触发。第二个坑是约束写成了建议。我写过“建议使用 final 修饰不可变变量”结果 AI 时用时不甩。改成“必须使用 final 修饰不可变变量”之后执行率明显提升。AI 对“建议”和“必须”的敏感度差异很大关键约束一定要用强语气。第三个坑是示例太长。我曾经在一个 Skill 里放了一个两百行的示例想着“示例越详细越好”。结果 AI 把示例当成了模板不管什么输入都往示例结构上套反而限制了灵活性。后来我把示例压缩到二十行以内只保留关键结构AI 的表现反而更自然。6.3 让 Skill 持续迭代的两个习惯Skill 不是写完就完了它需要跟着项目一起进化。我保持两个习惯。第一个是每次踩坑就补一条约束。比如某次 AI 生成的代码用了废弃的 API我就在约束里加一条“禁止使用 Deprecated 标注的 API”。日积月累Skill 越来越贴合项目实际。第二个是每月 review 一次 Skill 集合。项目在变依赖在升级有些约束可能已经过时。我会花半小时扫一遍所有 Skill删掉过时的合并重复的补充新场景的。这个习惯让我的 Skill 集合始终保持精简有效。7. 把 Skill 变成团队资产协作与版本管理7.1 用 Git 管理 Skill 的目录结构Skill 既然是资产就应该像代码一样用 Git 管理。我推荐的目录结构是这样的skills/ ├── base/ │ ├── naming.md │ ├── logging.md │ └── exception.md ├── codegen/ │ ├── service.md │ └── controller.md ├── review/ │ ├── security.md │ └── performance.md └── docs/ ├── api.md └── commit.mdbase 目录放基础规范其他目录放具体场景 Skill。具体 Skill 通过引用 base 里的规范来保持一致性。这样改一处基础规范所有引用它的 Skill 都跟着更新。7.2 团队协作中的 Skill review 机制Skill 进仓库前应该像代码一样 review。我团队的 review 清单有三条触发条件是否明确、约束是否可验证、示例是否真实可运行。三条都过才能合并。review 的时候特别关注冲突。两个人可能写了两个 Skill对同一个问题有不同要求。比如一个要求日志用英文一个要求用中文。这种冲突必须在合并前解决否则 AI 执行时会随机选一个输出不稳定。7.3 新人如何快速上手现有 Skill 集合新人入职时我通常让他先读 base 目录下的基础规范然后挑一个具体 Skill照着示例跑一遍。跑通之后让他尝试修改一个约束观察输出变化。这个过程能让他快速理解 Skill 的运作方式比看文档快得多。我还会让新人做一件事用现有 Skill 完成一个真实的小任务。比如用代码生成 Skill 写一个简单的 CRUD 接口用审查 Skill 检查一遍用提交信息 Skill 提交。走完整个流程他就基本掌握了这套工具。8. 从 Skill 到工作流下一步可以怎么扩展单个 Skill 用熟了之后自然会想把它串成工作流。我目前的做法是用一个“主控 Skill”来编排。主控 Skill 不干具体活只负责判断当前处于哪个阶段、该调用哪个子 Skill、子 Skill 的输出如何传递给下一个。比如一个完整的“新功能开发工作流”是这样的需求分析 Skill 产出接口设计代码生成 Skill 产出实现单元测试 Skill 补齐测试审查 Skill 做检查提交信息 Skill 生成 commit。每个环节的产出都是下一个环节的输入。整条链路跑下来我只需要在关键节点做决策。这个方向还在持续打磨目前最大的挑战是错误传递。如果第一个 Skill 的输出有问题后面所有环节都会跟着错。我的应对办法是在每个环节加一个轻量校验比如代码生成后先编译一次编译不过就停下来。校验通过再进入下一环节。另外Skill 的跨工具迁移也值得关注。不同 AI 工具对 Skill 的解析能力不一样有的支持引用有的只支持单文件。我的做法是尽量用纯 Markdown 写避免平台专有语法这样换工具时迁移成本最低。实测下来结构清晰的 Markdown Skill 在主流工具里都能跑只是触发方式可能需要微调。最后分享一个我最近在试的小技巧把 Skill 的约束部分单独抽出来做成一个“检查清单 Skill”在提交代码前跑一遍。这个清单不生成任何内容只做检查输出“通过/不通过 原因”。跑了几次之后发现它抓出的问题比人工 review 还多尤其是那些“大家都知道但总是忘”的细节。这个思路你可以在自己的项目里试试成本很低收益挺明显。