7.0
热点
AI SCORE
编程提效2025-05-20 22:29
OpenAI Codex编程能力实测评价
Hacker News · zackproser.com#Codex#代码生成
Editor brief · 编辑速览
对Codex代码生成工具的深度体验评测，分析其实际表现、局限和最佳应用场景。为程序员选型和使用AI编程提供参考。
对Codex代码生成工具的深度体验评测，分析其实际表现、局限和最佳应用场景。为程序员选型和使用AI编程提供参考。
我喜欢 Codex 的地方
意识和欲望是多线程的
我认为，它最终会支持我梦寐以求的无束缚工作流
通过聊天跟进
看起来不错——发布吧！
监控日志和任务进度
意识和欲望是多线程的
我认为，它最终会支持我梦寐以求的无束缚工作流
看起来不错——发布吧！
监控日志和任务进度
我期待改进的地方
糟糕的错误处理
代码质量与一次性完成任务
在同一分支上进行多轮更新
执行 sandbox 无法连接网络
代码质量与一次性完成任务
在同一分支上进行多轮更新
执行 sandbox 无法连接网络
它是否为我带来了惊人的生产力提升？
Codex 目前是一种以聊天为核心的使用体验。你可以通过受邀获得使用权限，也可以订阅 Pro 套餐（每月 200 美元）。
获得权限后，首先需要启用多因素身份验证，这是使用 Codex 的必要条件。接下来，你需要为希望 Codex 操作的每个组织授权 Codex GitHub app。
随后，Codex 会将你的代码仓库克隆到它自己的 sandbox 中，以便代你运行命令和创建分支。
如果你维护着几十个公开和私有代码仓库，这套配置体验非常棒，因为你无须离开当前界面，就能在不同项目之间切换，并为每个项目排队安排任务。
如果你只有一两个代码仓库，那么这套流程带来的额外负担，可能会比直接向 LLM 求助，或使用 Cursor 这类 AI 驱动的编辑器更重。
Codex 给我的感觉，就像是专门为我设计的。
通过 GitHub 连接，你可以指定当前指令针对哪个代码仓库和哪个分支。因为 Codex 对主聊天界面的设想，就是让你能在这里快速连续输入一天要做的任务，同时启动多个并行任务。
我浏览了一遍 Codex 最佳实践指南，它鼓励你根据需要启动任意数量的任务。目前的速率限制足以支持这种用法。
这是我最喜欢 Codex、也最期待它随着平台改进而发展的特性之一，因为它与我的工作方式十分契合。
开始工作时，我通常已经积累了一长串想要完成的事项，因此，通过自然语言并行启动大量任务，在我看来是一种很合理的交互方式。
正如我在《在树林里边走边与 AI 交谈》中所写的那样，理想情况下，我希望早晨先在办公室开始工作，启动一批任务，处理完一些规划事项，然后出门去大自然中长时间散步。
即使是现在，我也已经可以在手机上使用 Codex：
我认为，归根结底，等到一些棘手的边缘问题得到打磨之后，Codex 将能帮助我和其他人离开办公桌，依然高效地完成工作。
如果你想了解我是如何把 Codex 作为一个 Agent 系统，从头到尾融入其余开发工作流的，可以观看我在 DevSecCon 2025 上的主题演讲：
当初始任务运行了一段时间后，你可以点击进入任务，查看执行进度和日志，还能通过一个非常熟悉的聊天界面提出后续请求。
当你对某个分支上的修改感到满意后，可以让 Codex 为你创建 PR，它会自动填写 PR 描述。
你可以进入任意任务，查看聊天面板以及原始日志。日志会显示 Codex 为完成修改而启动的命令和 shell。
任务启动会失败。创建 pull request 也会失败。
截至撰写本文时，我已经试用了大约三天的 Codex。我还没有发现 Codex 模型的表现存在明显差异。OpenAI 称，该模型是 GPT-3 的后代，并且精通 12 种以上的编程语言。
目前的体验是，我可以并行启动多个任务，但每个任务大概只有 40%～60% 的概率能让我对结果足够满意，直接点击 Open PR 按钮，而不需要继续要求修改。
到目前为止，Codex 非常适合一次性派发大量维护级别的更新，例如细微的文案调整、样式修改，以及其他小型杂务。我也尝试过让它处理规模更大的重构，但整个体验很快就会变得繁琐。目前的工作流倾向于为每轮迭代创建一个全新的 pull request，这意味着想把后续 commit 推送到已有分支，即使在最理想的情况下也很别扭。
更新已有 PR 的体验很糟糕。
你无法确定修改究竟会不会、又会在什么时候被推送到现有分支，而且目前这个应用一直在鼓励你创建更多 pull request。这让多步骤重构变得十分棘手，因为你无法在 Codex 中可靠地针对同一个分支持续迭代。在这个流程变得更顺畅之前，我计划主要用它处理那些单次执行就能发布的快速收益型任务。
需要说明的是，我理解这是一项有意为之的设计选择。它能够缓解远程代码执行漏洞等安全风险。
但它目前也让 Codex 无法处理许多开发者在实际工作中希望交给它的任务，尤其是通过安装更新版本的软件包来解决烦人的依赖问题，并在此过程中重新生成相应的 lockfile。
Codex 目前无法访问互联网，但它确实会把你的代码仓库全新克隆下来，并提供给执行环境。
这意味着，即使你要求它执行，Codex 也无法运行 pnpm add @tar-fs@latest。因此，目前我仍然需要把这些分支拉取到本地进行修复，或者在支持这种操作的 PR 下评论 @dependabot rebase。
还没有，但我能看到，在以下条件实现后，它会做到这一点：
更多任务可以通过进一步改进或模型训练实现一次性完成，或许还可以根据不同任务，在不同模型之间进行多路调度。
改善创建分支以及向已有分支推送修改的开发者体验，从而能够更新已经打开的 pull request。
Codex 能够与更多 OpenAI 平台能力集成，例如生成图片。
Codex（有可能）进一步成为人类主要使用的高层编排与信号传递层。
目前，Codex 很适合在一天开始时集中清理那些优先级较低、数量众多且繁琐的维护任务和小型更新。
对于重要的重构或功能开发，我目前仍然更适合亲自在 IDE 中完成，并按需使用 LLM 辅助。
我相信，不久之后，Codex 将成为开启一天工作、持续掌握哪些事项需要关注以及接下来该做什么的理想界面。
目前在 WorkOS 从事 Applied AI 工作。此前曾任职于 Pinecone、Cloudflare 和 Gruntwork。全栈开发者——覆盖数据库、后端、middleware 和前端——并长期深耕基础设施即代码与云系统。