在Codex中,技能不是/命令(在Claude Code中几乎是)

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中分离的两个概念合并了: ...

2026年3月30日 · Fernando

Codex CLI 没有 worktrees(教你手动实现!)

如果你读过我之前写的 关于 Claude Code 中 worktrees 的文章,你应该知道这个功能的核心就是一个小小的参数:--worktree。执行这个参数之后,每个代理都能在一个隔离的代码仓库副本中运行。每次启动一个代理程序,就在独立的目录中操作。三个代理同时跑也互不干扰,仿佛魔术一般。 现在打开 Codex CLI,想找一下等效的参数,结果发现它根本不存在。 没有 --worktree。没有 --tmux。也没有支持自定义代理的 isolation: worktree 参数。而且,尽管issue #12862 在 GitHub 上已经开了很久,并且已经有人在 fork 中实现了这些功能,但官方始终没有合并代码。到目前为止,Codex CLI 还是无法原生支持多个代理并行操作。 这是否意味着无法使用 Codex 实现并行工作?答案是否定的。这只是意味着你需要自己动手 “折腾” 一下。而这件事说穿了,不过是几个 git 命令和一些预防措施。 计划:手动 worktrees + 每个目录运行一个 Codex 整体思路跟 Claude Code 中的方法类似,只是没有自动化功能。简单来说,就是你自己创建 worktree,自己启动代理程序,事情完了也需要自己清理。这工作听上去有点人工,但它确实管用。 # 从你的主仓库目录开始 cd ~/code/mi-proyecto # 为每个任务创建一个 worktree git worktree add ../mi-proyecto-feat-auth -b feature/auth git worktree add ../mi-proyecto-fix-tests -b fix/tests-rotos git worktree add ../mi-proyecto-refactor -b chore/refactor-db --- 现在你有四个目录:一个主目录和三个 worktree,每个 worktree 都是相互独立的。每个 worktree 拥有自己的分支、暂存区 (*staging area*) 和 HEAD,但共享仓库的元数据(`.git/` 目录),其他一切隔离。 接下来,在每个 worktree 运行一个 Codex: ```bash # 终端 1 cd ../mi-proyecto-feat-auth codex --approval-mode never --sandbox workspace-write \ "实现 JWT 鉴权中间件,编写测试代码。" # 终端 2 cd ../mi-proyecto-fix-tests codex --approval-mode never --sandbox workspace-write \ "运行测试套件,修复所有失败的测试,一直重复直到全部通过。" # 终端 3 cd ../mi-proyecto-refactor codex --approval-mode never --sandbox workspace-write \ "重构数据库模块以使用连接池功能。" 三个代理,三个任务,它们互不干扰。每个 Codex 只看到自己对应的 worktree,并且只操作相应的分支。 ...

2026年3月11日 · Fernando

纪律战胜魔法的一周

我本周发布了六篇文章。一篇关于 PostgreSQL,另一篇关于人工智能代理的,一篇关于上下文管理的教程,一篇自动化的教程,一篇调试案例分析,最后一篇是关于为评估 MVP(最小可行性产品)设计对抗性建议的。 这些并非有计划发布,而是每一篇都从一篇论文、一场演讲,或是一个某种程度上让我感到有趣的项目衍生出来的。可当我将它们汇聚到一起时,却发现了一个自己在写的时候没有注意到的“共同主线”。 这六篇文章说的是一回事。 不经意间发现的模式 最开始是在看 Bohan Zhang 关于 OpenAI 如何扩展 PostgreSQL 的文章得出的结论。这篇文的结尾非常震撼——8 亿用户,只用一个 primary,没有分片。PgBouncer(发布于 2007 年)。只读副本(90 年代的概念)。这世上最无趣的技术,却支撑了历史上应用最广泛的一个服务,至今依旧“仍在很好地运行”。 接着是 Michael Bolin 解析 coding agents(代码代理)构造的文章。不管是 Codex CLI,还是 Claude Code,剖开内部,你会发现它们其实是一个 带 LLM 的 while 循环。没有知识图谱,没有符号规划。有的只是一个循环、一些工具,还有模型决定该停止的时间点。它的“魔法”其实就是一个 while True。 之后是 OpenAI 的关于 上下文工程(Context Engineering) 的 Cookbook 文章。事实是,模型看到的内容比模型本身更重要。而这些技术并不新鲜:启动时注入上下文(相当于一个 README 文档),剪切历史记录(类似循环缓冲区),压缩旧的内容(通过总结)。这些方法早在 2000 年代的聊天系统中就已出现。 然后是那个 自动化教程,更是对此的有力印证:OpenAI 的 Codex Automations 是 cron + curl + 一个 LLM。完全字面意义上就是这样。Unix 系统中最老套的调度器接口,调用当今世界上最前沿的模型。这基础设施已经存在了 40 年,而这“脑袋”才开发了两年。 接着还有两个非基础设施主题的帖子。那个 Jane Street 的谜题 中,一个神经网络有 2500 层,但结果证明它只是一个 MD5。这解法靠的是传统的调试思维:观察数据形式、逐步缩小范围、叠加约束条件,直到剩下唯一可能的答案。工具可能是新的(SAT 解算器,ChatGPT),方法却是老的(有条不紊地假设排除法)。 最后一篇是关于 用对抗性建议评估 MVP 的文章:用 LLM 模拟 5 个专家去评估创意的可行性,这听起来很高科技,直到你发现它其实就是一种 战争推演方法。从 50 年代开始军队就在用了,产品团队也称之为 预死因分析(pre-mortems)。创新之处无非在于,现在只用 2 美元在云端即可串联这些分析,而用不到雇佣 5 万美元的顾问了。 ...

2026年3月11日 · Fernando

Codex CLI 自动同意:两个标志让它不再打断你

安装 Codex CLI 后,满怀期待地启动它。你告诉它“修复这个代码库中失败的测试”。然而,灾难随即开始: Codex: I want to run pytest Allow? (y/n) 你输入了 y。接下来: Codex: I want to modify test_user.py Allow? (y/n) 又输入了 y 。一次又一次,每次需要读取一个文件、执行一个命令或者修改一行代码,它都会请求确认。确认,确认,还是确认。这感觉就像跟一个刚入门的实习生合作,他每次连去洗个手间都要问你同不同意。 与此同时,Claude Code 或 Cursor Agent 却可以实现相同的功能,但却不会多说一句话。这是为什么? 原因在于:默认情况下,Codex 被配置为一个“过于谨慎”的助手。这么做是为了安全考虑,尤其是针对一款新产品来说是很合理的。但如果你对操作足够了解,这种保守模式在实际工作中将让人无法忍受。 好消息是:只需几秒钟便能调整过来。 权限模式:approval mode Codex 使用一种叫做 approval mode(批准模式)的概念来控制需要你授权的情境。默认设置下,它对所有操作都需要你的确认: 执行命令 写入文件 修改代码 创建新文件 运行测试 简单来说:默认状态下,Codex 无法在没有你按下 y 键的情况下做任何事情。可以将其形容为:对每一个操作都需要一次 sudo 操作。 这使得一个本应是自主代理的工具,变成了一场你成为整个过程中最慢环节的无休止对话。 解决方案:使用一个标志 codex --full-auto 从版本 0.1.2 起,--full-auto 是官方的快捷方式,它将 --approval-mode never 和 --sandbox workspace-write 两个参数组合在一起。如果你使用的是旧版本,也可以用完整写法: codex --approval-mode never 无论选择哪种方法,Codex 都会停止询问你,直接执行命令、修改文件、创建需要的内容。它将真正成为一个自主工作的代理。 ...

2026年3月11日 · Fernando