Codex重度用户必备插件,实测每一个都是夯爆了!

插件装对以后，Codex 才会接住一整段工作流程。

Hi，大家好，我是老颜。

这段时间，我几乎每天都在用 Codex。

写公众号、整理 Obsidian、看产品代码、做封面、排版文章，有时候还会让它直接打开软件，把最后几步也一起完成。

用得越多，我越能感受到一件事：Codex 本身决定了它有多聪明，插件决定了它到底能替你做多少事。

只用基础能力时，它更像一个很聪明的顾问。它可以帮你分析、给方案、写代码，但很多工作到了“打开软件、登录网站、检查页面、部署上线”这一步，还是要自己接过去。

插件装对以后，Codex 才会逐渐变成一个能够完成整段工作流程的助手。

我这段时间依次用下来，下面 5 组插件的使用频率最高。每一组我都会讲清楚三个问题：适合什么场景、我会怎么下指令、使用时要注意什么。

打开 Codex App 左侧的插件入口，直接搜索插件名称并安装即可。

这里有一个很容易忽略的细节：插件安装完成后，建议新建一个任务再使用。 已经打开的旧任务不一定会加载刚安装的插件能力。

插件能够做多少事，也取决于你授予了什么权限。涉及账号、文件、部署和发布时，我的习惯是让 Codex 先完成检查和预览，最后一步保留人工确认。

这三个插件都能操作页面，所以很多人第一次使用时容易混在一起。

我用下来，它们的分工很明确：

Computer Use：操作范围最广

Computer Use 可以直接操作 macOS 上的原生软件。浏览器之外的 Obsidian、Word、访达、系统设置，都属于它更擅长的范围。

比如我整理知识库时，会直接让它打开 Obsidian，检查当天生成的文章是否放进正确目录，再确认 Markdown、Word 和图片是否齐全。这样可以省掉很多重复的点击和查找。

可以直接这样说

Computer Use 的权限比较大，所以删除文件、提交表单、修改系统设置这些动作，我都会要求它先停下来确认目标。范围越广，越需要把边界写清楚。

Chrome：处理需要登录的网站

Chrome 插件接管的是你正在使用的真实浏览器。公众号后台、GitHub、产品管理后台这些已经登录的网站，用它会方便很多。

比如文章写完以后，我可以让 Codex 检查公众号草稿页里的标题、摘要、封面和正文排版，但明确要求它不要点击发布。

可以直接这样说

Chrome 最适合利用现有登录状态。账号相关的验证码、付款、正式发布，我仍然建议自己完成最后一步。

Browser：本地网页开发和调试最好用

Browser 是 Codex 自带的独立浏览器。它和你日常使用的 Chrome 不是同一个环境，因此不会自动继承 Chrome 里的登录状态。

它的优势是适合开发和检查。做完一个网页、一个公众号排版预览，Codex 可以直接打开本地地址，检查控制台报错、页面溢出、按钮能不能点击，再分别查看手机和电脑尺寸。

可以直接这样说

我的选择方法很简单：桌面软件用 Computer Use，登录网站用 Chrome，本地网页和前端调试用 Browser。 三个都装，不需要强行选一个。

如果你要做产品介绍、功能演示、短视频动效，HyperFrames 很值得装。

它使用 HTML、CSS 和 JavaScript 来制作视频画面。相比直接让文生视频模型随机生成，它更适合需要统一字体、品牌色、页面截图和产品界面的内容。

HyperFrames 的完整流程并不是“输入一句话，马上得到成片”。一条质量稳定的视频，通常要经过下面 7 步：

这套流程的价值在于可修改。某一屏文字太多，可以只改这一屏；品牌色不对，可以统一调整；镜头节奏太慢，也可以按时间轴精确修改。

可以直接这样说

我认为它最适合三类内容：产品功能演示、工具教程、带界面截图的知识短视频。

如果你只想快速生成一段人物说话或纯氛围画面，其他视频模型可能更省事。HyperFrames 的优势是结构清楚、画面可控、后期容易修改。

Codex 写前端代码很快，但只给一句“帮我做一个高级感网页”，最后得到的页面很容易千篇一律。

常见的问题包括：大面积渐变、到处都是圆角卡片、标题大得离谱、内容看起来像一个模板。代码可能没有错，视觉上却很难直接使用。

Build Web Apps 给了一个更稳定的工作顺序：

明确使用场景 → 生成视觉参考 → 按参考图实现 → 用浏览器检查 → 根据截图继续修改。

这比不断追加“再高级一点”“再简洁一点”有效得多。因为“高级”和“简洁”都很模糊，参考图可以把布局、颜色、字号和信息密度直接固定下来。

可以直接这样说

我平时做工具页面时，会先把用户是谁、每天要完成什么任务、最需要看到哪些信息写清楚。这样 Codex 才能判断页面需要高密度表格，还是需要更强的视觉展示。

Build Web Apps 解决的是前端的视觉起点。业务流程、字段含义、权限和数据逻辑，仍然需要自己提供准确的产品背景。

Superpowers 是我认为最值得长期使用的开发类插件之一。

它最有价值的地方，是提供了一套完整流程：先讨论需求，再写方案，然后按测试驱动开发，遇到问题进行系统排查，完成后继续做代码审查。

很多 Codex 任务失败，常见原因是需求还没弄清楚，它就开始改文件。改到一半发现方向不对，只能继续打补丁，最后代码越来越乱。

Superpowers 会让 Codex 在关键节点停下来思考：

这套方法并不限于开发。我在规划 YC 功能、整理知识库结构、讨论售前流程时，也会使用里面的 brainstorming 能力先把问题展开，再收敛成可以执行的方案。

可以直接这样说

它也有使用边界。改一个错别字、换一个颜色、调整一行配置，没有必要启动完整流程。任务越复杂、影响范围越大，Superpowers 的价值越明显。

前面几个插件解决的是操作、设计和开发，GitHub 与 Vercel 负责把最后一段流程接起来。

GitHub 插件可以读取仓库、Issue、Pull Request 和代码改动，让 Codex 在真实项目背景中工作。它可以先了解当前分支，再修改代码、运行测试、整理提交说明，并把改动放进现有的协作流程。

Vercel 负责把网页部署成一个可以打开的预览地址。内部工具、活动页面、产品原型做完以后，不需要只发截图，直接把链接交给合伙人或客户查看，反馈会具体很多。

我更推荐下面这条流程：

新建分支 → 完成功能 → 本地验证 → 推送 GitHub → 创建预览部署 → 人工检查 → 再决定是否合并和正式上线。

可以直接这样说

需要注意的是，GitHub 和 Vercel 都会接触真实项目。分支、环境变量、数据库和生产域名要提前写清楚。我的原则一直是：Codex 可以自动完成准备工作，生产发布必须保留明确的检查点。

插件不用一次装满。可以根据自己当前最常做的事情来排顺序：

我不会用“装得多不多”来判断 Codex 用得好不好。

更值得关注的是：一个任务原来需要在五六个软件之间来回切换，现在能不能让 Codex 接住其中三步、四步，最后只把需要判断的地方交给自己。

插件的价值，就是把 Codex 从一个会分析的助手，逐渐变成一个能够进入真实工作流程的执行者。

这 5 组插件里，电脑操作三件套和 Superpowers 是我认为适用范围最广的。前者让 Codex 能操作更多工具，后者让它做事更有顺序。

Build Web Apps、HyperFrames、GitHub 和 Vercel，则分别补上了视觉、视频、代码协作和部署能力。

你不需要一次掌握所有插件。先选择一个自己每天都会遇到的重复任务，把输入、操作和检查标准写清楚，让 Codex 完整跑通一次。一次跑通，比收藏几十个插件名称更有价值。

我是老颜，YC 公众号管理系统作者，也在持续研究 AI 工具如何进入真实的产品、写作和知识管理流程。

如果你觉得这篇文章有用，记得点赞、收藏、在看、转发。也欢迎在评论区告诉我，你最想看哪个插件的完整实战教程，我会优先安排。

觉得有用，记得点赞、收藏、在看、转发。

评论区告诉我，你最想看哪个插件的完整实战教程。

THANKS FOR READING