我用 Codex 做了个浏览器插件,从提需求到能用只花了半个小时

说实话，我已经用 Codex 很久了。

不是那种"试了一次觉得好神奇"的状态，而是真的把它用进了日常工作里，改东西、做功能，它是我现在每天都会用到的工具。

所以这篇文章不是来介绍 Codex 是什么的。

我想聊的是我最近用它做的一件小事——做了一个 Chrome 浏览器插件，一键清理缓存。以及，我平时到底是怎么用 Codex 的。

为什么要做这个插件

原因很日常。

浏览器缓存这个东西，有时候会让你以为改了的东西没生效，刷新页面没反应，第一反应就是清缓存。

以前每次都要打开设置，找到清除数据，勾选，确认，操作不复杂，但做多了就烦。

网上也有现成的插件，但要么功能太杂，要么权限申请得莫名其妙，用着不踏实。

干脆自己做一个。就一个按钮，点一下，缓存清掉，完事。

我是怎么跟 Codex 说的

第一句话是这样的：

"我想做一个谷歌浏览器插件可以一键点击清缓存帮我分析一下可行性。"

我没有直接说"帮我写代码"。

这是我用 Codex 一直以来的习惯——先让它分析，给我一个方案，我来判断这个方向对不对，确认了再让它动手。

直接要代码有个问题：它可能给你一个能跑，但方向不对的东西，等你发现再改，还不如一开始想清楚。

Codex 回来说，Chrome 插件可以通过 chrome.browsingData 这个 API 来清理缓存，权限在配置文件里声明，逻辑不复杂，可以做。

我看了觉得没问题，就说：方案可行，按这个实现。

说实话我以为多少会有点折腾。

结果它给出来的东西，文件结构完整，代码逻辑清楚，我按流程走了一遍——先看代码，确认没问题，再本地加载测试，点图标，缓存清了，弹出提示，没有报错。

从第一句话到插件能用，半个小时不到。

做这个插件的过程，其实就是我平时的缩影。

稍微展开说一下，因为我觉得用 AI 写代码，方法比工具本身更重要。

改 Bug 的时候：

我不会直接把代码扔给它说"帮我看看哪里有问题"。

我会先说清楚背景——这个功能是干什么的，涉及哪个接口，接口参数是什么，现在的问题现象是什么。

说得越具体，它给出来的东西越准。描述模糊，它只能猜，猜出来的东西大概率要返工。

改完之后，我自己再审一遍代码，再验证一遍功能，确认没问题才算完。

做新功能的时候：

还是先出方案。

我说需求，它给方案，我判断有没有坑、和现有的东西有没有冲突。确认之后再让它实现，再验证。

这个顺序不能倒——方案确认好再动手，比动手之后发现方向错了要省事得多。

有一个原则我一直在用：

AI 负责实现，我负责判断。

它的代码能力值得信任，但它不了解我的具体情况，这部分判断只能自己来。

没有发布，就自己用。

需要清缓存的时候，点一下图标，两秒搞定，继续工作。

小东西，但用得很频繁。

做完这个之后我发现一件事：以前有很多"感觉有点用但懒得做"的小工具，现在门槛低了很多。下午有空，花一两个小时，跟 Codex 说清楚要做什么，自己验证一下，就能用了。

这种感觉挺好的——不是 AI 帮你做了所有事，而是它把"动手的成本"压低到了你愿意动手的程度。

如果你也在用 Codex，或者对怎么跟它沟通有疑问，欢迎留言聊——怎么描述需求、怎么审它给的代码、遇到它给错了怎么处理，这些都可以说。

觉得有用的话，点个关注，下期继续分享。