写代码之后 AI 还能自己验证？Codex 这两个更新有点值得聊

哈喽，我是飞飞。

昨天 OpenAI 推了两个 Codex 更新，刷到的人大多划走了。我多看了几眼，越琢磨越觉得这两件事放在一起挺值得聊的。

一个是浏览器开发者模式：Codex 现在可以通过 Chrome DevTools Protocol 直接读取浏览器的控制台输出、网络流量、DOM 状态和运行时报错。另一个是速率重置攒存：以前 Codex 的额度重置是系统定时触发的，你没法选择时机；现在可以把这次重置先攒着，等你真正需要的时候再用。

一个在加能力，一个在改体验。背后有同一个逻辑。

CDP 开发者模式：AI 助手终于能自己「看见」报错了

以前 Codex 调试的流程是什么样的？

你让它修一个前端 bug，它写完代码，交给你。你在本地跑，报错了，F12 打开 DevTools，看 console，截图或者把错误信息粘出来，再发给 Codex 说明一遍，它才知道刚才发生了什么，再改一轮。

这个流程里，你是 Codex 和浏览器之间的传话筒。Codex 写代码，但它看不见代码跑起来是什么样的。

这次 CDP 开发者模式把这个传话筒去掉了。

Codex 现在可以主动读取：

• console 里有没有报错，是什么类型的
• 某个网络请求是不是挂了，HTTP 状态码是什么
• 当前页面的 DOM 结构对不对
• 有没有未捕获的 JavaScript 异常

说白了，Codex 以前写完就交卷，现在写完还能自己翻一下答案。

DOM 快照读取同样开放。以前你跟 Codex 说「按钮怎么不显示了」，你得自己进 DevTools 截图、粘出 DOM 结构，再贴给它看。现在 Codex 自己能读到当前页面的 DOM，直接判断这个按钮在不在、样式有没有被其他选择器覆盖。

一个具体场景：你告诉 Codex「登录之后页面是空白的，帮我查一下」。老流程里，Codex 只能根据代码逻辑猜测可能是哪里的问题，你再去 DevTools 里核实，发现是某个 API 请求返回了 401，贴给 Codex，它才知道是 Authorization header 没带上。新流程里，Codex 直接开 CDP，自己看到那个 401，定位到对应的 fetch 调用，直接去改 header，整个过程你不用插手。

这个变化比表面看起来大。

实际写代码，生成那几行代码往往是最快的。后面的调试循环才是真正吃时间的：跑起来看效果，有问题定位根因，修了再跑，再验。一个只覆盖「生成」这一截的 AI 助手，等于帮你做了开发流程里比较轻松的那部分，把最耗精力的那部分留给你自己。

顺带一提，这次一起推出的还有 Browser use 整体提速 2 倍，是 CDP 直读数据比截图识别效率高得多带来的额外收益，日常用起来体感应该会明显一些。

一个 AI 助手会调试浏览器，这意味着什么？

关于这件事的意义，我有个判断，说出来可以不同意。

现在大家评价 AI 编程助手，多数还是在比写得准不准、补全聪不聪明。但写代码和验证代码是两件事，目前验证这部分几乎全靠人来兜底。

CDP 这一步，是 Codex 开始接验证这个盘。

口子一开，Codex 的价值主张就开始变了：从「帮你写代码」走向「帮你写，还帮你看结果对不对」。

我知道，现在还是受控调试，Codex 没法完全自主地在浏览器里跑一套完整的端到端测试。但它能读 console、读网络请求，这个口子一开，方向已经很清楚：AI 助手会越来越深地参与「写→跑→看→改」这个循环，而不只是停在写这一步上。

帮你写 10 行代码，和帮你写 10 行代码然后自己看一遍报错告诉你「第三行逻辑有问题，请求带的 token 格式不对」，对工作流的影响不是一个量级。

说到底，AI 助手要真正嵌进开发者的工作流，不能只管生成那一半。

速率重置攒存：一个小功能，但开发者在意了很久

相比 CDP，速率重置攒存这件事小多了。但社区反应不小，因为这是反复有人提过的需求。

以前的问题是：Codex 的额度用完之后，系统会在某个时间点自动重置，但这个时机你说不上话。重置了但你正在做别的，没用上；等你真正要赶 deadline 高强度跑任务，重置刚好没到，被卡住。工具的调度权在系统手里，不在你手里。

现在可以把重置「存起来」，等你自己判断合适的时候再触发。

Go、Plus、Pro、Business 用户都支持，上线就送一次免费重置，存着的重置有效期 30 天。还有个限时 referral 机制：邀请朋友完成第一次 Codex 对话，双方各得一次重置，最多邀 3 个人，两周窗口期。

有人说这没什么，算什么技术创新。这个判断是准的，它确实不是技术上的大动作。

但实话讲，这类「把使用权还给用户」的改动，对重度用户是真实的感受变化。我自己的情况是这样：主力用 Claude Code，流水线上挂着十几个 skill，每次让 agent 跑任务之前，我都会在心里先掂量一下这件事值不值动用 Opus，杂活的话手动切便宜模型省点额度。这种用之前先在心里过一遍秤的绷着感，根本上是因为「额度什么时候耗完、什么时候重置，不受我控制」。能自己决定什么时候用，哪怕只是一次重置时机，体感上会顺很多。那种绷着感，你知道工具够用，但一直有个潜台词：用的节奏不是自己说了算。

说实话，这件事的竞争逻辑没那么简单。

Codex 周活目前已经超过 300 万。这个规模下，面对 GitHub Copilot、Claude Code、Gemini Code Assist 这些竞品，拼能力上限是一条路，但拼「用起来到底顺不顺」也是一条路，留住已有用户这件事上往往后者更直接。速率攒存解决的就是「用着用着被系统打断」这个具体摩擦点。

两件事合起来，背后是同一个方向

能力加（CDP 调试）和体验改（重置攒存），单独看都不算大新闻。

放在一起，我看到的是同一个方向：Codex 在补一个闭环。

写代码是起点，验证代码才是终点。CDP 把「验证」这一步往前推了，让 Codex 开始参与调试循环的后半段。

速率攒存是在说，这个工具想嵌进你的工作节奏，额度什么时候用，该由你来定。

两件事都在建黏性，用不同的手段回答同一个问题：为什么开发者应该把 Codex 当成日常工具，而不只是偶尔打开的补全器。

我现在主力还是 Claude Code。那套 skill 流水线已经长在 Claude Code 的 frontmatter 和 hook 机制上，换底座的迁移成本太高，短期不打算动。但 CDP 这个方向，我是真的在盯着看。

如果 Codex 继续往前走，能真正跑通「写→验证→修→再跑」整个循环，不打断你，那是值得我重新掂量的那种变化。

现在还不到那一步。但门开了。

你在用 Codex 吗？速率限制有没有卡过你？还是你主力用的是别的 AI 编程工具，欢迎评论里说说。