什么时候应该做 Skill，什么时候继续用提示词
什么时候应该做 Skill，什么时候继续用提示词
Section titled “什么时候应该做 Skill，什么时候继续用提示词”上一篇讲了 Skill 是什么。
这一篇专门讲判断：
这个流程到底值不值得做成 Skill？前置教程：Skills 是什么，为什么它比复制提示词更稳定
如果你还不清楚 Skill 的定位，先看前置教程。
不是所有提示词都应该变成 Skill。
只有当一类任务反复出现，而且你已经知道稳定做法时，才值得沉淀成 Skill。
| 需求 | 更适合用什么 |
|---|---|
| 这一次任务的目标和范围 | 当前提示词 |
| 当前项目长期规则 | AGENTS.md |
| 默认模型、审批、沙箱、MCP 配置 | config.toml |
| 访问外部资料或工具 | MCP |
| 一类任务的稳定流程 | Skill |
| 想把多个 Skill、MCP、应用入口打包给别人安装 | Plugin |
适合做成 Skill 的 6 类场景
Section titled “适合做成 Skill 的 6 类场景”场景 1：你已经重复复制同一段提示词很多次
Section titled “场景 1：你已经重复复制同一段提示词很多次”比如你每次写教程都复制：
这就适合做成 Skill。
场景 2：任务步骤稳定
Section titled “场景 2：任务步骤稳定”比如修 Bug：
- 读现象。
- 找复现方式。
- 只读分析相关文件。
- 提出修复方案。
- 最小修改。
- 运行检查。
- 汇报 diff、检查结果和风险。
这类流程很稳定，适合 Skill。
场景 3：你希望 Codex 自动选择流程
Section titled “场景 3：你希望 Codex 自动选择流程”如果 description 写得好，Codex 可以在任务匹配时自动加载 Skill。
比如用户说：
帮我排查构建失败。Codex 可以匹配到“构建失败排查 Skill”。
场景 4：流程需要附带参考资料
Section titled “场景 4：流程需要附带参考资料”比如写教程时需要固定参考：
- 教程结构模板。
- 中文术语表。
- 常见错误清单。
这些可以放在 Skill 的 references/ 里。
场景 5：流程需要脚本辅助
Section titled “场景 5：流程需要脚本辅助”比如某个 Skill 需要：
- 生成检查清单。
- 跑固定验证脚本。
- 读取固定格式文件。
可以在 Skill 里放 scripts/。
新手第一波不建议加脚本，先做 instruction-only Skill。
场景 6：流程会和 MCP 配合
Section titled “场景 6：流程会和 MCP 配合”比如：
修 issue 流程：1. 通过 GitHub MCP 读取 issue。2. 总结需求和验收。3. 读本地代码。4. 修改。5. 验证。MCP 提供外部资料，Skill 规定工作顺序。
不适合做成 Skill 的 7 类场景
Section titled “不适合做成 Skill 的 7 类场景”场景 1：只用一次
Section titled “场景 1：只用一次”比如：
今天把首页标题改成“Codex喂饭教程”。当前提示词就够。
场景 2：规则只属于当前项目
Section titled “场景 2：规则只属于当前项目”比如：
本项目教程必须叫“喂饭教程”。这更适合 AGENTS.md。
场景 3：只是配置模型
Section titled “场景 3：只是配置模型”默认模型、provider、Base URL，放 config.toml。
场景 4：只是连接外部工具
Section titled “场景 4：只是连接外部工具”连接文档、issue、设计稿，用 MCP。
场景 5：流程还没跑通
Section titled “场景 5：流程还没跑通”不要把你还没验证过的想法做成 Skill。
先在普通对话里跑 3 到 5 次，稳定了再沉淀。
场景 6：流程太大太散
Section titled “场景 6：流程太大太散”比如：
帮我做所有开发工作。这不是 Skill，是愿望。
Skill 应该聚焦。
场景 7：你还不敢让别人复用
Section titled “场景 7：你还不敢让别人复用”如果这个流程连你自己都不确定，就先别做成团队 Skill。
做 Skill 前的 10 个问题
Section titled “做 Skill 前的 10 个问题”每次准备做 Skill 前，先问：
- 这个流程我是否已经用过多次？
- 每次步骤是否基本一样？
- 是否能写清楚触发条件？
- 是否能写清楚不适用场景？
- 是否有明确验收标准？
- 是否需要引用固定资料？
- 是否需要脚本？
- 是否需要 MCP？
- 是我个人用，还是项目团队用？
- 如果 Codex 自动触发它，会不会误伤其他任务？
如果 1 到 5 都答不上来，先不要做 Skill。
推荐提示词：判断是否应该做 Skill
Section titled “推荐提示词：判断是否应该做 Skill”可以复制：
请帮我判断下面这个流程是否适合做成 Codex Skill。
流程或提示词：【这里粘贴你经常复制的提示词或流程】
要求：1. 判断它更适合当前提示词、AGENTS.md、config.toml、MCP 还是 Skill。2. 如果适合 Skill，请总结触发条件和不适用场景。3. 如果不适合 Skill，请说明应该放在哪里。4. 如果适合 Skill，请建议一个清晰的 skill name 和 description。5. 不要创建文件。推荐提示词：从重复提示词提炼 Skill
Section titled “推荐提示词：从重复提示词提炼 Skill”我有一段经常复制的提示词，想提炼成 Codex Skill。
提示词如下：【粘贴提示词】
请先只做设计，不要创建文件。
要求：1. 提炼这个 Skill 的目标。2. 写出适用场景。3. 写出不适用场景。4. 写出建议的 name 和 description。5. 写出 SKILL.md 的目录结构草稿。6. 标出哪些内容应该保留在当前任务提示词里，不应该放进 Skill。这一篇的验收标准
Section titled “这一篇的验收标准”读完后你应该能判断：
- 哪些东西继续写在当前提示词里。
- 哪些东西写进
AGENTS.md。 - 哪些东西用 MCP。
- 哪些流程值得做成 Skill。
- 为什么流程没跑通前先不要做 Skill。