从简单到复杂，拆开一个 Skill 看看里面有什么
Taking a Skill apart, simple to complex上一篇拆了 make-photo-stamp-archive。它其实是一个很简单的 Skill：没有复杂代码，主要靠一份设计方法和 Prompt 模板，就能做出相当稳定的效果。
继续往下研究后，我觉得理解 Skill 最好的方法，不是先背 scripts / references / assets 这些文件夹，而是先看两头：
最简单的 Skill 可以简单到什么程度？一个复杂 Skill 又为什么需要变复杂？
一个 Skill 最简单可以只有一份 SKILL.md
Agent Skills 的最低结构其实只有：
my-skill/
└── SKILL.md
里面包含名称、description，以及 AI 完成这类任务时需要遵守的 instructions。
所以简单 Skill 确实可以非常接近一份被整理好的 Prompt / SOP。Agent 平时先根据名称和 description 判断这个 Skill 是否和当前任务有关，真正需要时才加载完整内容。
make-photo-stamp-archive 就接近这一类。
它主要需要解决的是：
- 什么样的构图比较好；
- 不同照片应该选什么印章；
- 哪些东西不能修改；
- 最后怎么检查生成结果。
模型本来已经会看图、理解文字，也有图片生成工具。这个 Skill 不需要自己处理数据库、调用复杂 API，或者执行大量确定性程序。
所以作者最需要补给 AI 的，是一套稳定的设计方法。
这种任务天然就不需要很复杂。
Skill 为什么会开始变复杂
换一个任务，情况就完全不同了。
OpenAI 官方的 chatgpt-apps Skill，是用来帮助 Codex 开发 ChatGPT App 的。它不可能只靠一份几百字的 SKILL.md 完成。
开发一个 App 时，Agent 需要处理：
- 不同类型 App 应该采用什么架构；
- MCP server 和 UI 怎么连接；
- 应该复用哪个官方 example；
- 项目结构应该满足哪些最低要求；
- 没有合适模板时怎么创建脚手架；
- 最后如何验证实现是否正确。
所以它除了 SKILL.md，还有大量 references，以及现成的 scaffold script。
这里出现了一个我觉得很重要的区别：
Skill 的复杂度不是“水平高低”，而是任务需要多少不同类型的信息和操作。
图片风格转换主要缺的是方法和审美规则，一份说明可能就够。
开发一个完整 App，既需要方法，又需要技术知识、项目模板、确定性代码和验证流程，自然就会复杂很多。
为什么不把所有东西都写进 SKILL.md
理论上当然可以写一份几万字的超级 Skill。
但这通常不是好的设计。
Agent 的 context 是有限的。OpenAI 的 Skill Creator 明确建议，只提供模型真正需要的额外信息；Agent Skills 的 best practices 也建议让 SKILL.md 保持核心和精简，详细内容再拆出去按需加载。
所以常见的拆法是：
SKILL.md
放每次执行任务都需要知道的东西：
- 整体流程；
- 关键判断；
- 必须遵守的规则；
- 什么情况下应该读取其他材料。
references/
放偶尔需要查询的大量知识。
例如：
references/
├── api-docs.md
├── database-schema.md
└── business-rules.md
需要 API 时读 API 文档，需要指标定义时再去看指标定义。
references 是给 AI 看。
scripts/
放已经非常确定、没必要每次重新让模型写的程序。
例如：
scripts/
├── validate_output.py
└── convert_data.py
文件转换、数据校验、固定格式处理，这类事情让一个已经测试过的 script 做，通常比模型每次现场写一遍稳定。
OpenAI 的 Skill Creator 也明确建议：如果 Agent 反复在重新写同样的代码，就值得把它整理成 script。
scripts 是给 AI 跑。
assets/
则是最后产出可以直接复用的东西：
- starter project；
- 模板；
- 图片；
- 样式文件；
- 文档骨架。
assets 是给 AI 拿来用。
所以一个复杂 Skill 并不是单纯“Prompt 越写越长”。
更好的做法反而是把不同性质的东西分开。
想亲自体验，可以从简单和复杂两边各试一个
如果只是第一次感受 Skill，可以从简单任务开始。
例如自己做一个：
README-review Skill
里面只有 SKILL.md：
- README 应该检查哪些内容；
- 什么算信息缺失；
- 哪些表达应该避免；
- 最后的 review 用什么格式输出。
先不用 scripts，也不用 references。
这样最容易感受到 Skill 和“临时写一条 Prompt”的区别：以后每次 review README，都可以直接复用同一套方法。
图片类也很适合入门。make-photo-stamp-archive 就是很好的现成例子。
如果想看看复杂 Skill 到底长什么样，可以直接去读 OpenAI 的 chatgpt-apps Skill；如果本身在做开发，也可以让 Codex实际用它搭一个很小的 ChatGPT App。它会让你看到 references、脚手架、validation 和主 Skill 是怎么配合的。
另外，PDF 处理也是一个很典型的复杂 Skill 类型：读取、拆分、旋转、表单、OCR、加密等任务需要不同工具和参考方法，Anthropic 官方公开的 PDF Skill 本身就已经有两百多行主说明，并把更高级的内容继续放到 reference 文件。
如果自己做 Skill
我现在觉得更实用的判断方式是先看自己平时的工作。
有一件事情同时满足下面几个条件，就比较值得做成 Skill：
- 会反复发生；
- 每次输入不同，但做法大体稳定；
- 已经积累了一些明确判断，而不是每次凭感觉重新来；
- AI 经常在类似地方犯错；
- 结果有办法检查。
然后从最简单的版本开始。
如果规则都能放进一份 SKILL.md，就先到这里。
等实际使用后发现：
有些背景资料太长，每次并不需要→ 放 references
AI 一直重复写相同的代码→ 做成 scripts
每次都从头生成同一个模板→ 放进 assets
换句话说，复杂度应该从实际问题长出来，而不是一开始就设计一个看起来很完整的文件夹。
我现在对 Skill 的理解
简单 Skill 和复杂 Skill，并不是两个不同物种。
它们解决的是同一件事：把一类反复出现的工作，整理成 AI 可以重复使用的方法。
有的任务本来就只需要一页说明。
有的任务涉及大量知识、工具和确定性操作，于是需要 references、scripts、assets，甚至更完整的验证流程。
真正需要设计的不是文件夹，而是边界：
- 什么应该让模型判断，什么已经可以固定；
- 什么每次都需要知道，什么只在特定情况下查询；
- 什么值得交给 AI 临场处理，什么应该直接给它一个可靠工具。
所以第一次自己做 Skill，先不追求复杂。
先找一件自己已经反复做过、而且确实知道该怎么做的事情。
从一份 SKILL.md 开始就够了。
可以试试：
- Review 类例如 README review、PR review、简历 review、设计稿 review。最适合入门，因为通常已经有一套比较稳定的检查标准，一份 SKILL.md 就能开始。
- 固定输出风格类例如这次的 make-photo-stamp-archive，或者固定的报告、图表、文档风格。重点不是写“高级、简洁”，而是把自己真正的判断拆出来：比例、结构、禁忌、什么情况下做什么选择。
- 重复性的项目检查例如每次 release 前都检查配置、测试、文档、权限、错误处理。这类很适合慢慢加入 scripts，让确定性的检查不要每次靠模型重新判断。
- 需要固定参考资料的任务例如分析业务数据时总要查同一套指标定义，或者写 API 时总要看同一批内部规范。可以把这些放进 references/，需要时再读取。
- 自己已经形成一套方法的工作例如用户研究整理、需求拆解、竞品分析、文章审稿。这类可能反而最有个人价值，因为 Skill 里保存的不只是步骤，还有你长期积累下来的判断。
我会用一个很简单的标准筛：
这件事是不是经常重复？每次输入会变，但我的做法大致不变？我已经知道哪些地方 AI 最容易做错？
三个答案大多是“是”，就值得先做一个最简单的 Skill 试试。
而且第一版只有一份 SKILL.md 完全没问题。实际用了几次，真的发现缺资料、缺脚本、缺模板，再慢慢长出 references / scripts / assets。
Skill 不需要从“复杂”开始，应该从“我确实有一套值得重复的方法”开始。