博主们都在用的Codex插件 我把它们拆开看了一遍

📝 编辑 / 排版: 阿兰

一. 上下文接入

二. 沟通协作

三. 工程研发

03

工程研发这块我用得最多，GitHub、gh-fix-ci、gh-address-comments这些。

这是Codex最原生的战场。它能读仓库、理解代码、处理issue、修CI、响应PR review。重点不是写代码更快，是把开发流程串成一条线，从issue理解需求，到找修改点，到最小必要改动，到跑测试，到根据评论继续改，最后整理变更说明。

单点写代码只是效率高了一点。串起整条闭环，那才是真的省事！

运行部署这块，解决的是另一个问题，写完之后，东西能不能跑起来。Vercel、Docker、Env Vars这些都归在这类。

很多AI编程的演示停在生成代码那一步就完了，可真实交付不会停在那。你还要能预览、能部署、能看日志。尤其做前端和小工具，能不能真的跑出来，体验差得很远。

界面操作这块我觉得最容易被低估，Browser、Chrome、Playwright、Computer Use。

有些问题看代码根本看不出来，非得打开页面才知道。文案有没有溢出，按钮有没有遮挡，登录之后流程还走不走得通。Browser让Codex能看网页，Playwright让它能自动跑一遍流程验证，Computer Use干脆把能力扩到本地桌面应用了。

一个能看见结果的Codex，跟一个只会读文件的Codex，完全是两种协作者。

设计多媒体这类我最熟悉，因为我本就是设计行业，Figma、Imagegen、HeyGen、Slide Deck。

它把Codex从纯代码拉进了视觉那边。产品团队用得上Figma，做UI实现。内容团队更看重Imagegen、Cover、Infographic这些，直接影响一篇内容第一眼有没有人愿意点进来。

图表不是装饰，很多时候图表是读者理解一件复杂事情的第二条路。

文档数据这块看着不太炫，但特别贴日常，使用频率很高，Documents、Spreadsheets、PDF、飞书多维表。

写报告，改文档，读PDF，分析表格，生成PPT，把散乱的材料整理成能直接交出去的版本。要是你的工作大部分发生在Word、Excel、PPT和飞书表格里，这类插件的重要程度可能比工程插件还高。

最后是垂直工作流，内容工厂、小红书/微信/X相关技能这些。

这类跟前面几类不太一样，它们自带流程、自带判断标准、自带模板。内容工厂管的是选题到写作到改写到配图到平台适配的整条链。任务足够专业、步骤足够固定的时候，垂直工作流比你自己一个个调工具省心得多。

看完这八类我自己的判断是这样的。

如何你按插件名字挑，会挑花眼。按能力边界挑，反而清楚。挑之前可以先问自己三句话，我最缺的是上下文还是执行能力，我需要的是能验证的结果还是一份草稿，我做的是通用任务还是已经有固定流程的专业任务。

我自己是做广告创意的，接触的活大部分是内容和素材，所以我优先装的是Google Drive、Notion、Documents、Imagegen这几个，工程那一整套我基本没碰。

好插件不是让Codex看起来更忙。是让它离你真正要交付的那件事更近一点。

不知道上下文，先接资料。不能验证结果，先接浏览器。交付卡在部署，先接运行环境。流程本来就固定，直接找垂直工作流。

别想着把插件列表装满，那样只会被列表本身淹没。