很多人低估了 Skill。
不是因为它复杂，恰恰相反——Skill 太简单了，简单到让人忽略它的价值。一个文件夹，一个 SKILL.md，再放点 scripts、references、assets。就这？
Zesee 用了一个月才看清楚：Skill 不是让 Codex/Claude Code 变聪明，它解决的是"别让你每次都重新当人肉配置文件"。
一次性 prompt 的天花板
你想想看。
让 AI 写文稿，你是不是每次都要说：
- 先查资料，别瞎编
- 开头要抓人
- 写完从读者角度挑刺
让 AI 做 review，你是不是每次都要说：
- 先看 bug 和风险，不要先夸
- 问题要带文件位置
让 AI 改前端，你是不是每次都要说：
- 别只改代码，要看页面
- 要测移动端
这一堆话本来就不该每次重讲。
普通 prompt 解决的是"这一次怎么做"——你给一次上下文，AI 做一次。Skill 解决的是"以后遇到这类事，都按这套流程做"。
Skill 是一次性 prompt 的升级路径：从"每次讲一遍"变成"调用一次"。
Skill 的 5 个分类
Zesee 给出了当前最干净的一份分层方案：
| 形态 | 用途 | 触发方式 |
|---|---|---|
| prompt | 一次性偏好 | 当次输入 |
| AGENTS.md / CLAUDE.md | 项目规则 | 每次启动自动加载 |
| Skill | 可复用流程 | 用户或 Agent 主动调用 |
| slash command | 固定入口动作 | / 触发 |
| subagent | 独立角色 + 上下文 | 显式委派 |
这五个形态互不替代。错误用法的典型是"用 prompt 写 Skill 内容"——结果每次都要重新粘贴；或者"用 AGENTS.md 写 Skill"——结果项目规则跟可复用流程混在一起，没法跨项目用。
好的 Skill 必须窄
最容易踩的坑：把 Skill 写成一本人生百科。
不需要。
好的 Skill 反而要窄到一句话就能召唤：
- "代码 review"
- "前端验收"
- "调研查证"
- "陌生仓库导览"
窄的好处是 Agent 在"该不该加载这个 Skill"时有明确的触发信号。如果一个 Skill 写得很宽（"AI 写文章的所有规则"），Agent 每次看到"写文章"的需求都可能加载它，结果就是 context 浪费 + 加载的内容跟具体任务不匹配。
窄的另一个好处是维护成本低。"前端验收 Skill"改一次只影响前端验收，不会牵动其他工作流。
一个具体的 Skill：前端验收
Zesee 举的最简例子是"前端验收 Skill"。
里面不写玄学 prompt，就写流程：
- 改完页面后，先启动本地服务
- 再打开浏览器看真实页面
- 桌面端看一次，移动端看一次
- 检查文字有没有溢出，按钮有没有错位，弹窗有没有挡住主流程
- 再看 console 有没有报错
- 最后截图，告诉我改了什么、验证了什么、还有什么没验证
这套流程不复杂。但它把 Zesee 每次验收前端都会做的动作固定下来了。
以前 AI 很容易改完代码就说"好了"。但页面到底好不好，很多时候不是代码能看出来的——它得真的去看。改完代码 ≠ 验收通过。人类不会"读 diff 觉得 OK 就 merge"，人类会"打开页面看是不是真的能用"。
Skill 真正值钱的地方：判断顺序
注意上面那 6 步的顺序：
- 启动服务（不是看 diff）
- 桌面端（不是 mobile first）
- 检查溢出
- 检查按钮
- 检查弹窗
- 检查 console
- 截图汇报
这个顺序是反"开发者直觉"的。开发者习惯"先看代码 diff，再看页面"。但 AI 改完代码的常见错误是"代码看着对，页面就出 bug"——比如 flex 布局在小屏幕溢出、CSS animation 卡顿、第三方 cookie 弹窗挡住主流程。
Skill 把这个反直觉的顺序固化下来，AI 不会"我觉得代码对就行"，它必须"按顺序做完 6 步"。
判断顺序比内容重要。 这是 Skill 跟普通 prompt 最本质的区别——prompt 是"做什么"，Skill 是"按什么顺序做"。
第一次做 Skill 的最小可行路径
Zesee 给了非常具体的建议：
如果你还没做过 Skill，别从大系统开始。
就从今天最烦的一件重复劳动开始。
写一个 20 行的小 Skill。让它先帮你少解释一次，少漏一步，少返工一轮。
这就已经很值了。
这是个非常反"AI 大跃进"心态的建议。Skill 圈很多人追求"做一个 200 行的超级 Skill 覆盖所有场景"，结果就是 Skill 写完根本不被调用——因为太宽，Agent 不知道什么时候用。
20 行的小 Skill 是一切的起点。
诚实说不适合谁
Skill 不是所有人都该用。
- 一次性任务（写一次性邮件、做一次性调研）→ prompt 足够，加 Skill 是过度工程
- 跨项目差异极大的工作流（不同公司的代码 review 标准）→ 写 Skill 时要带大量 if/else，不如每次 prompt
- 需要强反馈循环的场景（写作、设计、决策）→ Skill 固化流程会扼杀灵活性
- Prompt 工程新手 → 先把 prompt 写好，再考虑升级到 Skill。Skill 解决"prompt 写得太好但每次都重写"的问题
Zesee 没说的两件事
1. Skill 的版本管理问题。Skill 是代码，但它不是被 git 跟踪得最好的那种资产。一个 Skill 改 3 次后，谁也说不清"为什么 2 周前的版本能修这个 bug，现在不行了"。Skill 的版本控制需要专门的工具——不是简单的 git 提交，而是带 semantic version + 测试用例 + 回滚路径。Anthropic 当前没有给出这个能力。
2. Skill 的"被调用概率"困境。一个 Skill 写得再好，Agent 不调用它就是废纸。Agent 决定调不调用 Skill 是基于"这个 Skill 的描述跟当前任务的相关度"——但描述写得不准确，Agent 永远不会用。Skill 描述本身是 meta-prompting——你要用一句话告诉 Agent "什么时候用我"。这个一句话，比 SKILL.md 主体还难写。 Zesee 提了"窄到一句话能召唤"，但没展开"这句话怎么写才对"。
结论
Skill 的真正价值不是格式（一个文件夹 + SKILL.md）——那是表面。
Skill 的真正价值是判断顺序的封装 + 重复劳动的固化。当你发现自己每次都要给 AI 重复同一段话，把它写成 Skill；当你发现 AI 总在某个环节跳过，把它写成 Skill；当你发现自己的工作流有"必须按 A→B→C 顺序做"的硬约束，把它写成 Skill。
SOTA Sync 的判断：未来 12 个月，Skill 会成为 AI 工具的"个人流程资产"。每个 Agent 重度用户会有自己的 Skill 库（20-100 个），跨项目复用。这是比 prompt engineering 更稳定的能力沉淀——prompt 是一次性的，Skill 是可调用的。
但 Skill 的下一道关卡是"被 Agent 自动发现"——目前仍是"用户或 Agent 主动调用"。如果 Anthropic 把 Skill discovery 做成自动的（Agent 自己判断什么时候需要），Skill 才真正成为 AI 工作流入口。 Zesee 看到的入口，目前还是半自动的。