上一篇讲了 Skill 是什么。

这一篇专门讲判断：

``

这个流程到底值不值得做成 Skill？

`

> 前置教程：Skills 是什么，为什么它比复制提示词更稳定

> 如果你还清楚 Skill 的定位，先看前置教程。

核心判断原则

不是所有提示词都应该变成 Skill。

只有当一类任务反复出现，而且你已经知道稳定做法时，才值得沉淀成 Skill。

决策矩阵

| 需求 | 更适合用什么 |

| :--- | :--- |

| 这一次任务的目标和范围 | 当前提示词 |

| 当前项目长期规则 | AGENTS.md |

| 默认模型、审批、沙箱、MCP 配置 | config.toml |

| 访问外部资料或工具 | MCP |

| 一类任务的稳定流程 | Skill |

| 想把多个 Skill、MCP、应用入口打包给别人安装 | Plugin |

适合做成 Skill 的 6 类场景

场景 1：你已经重复复制同一段提示词很多次

比如你每次写教程都复制：

`

要求：

  1. 结构要按...

    2. 2. 文案要用...

    3. 图片要记录...

    `

    这就适合做成 Skill。

    场景 2：这类任务有非常稳定的执行步骤

    比如修 Bug：

    1. 读现象。

      2. 2. 找复现方式。

      3. 只读分析相关文件。

      4. 提出修复方案。

      5. 最小修改。

      6. 运行检查。

      7. 汇报 diff、检查结果和风险。

      这类流程很稳定，适合 Skill。

      场景 3：你希望 Codex 自动选择流程

      如果 description 写得好，Codex 可以在任务匹配时自动加载 Skill。

      比如用户说：

      `

      帮我排查构建失败。

      `

      Codex 可以匹配到“构建失败排查 Skill”。

      场景 4：任务需要大量外部参考资料

      比如写教程时需要固定参考：

      • 教程结构模板。
      • 中文术语表。
      • 常见错误清单。

      这些可以放在 Skill 的 references/ 里。

      场景 5：任务需要运行固定脚本

      比如某个 Skill 需要：

      • 生成检查清单。
      • 跑固定验证脚本。
      • 读取固定格式文件。

      可以在 Skill 里放 scripts/。新手第一波不建议加脚本，先做 instruction-only Skill。

      场景 6：需要和特定的 MCP 配合

      比如：

      `

      修 issue 流程：

      1. 通过 GitHub MCP 读取 issue。

        2. 2. 总结需求和验收。

        3. 读本地代码。

        4. 修改。

        5. 验证。

        `

        MCP 提供外部资料，Skill 规定工作顺序。

        不适合做成 Skill 的 7 类场景

        场景 1：只有这一次任务要用的要求

        比如：

        `

        今天把首页标题改成“Codex喂饭教程”。

        `

        当前提示词就够。

        场景 2：项目特有的业务偏好

        比如：

        `

        本项目教程必须叫“喂饭教程”。

        `

        这更适合 AGENTS.md。

        场景 3：基础配置

        默认模型、provider、Base URL，放 config.toml。

        场景 4：只是连接外部工具

        连接文档、issue、设计稿，用 MCP。

        场景 5：你还没验证过的流程

        不要把你还没验证过的想法做成 Skill。先在普通对话里跑 3 到 5 次，稳定了再沉淀。

        场景 6：目标太大、太模糊

        比如：

        `

        帮我做所有开发工作。

        `

        这不是 Skill，是愿望。Skill 应该聚焦。

        场景 7：流程极其复杂，你自己都说不清

        如果这个流程连你自己都不确定，就先别做成团队 Skill。

        做 Skill 前的 10 个问题

        每次准备做 Skill 前，先问：

        1. 这个流程我是否已经用过多次？

          2. 2. 每次步骤是否基本一样？

          3. 是否能写清楚触发条件？

          4. 是否能写清楚不适用场景？

          5. 是否有明确验收标准？

          6. 是否需要引用固定资料？

          7. 是否需要脚本？

          8. 是否需要 MCP？

          9. 是我个人用，还是项目团队用？

          10. 如果 Codex 自动触发它，会不会误伤其他任务？

          如果 1 到 5 都答不上来，先不要做 Skill。

          推荐提示词：判断是否应该做 Skill

          可以复制：

          `

          请帮我判断下面这个流程是否适合做成 Codex Skill。

          流程或提示词：

          【这里粘贴你经常复制的提示词或流程】

          要求：

          1. 判断它更适合当前提示词、AGENTS.md、config.toml、MCP 还是 Skill。

            2. 2. 如果适合 Skill，请总结触发条件和不适用场景。

            3. 如果不适合 Skill，请说明应该放在哪里。

            4. 如果适合 Skill，请建议一个清晰的 skill name 和 description。

            5. 不要创建文件。

            `

            推荐提示词：从重复提示词提炼 Skill

            `

            我有一段经常复制的提示词，想提炼成 Codex Skill。

            提示词如下：

            【粘贴提示词】

            请先只做设计，不要创建文件。

            要求：

            1. 提炼这个 Skill 的目标。

              2. 2. 写出适用场景。

              3. 写出不适用场景。

              4. 写出建议的 name 和 description。

              5. 写出 SKILL.md 的目录结构草稿。

              6. 标出哪些内容应该保留在当前任务提示词里，不应该放进 Skill。

              `

              读完后你应该能判断：

              1. 哪些东西继续写在当前提示词里。

                2. 2. 哪些东西写进 AGENTS.md`。

                3. 哪些东西用 MCP。

                4. 哪些流程值得做成 Skill。

                5. 为什么流程没跑通前先不要做 Skill。

                下一篇看：第一次做一个 instruction-only Skill。