为什么需要 Skill
刚开始学编程，你在终端运行一个程序，屏幕上突然刷出一大段英文报错。 你把报错贴给 Codex，但它的回答总是差点意思：要么只复述英文，要么上来就改代码，却不告诉你错在哪里。于是你每次都要重复敲一遍同样的提示词：
第 1 节 为什么需要 Skill
1.1 本节目标
理解 Skill 解决什么问题，以及什么样的经验值得沉淀为 Skill。
1.2 从一条看不懂的报错开始
刚开始学编程，你在终端运行一个程序，屏幕上突然刷出一大段英文报错。
你把报错贴给 Codex，但它的回答总是差点意思：要么只复述英文，要么上来就改代码，却不告诉你错在哪里。于是你每次都要重复敲一遍同样的提示词：
1. 先告诉我最关键的是哪一行。
2. 解释错误类型，不要只重复英文。
3. 指出应该看哪个文件、哪一行。
4. 告诉我下一步先检查什么。
5. 暂时不要直接修改代码。
第一次这样写，没有问题。
但同类报错会不断出现。你可能某次忘了要求"保留报错原文"，Codex 也可能某次自作主张直接改了代码，让你错过了理解错误信息的机会。
方法明明已经想清楚了，却散落在聊天记录里，既不稳定，也无从复用。
这就是 Skill 要解决的问题。
1.3 Skill 是什么
Skill 是一套可复用的任务说明书，相当于给 Codex 准备的工作手册。它把一类任务的操作步骤、限制条件、参考资料和工具脚本放在同一个目录中，需要时整体加载。
用一句话区分两者：
- 提示词：告诉 Codex 这一次怎么做。
- Skill：告诉 Codex 这一类任务通常怎么做。
Skill 保存的是一类问题的解法，而不是某一道题的答案。
1.4 Skill 可以保存什么
| 场景 | Skill 可以保存的内容 |
|---|---|
| 解释报错 | 阅读顺序、通俗解释模板、下一步检查清单 |
| 代码审查 | 审查顺序、严重程度分级、输出格式 |
| 发布新版本 | 发布流程、执行命令、回滚检查项 |
| 查询数据 | 表结构说明、指标口径、查询规范 |
| 处理 PDF | 操作说明和可重复执行的脚本 |
Skill 不会让模型突然学会它本来不会的东西。它只是在需要时，把已经沉淀好的方法和资料准确地交给 Codex。
1.5 Skill 解决三个问题
1. 不再重复粘贴长提示词
同一套要求只写一次。以后调用 Skill，再补充本次的报错内容、相关文件和目标即可。
2. 让结果更稳定
把步骤、限制条件和检查项写清楚后，不同会话的输出更容易保持一致，团队成员也更容易按同一套方法协作。
⚠️ 这里说的是"更稳定"，不是"保证正确"。重要结果仍然需要人工检查。
3. 把经验变成可维护的资产
聊天记录难以搜索、难以修订、离职即失传。Skill 是普通文件，可以纳入版本控制，可以由团队共同维护、持续迭代。
好用的提示词值得整理成 Skill——需要时直接修改复用，而不是去聊天记录里翻找。
1.6 Skill、提示词和 AGENTS.md 的区别
第 1 章已经介绍了 AGENTS.md。它和 Skill 都会影响 Codex 的行为，但定位不同：
| 内容 | 适合放在哪里 |
|---|---|
| 本次任务的目标和范围 | 当前提示词 |
| 当前项目长期遵守的规则和约定 | AGENTS.md |
| 跨任务重复使用的工作方法 | Skill |
举个直观的例子：
- "这个项目统一使用 TypeScript" —— 这是项目规则，写进
AGENTS.md。 - "解释报错时先保留原文，再指出文件和行号" —— 这是任务方法，写成 Skill。
1.7 什么时候值得写 Skill
不是每条提示词都值得沉淀为 Skill。可以用三个条件来判断：
- 会重复：同类任务会反复出现；
- 已稳定：做法已经比较成熟，不是一次性的权宜之计；
- 可验证：结果有办法检查对错。
"解释报错"恰好满足全部三个条件：报错原文是否保留、文件位置是否指出、下一步检查是否给出——这些都可以直接核对。
一次性的要求，直接写进当前提示词即可。做法还没定型？先多试几次，等它稳定下来，再整理成 Skill。
1.8 思考
试着回答这个问题：
Skill 与一次性提示词的本质区别是什么？如果一条提示词只打算用一次，把它写成 Skill 反而会带来什么负担？
下一节，我们动手写第一个 Skill。