很多人低估了 Skill。
Rachel 的核心观点很清晰：Skill 解决的不是「这一次怎么做」，而是「以后遇到这类事，都按这套流程做」。
为什么 Skill 被低估
Skill 看起来太普通了——一个文件夹，一份 SKILL.md，再放点 scripts 和 references。就这？
但问题在于：那些每次都要重复讲的话，本来就不该每次重讲。
让 AI 写文稿，每次都要说「先查资料，别瞎编，开头要抓人，写完从读者角度挑刺」。
让 AI 做 code review，每次都要说「先看 bug 和风险，不要先夸，注明文件位置」。
让 AI 改前端，每次都要说「别只改代码，要看页面，要测移动端」。
这一堆话，沉淀成 Skill，才是真正的效率来源。
按场景分类：prompt vs AGENTS.md vs Skill vs slash command vs subagent
文章给出了一个清晰的分层：
| 类型 | 适用场景 |
|---|---|
| 普通 prompt | 一次性偏好 |
| AGENTS.md / CLAUDE.md | 项目规则 |
| Skill | 可复用流程 |
| slash command | 固定入口动作 |
| subagent | 需要独立角色和上下文 |
这个分层背后的逻辑是：不同粒度的沉淀，匹配不同性质的工作。项目规则是环境级别的，可复用流程是任务级别的，固定入口动作是高频操作级别的。
Skill 最大的坑：写成人生百科
Skill 不是百科全书，不需要覆盖一切。
好的 Skill 要窄，窄到一句话就能召唤。比如「代码 review」「前端验收」「调研查证」「陌生仓库导览」。
具体例子：前端验收 Skill
文章给了一个很具体的 Skill 模板——「前端验收 Skill」：
改完页面后，流程是：
- 启动本地服务
- 打开浏览器看真实页面
- 桌面端看一次，移动端看一次
- 检查文字溢出、按钮错位、弹窗挡主流程
- 看控制台有没有报错
- 截图，汇报改了什么、验证了什么、还有什么没验证
这不复杂。但它把「每次验收前端都会做的动作」固定下来了。
关键在于：AI 很容易改完代码就说好了，但页面到底好不好，很多时候不是代码能看出来的。Skill 的价值就在这里——让它少跳过那些人类真正会检查的步骤。
核心比喻
模型是发动机，Skill 是驾驶习惯。发动机再强，如果你每次都临时问路，还是会绕远。
这个比喻点出了本质：模型能力是基础，但 workflow 的积累才是真正的差异化竞争力。
行动建议
如果你还没做过 Skill，别从大系统开始。就从今天最烦的一件重复劳动开始。
写一个 20 行的小 Skill。让它先帮你：
- 少解释一次
- 少漏一步
- 少返工一轮
这就已经很值了。
原文来自 Rachel（@Zesee）的推文串，探讨了 Skill 在 AI 工作流中的定位与价值。