Codex 要定「每周四大版本日」!AI 编程工具的发版节奏,正在向 Chrome 看齐

「周四发大版本，你们觉得怎么样？」

5 月 12 日，Codex 团队成员 Tibo（@thsottiaux）在 X 上抛出一个问题：

"For Codex, we've been thinking about keeping a stable release cadence and have a larger release each week on Thursday. That does make the start of the week a bit less exciting. Thoughts?"

「我们一直在考虑让 Codex 保持一个稳定的发版节奏，每周四放出一个更大的版本更新。这确实会让一周的前半段没那么刺激。大家怎么看？」

▲ Codex 团队成员 Tibo 在 X 上公开征求「周四大版本」意见

回复区的反应很能说明问题。

有人直接说："Predictable beats exciting every single time"——可预期永远比惊喜重要。有人已经在喊"Thursday = release day"。也有人从日常使用出发反馈：更新本身没问题，但有时候刚更完又马上推一版，体验上很割裂。

注意这条帖子在聊什么——整个焦点就是「什么时候发版」。没有聊新功能，没有聊模型升级，纯粹在讨论发版节奏。

Codex 团队把发版节奏拿出来公开讨论，这个动作的含义比发十个新 feature 都大。

changelog 已经在说话

觉得「固定节奏」只是嘴上说说？OpenAI Developers 官方 changelog 已经能看出端倪。

▲ OpenAI Developers 官方 Codex changelog，2026 年 5 月上旬密集更新

光是 5 月上旬，changelog 上就排满了：

• 5 月 11 日
  ：Expanded Auto-review documentation
• 5 月 8 日
  ：Codex CLI 0.130.0
• 5 月 7 日
  ：Codex for Chrome + Codex CLI 0.129.0
• 5 月 6 日
  ：Codex analytics governance docs update

几天之内，CLI 新版、浏览器扩展、文档更新、治理说明……全部在同时推进。Codex 的产品面已经变得很厚。

当更新密度高到这个程度，团队开始考虑固定发版节奏，完全是顺理成章的事。

版本时间线：周四确实在成为「落点」

changelog 只是定性感受。GitHub Releases 和 npm 的版本时间线提供了更精确的数据。

▲ Codex GitHub Releases 页面，0.130.0 稳定版详情

最近几个稳定版的发布时间对照：

0.128.0 和 0.129.0 都落在周四，间隔刚好 7 天。周四作为稳定版落点，已经有了实际痕迹。

但另一面也值得注意：0.130.0 在 0.129.0 发布仅 30 小时后就跟上了，Codex 的工程流水线跑得飞快。团队想做的，更像是在高速运转的流水线上设置一个「用户可感知的稳定节点」——底层迭代照样跑，但对外的大版本收拢到固定日期。

更关键的细节：0.130.0 稳定版之后，GitHub 上很快就接上了多条0.131.0-alpha预发布。稳定版日历和内部预发布流水线正在分层——这恰恰是浏览器最经典的做法。Chrome 有 stable / beta / dev / canary 四个通道，Codex 目前还没这么完整，但「稳定版按节奏走 + alpha 高速流动」的雏形已经出现了。

用户已经在喊：更新太快，跟不上了

从工程角度看，高频更新当然好。但从用户体验看，更新快到用户跟不上，就成了产品问题。

GitHub issue #19948 把这个痛点摆到了台面上。

▲ GitHub issue #19948：用户反馈 Codex App 更新频繁但缺少 release notes

提交者的原话：

"I see tons of updates for the codex app happening, which is really cool. however, I do not see any release notes for the app? is that intended?"

「Codex app 的更新非常多，很酷。但是我看不到 app 的 release notes？这是故意的吗？」

"I 'have to' update my app basically once a day, sometimes even more than that and nothing shows up."

「我基本上每天都'必须'更新一次 app，有时候一天不止一次，但什么说明都没有。」

用户的诉求已经从「希望有新功能」变成了「希望知道更新了什么、什么时候更新」。这正是成熟软件用户的典型心态。

回看 Tibo 那条帖子，逻辑就通了：团队想固定周四大版本，背后的驱动力之一，就是用户已经在用对待生产级工具的方式来使用 Codex——他们需要可预期的节奏。

开发者社区怎么看：Codex 已经在和 Claude Code「掰手腕」

Hacker News 上，Codex 的讨论帖拿到了516 points，标题是 *"OpenAI Codex CLI: Lightweight coding agent that runs in your terminal"*。

▲ Hacker News 上关于 Codex CLI 的讨论，516 points

讨论区的画风完全是「成熟开发工具对比评测」：

Codex 被直接放到和 Claude Code 对打的语境里。有评论直说，Codex 就是对 Claude Code 快速 shipping 的直接回应。社区已经把 AI coding assistant 当成一个比迭代速度、比工作流契合度、比工程成熟度的产品品类。

terminal-native 被当作独立产品方向。有评论指出，OpenAI 和 Anthropic 都在推 terminal 里跑的工具。一旦进了 terminal-native agent 赛道，用户对发版的期待就更接近传统 CLI 工具和浏览器——跟模型榜单刷新已经是两回事了。

用户已经在做 head-to-head 测试。有人拿 Codex o4-mini 和 Claude Code 对同一段代码做文档编写任务对比，有人转头拿 Amazon Q Pro on the CLI 比成本。谁更稳定、谁更顺手、谁更便宜、谁升级更频繁、谁 bug 更少——这些讨论维度，和十年前开发者比较 Chrome vs Firefox 的时候如出一辙。

外部从业者的判断：这已经是 first-class product

竞品 Augment Code 在 4 月中旬发了一篇博客，标题是 *"OpenAI releases Codex CLI: what developers should know"*。

▲ Augment Code 博客分析 Codex CLI，2026 年 4 月 16 日

文中有几个数据值得注意：截至 4 月中旬，Codex 在 GitHub 上已有75.6K stars、10.7K forks、709 个 releases。作者把 Codex CLI 定义为 terminal-native coding agent，并认为这个发布速度说明 OpenAI 把 Codex 当成了first-class product surface（一线产品入口）。

这是第三方观察，但它反映了一个市场共识：Codex 已经被当成需要持续评估、持续比较、持续追踪版本的生产级开发工具看待，一条发布新闻看完就完事的阶段过去了。

为什么说 AI 编程工具正在进入「浏览器时代」

把所有线索拼到一起：

• X 帖子
  ：Codex 团队公开讨论固定周四大版本
• 官方 changelog
  ：更新密度极高，覆盖 CLI、浏览器扩展、文档、治理等多条产品线
• GitHub + npm 时间线
  ：最近稳定版确实集中在周四，同时 alpha 预发布高速流动
• GitHub issue
  ：用户已经开始抱怨更新太快、说明跟不上
• HN 讨论
  ：Codex 被放进 Claude Code、Amazon Q 的对比评测语境
• 外部博客
  ：从业者已经在按 first-class product 追踪 Codex

这些信号指向同一个方向：AI 编程工具的竞争正在进入新阶段。

早期，拼的是「有没有这个能力」。中期，拼的是「谁的模型更强、上下文更长、价格更低」。现在，竞争已经延伸到产品运营层面——什么时候发、发完用户能不能看懂、高频更新会不会打断工作流、能不能让重度用户形成日历级别的预期。

这就是浏览器、IDE、数据库客户端、CI 工具这些成熟赛道都走过的路。更新可以快，但必须让用户有节奏感。

边界也要划定：Codex 目前还没有正式宣布「固定每周四大版本」，现有证据更接近「团队已经在认真考虑，并且实际发布节奏正在往那个方向收拢」。完整的 stable / beta / dev / canary 多轨制度也还没形成。

但趋势已经足够明确——当一个 AI 编程工具开始认真讨论「哪天发版」的时候，它已经不只是模型套壳了。它正在变成一个真正的软件产品。

— END —