CODEX · 网页排障

先别急着让它修

事实／范围／验证：三道观察关

别让 Agent 先猜页面，先把事实、范围和验证放好。

网页出了问题时，人很容易进入一个很奇怪的状态。

页面白屏了，打开开发者工具，控制台红了一片；再切到网络面板，几十条请求挤在一起。最后回到 Codex，丢下一句，帮我看看这个网页为什么不对。

这句话并不算错，只是它把最关键的部分省掉了。

你真正想知道的可能是，哪一条报错先发生；也可能是，接口有没有返回；也可能只是，一个按钮为什么看起来没套上该有的样式。这三件事，都会让人觉得页面不对，可排查路径完全不同。

OpenAI 在 2026 年 6 月 11 日的更新说明里提到，Chrome 中的 Browser use 和 Codex 应用内浏览器可以启用 Developer mode。这个模式给 Codex 受控的 Chrome DevTools Protocol 访问，它可以分析 JavaScript，查看控制台输出和网络流量，检查 DOM 与已应用的样式，并协助诊断在线网页问题。它默认是关闭的，需要在 Codex app 设置里开启。

这里最值得留意的，不是多了一个能看浏览器的开关。

而是网页排障终于可以少一点猜。

不过，少一点猜，不等于把浏览器一交出去就完事。Developer mode 给的是观察入口，不是一句万能的帮我修好。页面上的线索越多，越需要先把问题收成一个能验证的任务。

先过第一关，分清看到的事实

打开控制台时，先别急着让 Codex 从一整屏红字里找答案。先把已经看见的事实写出来。

例如，点击保存后页面没有跳转；控制台出现了一条错误；网络面板里有一个请求返回了 500；元素检查器显示按钮存在，但它的颜色和预期不同。这里每一句都只是观察，不抢着解释原因。

这一步听着笨，其实很有用。因为网页问题里最常见的混乱，就是把现象和解释粘在一起。看到请求失败，就断言后端坏了；看到样式没生效，就断言 CSS 文件没加载；看到一个报错，就默认它一定是第一处故障。

让 Codex 接到控制台、网络、DOM 或已应用样式的信息，并不等于它应该替你把猜测升级为结论。更可靠的提问是：请先列出当前能够直接确认的事实，并标出哪些地方还只是推测。

这一句会把它的第一项工作，从立刻改代码，变成整理证据。

网页排障最怕的不是没有答案，是很快拿到一个听起来顺的答案。

这里可以要求一个很朴素的输出顺序。先列现象，再列和现象直接相连的浏览器证据，最后才列候选原因。候选原因也不必堆满十条，按下一步最容易确认的顺序排两三条就够了。这样做不是限制 Codex 思考，而是让人能看清它从哪一条记录走到了哪一个判断。

如果某条 console 信息和当前动作没有时间上的对应，也应该允许它被暂时放到一边。浏览器里经常留着旧警告、扩展注入的提示、开发环境的噪声。先把当前复现动作前后出现的材料圈出来，才不会让一条无关红字带着大家跑半天。

第二关，这次只查哪一层

一个网页里，前端状态、接口响应、鉴权、缓存、构建产物、浏览器扩展，甚至某个刚好过期的测试数据，都可能让同一个按钮表现得不对。

如果范围不收住，Codex 看见的线索越多，可能给出的分支也越多。你会得到一串都不算离谱的可能性，却不知道该先做哪一个。

所以第二关要写得很具体：这次先查哪一层，以及暂时不查哪一层。

可以这样交代：先判断这个提交动作有没有发出请求；只检查浏览器里可见的 console 和 network 信息；暂不修改接口、数据库或部署配置。又或者：只比较这个按钮的 DOM 结构和已应用样式，不讨论视觉稿，也不要顺手改组件文件。

这不是给工具设障碍。

恰好相反，它是在减少无效排查。范围越清楚，Codex 越能把观察到的内容归到一条短路径上。它可以告诉你先看哪一个请求、哪个报错更像源头、还缺哪一段材料，但不会把一次局部确认扩展成一场没有边界的翻修。

Developer mode 默认关闭，也提醒了同一件事：这类浏览器调试能力不该被当成无差别的背景权限。先确认自己要查什么，再决定是否启用，通常比先开着再想办法收尾更稳妥。

范围里还可以写一个停止条件。比如，若当前页面没有可复现的操作，就先停在收集复现步骤；若请求和页面状态能够对上，就不再扩展到服务端代码；若发现需要访问真实用户数据，就暂停，改用脱敏样本或测试环境。停止条件并不消极，它是在帮一次浏览器排查守住任务边界。

第三关，答案怎么验证

很多排障对话在这里断掉。

Codex 给出一个解释，看上去也有道理；人改了一处，页面似乎恢复；然后任务结束。可如果没有验证条件，下一次遇到相似问题，大家还是得从第一句帮我看看开始。

第三关只问一件事：什么结果能证明这条判断站得住。

比如，如果怀疑请求根本没发出，就要求答案指出应该观察哪一次点击、哪条网络记录，什么状态才算符合预期。如果怀疑样式被覆盖，就要求它说明要比较哪个元素、哪条已应用规则，以及改动后页面上应当出现什么变化。如果线索不足，也让它直接列出需要补的最小材料，而不是继续把所有日志、所有接口、所有代码都搬进对话。

可以把三道关直接复制到任务里：

事实：请先区分当前浏览器里能直接确认的现象，和仍需验证的推测。

范围：这次只检查 console、network、DOM 或已应用样式中的指定部分；先不要修改代码、接口或部署配置。

验证：请给出下一步最小检查动作，并说明看到什么结果才支持或推翻当前判断。

这不是官方模板，只是一种把网页问题讲清楚的工作卡。它也不要求每次都打开 Developer mode。遇到长日志、后端链路、性能曲线或敏感数据时，仍然要挑最小、最合适的材料；该脱敏的先脱敏，该人工确认的别省。

也别把可见的浏览器状态和全部事实混为一谈。网络面板能展示一次请求发生了什么，DOM 能展示此刻页面是什么结构，已应用样式能解释一部分视觉结果；它们都只是问题链路中的一段。需要服务端日志、发布记录或权限确认时，仍应沿着验证关补材料，而不是让工具从半截上下文里替你补全故事。

别让 Agent 先猜页面

Developer mode 的价值，不在于让浏览器自己把问题解决。

它把控制台、网络、DOM 和样式这些原本散在不同面板里的观察，变成了 Codex 可以协助整理的上下文。真正决定排障质量的，还是人有没有把现象、范围和验证讲清楚。

下次页面又不对劲，可以先停十秒。

别急着问它怎么修。先告诉它你看见了什么、这次只查什么、答案要怎么被验证。网页问题一旦从模糊抱怨变成可检查的任务，后面的协作才会开始有抓手。

-–

来源：OpenAI《ChatGPT Release Notes》（2026-06-11 Codex updates）。

先确认看见什么，再决定下一步查什么。