这两天如果你正好在用 Codex 改网页，应该很容易遇到一种让人抓狂的情况：页面看起来差不多，按钮也能点，可一到真正提交、登录、加载数据时，就开始出问题。

以前让 Agent 排查这类故障，它能看到代码，也能操作页面，但常常只能根据截图和现象猜缘由。按钮没反应，它可能先改事件绑定；接口报错，它可能先查前端参数；页面卡顿，它又可能直接重构组件。改了一圈，真正的错误还藏在 Console（控制台）和 Network（网络请求）里。

2026 年 6 月 11 日，OpenAI 发布 Codex App 26.609，其中最值得网页开发者关注的变化，是 Browser Developer Mode（浏览器开发者模式）。打开后，Codex 可以在受控和需要确认的前提下，通过 Chrome DevTools Protocol（Chrome 开发者工具协议）查看网络流量、控制台输出、运行时错误、DOM、页面样式和性能信息。

官方还提到，这一轮通过 CDP 和 DOM 快照优化，让 Browser use（浏览器操作）最高提速约 2 倍。对普通读者来说，重点不在“速度翻倍”这四个字，而在于 Codex 终于能拿着浏览器里的证据排错，不必只靠页面表象猜。

它解决的烦事，是网页能打开却不好用

网页故障大致可以分成两类。

第一类很直观。页面打不开、代码编译失败、服务器没有启动，这些问题一般在终端里就能看到。

第二类更麻烦。网页可以正常打开，甚至大部分界面都没问题，但某个按钮失效、登录接口返回错误、数据加载特别慢，或者样式只在某个状态下错位。

这类问题往往藏在浏览器开发者工具里：

• Console 里有一条 JavaScript 运行错误。
• Network 里某个接口返回了 401、404 或 500。
• 请求参数缺少字段，或者 Token 没有正确带上。
• 页面重复发起同一个请求，造成加载变慢。
• 某个组件不断重新渲染，拖慢整个页面。
• CSS 已经加载，但实际应用到元素上的样式被覆盖。

Codex 以前也能打开网页、点击、输入和截图。26.609 新增的 Developer Mode，让它能进一步查看页面内部发生了什么。它可以先复现问题，再检查 Console、Network 和页面状态，最后回到代码里寻找对应位置。

这就像以前只让修理工看一眼“车开不动”，目前终于把故障码、传感器数据和运行记录一起交给他。

为什么这次更新值得单独写一篇

这次变化看起来只是多了一个开关，背后实则补上了 Agent 做网页任务时最缺的一段闭环。

第一，Codex 开始从“操作网页”走向“调试网页”

会打开页面、点击按钮，只能证明 Agent 能操作浏览器。能检查网络请求、运行错误、DOM 和应用样式，才算真正进入调试环节。

网页开发最浪费时间的地方，往往不是写代码，而是定位错误到底发生在哪一层。是按钮事件没触发，还是接口拒绝了请求？是后端没返回数据，还是前端拿到数据后渲染失败？Developer Mode 的价值，就是先把证据链补起来。

第二，排错过程更容易被人检查

Agent 最让人不放心的情况，是它直接说“问题已经修复”，却没有告知你问题如何复现、证据在哪里、修改后有没有重新验证。

目前可以明确要求 Codex 按固定顺序工作：

复现问题 → 查看 Console 和 Network → 给出证据 → 判断缘由 → 最小修改 → 重新验证

这个流程并不能保证它每次都判断正确，但比“看到现象就改代码”可靠得多。

第三，Chrome 和内置浏览器各有分工

Codex 内置浏览器更适合本地开发服务器、无需登录的公开页面和文件预览。它与平时使用的 Chrome Profile 分开，不会直接带入日常浏览器里的 Cookie、扩展和历史状态。

需要检查已登录后台、企业内部工具或依赖真实 Chrome 状态的网页时，可以安装 Codex Chrome 扩展，再用 @Chrome 调用。

这也意味着权限风险更高。Chrome 扩展可能涉及当前页面、调试器、浏览数据和已登录状态。使用前要确认网站范围，涉及邮箱、财务后台和敏感业务系统时，不要图方便直接全部放开。

这几类人最适合，纯静态网页没必要急着开

第一类，是正在用 Codex 做网页、管理后台、小工具或本地应用的人。只要项目里有按钮、表单、接口和状态变化，Developer Mode 就能减少大量来回描述问题的时间。

第二类，是能看懂网页效果，但不熟悉 Chrome 开发者工具的人。你不必定会手动筛选几十条 Network 请求，也不必定能从调用栈里找出第一条真正的错误，但可以让 Codex 先整理证据，再用中文解释。

第三类，是常常让 Agent 自己修改并验证网页的人。Developer Mode 让“改完后来再跑一遍”变得更自然，不用只看代码 Diff（差异）猜效果。

下面几种情况暂时没必要专门开启：

• 只做一个没有交互的静态介绍页。
• 问题已经明确出目前终端编译阶段。
• 只是调整文字、配色和间距，用浏览器批注已经够用。
• 正在处理高度敏感的已登录页面，却无法确认扩展权限边界。

Developer Mode 是调试能力，不是每个网页任务都必须打开的万能模式。页面越简单，使用普通 Browser use 反而越省事。

升级、开启、测试，再用 3 套提示词排错

这一部分尽量从最小测试开始。先确认 Codex 能读取一个本地页面的 Console 和 Network，再把它交给真实项目。

第一步：更新到 26.609 或更高版本

打开 Codex App，先完成应用更新。不同系统的更新入口可能略有差别，看到更新提示时直接安装即可。更新后重新启动 Codex，避免旧进程依旧占用浏览器插件。

如果设置中完全找不到 Developer Mode，先确认自己使用的是 Codex App，而不是只安装了 Codex CLI 或 IDE 扩展。这次浏览器开发者模式主要落在 Codex App 的 Browser use 中。

第二步：开启 Browser Developer Mode

进入：

Settings → Browser → Developer mode

打开：

Enable full CDP access

这个开关允许 Codex 通过 CDP 检查更深层的浏览器状态。真正使用时，Codex 还会针对网站和任务请求确认。遇到企业工作区禁止此功能的情况，本地用户无法自行绕过管理员设置。

第三步：决定使用内置浏览器还是 Chrome

本地项目和无需登录的页面，优先使用内置浏览器，在提示词里写 @Browser。

需要 Chrome 登录状态时，进入 Codex 的 Plugins 页面，添加 Chrome Plugin，按照引导安装 Codex Chrome 扩展。完成后打开 Chrome，确认扩展显示 Connected（已连接），再新建一个 Codex 对话，用 @Chrome 指定浏览器。

第四步：先做一次不改代码的最小测试

启动项目的开发服务器，然后给 Codex 输入：

请检查当前项目的开发服务器是否已经启动。

使用 @Browser 打开本地首页，只读取页面状态、Console 和 Network，不要点击按钮，也不要修改代码。

请告知我：
1. 页面是否正常加载；
2. Console 是否存在错误；
3. 是否有失败的网络请求；
4. 当前页面地址和主要内容是否符合预期。

第一次测试成功，应当看到这些信号：

• Codex 能打开指定页面。
• 它明确说明检查了 Console 和 Network。
• 页面出现 CDP 访问确认时，你能看到并审核请求。
• 它不会在没有允许的情况下直接修改代码。
• 发现错误时，能给出状态码、错误信息或页面位置。

提示词一：按钮点了没反应

请先检查当前项目的开发服务器是否已经启动，然后使用 @Browser 打开：

[填写本地网页地址或具体页面]

请按照下面的动作复现问题：

[填写具体操作，例如：填写标题后点击“保存”按钮]

正常情况下应该出现：

[填写预期结果，例如：提示保存成功并返回列表页]

请使用 Developer Mode 完成下面的检查：

1. 清理或区分本次操作前已有的 Console 信息；
2. 检查点击后是否触发了对应事件；
3. 找出本次操作出现的第一条关键错误；
4. 查看点击前后按钮状态、DOM 和页面状态是否变化；
5. 检查是否发出了网络请求；
6. 判断问题更可能来自事件绑定、页面状态、权限限制，还是后端接口。

先不要修改代码。

请按“复现结果、关键证据、缘由排序、提议检查位置”四部分输出。等我确认后，再做最小范围修改。

这套提示词适合保存、提交、登录、弹窗、菜单和表单按钮失效。重点是先要求 Codex 复现，再要求它区分前端事件和后端接口。

提示词二：接口请求失败

请使用 @Browser 打开：

[填写网页地址]

然后执行：

[填写操作，例如：输入测试账号后点击登录]

请使用 Developer Mode 检查本次操作产生的 Network 请求，重点找出：

1. 哪一个请求失败或返回异常；
2. 请求地址、请求方法和状态码；
3. 请求参数中是否缺少必要字段；
4. 返回内容里最关键的错误信息；
5. 是否存在跨域、鉴权、Cookie、Token、接口地址或环境变量问题；
6. 前端是否正确处理了失败结果。

不要输出密码、Cookie、Authorization、API Key 或其他敏感字段，相关内容请用星号遮盖。

先只给出证据和缘由排序，不要直接修改代码。

最后告知我应该优先检查哪个文件、哪个配置或哪一段逻辑。

这套提示词适合登录失败、数据加载不出来、提交接口报错和后台返回异常。把“遮盖敏感字段”写进去很重大，由于 Network 中常常带有 Cookie、Token 和鉴权信息。

提示词三：页面卡顿和加载慢

请使用 @Browser 打开：

[填写网页地址]

请用 Developer Mode 检查从页面打开到主要内容可以操作的完整过程。

完成以下任务：

1. 找出加载时间较长的网络请求；
2. 检查是否存在重复请求、超大图片、过大的 JavaScript 文件或阻塞资源；
3. 查看 Console 中是否存在重复报错或持续出现的警告；
4. 检查是否有频繁重绘、重复渲染或长时间运行的脚本；
5. 按影响大小列出最值得先处理的 3 个问题。

先不要进行大规模重构。

请给出一份最小优化方案，每次只处理一个问题。每次修改后重新测试，并按“修改前、修改后、是否明显改善”汇报结果。

这套提示词适合首屏慢、按钮反应迟钝、页面滚动卡顿，以及数据迟迟不显示。不要只说“帮我优化性能”，否则 Codex 可能同时改网络、组件、缓存和样式，最后很难判断哪项修改真正有效。

看不到 Developer Mode 时怎么排查

按下面顺序检查：

1. 确认 Codex App 已更新到 26.609 或更高版本。
2. 完全退出并重启 Codex App。
3. 进入 Settings → Browser，确认 Browser Plugin 已安装并启用。
4. 使用 Chrome 时，确认 Chrome Plugin 已打开，扩展显示 Connected。
5. 确认当前使用的是安装扩展的同一个 Chrome Profile。
6. 新建一个 Codex 对话，再重新调用 @Browser 或 @Chrome。
7. 企业账户看不到开关时，检查管理员是否关闭了完整 CDP 权限。

Chrome 明明显示已连接，Codex 却无法操作时，可以先检查网站是否被放进 Blocklist（阻止列表），再重启 Chrome 和 Codex。依旧失败，再移除并重新添加 Chrome Plugin，比反复重装整个 Codex 更容易定位问题。

这 5 个坑，比不会写提示词更容易翻车

坑一：只说“帮我检查这个网页”

页面、路由、操作动作和预期结果都不写，Codex 只能自己猜范围。应当明确告知它是首页、登录页还是设置页，点击哪个按钮，正常情况下应该看到什么。

坑二：一上来就让它修

先复现、收集证据、判断缘由，再修改。没有证据就改代码，很容易把原问题盖住，又制造新的故障。

坑三：把 Console 里所有红字都当根因

页面可能早就存在无关警告。提示词里要强调“本次操作后出现的第一条关键错误”，并要求结合 Network 和页面状态判断。

坑四：给 Chrome 过大的网站权限

内置浏览器解决不了登录状态时，再思考 Chrome。每次授权前看清域名、任务和访问范围。涉及邮箱、后台、内部系统和财务信息时，不要为了省一次确认就选择永久允许。

坑五：改完代码没有重新做同一套动作

真正的完成标准不是 Codex 说“已经修好”，而是它重新打开同一个页面、执行同一个操作，并用 Console、Network 和页面结果证明问题消失。

最后判断

Codex 26.609 多出来的，不只是一个会自动点网页的浏览器。它开始能看 Console、Network、DOM 和运行状态，网页排错终于从“看现象猜缘由”走向“拿证据再修改”。

但别只对它说“帮我修好”。页面、动作、预期结果和修改边界写得越清楚，这个 Chrome 调试台才越像工具，而不是另一个会乱改代码的 Agent。