Codex

在每个使用编程智能助手的开发者生命中，总有一个时刻，你盯着月结账单看，心想：“这些服务确实很好用，可我的订阅怎么比小区健身房的会员费还多？” 那个时刻就这样悄然降临了。当时我同时订阅了Claude Max 5、Codex Plus，还在考虑加上Z.AI配合OpenCode处理廉价的机械性工作。理论看上去很美好。问题出在这样搞下去，就像一个管理乱糟糟工地的包工头，工人各忙各的，却没人看图纸。 我的初步想法很简单：在自动化分流之前，最好先手动做个小实验，持续两周。规则简单，但明确。 问题不在于成本，而在于协调 分开来看，支付23欧元、90欧元或者10美元一点也不算多。 问题在于，当每个工具开始互相干扰时，就开始麻烦了。你让一个助手思考，另一个实现，再让第一个检查，最后还要麻烦第三个处理一些琐事。二十分钟后，你已经搞不清楚是在优化成本、提升质量，还是单纯地折腾自己不停切换窗口了。 用大白话说：真正的成本不仅仅是订阅费，还有你的上下文切换成本。 就像一个厨房里同时有一把日本刀、一台智能厨师机、和一个空气炸锅。它们各有用处，各有千秋。但如果你用厨师机来炸土豆，那肯定不行。 假设：思考、执行、清理 我想要试验的规则说起来不过三句话： 用Claude进行思考 用Codex完成主要实现 用GLM/Z.AI处理基础任务 这不是学术讨论，而是一条实用的工作坊规则。 当一项任务模糊不清、涉及架构、存在风险或者需要判断时，把它交给擅长推理的代理是最合逻辑的选择。在这个实验中，就是Claude。 而当一项任务已经很明确，需要进入代码库、修改文件、运行测试并在错误间反复调试时，就轮到Codex登场。 至于那些没有人愿意干但必须有人去完成的工作，比如简单的测试代码、文档编写、小脚本处理、文件重命名或机械化的代码重构，那么就让GLM+OpenCode来试试。 暂不考虑的事情 目前还不考虑设置一个自动化分流器。 我不打算弄一个能自动读取提示词、分类任务、选择代理、按时间切换模型，还能输出漂亮图表证明其复杂性的魔法中介层。 这听起来或许是个超级有趣的项目，但也可能事倍功半。 这里最常见的错误是在真正需要航管之前就急着建塔台。先观察好了，再决定是否需要设置交通信号灯。 手动操作的两周实验 我的实验相当朴实，够不上“炫技”，但大概率更有用。 1. 用Claude处理复杂任务 当以下情况之一发生时，我会优先用Claude： 我不确定怎么入手 需要设计决策 存在破坏性风险 需要审查逻辑或论证，而不仅仅是代码 翻译成人话：如果任务需要准确判断，我不会吝啬。 2. 用Codex主导代码库工作 当任务已经清晰时，我会用Codex处理： 实现真实的功能修改 修复测试 带验证的重构 反复迭代，直到项目重新回到稳定状态 在这个阶段，一个好的执行代理最能展现价值。这不是模型本身的问题，而是流程的问题。 3. 用Z.AI负责简单工作 对于Z.AI，规则很简单： 模板代码 初稿 文档 简单的测试 小型脚本 文件重命名 容易检查的机械性操作 即使失败了，也没关系。可以随时丢弃，然后换成别的工具重做。 这才是关键。我不会向GLM要求飞针走线般的精细活，我的目标只是拧几颗螺丝。 最重要的规则：失败两次便升级 这一点是最重要的，但也最容易被忽视。 当一个便宜的工具失败了，你可能会倾向于继续试，“再试一次就好”，“这次应该可以”，“我改下提示词试试”，“再加点上下文”。半个小时过去了，你还在像与“抓狂的打印机”讨价还价一样调整模型。 我的规则是： 如果Z.AI1到2次尝试后仍失败，那我就提升它 如果是执行问题，转交Codex 如果是理解或设计问题，转给Claude 低成本工具一旦浪费掉太多时间，就不再低成本。 我要真正关注的是什么 我对“表演式性能对比”没兴趣。 不会去费劲列出诸如每秒处理字节数、平均延迟这类看起来“很专业”的表格，毕竟我的主要问题还是怎么快速重命名40个符号，而不是花一下午来折腾。 但我要在这两周内统计以下内容： 指标 意义 Z.AI吸收的简单任务数量 它是不是真的帮我减少负担 我有多少次需要提升任务 节省的时间和金钱是否值得 减少的Codex使用量 整体思路是否划算 切换工具的总耗时和难度 系统是否够流畅，易于长期使用 如果实验成功，那再好不过。 ...

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

TL;DR: 在165次Claude Code会话和27次Codex CLI会话后，我发现了一个清晰的模式：早上使用Claude来处理需要头脑风暴的互动型任务，下午让Codex完成可自动执行的具体任务。这不是哪个更好的问题，而是何时使用哪一个的问题。数据显示，两者结合远胜于单独使用任何一个。 早上九点，手握一杯咖啡，我脑中只有一个模糊的点子，准备重新构建一个模块。我不知道确切该怎么做，只是确信当前的模式并不理想。 于是我启动了Claude Code。 并不是因为它是“最好的”选择——而是因为我需要一种“自言自语”的方式，一个能理解上下文的助手。我告诉Claude：“这个服务的职责太多了，帮我拆分它。”随即，一场对话开始了。它提出一种分离方案，我讨论修改它，我让它探索另一种可能性，它在动手之前还会展示diff。这是一种协作的过程。 三个小时后，模块被成功拆分，测试通过，设计也有所改进。但这是我的Claude配额的40%。而我还列了一堆机械性任务，比如更新集成测试、清理无用的import、重整目录结构。 然后我打开了Codex。 我给它任务，设置为全自动模式，然后悠闲地去吃午饭。 数据揭示的模式 几个月来，我使用一款菜单栏应用监控自己的使用情况，这款工具记录了会话、token用量及耗时。以下是统计数据： Claude Code: 165次会话，160,893条消息，28,052次工具调用。使用模型：Opus 4.5和Opus 4.6。从缓存中读取了56亿token。 Codex CLI: 27次会话。使用模型：GPT-5.4。模式：danger-full-access，审批策略：never。 令我意外的首先是Claude Code的使用时间分布： 09:00 1 ▏ 10:00 5 ██ 11:00 10 ████▌ 12:00 14 ██████▎ 13:00 7 ███ 14:00 16 ███████▏ 15:00 21 █████████▍ 16:00 15 ██████▋ 17:00 18 ████████ 18:00 13 █████▊ 19:00 14 ██████▎ 20:00 9 ████ 21:00 10 ████▌ 22:00 8 ███▌ 我70%的Claude Code会话发生在下午，仅22%在上午。 初看这些数据，我还以为自己“清晨用Claude”的理论行不通。但深入分析每个时间段的任务类型后，一切都渐渐清晰。 上午用于探索，下午用于执行 Claude Code的上午会话少但时长较长。这些会话属于设计阶段：“这部分功能应该如何运作？”、“帮我审阅这个计划”、“能不能提供一些其他选项”。这些是一次又一次的讨论，需要反复修改观点，最终达成决定。 ...

你是否曾经在晚上 11 点写了一个技术计划，确信一切无懈可击，但第二天早上发现忘记添加身份验证？ 我深有同感，而且不止一次。最糟糕的不是这个疏忽——而是当你用人工智能来规划时，计划听起来是如此连贯，以至于你的大脑停止了对问题的挖掘。Claude 会生成一个带有章节、依赖项和执行顺序的文档，一切看起来都是高级工程师的作品。但问题是，没有人反驳过它。 Aseem Shrey 发布了一篇文章，精准点出了这个问题，并为此提出了一个优雅的解决方案：让第二个模型审查第一个模型的计划。而且不仅仅审查一次——循环审查，直到审查员说“通过”。 问题：没有人反对你的 AI 当你仅依靠一个模型来规划和执行时，你得到的结果确实连贯但没有争议。AI 不会反驳自己。它不会说“嘿，这个身份验证模型不完整”，或者“你的 shell 脚本中的引用有问题”。 这就像你自己写了一份文档，自我审查，然后对自己说“这可真是完美”。当然是完美的——毕竟是你自己写的。注意这个点：同行评审会存在于科学、工程和医疗领域是有原因的。并不是因为作者愚蠢，而是因为创作者通常是自己作品最差的审查者。 我以前在写我的 Jedi 代码审查委员会时讨论过这个问题。不过当时谈论的是如何审查代码。而 Aseem 的建议是先审查计划，在写出任何代码之前就发现问题。这相当于提前一阶段处理问题。 操作方法：Claude 规划，Codex 审查 这个过程基于 Claude Code 的一个“技能”实现——一个 Markdown 文件，无需额外的基础设施或外部服务。当你调用 /codex-review 时： Claude 会将计划写入一个临时文件。 计划会以只读模式发送到 Codex CLI（它可以读取你的代码库获取上下文，但不改动任何东西）。 Codex 审查后会给出结论：VERDICT: APPROVED 或 VERDICT: REVISE。 如果返回的是 REVISE，Claude 会修正计划并重新提交。关键在于，Codex 会恢复之前的会话，因此能够记住它之前的反馈，并验证问题是否真的被解决了。 审查最多迭代 5 次。在实践中，通常 3 次就足够了。 简而言之，这是两个 AI 之间的一次“拉取请求”，一个提出计划，另一个专注于找漏洞。全程无需人为干预。 3 轮迭代解决了 14 个漏洞 在 Aseem 的文章中，以一个多代理系统的控制面板为案例，循环审查从原计划中找到了 14 个问题： 第一轮（8 个问题）：写入端点没有身份验证。Shell 脚本的引用存在错误。数据模式的字段冲突。嵌套数组没有限制。未处理并发问题。仅支持手动测试。 第二轮（剩余 6 个问题）：非原子操作的声明。ACL 权限分配过于宽泛。未指定密钥轮换机制。状态建模不一致等问题。 第三轮：所有问题解决，计划获得通过。 ...

如果你读过我之前写的 关于 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，并且只操作相应的分支。 ...

安装 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 都会停止询问你，直接执行命令、修改文件、创建需要的内容。它将真正成为一个自主工作的代理。 ...

第一次使用Claude Code重构整个模块时，我几乎产生了宗教般的震撼体验。描述需求后喝了杯咖啡回来，就看见14个文件变更的PR，测试用例全更新，提交信息也像模像样。“这简直是魔法”，我当时这样想。 但根本不是魔法。就是个while循环。 OpenAI的Michael Bolin最近发文拆解了Codex CLI的内部机制。原来这些AI编程助手背后的秘密既不是革命性算法，也不是神秘神经网络，而是一个循环调用LLM、执行工具直到任务完成的简单流程。 让我们来庖丁解牛。 状态机：5阶段循环结构 所有编程助手——Codex、Claude Code、Cursor等都遵循相同的基础模式。Michael Bolin将其描述为5阶段循环： flowchart TD A["1. 提示词组装"] --> B["2. 模型推理"] B --> C{需要工具调用?} C -->|是| D["3. 工具执行"] D --> E["4. 工具结果反馈"] E --> B C -->|否| F["5. 生成最终响应"] F -->|新输入| A 用开发者能懂的话说： 提示词组装：构建包含系统指令、可用工具、读取文件、对话历史等完整上下文的提示词 模型推理：将提示词token化后传给模型，获取思维链/工具调用/文本响应 工具调用：若模型请求工具(读文件/执行命令等)，则运行对应操作 工具反馈循环：将工具执行结果作为新增上下文再次传给模型，重复2-4阶段 结果生成：当模型判定任务完成时输出最终响应 就这么简单。没有知识图谱，没有符号规划器，没有复杂架构。本质上就是个封装了LLM的while循环。 优秀助手与平庸助手的差异不在循环结构——它们完全一致——而在于每个阶段的实现细节。 阶段1：提示词工程的艺术 第一阶段是核心所在。在LLM看到任何代码前，助手需要构建包含以下要素的提示词： flowchart LR subgraph 提示词组件["提示词组装"] 方向 TB SP["系统指令\n(角色设定/规则)"] Tools["可用工具\n(读/写/Bash等)"] Ctx["已读取文件/图像"] Inst["CLAUDE.md/AGENTS.md\n(项目规范)"] Env["环境信息\n(OS/git状态等)"] Hist["完整对话历史"] User["用户最新消息"] end SP --> 最终提示 Tools --> 最终提示 Ctx --> 最终提示 Inst --> 最终提示 Env --> 最终提示 Hist --> 最终提示 User --> 最终提示 这里有个关键设计决策：组件顺序至关重要。提示词按稳定性降序排列：系统指令最前(永不变动)，工具定义次之(很少变动)，最后是动态增长的文件内容和对话历史。 ...

两周前，OpenAI 推出了 Codex Automations。简单来说：你定义一个触发器（如 cron、代码 push 或新 issue），写下自然语言指令，一个代理在独立的 worktree 中自动执行这一切。整个过程无需人类介入。在你睡觉时，代理自动整理 issues、总结 CI 错误、生成发布文档，甚至优化自身的指令。 听上去像魔法？确实有几分神奇。但他们在 keynote 里没怎么提到的一个细节是：你必须在桌面上运行 Codex App。支持 macOS 和 Windows。没有无头服务器的选项。安装在一个迷你 PC 上并丢一边任其运行？没门。 这时我想：“等等，我已经有这个了。” 你已经拥有的组件 如果你在使用 Claude Code，那么你已经拥有 90% 的基础设施。用命令 claude --print 就能在非交互式会话中执行提示（prompt）。传递指令，获取结果，关闭，不需要图形界面或者打开的终端窗口。这对于一个 cron 工作来说简直完美。 如果你已有一台永远开机的服务器（比如迷你 PC、树莓派，或者每月 5 欧元的 VPS），那么你已经有了调度程序。systemd 或 cron，任选一个，它们都已运行了多年，已经非常稳定。 如果你在用 Gitea、GitHub 或任何支持 API 的代码托管平台，意味着你已经有了存放结果的位置：PR 评论、新建 Issue 或直接提交文件。 用简单点的话说：Codex Automations 是一种范式，而不是一个产品。而且这种范式已经存在很多年了。 ┌─────────────────────────────────────────────┐ │ systemd timer (每隔 N 小时运行) │ │ │ │ │ ▼ │ │ bash/fish 脚本 │ │ │ │ │ ├── git pull --ff-only │ │ ├── claude --print "prompt" │ │ ├── 解析结果 │ │ ├── 通知 (Telegram/email) │ │ └── git push (如果有变更) │ └─────────────────────────────────────────────┘ 自动化的构成 所有的自动化都遵循同样的结构。一个脚本会经过以下步骤： ...