1- 背景

我正在基于 Electron 开发一款名为 Noi 的 AI 浏览器，此项目源代码文件目前有 300 多个，3 万多行代码。Codex 是当前使用最多的工具，遇到过坑，也有不少惊喜。

Noi 部分截图（macOS 系统毛玻璃，让 Noi 更具 macOS 原生质感）

2- 案例分享

继上一篇 Codex 初体验有点小兴奋！，这次再写点。实际项目代码复杂多变，很难用几句话说明白，下面分享两个最近的遇到的问题。

2.1- 案例 1

在使用某个依赖包开发时，因文档不够详细，遇到了一些问题（自己又懒的去查看源码）。于是我就去 GitHub 把该依赖包项目 clone 到本地，然后把关于该依赖实现的代码文件丢进该 clone 项目，在一个项目上下文里，开始让 codex review 项目，然后进行问题修复。效果还不错，一次就解决了我的问题。有最直接的代码样本作为资料参考，可以避免很多描述上的弯弯绕绕，此方法也仅限于代码量比较少，且文档缺失的依赖。

主要还是依赖 codex 的学习模仿能力，它的文件检索分析能力是真的强（基本一通 rg 下来，就把问题定位的七七八八了）。

📌 Codex 提问模板请 review 该项目，尝试修复 xxx.tsx，它的问题是 xxxx（简单描述问题和预期结果）。

2.2- 案例 2

在 Noi 项目中，为了省事，我借助 @electron/remote 进行部分 IPC 通信，它确实简化了部分逻辑操作。今天心血来潮，想让 codex 帮我把 @electron/remote 完全移除，使用 ipcRenderer.invoke 重写。它在一通分析后，给我来了句 Sorry 就结束了（大意：抱歉，我需要更多时间才能安全地完成所有 @electron/remote 用法的移除。这项更改涉及许多地方的窗口/菜单处理，因此在启用新的 IPC 桥之前，我想再检查一下）。

然后我反复几次，它才开始干活（预判到是个大工程，死活不上套）。但真开始干活了，我看着长长的 thinking 却有点虚了（是真长！我第一次见超过上百步的 thinking），修改的文件也超过 40 个（还好我 commit 过了，虽虚不慌，大不了回退）。

在重写中，codex 会高频调用 shell 命令（如 rg、cd、cat 等）来进行文件分析（事实证明，它真的好用，可以做到相关函数引用全覆盖）。

在这一次重写中，修改文件超过 40 个，涉及到的功能极多且复杂。后来我 review 验证了下，只能说一半一半。虽然整个代码可以运行，但部分功能失效，如：

• renderer 进程中的 menu 在移动到 main 进程中后点击事件失效。
• 部分 react 开发的页面可以查看却无法点击（因牵扯逻辑太多，还需具体排查）。
• 部分 view 在 window resize 时，偶现布局计算错误。可能某些配置文件被修改，或数据缓存错误。

因时间关系，我只验证了几个核心功能，可能还有细节问题暂未发现。也查看了 @electron/remote 方法迁移到主进程的核心实现，基本是 ok 的。针对此次重写，我可以给 codex 打 60 分，虽然部分功能失效，但项目并未崩掉无法运行。如果必须重写，那它起码可以帮你节约一半的重构时间，剩下时间就需要人力介入来逐个修复了（大方向基本 ok，这也是我特别喜欢看 thinking 过程的原因，有些分析确实精准到位）。如果重写只是优化项目的非必要选项，那获得的收益比在我看来不算很大。一次修改那么多文件，没有崩掉，可能也得益于 TypeScript 类型系统，借助类型错误提示，直接避免了许多显式错误。

3- 结语

如果非要总结 Codex 重写体验，那我想说：它写的核心代码大部分是可用的，但为了完善它的实现，还需手动处理很多东西。内心 OS：不重写最省事…

使用 AI 编程 给我最大的感受：它不会拒绝你的任何请求，只要不违背法律道德约束，在没有限额时，都会不知疲倦的帮你去实现（即使完全错误的方向，既可笑又强的可怕）。不要钻牛角尖，当 AI 在某个方向行不通时，那就新开上下文换个思路去做（在错误里打转只会越陷越深）。

这也让我想起，前段时间有人在群里聊起 AI 编程什么最重要？如果在早期非 AI 时代，我认为掌握原理（微观层面）、生态（宏观层面）、快速定位问题（经验积累）都很重要，也必须多者结合才能让你站在更高的角度去思考，用更高效的方式来解决问题。

但 AI 出现后，让编程这件事发生了一些微妙变化。不懂编程的小白也可以做出漂亮项目，既新奇又好玩（就像网上流传的这张图一样，Linus Torvalds 回答：非常低效，但很有趣）。

面对 AI 的日新月异，我们除了锤炼自身外（深度），还应该多多关注领域（广度），甚至在我看来，广度价值不亚于深度。比如对技术的判断力很大一部分也来自于生态，光懂原理没啥用（你可以完全手搓一个大几十万行代码的项目吗？即使可以也很困难，大部分时候也不需要）。AI 是可以写代码，但也只能写出你认知内的代码，你的技术视野将决定 AI 的潜力高度（你的上限不一定是 AI 的上限）。

对 AI 的使用也有点像打怪升级。你只有 1 级，就不会触发，或很难触发高级怪。无法自动触发，就意味着你要手动去触发，这个触发的动作就是认知或技巧。收藏各种 " 神级 " Prompt 就是在积累技巧，但这些都是浅技巧，沉迷于此，只会让人疲惫绝望，只有提升认知才是更深刻持久的技巧。

4- 题外话

继 Context7 MCP[1] 之后，最近 Google 出了个 DevTools MCP 值得关注。

4.1- Chrome DevTools MCP

Google 推出了 Chrome DevTools MCP[2]（Model Context Protocol）服务器预览版，让 AI 编程助手首次拥有 " 看见代码运行状态 " 的能力。源码：chrome-devtools-mcp[3]。

长期以来，AI 生成网页代码时，如同 " 戴着眼罩 " 工作：它能写代码，但看不到实际效果。Chrome DevTools MCP 解决了这个痛点 —— 通过标准化的协议接口，AI 代理可以远程控制 Chrome，实时调试网页、抓取性能数据、分析错误，并基于真实运行状态进行修复建议。

**MCP 是一个开源协议，旨在让大型语言模型（LLMs）连接外部工具和数据源。**借助 Chrome DevTools MCP，AI 可以调用如 performance_start_trace 等功能：自动打开网站、运行性能追踪，并分析页面响应、加载时间等关键指标。例如，AI 现在可以主动识别 LCP 过高的问题，并尝试优化加载路径。

你可以用它做很多事：

• 验证修改：AI 修复 bug 后立刻调用 DevTools 检查是否生效。
• 诊断网络错误：分析网络请求，定位如 CORS、加载失败等问题。
• 模拟用户行为：点击按钮、填写表单，重现复杂交互流程中的 bug。
• 调试样式布局：实时连接页面，分析 DOM 和 CSS，找出溢出或错位元素。
• 性能优化：运行 Chrome 追踪工具，识别并优化加载瓶颈。
• …

要使用这一能力，只需在你的 MCP 客户端中添加配置，调用 chrome-devtools-mcp 即可。比如你可以发出 prompt：" 请检查 web.dev 的 LCP"，AI 将自动启动 Chrome 并返回性能分析。

{  "mcpServers": {    "chrome-devtools": {    "command": "npx",      "args": ["chrome-devtools-mcp@latest"]    }  }}

4.2- GitHub MCP

MCP 正在成为 AI 编程主流，GitHub 甚至帮开发者精选了一份 MCP 列表（MCP Registry[4]）。

4.2.1- References

[1]**Context7 MCP:**https://github.com/upstash/context7

[2]**Chrome DevTools MCP:**https://developer.chrome.com/blog/chrome-devtools-mcp

[3]**chrome-devtools-mcp:**https://github.com/ChromeDevTools/chrome-devtools-mcp

[4]**MCP Registry:**https://github.com/mcp