编程工具 on Codexer

Codex 生产力实录：一个开发者用了快一年后的真实感受

Mon, 18 May 2026 09:00:00 +0800

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

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 有一个让人抓狂的问题：任务失败了，但你不知道为什么。没有报错信息，没有建议，就是静静地失败了。

Claude Code 和 Codex 不是竞品：一个开发者同时用了一个月的真实体悟

Sun, 17 May 2026 09:00:00 +0800

一个「不选」的选择

很多开发者在选 AI 编程助手时，脑子里总有一个执念：哪个更好？Claude Code 还是 Codex？我要选出那个唯一的最优解。

这种想法可以理解，但也是陷阱。

一位开发者在 2026 年 4 月做了一件事：删掉所有第三方工具（Aider、Continue、各种 VS Code 插件），只留下 Claude Code 和 ChatGPT Codex 两个官方产品。他的预期是一周内决出胜负。结果一个月过去了，他两个都在用，而且离不开任何一个。

这不是优柔寡断。这是认知升级。

它们的本质完全不同

把 Claude Code 和 Codex 放在一起比较，就像把厨师刀和慢炖锅放在一起比较。它们都能做出晚餐，但你用规格表来对比它们，就会完全错过重点。

Claude Code：终端里的结对伙伴

Claude Code 运行在你的本地终端。在项目目录下敲 claude，它就拥有了你文件系统的完整读写权限。它实时编辑文件，你能看到它在做什么。发现方向不对，随时打断、纠正、调转方向，对话继续进行。

用一个比喻来说：它就像一个阅读飞快的同事，坐在你旁边看你的屏幕。

核心特征是「同步」和「对话」。你必须在场，你得参与，你得引导。

Codex：云端的异步实习生

Codex 完全不同。你给它一个任务描述，它在云端的沙箱环境里克隆你的 GitHub 仓库，然后安安静静地干活。任务完成后，它提交一个 Pull Request 给你。你可以在午饭前排五个任务，午饭后一起审查 PR。

用一个比喻来说：它就像一个远程工作的实习生，只交完整的报告。

核心特征是「异步」和「托管」。你可以走开，它可以独立工作。

关键差异速查

维度	Claude Code	Codex
运行环境	你的本地机器	OpenAI 云端沙箱
交互方式	同步对话	异步排队
文件访问	直接读写本地文件系统	沙箱中克隆的 GitHub 仓库
终端管道	支持 `claude -p`	不支持
订阅价格	Pro $20，Max 5x $100	Plus $20，Pro $100
最佳场景	深度调试、架构讨论	批量任务、无人值守

二选一的代价

这位开发者尝试过两周只用 Claude Code，也尝试过两周只用 Codex。两次实验都以失败告终。

Codex 30 天实测：零手写代码的背后，人类还剩下什么？

Wed, 13 May 2026 10:00:00 +0800

一个月前，我还在手写代码

一个月前，我的日常是这样的：打开 Xcode，敲键盘，调试，重构，再敲键盘。我已经用 ChatGPT 辅助开发很久了——我那些从 Objective-C 迁移到 Swift 的十几万行代码里，有不少是 LLM 帮忙写的。但本质上，我还是那个在键盘上敲代码的人。

直到 Xcode 26.3 发布，内置了 Codex 集成。我好奇地试了一下，然后就再也没有回去过。

这篇文章不是评测。不是功能介绍。这是一个独立开发者花了整整一个月，用 Codex 做了所有他能想到的"疯狂实验"之后，写下的真实记录。

前情提要：我没有写过一行代码。全程。

第一周：从怀疑到震惊

第一个实验：一小时内做出完整 App

我很谨慎。我甚至不敢让 Codex 碰我的真实代码库。于是我挑了一个 Todo 列表里躺了很久的小项目——一个「时间线」App，让它从零开始。

我给了它一个 Markdown 格式的编码风格文件（类似于 AGENTS.md 的概念），以及一个预配置好的 Xcode 项目模板。然后就开始了。

一两个小时后，我得到了一个完整的 Mac/iPad 应用：有数据模型、能持久化到磁盘、支持打印和导出 PDF、自定义布局容器和拖拽选择。不是 Demo，不是原型，是可以直接上架 App Store 的应用。

我查了一下预算：用了 7% 的月度配额。对，一个完整 App，只花了我月配额的 7%。

第二个实验：更复杂的非标准 UI

一个像素绘图 App——有浮动面板、毛玻璃效果、可缩放画布、在安全区域内居中显示内容并支持过度滚动。这些东西我自己写至少要好几天，Codex 在一个会话里就搞定了。

到此为止，它做的所有事情都在 Xcode 的沙盒里完成。但是很快，我就不满足于沙盒的限制了。

iPhone → Android：两次远离原始代码的移植

我从 Git 历史里翻出了十年前的 SameGame——一个用 Objective-C 写的经典消除游戏。里面有早已废弃的音频 API、已经死掉的 Flurry 统计、还有为各种屏幕尺寸打的一堆补丁。

我让 Codex 把它一次性迁移到 Swift。