本文纯手写，为了不误导，本文已确保发给过至少三个 AI （Claude Gemini ChatGPT）做交叉检查，尽量减少错误；但因为存在本人主观判断，所以仍可能存在疏漏，欢迎指出。

一、什么是 Skills

一句话概括，Skills 就是 给 Agent 用的“可复用能力模块（插件包）”。

初学编程的时候，经常会疑惑为什么一个项目里有那么多代码文件呢？只写一个代码文件不好吗？

Skills 的本质，与该问题的解答是一致的——

项目越来越复杂的同时，单一提示词文件已经无法长期稳定承载所有规则与流程，于是把“固定流程 + 规范 + 资源”拆成模块化的 Skills，按需取用。

二、从问题切入 Skills 的本质

1.为什么之前使用 AI 的方式不够用？

通常，如果我们想让 AI 输出一段高质量，高可用的代码，通常都会

你是一名资深 Java 架构师，现在需要你切入该目录下的复杂微服务项目……

在提示词中加入角色、项目背景、技术背景。

Vibe 多了就会发现，AI 写点简单工具，甚至搓逆向工具都不在话下。

但一旦项目越来越深入，越来越复杂，AI 就会“忘记”之前的写法，或者“擅自”以跳脱提示词的方向来完成任务，从而在同一个服务下为了完成目标而不按要求干活。

于是，大家就会加上各种约束，导致 AGENTS.md 越来越长，AI 变得不听使唤。

原因是多样的，常见的原因有例如

• 上下文变长后注意力分散
• 约束之间冲突或优先级不清
• 指令太多导致执行路径不稳定

此处就不逐个展开了。

这跟初学编程的时候一样——所有函数全部放到一个文件里，写上千行，完全没有可维护性，阅读也无比困难，Debug 下来就是一整天。

Skills 便是优化、补足这点的。

更合理的做法是分层：项目级共识（怎么跑、怎么测、风格约定、目录约定等）放在 AGENTS.md；而通用的、规范的、流程固定的、需要严格遵守但繁琐的流程提示词与资源，则拆成 Skills，以“项目/插件包”的形式按需给 AI 使用。

是的，Skills 里不光包含传统意义上的提示词，也可以附带脚本、模板、样例、参考资料等资源；至于“打包好的二进制/指令集”能不能直接执行，取决于你所使用的 Agent 运行环境与权限配置。

比如说，我现在要逆向某款游戏，并反编译游戏内的二进制资源，

请从反编译的 exe 中，提取出该游戏在拿到该资源文件后，是如何一步步将其 IO 掉所有字节的，并复现其过程，将其结构给存储到以二进制的分布为顺序结构的类示例里，并输出为 JSON ，其中 JSON 需要能还原回源二进制文件，以此作为回归测试。

若是以往，我需要一遍又一遍地告诉 AI：什么是 “IO 掉”、反序列化和序列化的流程要符合什么流程、回归测试需要做到什么地步。

但现在，我可以将上述的好几点全部做成 Skills 中的模块，全部给架构化，以后再需要做类似的逆向工程，我只需要

反编译代码在 xxx 下，逆向的目标资源在 xxxx 下，把它逆了。

只要 Skills 工程做的足够好，它便能以相当高的完成度，直接复刻之前需要无数次来回才能做到的事情，把反复沟通的成本压到很低。

2.那么 Skills 应该怎么编写与使用呢？

首先，千万不要把 Skills 当“更长的提示词”，要把它当“可复用的流程包”。

2.1 先想清楚：哪些东西该放 Skills，哪些东西该放 AGENTS.md？

最简单的分法：

• AGENTS.md 放“共识”
  比如：怎么 build / test、代码风格、目录约定、禁止事项、你希望 Agent 默认怎么协作。
• Skills 放“可复用的固定流程”
  比如：某类任务的标准步骤、固定输出格式、检查清单、回归验证方法、常见坑的兜底处理。

这样做的好处是：AGENTS.md 不会越写越像“啥都有的字典”，Skills 也不会越堆越像“可有可无的垃圾堆”。

2.2 Skills 的最小结构长什么样？

以 Codex 的 Skills 规范来说，一个 Skill 就是一个目录，**目前来说必须有 SKILL.md**，里面至少要有 name 和 description，其余可以按需带脚本、模板、参考资料等。

你写 Skills 时，建议按这个最小结构组织（不要求完全一致，但思路最好一致）：

• SKILL.md
  放：这个技能干什么、什么时候用、输出长啥样、怎么验收、失败怎么处理
• references/
  放：长说明、规范文档、格式定义、例子（真正长的东西别全塞 SKILL.md）
• scripts/
  放：能跑的脚本（生成/校验/格式化/回归测试）
• templates/ 或 assets/
  放：模板、样板文件、固定输出骨架

相信有工程经验的大伙就明白了：这不就是个给 AI 读的“文档项目”吗？

2.3 SKILL.md 应该怎么写才“好用”？

重点不是写得多，而是写得“可执行”，就个人来说：

1. 一句话目的：这个 Skill 解决什么问题
2. 触发条件：什么情况下应该用它（越具体越好）
3. 输入要求：需要你给什么信息/路径/文件
4. 输出约定：输出什么格式、有哪些字段/结构、命名规则
5. 执行步骤：按 1、2、3 写清楚固定流程
6. 验收标准：怎么判定“做对了”（比如回归测试必须通过）

按上述几点来写，当然，可以完全交给 AI 写一份。

2.4 Skills 怎么“使用”？

目前来说当两种用法就行：

• 1.自动：Agent 看到任务后，自己判断某个 Skill 相关，于是加载并执行。这个过程是“自动的”，通常只需要放到你打开 Agent 的目录下，AI 就会自己去加载查看。（这点不绝对，因为目前来说 Skills 还在发展阶段，所以“自动加载”通常不是 100% 的。就我个人来说，目前 2026-02-23 做得最好的是 Claude，codex 次之）
• 2.手动：你直接告诉它“用哪个 Skill 来做这件事”，并给足输入（路径/文件/目标/验收）

三、Skills 自身的属性

在总结之前，列一下 Skills 这套东西天然自带的属性。

• 高可用（可复用）
  在一个领域里，反复强调同一套流程是纯浪费。Skill 写一次，后面就是反复用，最多做小修小补。

• 结构化
  它不是“聊天记录”，而是“模块包”：有清晰边界、有输入输出、有步骤、有验收。你甚至可以把验收脚本一起塞进去，直接让流程闭环。

• 随用随拿（按需加载）
  最爽的点就在这：不需要把全部规范都常驻在上下文里。需要的时候再加载，既省 token，也更稳定。

• 可组合
  不是只能装一个技能。多个技能可以一起工作，所以你写 Skill 时不要假设“我就是唯一规则”。（你加了它也有概率乱写，目前无解，还是常 review 吧）

• 可移植
  同一个技能包在不同入口（IDE/CLI/平台）能不能完全一样，要看环境；但“技能作为模块包复用”的方向是明确的。

四、Skills 现在的局限性

说缺点更重要，因为这也是坑……

• 工具链支持不统一
  不是所有 Agent 目前都支持 Skills，同样叫 Skills 的实现细节也可能不同（发现、加载、脚本执行权限都不一样）。

• 技能之间可能会冲突
  两个 Skill 都描述同一件事，或者输出格式不一致，很容易出现“执行路径不稳定”。技能越多，越要人工仔细看。

• 维护成本是真实存在的
  Skills 写得越像工程，就越需要版本管理、变更记录、回归验证。在你决定要用 Skills 的同时，记得一定一定一定先加到 Git 里。

• 容易被误用
  name/description 写得不清楚，Agent 就可能在不该用的时候用；或者该用的时候没用，最后你还以为是模型不行，其实是技能设计不行。

五、Skills 推荐和本人的 Skills

（待补充）