1. 从agent-skills这个标题能读出什么第一次看到agent-skills这个仓库名我的直觉是这不是又一个提示词大全而是一套把 AI coding agent 当新同事来培养的技能体系。项目正文和关键词都是空的但热搜词已经把方向交代得很清楚了——agent-skills、AI coding agents、skills CLI、Claude Code、test-driven-development这几个词串起来讲的其实是一件事怎么给 AI 编码代理装上一套可复用、可版本管理、可组合的工作技能包。我先把结论摆出来agent-skills这类项目的核心价值不在于它内置了多少条提示词而在于它定义了一种把人怎么干活沉淀成agent 怎么干活的工程化范式。传统做法是每次开新会话都手动贴一大段上下文或者把规则塞进CLAUDE.md、.cursorrules这类全局文件里越堆越乱。而 skills 的思路是把能力拆成一个个独立单元按需加载、按场景触发这跟软件工程里高内聚、低耦合的模块化思想是一脉相承的。这篇文章适合三类人看一是已经在用 Claude Code、Cursor、各类 CLI agent但总觉得它不够懂我的开发者二是想把团队内部的编码规范、测试流程、发布检查清单固化下来让 agent 自动遵守的技术负责人三是刚接触 AI coding agent想搞清楚skills 到底解决什么问题的新手。我会从概念拆解讲到落地实操中间穿插我自己踩过的坑尽量让你看完就能动手搭一套自己的 skills 库。需要先说明一点agent-skills这个仓库本身的具体文件结构我没有拿到完整的一手资料所以下文涉及目录组织、CLI 命令的部分是基于当前 AI coding agent 生态里 skills 机制的通用实践做的合理还原。你在实际使用时以你所用工具的官方文档为准但底层的设计逻辑是相通的。2. skills 和 prompt、rules 到底差在哪很多人第一次接触 skills会下意识觉得这不就是高级点的提示词吗。我一开始也这么想直到被现实教育了几次才明白这三者的定位完全不同混用会出大问题。2.1 三种给 agent 下指令的方式对比我把 prompt、rules、skills 放在一张表里对比你一眼就能看出差异维度Prompt提示词Rules规则文件Skills技能包生命周期单次会话长期常驻按需加载触发方式手动输入全局生效场景/关键词触发内容粒度一个任务通用约束一套完整工作流可复用性低靠复制粘贴中容易膨胀高模块化组合典型载体聊天框CLAUDE.md / .cursorrules独立目录 元数据适合场景临时问答编码风格、语言偏好TDD 流程、代码审查、发布检查关键差异在触发方式和内容粒度。Prompt 是你主动喂给它的rules 是它一直记着的而 skills 是它知道有这么个技能需要的时候自己调用。这个区别听起来小实际影响巨大。2.2 为什么全局 rules 文件迟早会失控我见过太多项目CLAUDE.md写到三四百行里面塞了编码规范、Git 提交格式、测试要求、部署流程、甚至还有不要用某个库这种历史遗留禁令。问题在于agent 每次会话都要把这坨东西全部读一遍token 消耗大不说规则之间还会互相干扰。比如你写了优先用函数式写法又写了复杂逻辑用类封装agent 到底听谁的skills 的解法是把这些拆开。TDD 流程是一个 skill代码审查是一个 skill发布检查是另一个 skill。平时它们躺在磁盘上不占上下文只有当任务匹配到对应场景时才被加载进来。这就像你公司里的员工不需要每个人都会做财务报表但财务同事得会需要的时候找他就行。2.3 skills 的元数据才是灵魂一个 skill 通常由两部分组成元数据metadata和正文内容body。元数据一般包含名称、描述、触发条件正文才是具体的操作步骤。这里有个设计精髓——agent 平时只加载元数据判断这个技能跟当前任务相关吗相关才把正文读进来。这个机制叫渐进式披露progressive disclosure。打个比方你书架上有一百本书你不需要全部读完才知道哪本讲的是做菜——你看书脊上的书名就够了需要的时候再抽出来翻。skills 的元数据就是书脊正文就是书的内容。这个设计直接决定了 skills 能不能规模化——如果每个 skill 都要全量加载那跟堆 rules 没区别。提示写 skill 描述时触发条件要写得具体。用于代码相关任务这种描述等于没写agent 根本判断不出来。应该写成当用户要求编写新功能、修复 bug 或重构代码时使用强制先写测试再写实现。3. 一个 skill 的内部结构长什么样搞清楚了为什么要有 skills接下来看一个 skill 具体怎么组织。这部分我会给出一套可以直接抄的目录结构和文件模板。3.1 目录组织一个 skill 一个文件夹通用的做法是每个 skill 独立成一个目录目录名用短横线连接的英文小写比如test-driven-development、code-review、release-checklist。目录里至少有一个主文件通常叫SKILL.md或者skill.md有些实现还会配metadata.json、examples/、scripts/等辅助内容。一个典型的仓库结构大概是这样agent-skills/ ├── skills/ │ ├── test-driven-development/ │ │ ├── SKILL.md │ │ └── examples/ │ │ └── red-green-refactor.md │ ├── code-review/ │ │ └── SKILL.md │ ├── release-checklist/ │ │ ├── SKILL.md │ │ └── scripts/ │ │ └── check-version.sh │ └── debugging/ │ └── SKILL.md ├── README.md └── package.json为什么用目录而不是单文件因为一个成熟的 skill 往往需要配套资源——示例、脚本、模板、参考文档。单文件塞不下硬塞会让正文臃肿违背渐进式披露的初衷。目录结构让主流程和辅助材料分离agent 先读主流程需要细节时再去看 examples。3.2 SKILL.md 的头部元数据怎么写主文件的开头通常是 YAML frontmatter用来声明元数据。格式大致如下--- name: test-driven-development description: 当需要编写新功能、修复缺陷或重构现有代码时使用。强制遵循红-绿-重构循环先写失败测试再写最小实现最后重构。 version: 1.0.0 tags: - testing - workflow - quality ---这里每个字段都有讲究。name要唯一且语义清晰别用skill1、helper这种名字。description是最关键的它决定了 agent 能不能在正确的时机加载这个 skill——要写清楚什么时候用和用来干什么而不是这是什么。tags方便分类检索当 skills 多起来之后靠标签筛选比靠记忆靠谱得多。3.3 正文部分把工作流拆成可执行步骤元数据下面是正文也就是 skill 真正的内容。我的经验是正文要写成可执行的流程而不是知识科普。对比一下差的写法测试驱动开发是一种先写测试再写代码的开发方法它能提高代码质量……这是百科词条好的写法1. 阅读需求列出所有需要验证的行为2. 为第一个行为编写测试运行确认失败3. 编写最小实现让测试通过4. 重构保持测试绿色5. 重复直到所有行为覆盖。这是操作手册agent 需要的是后者。它不需要你告诉它 TDD 的历史和意义它需要知道下一步做什么。所以正文里应该大量使用有序列表、明确的判断条件、具体的命令示例。注意正文里不要写你应该考虑……这种模糊表述。agent 会把它当成可选建议而忽略。要写必须、禁止、如果 X 则执行 Y这种确定性指令。4. 用 skills CLI 把技能装进工作流光有 skill 文件还不够得让 agent 能找到它们、加载它们。这就轮到skills CLI出场了。不同工具的 CLI 命令不一样但核心动作就那么几个安装、列出、启用、禁用、更新。4.1 安装与初始化假设你已经有了一个 skills 仓库第一步是把它接入你的 agent 环境。常见的做法是通过 CLI 把 skills 目录链接到 agent 的配置路径下。命令形态大概是# 初始化 skills 配置 skills init # 从本地目录安装 skills skills install ./agent-skills/skills # 或者从远程仓库安装 skills install gitgithub.com:yourname/agent-skills.gitinit会在你的用户目录下创建一个配置文件夹通常叫.skills或.agent-skills里面记录已安装的 skills 清单和启用状态。install则是把 skill 文件复制或软链接进去。我强烈建议用软链接而不是复制。原因很简单你在开发 skill 的时候会反复修改软链接能让改动立即生效不用每次改完都重新 install。很多 CLI 默认就是软链接如果你的不是可以手动建。4.2 列出、启用与禁用skills 装多了之后管理就成了问题。CLI 一般提供这几个命令# 列出所有已安装的 skills skills list # 查看某个 skill 的详情 skills info test-driven-development # 临时禁用某个 skill skills disable code-review # 重新启用 skills enable code-review这里有个实战经验不要一次性启用所有 skills。启用的 skill 越多agent 每次判断该用哪个的负担越重而且容易误触发。我的做法是保持 5 到 8 个核心 skill 常驻启用其余的按项目需要临时开。比如做前端项目时启用component-design做后端时启用api-design两者很少同时需要。4.3 版本管理与团队协作skills 是代码就该用代码的方式管理。把 skills 仓库纳入 Git每个 skill 的改动走 PR 流程版本号遵循语义化版本。这样团队里谁改了哪个 skill、为什么改都有迹可循。更进一步可以在 CI 里加一道检查skill 的元数据格式是否合法、description 是否为空、引用的脚本是否存在。这些检查能避免skill 写了一半就提交的情况。我见过有人提交了一个 description 是空的 skill结果 agent 永远不加载它排查了半天才发现是元数据的问题。提示团队协作时给每个 skill 指定一个 owner。skill 不像普通代码那样有明确的调用方出了问题往往没人认领。指定 owner 之后谁负责维护、谁负责 review 就清楚了。5. 用 TDD skill 跑通第一个完整案例理论讲了一堆不如动手跑一遍。我拿test-driven-development这个 skill 做例子完整走一遍从写 skill到agent 按 skill 干活的流程。选它是因为 TDD 流程边界清晰、步骤固定最适合作为第一个 skill 来练手。5.1 为什么 TDD 特别适合做成 skillTDD 有三个特点让它成为 skill 的理想候选流程固定红-绿-重构循环、容易验证测试通过与否是客观的、agent 容易跑偏不强制的话它总想先写实现。这三点决定了它值得被固化成一个 skill——你不希望每次都要口头提醒 agent先写测试你希望它自动就这么干。而且 TDD 的红-绿-重构循环天然适合拆成有序步骤agent 执行起来不容易乱。相比之下设计一个优雅的架构这种任务就很难做成 skill因为步骤不固定、判断标准主观。5.2 把 TDD 流程写成可执行步骤下面是我实际在用的 TDD skill 正文你可以直接参考## 执行流程 1. **理解需求**阅读任务描述列出所有需要验证的行为点每个行为点写成一句话。 2. **写第一个测试**选择最简单的行为点编写测试用例。测试必须能独立运行。 3. **运行测试确认失败**执行测试命令确认测试失败且失败原因是功能未实现而非语法错误。 4. **写最小实现**只写让当前测试通过的最少代码不要提前实现其他行为。 5. **运行测试确认通过**执行测试命令确认变绿。 6. **重构**在不改变行为的前提下优化代码结构每次重构后重新运行测试。 7. **重复 2-6**直到所有行为点都被覆盖。 ## 禁止事项 - 禁止在写测试之前编写任何实现代码。 - 禁止一次编写多个测试必须逐个推进。 - 禁止为了让测试通过而修改测试断言。 - 禁止跳过确认失败这一步。注意第 3 步和第 5 步——确认失败和确认通过是两个独立的验证动作。很多人包括 agent会偷懒写完测试直接写实现然后跑一次测试看通过就完事。但如果不确认测试真的失败过你根本不知道这个测试有没有在验证正确的东西。我踩过这个坑写了个测试跑出来是绿的以为功能没问题结果发现测试断言写错了根本没测到目标行为。5.3 agent 实际执行时的观察与调整把上面这个 skill 启用之后我让 agent 实现一个字符串反转函数。它的执行过程大致是先列出行为点空字符串、单字符、多字符、含特殊字符然后写第一个测试reverse() 运行确认失败因为函数还不存在写最小实现return 测试通过。接着写第二个测试发现return 不满足改成return str通过。第三个测试才真正实现反转逻辑。这个过程看起来很笨但正是 TDD 的精髓——每一步都只做刚好够的事。agent 在没有 skill 约束时往往会一次性写出完整实现然后补一堆测试测试全绿但你没发判断测试到底有没有覆盖边界情况。实测下来有两个调整点一是 agent 有时会跳过确认失败直接写实现需要在 skill 里把这一步标成必须二是重构阶段 agent 容易过度发挥把无关代码也改了可以在 skill 里限定只重构当前测试涉及的代码。6. 让 skills 真正好用的几个关键设计跑通一个案例不难难的是让 skills 体系长期可用、越用越顺手。这部分我分享几个从实践中总结的设计原则都是踩过坑之后才想明白的。6.1 单一职责一个 skill 只干一件事我最早写的 skill 叫coding-best-practices里面塞了命名规范、测试要求、错误处理、日志格式、性能建议……结果 agent 加载之后执行到一半就忘了后面的要求。原因很简单内容太长超出了有效注意力范围。后来我把它拆成了naming-conventions、error-handling、logging-standards三个独立 skill每个都短小精悍效果立刻好转。这跟写函数是一个道理——一个函数只做一件事一个 skill 也只解决一类问题。判断标准是如果你能用一句话说清这个 skill 干什么且这句话里没有和字那它就够单一了。6.2 触发条件要窄不要宽skill 的 description 决定了它什么时候被加载。写得太宽比如用于所有编程任务那它几乎每次都会被加载等于常驻失去了按需加载的意义。写得太窄比如用于处理 UTF-8 编码的 CSV 文件中的日期字段那它几乎永远不会被触发。我的经验是从窄开始逐步放宽。先写一个具体的触发场景用一段时间发现该触发的时候没触发再放宽一点。反过来如果发现它老在不该出现的时候冒出来就收紧。这个调优过程跟调搜索引擎的关键词是一个逻辑。6.3 给 skill 配反例这是我觉得最有价值的一条经验在 skill 里明确写出不要做什么。agent 对禁止类指令的遵守度往往比应该类指令更高。比如 TDD skill 里写禁止在写测试之前编写实现代码比写应该先写测试有效得多。更进一步可以配一个anti-patterns.md列出常见的错误做法和对应的正确做法。比如错误做法正确做法一次写 5 个测试再一起跑一次写 1 个测试跑通再写下一个测试失败就改断言测试失败就改实现实现写完再补测试测试写完再写实现这种对照表 agent 理解起来特别快比大段文字描述管用。6.4 定期清理僵尸 skillskills 用久了会积累一堆不再需要的。有的是项目结束了有的是被更好的 skill 替代了有的是当初写了一半就没再用过。这些僵尸 skill不会主动消失反而会在 agent 判断时造成干扰。我的做法是每个季度过一遍 skills 列表问三个问题过去三个月用过吗还有项目依赖它吗有更新的 skill 能替代它吗三个都是否就归档。归档不是删除移到archived/目录万一以后要用还能找回来。7. 常见问题与排查思路最后这部分我把实际使用中遇到的高频问题整理出来附上排查思路。这些问题大多不是bug而是设计没想清楚导致的。7.1 skill 不触发怎么办最常见的症状是明明写了 skillagent 就是不用。排查顺序如下先看元数据格式。description 是不是空的YAML 语法有没有错缩进对不对YAML 对缩进极其敏感一个 tab 和空格的混用就能让整个 frontmatter 解析失败而 agent 不会报错只会默默忽略这个 skill。再看触发条件。把 description 读一遍问自己如果我是 agent看到当前任务会认为这个 skill 相关吗如果答案不确定那就是 description 写得太模糊。改成更具体的场景描述。最后看是否启用。skills list确认一下状态有时候是安装时没启用或者被别的操作禁用了。7.2 skill 之间冲突怎么处理两个 skill 给出矛盾指令时agent 的行为会变得不可预测。比如一个 skill 说优先用函数式写法另一个说复杂逻辑用类封装。这种情况的根源往往是职责边界没划清。解法是明确优先级。可以在 skill 的元数据里加一个priority字段或者在项目级的配置里声明加载顺序。但更根本的做法是消除重叠——如果两个 skill 都在管代码风格那它们本来就该合并或者重新划分边界。7.3 skill 内容太长导致效果下降前面提过skill 正文太长会稀释注意力。判断标准是如果一个 skill 的正文超过 200 行就该考虑拆分了。拆分维度可以是流程阶段写测试 / 跑测试 / 重构也可以是场景新功能 / 修 bug / 重构。拆分之后用一个入口 skill来串联。入口 skill 只负责判断当前处于哪个阶段然后指向对应的子 skill。这样 agent 每次只加载当前阶段需要的内容注意力集中执行质量更高。7.4 怎么衡量 skill 有没有效果这个问题很多人忽略但很重要。我的衡量方式是看三个指标返工率agent 产出需要人工修改的比例、token 消耗同样任务消耗的上下文量、一致性同类任务产出是否稳定。好的 skill 应该让返工率下降、token 消耗下降、一致性上升。如果某个 skill 加上去之后返工率反而涨了那说明它的指令有问题要么太模糊要么和实际工作流不匹配。这时候别硬撑回去改 skill改到指标改善为止。提示刚开始用 skills 时别追求一步到位。先写一个最粗糙的版本用起来根据实际表现迭代。skills 是长出来的不是设计出来的。我现在的核心 skills 都改过十几版每一版都是被实际问题逼出来的。这套东西说到底核心就一句话把你自己干活的经验翻译成 agent 能执行的步骤然后用工程化的方式管理起来。它不难但需要耐心——耐心观察 agent 哪里做得不对耐心把纠正措施沉淀成 skill耐心等它慢慢变好。等你攒够一套顺手的 skills会发现跟 AI 协作的效率完全是另一个量级。
1. 从agent-skills这个标题能读出什么第一次看到agent-skills这个仓库名我的直觉是这不是又一个提示词大全而是一套把 AI coding agent 当新同事来培养的技能体系。项目正文和关键词都是空的但热搜词已经把方向交代得很清楚了——agent-skills、AI coding agents、skills CLI、Claude Code、test-driven-development这几个词串起来讲的其实是一件事怎么给 AI 编码代理装上一套可复用、可版本管理、可组合的工作技能包。我先把结论摆出来agent-skills这类项目的核心价值不在于它内置了多少条提示词而在于它定义了一种把人怎么干活沉淀成agent 怎么干活的工程化范式。传统做法是每次开新会话都手动贴一大段上下文或者把规则塞进CLAUDE.md、.cursorrules这类全局文件里越堆越乱。而 skills 的思路是把能力拆成一个个独立单元按需加载、按场景触发这跟软件工程里高内聚、低耦合的模块化思想是一脉相承的。这篇文章适合三类人看一是已经在用 Claude Code、Cursor、各类 CLI agent但总觉得它不够懂我的开发者二是想把团队内部的编码规范、测试流程、发布检查清单固化下来让 agent 自动遵守的技术负责人三是刚接触 AI coding agent想搞清楚skills 到底解决什么问题的新手。我会从概念拆解讲到落地实操中间穿插我自己踩过的坑尽量让你看完就能动手搭一套自己的 skills 库。需要先说明一点agent-skills这个仓库本身的具体文件结构我没有拿到完整的一手资料所以下文涉及目录组织、CLI 命令的部分是基于当前 AI coding agent 生态里 skills 机制的通用实践做的合理还原。你在实际使用时以你所用工具的官方文档为准但底层的设计逻辑是相通的。2. skills 和 prompt、rules 到底差在哪很多人第一次接触 skills会下意识觉得这不就是高级点的提示词吗。我一开始也这么想直到被现实教育了几次才明白这三者的定位完全不同混用会出大问题。2.1 三种给 agent 下指令的方式对比我把 prompt、rules、skills 放在一张表里对比你一眼就能看出差异维度Prompt提示词Rules规则文件Skills技能包生命周期单次会话长期常驻按需加载触发方式手动输入全局生效场景/关键词触发内容粒度一个任务通用约束一套完整工作流可复用性低靠复制粘贴中容易膨胀高模块化组合典型载体聊天框CLAUDE.md / .cursorrules独立目录 元数据适合场景临时问答编码风格、语言偏好TDD 流程、代码审查、发布检查关键差异在触发方式和内容粒度。Prompt 是你主动喂给它的rules 是它一直记着的而 skills 是它知道有这么个技能需要的时候自己调用。这个区别听起来小实际影响巨大。2.2 为什么全局 rules 文件迟早会失控我见过太多项目CLAUDE.md写到三四百行里面塞了编码规范、Git 提交格式、测试要求、部署流程、甚至还有不要用某个库这种历史遗留禁令。问题在于agent 每次会话都要把这坨东西全部读一遍token 消耗大不说规则之间还会互相干扰。比如你写了优先用函数式写法又写了复杂逻辑用类封装agent 到底听谁的skills 的解法是把这些拆开。TDD 流程是一个 skill代码审查是一个 skill发布检查是另一个 skill。平时它们躺在磁盘上不占上下文只有当任务匹配到对应场景时才被加载进来。这就像你公司里的员工不需要每个人都会做财务报表但财务同事得会需要的时候找他就行。2.3 skills 的元数据才是灵魂一个 skill 通常由两部分组成元数据metadata和正文内容body。元数据一般包含名称、描述、触发条件正文才是具体的操作步骤。这里有个设计精髓——agent 平时只加载元数据判断这个技能跟当前任务相关吗相关才把正文读进来。这个机制叫渐进式披露progressive disclosure。打个比方你书架上有一百本书你不需要全部读完才知道哪本讲的是做菜——你看书脊上的书名就够了需要的时候再抽出来翻。skills 的元数据就是书脊正文就是书的内容。这个设计直接决定了 skills 能不能规模化——如果每个 skill 都要全量加载那跟堆 rules 没区别。提示写 skill 描述时触发条件要写得具体。用于代码相关任务这种描述等于没写agent 根本判断不出来。应该写成当用户要求编写新功能、修复 bug 或重构代码时使用强制先写测试再写实现。3. 一个 skill 的内部结构长什么样搞清楚了为什么要有 skills接下来看一个 skill 具体怎么组织。这部分我会给出一套可以直接抄的目录结构和文件模板。3.1 目录组织一个 skill 一个文件夹通用的做法是每个 skill 独立成一个目录目录名用短横线连接的英文小写比如test-driven-development、code-review、release-checklist。目录里至少有一个主文件通常叫SKILL.md或者skill.md有些实现还会配metadata.json、examples/、scripts/等辅助内容。一个典型的仓库结构大概是这样agent-skills/ ├── skills/ │ ├── test-driven-development/ │ │ ├── SKILL.md │ │ └── examples/ │ │ └── red-green-refactor.md │ ├── code-review/ │ │ └── SKILL.md │ ├── release-checklist/ │ │ ├── SKILL.md │ │ └── scripts/ │ │ └── check-version.sh │ └── debugging/ │ └── SKILL.md ├── README.md └── package.json为什么用目录而不是单文件因为一个成熟的 skill 往往需要配套资源——示例、脚本、模板、参考文档。单文件塞不下硬塞会让正文臃肿违背渐进式披露的初衷。目录结构让主流程和辅助材料分离agent 先读主流程需要细节时再去看 examples。3.2 SKILL.md 的头部元数据怎么写主文件的开头通常是 YAML frontmatter用来声明元数据。格式大致如下--- name: test-driven-development description: 当需要编写新功能、修复缺陷或重构现有代码时使用。强制遵循红-绿-重构循环先写失败测试再写最小实现最后重构。 version: 1.0.0 tags: - testing - workflow - quality ---这里每个字段都有讲究。name要唯一且语义清晰别用skill1、helper这种名字。description是最关键的它决定了 agent 能不能在正确的时机加载这个 skill——要写清楚什么时候用和用来干什么而不是这是什么。tags方便分类检索当 skills 多起来之后靠标签筛选比靠记忆靠谱得多。3.3 正文部分把工作流拆成可执行步骤元数据下面是正文也就是 skill 真正的内容。我的经验是正文要写成可执行的流程而不是知识科普。对比一下差的写法测试驱动开发是一种先写测试再写代码的开发方法它能提高代码质量……这是百科词条好的写法1. 阅读需求列出所有需要验证的行为2. 为第一个行为编写测试运行确认失败3. 编写最小实现让测试通过4. 重构保持测试绿色5. 重复直到所有行为覆盖。这是操作手册agent 需要的是后者。它不需要你告诉它 TDD 的历史和意义它需要知道下一步做什么。所以正文里应该大量使用有序列表、明确的判断条件、具体的命令示例。注意正文里不要写你应该考虑……这种模糊表述。agent 会把它当成可选建议而忽略。要写必须、禁止、如果 X 则执行 Y这种确定性指令。4. 用 skills CLI 把技能装进工作流光有 skill 文件还不够得让 agent 能找到它们、加载它们。这就轮到skills CLI出场了。不同工具的 CLI 命令不一样但核心动作就那么几个安装、列出、启用、禁用、更新。4.1 安装与初始化假设你已经有了一个 skills 仓库第一步是把它接入你的 agent 环境。常见的做法是通过 CLI 把 skills 目录链接到 agent 的配置路径下。命令形态大概是# 初始化 skills 配置 skills init # 从本地目录安装 skills skills install ./agent-skills/skills # 或者从远程仓库安装 skills install gitgithub.com:yourname/agent-skills.gitinit会在你的用户目录下创建一个配置文件夹通常叫.skills或.agent-skills里面记录已安装的 skills 清单和启用状态。install则是把 skill 文件复制或软链接进去。我强烈建议用软链接而不是复制。原因很简单你在开发 skill 的时候会反复修改软链接能让改动立即生效不用每次改完都重新 install。很多 CLI 默认就是软链接如果你的不是可以手动建。4.2 列出、启用与禁用skills 装多了之后管理就成了问题。CLI 一般提供这几个命令# 列出所有已安装的 skills skills list # 查看某个 skill 的详情 skills info test-driven-development # 临时禁用某个 skill skills disable code-review # 重新启用 skills enable code-review这里有个实战经验不要一次性启用所有 skills。启用的 skill 越多agent 每次判断该用哪个的负担越重而且容易误触发。我的做法是保持 5 到 8 个核心 skill 常驻启用其余的按项目需要临时开。比如做前端项目时启用component-design做后端时启用api-design两者很少同时需要。4.3 版本管理与团队协作skills 是代码就该用代码的方式管理。把 skills 仓库纳入 Git每个 skill 的改动走 PR 流程版本号遵循语义化版本。这样团队里谁改了哪个 skill、为什么改都有迹可循。更进一步可以在 CI 里加一道检查skill 的元数据格式是否合法、description 是否为空、引用的脚本是否存在。这些检查能避免skill 写了一半就提交的情况。我见过有人提交了一个 description 是空的 skill结果 agent 永远不加载它排查了半天才发现是元数据的问题。提示团队协作时给每个 skill 指定一个 owner。skill 不像普通代码那样有明确的调用方出了问题往往没人认领。指定 owner 之后谁负责维护、谁负责 review 就清楚了。5. 用 TDD skill 跑通第一个完整案例理论讲了一堆不如动手跑一遍。我拿test-driven-development这个 skill 做例子完整走一遍从写 skill到agent 按 skill 干活的流程。选它是因为 TDD 流程边界清晰、步骤固定最适合作为第一个 skill 来练手。5.1 为什么 TDD 特别适合做成 skillTDD 有三个特点让它成为 skill 的理想候选流程固定红-绿-重构循环、容易验证测试通过与否是客观的、agent 容易跑偏不强制的话它总想先写实现。这三点决定了它值得被固化成一个 skill——你不希望每次都要口头提醒 agent先写测试你希望它自动就这么干。而且 TDD 的红-绿-重构循环天然适合拆成有序步骤agent 执行起来不容易乱。相比之下设计一个优雅的架构这种任务就很难做成 skill因为步骤不固定、判断标准主观。5.2 把 TDD 流程写成可执行步骤下面是我实际在用的 TDD skill 正文你可以直接参考## 执行流程 1. **理解需求**阅读任务描述列出所有需要验证的行为点每个行为点写成一句话。 2. **写第一个测试**选择最简单的行为点编写测试用例。测试必须能独立运行。 3. **运行测试确认失败**执行测试命令确认测试失败且失败原因是功能未实现而非语法错误。 4. **写最小实现**只写让当前测试通过的最少代码不要提前实现其他行为。 5. **运行测试确认通过**执行测试命令确认变绿。 6. **重构**在不改变行为的前提下优化代码结构每次重构后重新运行测试。 7. **重复 2-6**直到所有行为点都被覆盖。 ## 禁止事项 - 禁止在写测试之前编写任何实现代码。 - 禁止一次编写多个测试必须逐个推进。 - 禁止为了让测试通过而修改测试断言。 - 禁止跳过确认失败这一步。注意第 3 步和第 5 步——确认失败和确认通过是两个独立的验证动作。很多人包括 agent会偷懒写完测试直接写实现然后跑一次测试看通过就完事。但如果不确认测试真的失败过你根本不知道这个测试有没有在验证正确的东西。我踩过这个坑写了个测试跑出来是绿的以为功能没问题结果发现测试断言写错了根本没测到目标行为。5.3 agent 实际执行时的观察与调整把上面这个 skill 启用之后我让 agent 实现一个字符串反转函数。它的执行过程大致是先列出行为点空字符串、单字符、多字符、含特殊字符然后写第一个测试reverse() 运行确认失败因为函数还不存在写最小实现return 测试通过。接着写第二个测试发现return 不满足改成return str通过。第三个测试才真正实现反转逻辑。这个过程看起来很笨但正是 TDD 的精髓——每一步都只做刚好够的事。agent 在没有 skill 约束时往往会一次性写出完整实现然后补一堆测试测试全绿但你没发判断测试到底有没有覆盖边界情况。实测下来有两个调整点一是 agent 有时会跳过确认失败直接写实现需要在 skill 里把这一步标成必须二是重构阶段 agent 容易过度发挥把无关代码也改了可以在 skill 里限定只重构当前测试涉及的代码。6. 让 skills 真正好用的几个关键设计跑通一个案例不难难的是让 skills 体系长期可用、越用越顺手。这部分我分享几个从实践中总结的设计原则都是踩过坑之后才想明白的。6.1 单一职责一个 skill 只干一件事我最早写的 skill 叫coding-best-practices里面塞了命名规范、测试要求、错误处理、日志格式、性能建议……结果 agent 加载之后执行到一半就忘了后面的要求。原因很简单内容太长超出了有效注意力范围。后来我把它拆成了naming-conventions、error-handling、logging-standards三个独立 skill每个都短小精悍效果立刻好转。这跟写函数是一个道理——一个函数只做一件事一个 skill 也只解决一类问题。判断标准是如果你能用一句话说清这个 skill 干什么且这句话里没有和字那它就够单一了。6.2 触发条件要窄不要宽skill 的 description 决定了它什么时候被加载。写得太宽比如用于所有编程任务那它几乎每次都会被加载等于常驻失去了按需加载的意义。写得太窄比如用于处理 UTF-8 编码的 CSV 文件中的日期字段那它几乎永远不会被触发。我的经验是从窄开始逐步放宽。先写一个具体的触发场景用一段时间发现该触发的时候没触发再放宽一点。反过来如果发现它老在不该出现的时候冒出来就收紧。这个调优过程跟调搜索引擎的关键词是一个逻辑。6.3 给 skill 配反例这是我觉得最有价值的一条经验在 skill 里明确写出不要做什么。agent 对禁止类指令的遵守度往往比应该类指令更高。比如 TDD skill 里写禁止在写测试之前编写实现代码比写应该先写测试有效得多。更进一步可以配一个anti-patterns.md列出常见的错误做法和对应的正确做法。比如错误做法正确做法一次写 5 个测试再一起跑一次写 1 个测试跑通再写下一个测试失败就改断言测试失败就改实现实现写完再补测试测试写完再写实现这种对照表 agent 理解起来特别快比大段文字描述管用。6.4 定期清理僵尸 skillskills 用久了会积累一堆不再需要的。有的是项目结束了有的是被更好的 skill 替代了有的是当初写了一半就没再用过。这些僵尸 skill不会主动消失反而会在 agent 判断时造成干扰。我的做法是每个季度过一遍 skills 列表问三个问题过去三个月用过吗还有项目依赖它吗有更新的 skill 能替代它吗三个都是否就归档。归档不是删除移到archived/目录万一以后要用还能找回来。7. 常见问题与排查思路最后这部分我把实际使用中遇到的高频问题整理出来附上排查思路。这些问题大多不是bug而是设计没想清楚导致的。7.1 skill 不触发怎么办最常见的症状是明明写了 skillagent 就是不用。排查顺序如下先看元数据格式。description 是不是空的YAML 语法有没有错缩进对不对YAML 对缩进极其敏感一个 tab 和空格的混用就能让整个 frontmatter 解析失败而 agent 不会报错只会默默忽略这个 skill。再看触发条件。把 description 读一遍问自己如果我是 agent看到当前任务会认为这个 skill 相关吗如果答案不确定那就是 description 写得太模糊。改成更具体的场景描述。最后看是否启用。skills list确认一下状态有时候是安装时没启用或者被别的操作禁用了。7.2 skill 之间冲突怎么处理两个 skill 给出矛盾指令时agent 的行为会变得不可预测。比如一个 skill 说优先用函数式写法另一个说复杂逻辑用类封装。这种情况的根源往往是职责边界没划清。解法是明确优先级。可以在 skill 的元数据里加一个priority字段或者在项目级的配置里声明加载顺序。但更根本的做法是消除重叠——如果两个 skill 都在管代码风格那它们本来就该合并或者重新划分边界。7.3 skill 内容太长导致效果下降前面提过skill 正文太长会稀释注意力。判断标准是如果一个 skill 的正文超过 200 行就该考虑拆分了。拆分维度可以是流程阶段写测试 / 跑测试 / 重构也可以是场景新功能 / 修 bug / 重构。拆分之后用一个入口 skill来串联。入口 skill 只负责判断当前处于哪个阶段然后指向对应的子 skill。这样 agent 每次只加载当前阶段需要的内容注意力集中执行质量更高。7.4 怎么衡量 skill 有没有效果这个问题很多人忽略但很重要。我的衡量方式是看三个指标返工率agent 产出需要人工修改的比例、token 消耗同样任务消耗的上下文量、一致性同类任务产出是否稳定。好的 skill 应该让返工率下降、token 消耗下降、一致性上升。如果某个 skill 加上去之后返工率反而涨了那说明它的指令有问题要么太模糊要么和实际工作流不匹配。这时候别硬撑回去改 skill改到指标改善为止。提示刚开始用 skills 时别追求一步到位。先写一个最粗糙的版本用起来根据实际表现迭代。skills 是长出来的不是设计出来的。我现在的核心 skills 都改过十几版每一版都是被实际问题逼出来的。这套东西说到底核心就一句话把你自己干活的经验翻译成 agent 能执行的步骤然后用工程化的方式管理起来。它不难但需要耐心——耐心观察 agent 哪里做得不对耐心把纠正措施沉淀成 skill耐心等它慢慢变好。等你攒够一套顺手的 skills会发现跟 AI 协作的效率完全是另一个量级。
