TL;DR：如果你在使用Codex，command（命令） 用于控制会话或应用程序，而skill（技能） 用于教代理一种工作方法。在Claude Code中，目前的文档已经将技能视为可以用/skill-name直接调用的东西，所以这两种概念在Claude Code中更为融合。但在Codex中恰恰相反：types可以作为技能存在，但/types却可能不存在。
当你从Claude Code切换到Codex时，这种混淆非常常见。而且可以理解。
你创建了一个名为types的技能，回到终端时满怀信心地输入/types……然后Codex看着你，就像你在五金店里要了一杯拉格啤酒。
问题不是技能坏掉了。问题在于，在Codex中，技能和命令并不是一回事。
请注意，这种差异并非表面上的不同，它会彻底改变你设计工作流的方式。
一个让你秒懂的类比
想象一下，Codex就像是一架有两层结构的飞机。
第一层是驾驶舱：按钮、杠杆、指示器。这是命令的栖息地，用于改变会话、客户端或工具的状态，这是操作控制。
第二层是副驾驶手册：流程、标准、检查清单、避免陷阱的指南。这是技能的领域，用于改变代理思考和执行任务的方式。
通俗地讲：
- 命令是动驾驶舱里的按钮。
- 技能是改副驾驶脑中的手册。
如果你把手册当成按钮来用，那肯定行不通。
什么是Codex中的命令
在Codex中，命令有两种形式，千万别搞混。
第一种是CLI命令：
codex login
codex exec "run tests and fix failures"
codex resume --last
codex apply
---
这很直接明了。这些是应用程序的操作：登录、运行任务、恢复会话、应用变更。如果明天系统中没有了模型，这些命令依然有意义。
第二种是**交互式会话中的斜杠命令**：
```text
/model
/permissions
/personality
/agent
/status
它们也并非是“华丽的提示语”。它们控制的是实时的会话：更改模型、调整权限、切换人物风格、设定活动线程或改变可见状态。这些就像驾驶舱中的控制按钮。
OpenAI事实上非常清晰地记录了它们的用途：一方面，有专门的斜杠命令页面用于“在交互会话中控制Codex”的说明；另一方面，另有一份独立的技能页面，将技能定义为可重用工作流的创建格式。
这也是为什么有些操作会成为命令而不是技能：因为它们需要可预测性、即时响应和稳定语义。你不希望模型“有创意地解释”/permissions的含义。你只希望它直接更改权限。就这么简单。
什么是Codex中的技能
Codex中的技能是完全不同的东西。它就是一个可重用的工作流，用来教给代理何时运用某种方法、如何思考某个任务并按照特定步骤操作。
这里还有一个细微但重要的区别：OpenAI表示，skill是一种编写格式，而**plugin（插件）**是可安装或分发的单元。换句话说，你会先将工作流设计为技能；如果需要分享或进行封装，就可以把它打包成插件。
明确的例子：
$types
$improve
$owasp
$blog
或者，如果更偏语言化：
使用types来审计这个代码仓库
使用improve来检查这个diff
你在这些例子里并不是叫Codex去“切换设置”。你是在告诉它，“当我让你执行这项任务时，请按照这套剧本来操作”。
以我的types技能为例，它不应该是个按钮。它的工作是读取项目代码、检测语言、检查模型、寻找“字符串类型化的代码”、判断一个Optional的使用是否合理并是否能正确建模域状态。这需要背景和判断能力，正是技能擅长的工作。
同理，improve作为一个技能也讲得通：检查diff并不是什么机械性的操作，反而涉及到判断、上下文和优先级的权衡。
为什么在Claude Code中“看起来像是一样的”
这里就是认知的陷阱了。
最新的Claude Code文档对这一点已经毫不避讳了。它谈到技能时，会告诉你可以通过以下方式直接调用：
/skill-name
也就是说，在Claude Code中，你认为的某些属于“可重用工作流”的东西是通过斜杠命令语法来调用的。用户体验上，它将Codex中分离的两个概念合并了：
- 重用一个工作流
- 通过
/命令调用该工作流
此外，Claude Code也有其内置命令：
/help
/compact
并且将另一个独立概念区分开：子代理，即拥有自己的上下文、权限以及系统提示的专业助手。
换句话说：
- 在Claude Code中，技能、子代理和命令共存，但技能也能通过
/调用。 - 在Codex中，可重用工作流存在于技能，而
/命令仅用于显式会话控制。
因此，如果你从Claude Code背景来，你的大脑会很快习惯于一个实际的等式：“如果有某种可重用的工作流，那我大概是通过/命令来触发它”。而在Codex中，这样的习惯不起作用。
实例分析：哪些应该是技能，哪些不应该？
在Codex中应该是技能的场景
types
因为你不只是想“执行一个动作”。你想对实际代码库进行类型设计评估。
improve
因为检查一个差异代码不止于机械化操作，它要求判断、背景知识和优先权。
blog
因为写一篇风格、结构合适并经过事实核查的文章是一种思维流程，而不是一个按钮。
owasp
因为执行一项安全审计需要根据堆栈、代码仓库及具体风险来调整策略。
在Codex中应该是命令的场景
codex login
无需逻辑思考：你要么登录成功，要么没有。
/model
切换模型纯粹是客户端操作，而不是工作标准的调整。
/permissions
会话过程中调整权限是纯粹的操作控制。
codex resume --last
重新打开一个会话并不需要智能处理。这只是应用程序的动作。
最容易混淆的情况：混合案例
有一类情形一开始可能会搞乱你的思路，就是那些你希望通过简单语法调用，但其逻辑更接近skill的工作流。
比如：
- 你可能想直接输入
/types - 但实际上，
types概念上仍然是一个技能
这种情况下，优雅的解决方法不是把技能强行改成别的，而是用封装方法。
也就是说：
- 把核心逻辑保留在技能里。
- 创建一个插件或命令，用易于使用的
/命令语法来调用它。
这样，你可以同时获得两种优势：命令的良好用户体验和技能的强大逻辑。
在Codex中使用的黄金法则
如果你在技能和命令之间犹豫不决，可以用这个测试方法：
你想改变会话或应用的状态吗？
那你需要一个命令。
你想改变代理解决某项任务的方式吗？
那你需要一个技能。
用表格看看，可能更直观些：
| 我想要… | 在Codex中用… | 例子 |
|---|---|---|
| 更改权限 | command | /permissions |
| 切换模型 | command | /model |
| 恢复会话 | command | codex resume --last |
| 应用审计标准 | skill | $types |
| 用特定方法审查代码 | skill | $improve |
| 写作符合编辑原则的文章 | skill | $blog |
那么，到底该用哪个？
简短的答案是：在Codex中，可重用的知识和工作流用技能，而操作控制用命令。
如果你来自Claude Code，你可能会本能地把任何可重用的工作流和/某命令绑定起来。这是可以理解的反应，因为Claude Code的文档本身确实有这样的提示。但在Codex上，这种反射近乎走不通。
先设计好技能，然后若需要更简洁的操作方式，再将其封装到插件或命令中。切勿本末倒置。
因为如果你一开始专注于按钮，而未明确工作流步骤，你最终会得到一个好看的界面，但功能却寥寥。这种现象在行业里实在是太常见了。
请谨记这一点：在Claude Code中，技能可以通过/命令的形式进入操作逻辑；但在Codex中，不能。而这种区分可能反而是好事。
当你理解了这个区别，就不会再纠结/types为什么不工作，而是开始构建真正适配工具的工作流了。还不算太糟，对吧？