为什么自定义提示词会被淘汰
OpenAI 关于旧格式的页面一开篇就给出了结论：“自定义提示词已弃用。请使用 skills 来编写 Codex 可以显式或隐式调用的可重用指令。”
同一页面解释了促使这一改变的局限性。“自定义提示词需要显式调用，并且保存在本地的 Codex 主目录中（例如 ~/.codex），因此它们无法通过您的仓库进行共享。如果您想共享提示词（或希望 Codex 隐式调用它），请使用 skills。”
这句话说明了全部问题。自定义提示词在设计上就是个人化的。它保存在 ~/.codex/prompts 中，通过输入其名称来调用，而克隆同一个仓库的同事根本无法获取它。它所编码的任何流程知识，在实践中都只是个人的。
Skills 的设计初衷则完全相反。OpenAI 将 skill 描述为“打包了指令、资源和可选脚本，以便任一产品都能可靠地遵循工作流”，并且 Codex 会从多个位置读取它们。对于仓库，“Codex 会扫描从当前工作目录一直到仓库根目录的每个目录中的 .agents/skills。” 此外还有用户、管理员和系统位置，但仓库位置才是让 skill 实现共享的关键。
请注意文件夹名称。它是 .agents/skills，而不是 .codex 内部的文件夹。用户级别的路径也遵循相同的模式：$HOME/.agents/skills。在 Codex 主目录下寻找 Codex skills 文件夹的人找错了地方。
Skills 的应用范围也超出了 Codex CLI。“独立 skills 可在 ChatGPT 桌面应用、Codex CLI 和 IDE 插件中使用。” 这种广泛的适用性也是旧格式被淘汰而不是继续维护的部分原因。
人们尝试的其他替代方案
将提示词留在原处。 它们目前仍能继续工作，但弃用意味着它们不会获得新功能，而且团队中的其他成员仍然无法看到它们。
将每个提示词原封不动地粘贴到 SKILL.md 中。 结果看起来正确，但行为却不同。提示词只有在您输入其名称时才会运行。而 skill 可以被自动选择：Codex 可以通过“隐式调用”来激活它，即“当您的任务与 skill 的 description（描述）匹配时”选择该 skill。以前需要等待您手动执行的部署常规流程，现在可能会自动触发。
保留占位符并期望它们仍能展开。 自定义提示词支持位置占位符（编号 1 到 9），这些占位符“通过您在命令后提供的空格分隔参数进行展开”，此外还有 $ARGUMENTS 以及像 $FILE 这样的命名占位符。Skills 文档中并没有描述等效的占位符展开功能。OpenAI 的导入指南特别将这一类标记为需要审查：“依赖于参数、Shell 插值或文件路径占位符的提示词模板或命令式提示词。”
将每个 skill 都放在仓库根目录下。 Codex 提供层级结构是有原因的。与某个服务相关的 skill 可以放在该服务的目录中；而根级别的 skill 则对每个子文件夹都可见。
依赖导入器来完成。 在从其他 agent 迁移配置时，OpenAI 的导入流程会将“斜杠命令（Slash commands）”映射到“Skills”，这涵盖了其他工具的命令。这只是一个起点，而不是最终的审查。
解决方案：深思熟虑地转换每个提示词，然后决定如何调用它
目标是创建一组 skills，它们能实现您之前提示词的功能，保存在团队可见的地方，并且仅在您希望的时候触发。
步骤 1：盘点您的提示词并按归属进行分类
打开 ~/.codex/prompts 并列出每个文件。对于每个文件，记录三件事：它的功能、是否接受参数，以及它是个人流程还是团队流程。
个人提示词——例如您偏好的提交信息风格、您个人的习惯——属于用户级别，应放在 $HOME/.agents/skills 中。OpenAI 建议该位置的用途是“整理与用户相关的 skills，这些 skills 适用于该用户可能工作的任何仓库”。
团队流程——例如仓库如何发布版本、如何进行审查——属于仓库。如果它适用于仓库中的所有地方，请使用根目录；OpenAI 将根目录 skills 描述为“对仓库中的任何子文件夹都可用”。如果它仅适用于某个区域，请将其放得更近：文件夹级别的 skill 适用于“仅与微服务或模块相关的 skills”。
在列出清单时，检查是否有任何提示词在目的上重复。Codex 不会调和重复项：“如果两个 skills 共享相同的 name，Codex 不会合并它们；两者都可能出现在 skill 选择器中。” 两个名称相同且近乎相同的 skills 都会显示出来，这会让您和团队成员感到困惑。
步骤 2：将每个提示词重写为 skill，用显式输入替换占位符
一个 skill 是一个包含 SKILL.md 文件的文件夹，并且“SKILL.md 文件必须包含 name 和 description”。为每个提示词创建一个文件夹。
描述（description）是您要编写的最重要的一行，因为它是 Codex 决定是否应用某个 skill 的依据。OpenAI 的指南指出：“编写具有清晰范围和边界的简明描述。将关键用例和触发词放在前面，这样即使描述被缩短，主机仍然可以匹配该 skill。” 创建者模板甚至说得更直白：“准确解释该 skill 应该和不应该在什么时候触发。”
对于需要参数的提示词，将每个占位符转换为指令中要求的显式输入。如果提示词告诉 Codex “先暂存它们：$FILES”，那么 skill 就会说明要暂存哪些文件，以及在没有被告知的情况下如何找出这些文件。OpenAI 关于 skills 的最佳实践也指出了同样的方向：“编写具有显式输入和输出的命令式步骤。”
让每个 skill 只专注于一项任务——OpenAI 在其最佳实践中将“保持每个 skill 专注于一项任务”列在首位——并且“除非您需要确定性行为或外部工具，否则优先选择指令而非脚本”。
如果一个提示词用演示比用描述更容易表达，OpenAI 还提供了另外两条途径：内置的创建器（在 Codex 中通过 $skill-creator 调用），它会“询问该 skill 的功能、何时触发，以及它是应该保持仅指令形式还是包含脚本”；以及“记录与回放（Record & Replay）”，它可以根据演示起草一个 skill。
步骤 3：决定调用方式，禁用重复项，然后测试触发器
对于每个转换后的 skill，决定它是否应该自动运行。任何有副作用的操作——部署、开启拉取请求、删除分支——都是保持显式调用的候选对象。
OpenAI 在 skill 内部一个可选的 agents/openai.yaml 文件中记录了此开关：allow_implicit_invocation 默认为 true，而“当为 false 时，Codex 不会根据用户提示词隐式调用该 skill；显式的 $skill 调用仍然有效。” 这为需要它的 skills 恢复了旧的提示词行为。
要在不删除的情况下停用某个 skill，OpenAI 记录了在 ~/.codex/config.toml 中添加 [[skills.config]] 条目并设置 enabled = false，然后重新启动。
然后进行测试。OpenAI 的建议是“根据 skill 描述测试提示词，以确认正确的触发行为”。给 Codex 安排一些应该触发每个 skill 的任务，以及一些不应该触发的任务，并调整描述，直到结果符合您的预期。Codex 会“自动检测 skill 的更改”，如果更新没有出现，建议重新启动。
最后，一旦 skills 表现正常，删除旧的提示词文件，使每个常规流程只保留一个版本。
在 MemoryLake 中进行设置
转换后的 skill 记录了如何执行任务。但它并没有记录为什么要这样执行任务——例如导致发布清单的故障事件，或者审查时为什么要先检查迁移的原因。MemoryLake 是一个保存这些原因的地方，这样操作流程和其背后的原理就不会脱节。
您可以用自己的语言亲自编写这些条目。不会从您的 Codex 主文件夹、您仓库的 skills 目录或任何供应商的存储中读取、写入或删除任何内容。
步骤 1：创建 API 密钥
登录并从控制面板生成一个密钥。该密钥可以让 agent 读取您编写的条目，无论是在 Codex 中还是在您团队使用的任何其他工具中。
步骤 2：上传您的第一批记忆
对于每个团队 skill，添加其背后的决策：为什么存在该步骤、没有它会发生什么问题，以及谁同意了该步骤。每个条目记录一个决策，并附带原因。
步骤 3：连接您的 AI 和 agent
将您的 agent 指向该工作区。这样，无论工作在哪里进行，都可以获取这些原因，包括那些根本不读取 .agents/skills 的工具。
这在实践中带来了什么改变
第一个区别是流程知识变成了团队知识。保存在个人主文件夹中的提示词会随着那个人的离去而流失。而仓库中的 skill 会经过审查、版本控制并对所有人可用，这与使 Codex 始终遵循 AGENTS.md 规则 成为团队关注点而非个人关注点的举措是一致的。
第二个区别是调用变成了一种决策。提示词总是显式调用的。而 skills 默认符合自动使用的条件。针对每个 skill 做出这一选择只需少量工作，却能避免巨大的意外。
第三个区别是规则和程序之间的界限变得更加清晰。始终正确的项目事实属于指令文件；任务程序属于 skills。在 何时使用 skills 还是 rules 中针对 Cursor 讨论了相同的划分，这也同样适用于这里。将两者混淆是 Codex 遗忘项目上下文 的首要原因之一。
第四个区别是便携性。Skills 遵循开放标准，这就是为什么同一个文件夹在多个工具中都有意义——这也是 将 Devin 记忆迁移到 skills 背后的模式，以及 skills 出现在意想不到的目录中的原因，例如 Zed 的 skill 目录。
将提示词转换为 skills 的最佳实践
在 .agents/skills 中查找，而不是 .codex。 仓库 skills 保存在 .agents/skills 目录中；用户 skills 保存在 $HOME/.agents/skills 中。
在转换前区分个人和团队。 skill 的存放位置决定了谁能获取它。
将描述写成触发条件。 说明它应该和不应该在什么时候应用，并将关键词放在前面。
用显式输入替换占位符。 Skills 文档中没有描述参数展开，且 OpenAI 的导入指南将依赖占位符的提示词标记为需要审查。
对任何有副作用的操作关闭隐式调用。 将 allow_implicit_invocation 设置为 false，并保持这些 skills 为显式调用。
给每个 skill 起一个唯一的名称。 Codex 会并排显示同名的 skills，而不是合并它们。
将原理保存在持久的地方。 Skills 是程序，而不是记忆；Grok 的 skills 对 AI 记忆意味着什么 为另一个供应商做出了相同的区分，而 将 Cursor 规则迁移到 Codex 则涵盖了迁移常驻指令的邻近工作。
结论
OpenAI 的弃用说明只有两句话，第二句解释了一切：自定义提示词“保存在本地的 Codex 主目录中”，因此“它们无法通过您的仓库进行共享”。Skills 解决了这个问题。它们保存在 .agents/skills 中，其范围可以限定在某个文件夹或整个仓库，并且它们适用于 Codex CLI、IDE 插件和 ChatGPT 桌面应用。
转换是需要格外小心的地方。除非您另有说明，否则 skills 可以自动触发，并且您提示词所依赖的占位符需要转换为显式输入。
盘点提示词，按归属进行分类，用精确的描述重写每个提示词，深思熟虑地设置调用方式，并测试触发器。然后删除旧文件，并将每个常规流程背后的原因保存在下一个团队成员可以阅读的地方。