从怀疑到离不开，需要多久？#

去年五月，Zach Proser 写了一篇 Codex 的初体验评测。那时候他的结论很克制：「有潜力，但还太粗糙。」任务成功率大概只有 40% 到 60%，多轮对话经常跑偏，错误信息让人摸不着头脑。

快进到 2026 年 3 月，他在 WorkOS 的 Applied AI 团队维护着多个部署在 Cloudflare 和 Vercel 上的全栈 JavaScript 应用。Codex 已经从「偶尔试试」变成了他日常开发流程的核心组成部分。

他用一句话总结了变化：「不是细微的改善，是天壤之别。」

一个典型的工作日早晨#

现在 Zach 的工作日是这样开始的：

打开 Codex，一口气丢进去 4 到 5 个任务，然后去倒杯咖啡。

比如这些：

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

这些任务曾经要吃掉他 30% 到 40% 的上午时间。现在 Codex 在后台处理这些，他可以先去看看消息、做做规划。等咖啡喝完，通常已经有 2 到 3 个 PR 等着他 review 了。

然后他才会切换到 Cursor 或者 Claude Code，去做更需要深度思考的架构性工作。

这种「双层工作流」的思路很有意思：让 Codex 负责那些模式明确、代码库成熟的维护性工作，把需要创造力的部分留给人类加专用工具。

成功率从 40% 飙到 85%#

这是最让 Zach 感到惊讶的变化。

一年前，Codex 处理维护性任务的成功率大概在 40% 到 60%。这意味着你丢 5 个任务进去，可能只有 2 到 3 个能用。剩下那些要么代码质量不行，要么直接报错。

现在，对于范围清晰、代码库成熟的维护性工作，成功率已经到了 85% 到 90%。这个数字意味着什么？意味着你可以放心地把日常琐事交给它，不用花太多精力去「调教」。

为什么提升这么大？Zach 总结了几个关键改进。

错误处理：从「静默失败」到「主动建议」#

一年前最让人抓狂的是：任务失败了，但你不知道为什么。错误信息要么没有，要么是天书。

现在完全不同了。任务失败时，Codex 会给出清晰的错误信息，甚至主动建议修复方案。从「神秘崩溃」变成了「这条路走不通，试试这个」，这种变化对开发体验的提升是巨大的。

多轮对话和分支更新：终于能迭代了#

旧版 Codex 的一个大问题是：你没法在同一个分支上持续迭代。每次修改都要开新 PR，这让大型重构变得很痛苦。

现在你可以：

  • 可靠地往已有分支推送后续提交
  • 就实现细节进行来回对话
  • 在现有任务上请求特定修改，而不用重新开一个

Zach 最近用 Codex 迁移了一个跨多个文件的复杂认证系统，多轮迭代居然真的跑通了。

预览迭代系统：像有四个人同时提方案#

这是最有趣的新功能。当你提交一个任务时，Codex 会生成 2 到 4 种不同的实现方案，让你选择。

比如一个 API 端点的实现，它可能给出：

  • 一个追求速度的精简版
  • 一个带有完整错误处理的稳健版
  • 一个优先考虑向后兼容的版本
  • 一个为未来扩展优化的版本

这种感觉就像有好几个资深工程师同时提出方案，然后你根据具体场景选最合适的那个。

网络连接：从「完全断网」到「精细化控制」#

一年前，Codex 的沙箱完全没有网络连接。这意味着你没法安装依赖、跑集成测试、或者调用外部 API。对于日常开发来说，这几乎是致命的限制。

现在 OpenAI 提供了细粒度的网络访问控制：

  • 仅包管理器：允许访问 npm、PyPI 等已知注册中心
  • 完全开放：放开出站访问，用于集成测试和 API 调用
  • 指定域名：白名单特定网站
  • 完全沙箱：和以前一样，完全隔离

这个改进解决了实际开发中最常见的痛点。安装依赖、跑测试、调用外部服务，现在都可以根据安全需求灵活配置。

最有意思的发现：Codex 在用 Codex 改进自己#

OpenAI 之前说过他们用 Codex 本身来改进 Codex。Zach 说，现在证据已经很明显了。

改进曲线陡峭而持续，这更像是系统化的自动优化，而不是简单的模型版本升级。那些在 2025 年中期稳定失败的任务，现在基本都能成功。更重要的是，失败模式从「莫名其妙崩了」变成了「这个方案不行，建议换一个」。

这种自我改进的循环很有意思：用户用 Codex 产生的数据，被用来训练更好的 Codex，然后用户又用更好的 Codex 产生更高质量的数据。飞轮效应正在显现。

还有什么不爽的？#

模型选择不透明#

你没法选择哪个模型来处理你的任务。Codex 内部会根据任务复杂度、代码库大小等因素自动选择。

对于理解不同模型能力边界的开发者来说，这种缺乏控制的感觉不太舒服。有时候你想用最强的推理模型去处理复杂的架构决策，有时候一个简单的 CRUD 生成用小模型就够了。

系统显然在做智能决策，复杂任务会分配到更强的模型，简单的就用更快的。但如果有手动覆盖的选项就更好了。

个人项目的体验#

在个人项目上，Codex 的表现甚至更好。当你有一个成熟的代码库，有明确的模式、规范和架构时，Codex 能非常一致地延续这些模式。

比如在 Zach 的个人网站项目中，他可以让 Codex：

  • 添加新的博客文章模板，带结构化元数据
  • 创建阅读进度指示器组件，匹配现有设计系统
  • 实现基于标签的博客索引页过滤

它理解现有的 Next.js 结构，遵循组件模式，尊重 Tailwind 类名的使用习惯，甚至保持了他偏好具名导出而非默认导出的编码风格。

一个值得借鉴的工作流思路#

Zach 的经验其实揭示了一个更通用的模式：

把 AI 编程工具分层使用。

第一层是 Codex 这类「后台执行者」，负责批量处理那些模式明确、范围清晰的维护性工作。你不需要盯着它，它可以并行跑多个任务。

第二层是 Cursor、Claude Code 这类「深度协作者」，用于需要人类判断力的架构决策和复杂功能开发。你和工具紧密配合，来回迭代。

这种分层不是非此即彼的选择，而是互补的组合。Codex 处理了原来吃掉 30% 到 40% 开发时间的琐事，让你能把精力集中在真正需要创造力的部分。

从「有趣实验」到「不可或缺的工具」#

Zach 最初的评测是谨慎乐观但最终持怀疑态度的。那种怀疑已经被日常使用彻底推翻了。

他的结论是：2026 年的 Codex 已经成为生产级基础设施，从根本上改变了他构建软件的方式。改进幅度大到他无法想象回到没有 Codex 的工作流。

这不只是一个工具的进化故事。它更像是一面镜子，映照出整个 AI 编程领域的加速度。一年前还是「研究预览」的东西，现在已经变成了「不可或缺」。

如果你还在观望，Zach 的建议是：别等了。今天存在的 Codex 和一年前他评测的那个，已经是完全不同的工具了。而且从改进的轨迹来看，未来只会更好。

参考来源：OpenAI Codex Review 2026 — Updated from Daily Use by Zach Proser