本文目录
很多人对 Skill 的理解还停留在新闻和段子里。比如网上常见的说法是：把某位同事、专家或名人的经验“炼化”成一个 .skill 文件，让 AI 以后继续按照他的工作方式处理任务。
这种说法有夸张成分，但它抓住了 Skill 的核心：把一套可复用的经验、流程和规则，整理成 AI 能按需调用的工作说明。
读完这篇文章，你应该能说清楚几件事：Skill 是什么，它为什么能节省 token，一个 Skill 文件大概长什么样，应该放在哪里，怎么安装和手动调用，以及怎么借助 AI 创建自己的 Skill。
一、Skill 是什么？#
通俗地说，Skill 就是给 AI 准备的一套固定工作流程。
平时我们使用 AI，简单问题它可以直接理解并输出结果。但遇到复杂、专业或重复性很强的工作时，只靠一句提示词往往不够稳定。你需要告诉它背景、标准、步骤、禁止事项、输出格式和检查方法。
当然，你可以每次都把这些要求写进提示词里。但只要这个任务会反复出现，每次重复说明就很低效。这时就可以把这些要求整理成一个 Skill，让 AI 在遇到对应任务时自动读取并按流程执行。
所以，Skill 的目的不是让 AI 变得“玄学更强”，而是把你的经验沉淀成可复用的操作规范。
你可以把它理解成三件事的组合：
- 一份任务说明书
- 一套执行流程
- 一组可复用的规则、模板或脚本
二、Skill 通常由什么组成？#
一个最简单的 Skill，通常只需要一个 SKILL.md 文件。这个文件会写清楚名称、描述、适用场景、执行步骤、输出格式和注意事项。
复杂一点的 Skill，会在 SKILL.md 之外继续放脚本、模板、参考资料、示例文件或静态资源。AI 不一定一开始就读取所有内容，而是根据任务需要逐步打开。
一个常见结构大概是这样：
my-skill/
SKILL.md # 必须有，Skill 的入口说明
scripts/ # 可选，自动化脚本或辅助工具
references/ # 可选，详细规则、案例、规范文档
assets/ # 可选，模板、图片、数据文件等静态资源新手不用一开始就记住所有目录。你只需要先知道：SKILL.md 是入口，其他文件都是按需补充的材料。
真正重要的是描述写得准不准、步骤是否清楚、规则是否能落地。目录结构只是载体。
三、Skill 为什么能节省 token？#
Skill 常被提到的一个机制叫“渐进式披露”。
简单理解就是：AI 不会一上来把所有 Skill 的完整内容都读进上下文。它通常会先看到 Skill 的名称和描述，再根据当前任务判断是否相关。只有命中某个 Skill 后，才会继续读取这个 Skill 的详细说明，必要时再读取参考文件、脚本或模板。
这样做有两个好处：
- 不需要每次把长提示词复制进对话，减少重复 token 消耗
- 不需要一次读取全部资料，复杂内容可以按需加载
因此，写 Skill 时最关键的不是把内容堆得越多越好，而是把 description 写清楚。描述越准确，AI 越容易在正确任务中调用它，也越不容易误触发。
一个好的描述通常应该说明三点：
- 这个 Skill 解决什么任务
- 什么情况下应该使用它
- 它会输出什么结果或遵守什么标准
四、Skill 应该放在哪里？#
Skill 一般可以分为用户级和项目级。
用户级 Skill 面向你所有项目，适合放通用能力，比如写文章、做 SEO 审核、代码审查、生成运营素材、整理会议纪要等。
项目级 Skill 只服务于当前项目，适合放项目规范，比如某个网站的发布流程、某个产品的文案风格、某个代码库的测试要求、某个团队的提交规范等。
以 Codex 为例，常见做法是把个人 Skill 放在用户目录下的 .codex/skills 中，把项目专属 Skill 放在项目目录的 .codex/skills 中。
~/.codex/skills/ # 用户级，所有项目可复用
项目目录/.codex/skills/ # 项目级，只服务当前项目我的个人习惯是：通用 Skill 尽量放在用户级目录，方便统一维护；项目强相关的 Skill 才放进项目目录。开始阶段就做好分类，后面会省很多整理成本。
不同 AI 工具对 Skill 的支持路径和命名可能会有差别，实际使用时以对应工具的说明为准。但思路基本一致：通用能力放用户级，项目规则放项目级。
五、Skill 怎么安装？#
安装 Skill 最简单的方法，就是把别人分享的 Skill 文件夹放进对应的 skills 目录里，然后重启你的 AI 工具，让它重新扫描。
比如你下载了一个 seo-audit Skill，可以放成这样：
~/.codex/skills/seo-audit/SKILL.md也可以直接把别人分享的 Skill 内容、仓库地址或压缩包路径发给 Codex，让它帮你安装到指定目录。
这里有一个个人经验：Skill 不是装得越多越好。
Skill 多了以后，描述相近的 Skill 可能会互相干扰。比如你同时装了多个“写文章”“改文案”“做 SEO”的 Skill，它们都可能觉得自己应该被调用，最后反而影响输出稳定性。
更好的做法是：
- 只安装自己真的会用的 Skill
- 同类 Skill 保留一个主力版本
- 长期不用的 Skill 定期清理
- 描述相近的 Skill 尽量合并或改名区分
做减法，比盲目收集更重要。
六、Skill 怎么使用？#
安装好以后，Skill 通常会在提示词命中时自动调用。
比如你安装了一个文章润色 Skill，当你输入“帮我把这篇文章改成公众号风格”时，AI 可能会根据 Skill 描述自动判断并使用它。
如果你想更明确地调用，也可以手动指定。以 Codex 里的常见方式为例，可以输入类似：
/+skill-name例如：
/+create-skill手动调用的好处是减少歧义。尤其是你装了多个能力相近的 Skill 时，直接指定名称往往比等待自动匹配更稳定。
七、怎样创建自己的 Skill？#
你最需要的 Skill，往往不是网上下载来的，而是你自己工作里反复使用的流程。
网上分享的 Skill 大多是通用版本，可以帮你入门。但真正提高效率的，通常是你把自己的标准、偏好、经验和检查方法整理进去。
这就是很多人说的“炼化自己”：不是把人变成文件，而是把你做事时的判断标准，变成 AI 可以复用的流程。
创建 Skill 时，可以直接使用工具自带的创建能力。比如在 Codex 中输入：
/+create-skill然后告诉 AI 你想创建什么 Skill、解决什么任务、必须遵守哪些规则、输出应该长什么样。
我更推荐先用 Plan 模式规划，不要一上来就让 AI 直接生成最终文件。先让它问清楚需求，再列出 Skill 结构，确认后再写入文件。
一个比较实用的创建提示词可以这样写：
我想创建一个用于「文章改写发布」的 Skill。
请先进入规划阶段，不要直接创建文件。
你需要先帮我确认：
1. 这个 Skill 应该在什么任务中触发
2. 必须遵守哪些内容规则
3. 输出文章需要包含哪些结构
4. 完成后应该如何自检
5. 是否需要 templates、references 或 scripts
确认方案后，再帮我生成符合规范的 SKILL.md。创建 Skill 时，我一般会特别强调三类内容。
第一类是必须遵守的规则。比如标题风格、禁用词、输出格式、SEO 要求、事实核查要求、不能省略的检查步骤。这些是铁律，每次都要执行。
第二类是自我学习机制。好的 Skill 不应该只是一次性的提示词，而应该能根据你的反馈持续调整。你可以要求它在每次完成任务后总结偏差，把新的偏好沉淀到 Skill 里。
第三类是完成后检查。比如要求 AI 在交付前自查：是否调用了正确流程、是否遗漏必须字段、是否有事实不确定的内容、是否符合目标平台格式。
八、写 Skill 时最容易犯的错误#
新手写 Skill，最常见的问题有三个。
第一个是太泛。比如只写“帮我写高质量文章”，这类描述几乎没有约束力。AI 不知道什么叫高质量，也不知道你的判断标准是什么。
第二个是太长。把所有想法都塞进一个 SKILL.md，会让入口文件变得臃肿。更好的方式是入口文件只放核心规则，详细案例放到 references 里按需读取。
第三个是没有验收标准。Skill 不只是告诉 AI 怎么做，还要告诉它做完后怎么判断结果是否合格。没有验收标准，输出就容易飘。
一个更好的 Skill 应该做到：触发条件明确、流程短而清楚、关键规则不可忽略、输出格式可检查。
最后#
Skill 的本质不是神秘能力，而是把经验流程化，把流程文件化，再让 AI 在合适的时候调用它。
当你发现某类任务总是在重复解释、重复纠错、重复补充背景时，就说明它很适合做成 Skill。
你可以先从一个最小 Skill 开始：写清楚它解决什么任务、什么时候调用、必须遵守什么规则、最后输出什么结果。等真正用起来，再根据反馈慢慢迭代。
第一个 Skill 不一定要复杂。真正有价值的 Skill，往往来自你每天都在重复做、但又不想每次重新解释的那件事。