从「看起来不错」到「真的离不开」#

2025 年 5 月，OpenAI 发布了 Codex 的研究预览版。当时很多人试了一下，觉得「嗯，有点意思」，然后就回去继续用 Cursor 或者 Copilot 了。Zachary Proser 也是其中之一。他在第一时间写了评测，态度是「谨慎乐观但总体持怀疑态度」。

快一年过去了，他更新了自己的评测。结论很简单：之前的怀疑已经被彻底推翻了。

这不是又一篇「AI 改变世界」的鸡汤文。这是一位在 WorkOS Applied AI 团队工作的工程师，每天用 Codex 处理真实的生产代码，用数据和具体场景告诉你，这个工具到底好在哪里，还有哪些地方不够好。

他每天早上的工作流#

这是整篇文章最有价值的部分。

Zachary 的一天从一杯咖啡开始。但在喝咖啡之前，他会先做一件事：把当天要做的维护任务批量扔给 Codex。

比如某天早上的任务清单：

  • 修复用户注册流程中的 TypeScript 类型错误
  • 更新 Webhook 端点以支持新的事件格式
  • 给管理后台的 React 组件加上更好的错误边界
  • 把旧的认证中间件迁移到新的会话管理系统

这些任务有一个共同特点：它们属于「已知模式的重复性工作」。代码库里已经有了类似的实现，Codex 要做的是照着已有的风格把新功能补上。

以前这些事情会吃掉他 30% 到 40% 的上午时间。现在他把这些任务塞进 Codex 的队列，去喝咖啡、看消息。回来的时候，通常已经有 2 到 3 个 PR 准备好等他 review 了。

成功率从最初的 40%~60%，涨到了现在的 85%~90%。 这个数字只针对「范围明确的维护性任务」。更复杂的架构性工作，他仍然会用 Cursor 或 Claude Code 来做。

这就是他所说的「两层工作流」：Codex 负责 SDLC 中的体力活，专用编码工具负责需要深度思考的部分。

真正变好的三件事#

稳定性和错误处理#

2025 年的 Codex 有一个让人抓狂的问题：任务失败了，但你不知道为什么。没有报错信息，没有建议，就是静静地失败了。

现在不一样了。当任务失败时，Codex 会给出清晰的错误信息，甚至会建议修复方案。从「神秘崩溃」变成了「这个方案行不通，试试这个」。对于一个每天要处理大量任务的工具来说，这种透明度至关重要。

多轮对话和分支迭代#

早期的 Codex 有一个很别扭的工作流：每次迭代都要开一个新 PR。你想在一个分支上继续改？非常困难。

现在你可以：

  • 往已有分支上追加 commit
  • 在任务里来回对话，讨论实现细节
  • 对具体改动提出修改意见，而不用重新开任务

这一点的提升是质的飞跃。Zachary 提到他用 Codex 完成了一次跨多个文件的认证系统迁移，整个过程通过多轮对话逐步细化，最终成功了。这在一年前是不可想象的。

代码质量和上下文感知#

生成的代码质量明显提升了。Codex 现在能：

  • 更一致地遵循已有的代码风格和模式
  • 处理你没有明确提到的边界情况
  • 在实现过程中主动建议性能优化
  • 跨文件保持 TypeScript 类型的一致性

特别是最后一点。在大型 TypeScript 项目中，类型一致性是个容易出错的地方。Codex 能理解项目中已有的类型定义，并在新代码中正确引用，这说明它对代码库的「理解」确实在加深。

一个值得关注的新功能：预览迭代系统#

Codex 新增了一个预览功能。当你提交一个任务时，它会生成 2 到 4 个不同的实现方案，让你选择一个来执行。

Zachary 举了一个例子。他要创建一个新的 API 端点，Codex 给了他四个版本：

  1. 最小实现，侧重速度
  2. 健壮版本，包含全面的错误处理
  3. 向后兼容方案，不会破坏现有接口
  4. 可扩展版本，为未来的功能留出空间

这个功能的价值在于，它把「选方案」这个决策权留给了开发者。AI 负责生成选项，人负责判断哪个选项最适合当前的业务语境。

还不够好的地方#

模型选择不透明#

你仍然无法选择 Codex 用哪个模型来处理你的任务。系统会根据任务复杂度、仓库大小等因素自动选择。

对于理解不同模型之间权衡的开发者来说，这种不透明性确实令人不爽。有时候你想让最强的模型来处理一个复杂的架构决策，有时候一个简单的 CRUD 生成用小模型就够了。目前你只能接受系统的安排。

网络访问（已大幅改善）#

这是 2025 年的一个主要痛点。Codex 的沙箱环境完全无法访问网络，这意味着你没法安装依赖、跑集成测试、或者调用外部 API。

现在已经有了细粒度的网络控制选项：

  • 仅限包管理器：只允许访问 npm、PyPI 等注册表
  • 完全联网：允许所有出站请求
  • 指定域名：只允许访问白名单中的站点
  • 完全隔离：和以前一样，不允许任何网络访问

这个改进使得在 Codex 里跑完整的项目成为可能，而不只是做单文件的编辑。

Codex 在训练 Codex#

OpenAI 之前声称他们用 Codex 自身来改进 Codex。从一年的使用体验来看，这个说法得到了印证。

改进曲线非常陡峭，而且持续稳定，不像是「偶尔回来更新一下模型」，更像是「系统性地、自动化地在优化」。失败模式也从「神秘崩溃」变成了「这个方案不行，换一个试试」。

这种反馈循环本身就很有意思。用户每天产生的 Codex 使用数据，被用来训练下一代 Codex，然后用户得到更好的体验，产生更多数据。这是一个正向飞轮。

对实际工作的影响#

Zachary 的总结是：Workflow 确实被改变了，而且是根本性的改变。

具体体现在：

  1. 晨间例行：3 到 5 个任务并行启动，喝咖啡回来就有 PR 可以 review
  2. 功能开发：在成熟的代码库中，先画架构，再让 Codex 处理实现细节
  3. 维护积压：依赖更新、文档修复、测试覆盖率提升这些「一直想做但没时间做」的事情，现在可以一股脑扔给 Codex

在 WorkOS 的团队层面，功能交付速度有了可衡量的提升。不是因为 Codex 取代了开发者，而是因为它接管了那些消耗 30%~40% 开发时间的实现性体力活。

几点思考#

读完这篇评测，有几个点特别值得琢磨。

第一，「两层工作流」可能是未来一段时间的主流模式。 用 AI 处理可批量化的维护性任务，用传统工具处理需要深度思考的架构性工作。这不是在两个工具之间选一个，而是让它们各司其职。

第二，「成熟的代码库」是 Codex 发挥实力的前提。 如果你的项目结构混乱、没有统一的风格规范、缺少类型定义，Codex 的表现会大打折扣。这反过来要求团队在代码质量上投入更多，AI 不是万能的，它需要一个好的基础才能工作。

第三，成功率 85%~90% 听起来很高，但剩下的 10%~15% 仍然需要人来兜底。 这意味着你不能完全放手，review 环节不可或缺。但如果 90% 的 PR 质量已经可以接受，review 的重心就从「检查实现细节」变成了「确认方向是否正确」，这本身就是效率提升。

第四，Codex 训练 Codex 的飞轮效应值得关注。 当一个 AI 工具的用户量足够大，使用数据的反馈就能形成自改进循环。这可能是 OpenAI 在编程工具赛道上的一个结构性优势。

参考来源：OpenAI Codex Review 2026 — Updated from Daily Use，作者 Zachary Proser，2026 年 3 月 2 日发布。本文基于原文核心观点进行了原创分析和重写。