刚开始使用 Codex 时，我也犯过一个很常见的错误：看到插件目录里有很多工具，就觉得装得越多，Codex 的能力越强。

Chrome、Google Drive、Gmail、Slack、GitHub、Sites……只要看起来有点用，我都想先研究一下。

但真正使用一段时间后，我发现插件并不是越多越好。

有些插件虽然功能很强，但我的日常工作根本用不到；有些插件看起来很专业，安装之后却一直没有打开；插件装得越多，需要连接的账号和授权也越多，反而让整个工作流变得复杂。

所以我重新梳理了一遍自己的 Codex 插件清单。

这一次，我不再追求数量，也不再照着官方目录逐个介绍，而是只看一个标准：

这个插件能不能真正进入我的日常工作流。

我平时主要用 Codex 写公众号文章、整理资料、制作AI视频脚本、管理项目文件，偶尔还会让它帮助我安装软件、修改代码或者测试网页。

按照这些真实需求来看，普通人真正经常用到的 Codex 插件，其实只有下面几类。

一、第一类：让 Codex 真正开始“干活”的插件

首先是连个最重要的插件，几乎人人必装，那就是Chrome 和 Computer Use。

这两个插件解决的是最基础的问题：让 Codex 不只是回答问题，而是能够进入网页和电脑软件，真正执行任务。

1. Chrome：处理需要登录的网页

Codex 本身可以搜索公开网页，但很多真实工作都发生在登录之后。

例如公众号后台、内容管理平台、会员网站、课程后台、企业系统，这些页面只有登录账号后才能访问。

Chrome 插件的作用，就是让 Codex 使用你当前浏览器里的登录状态，在经过授权的网站中读取信息或完成操作。

对我来说，它比较实用的场景包括：

查看公众号后台的文章草稿，收集网页上的资料，检查网页内容，测试刚做好的页面，以及在多个网站之间整理信息。

我以前总觉得，AI能够搜索网页就已经够用了。真正使用之后才发现，搜索公开信息和进入自己的工作后台，完全是两回事。

Chrome 插件装好以后，Codex 才真正开始进入我的实际工作环境。

不过，我一般不会一开始就让它发布文章、删除内容或者提交表单，而是先让它执行查看、整理、检查这类只读任务。涉及发布、付款、删除和账号设置时，我仍然会自己做最后确认。

2. Computer Use：操作桌面软件

如果说 Chrome 是 Codex 进入网页的入口，那么 Computer Use 就相当于给 Codex 装上了一双“手”。

它可以看见电脑界面，并在获得允许后点击按钮、输入内容、切换窗口和操作软件。

这也是我认为普通人最容易感受到变化的一个插件。

我使用 Mac 的时间不算很长，刚开始安装软件、调整系统权限或者修改应用设置时，经常不知道应该点击哪里。以前遇到问题，只能一边看教程，一边来回切换窗口。

有了 Computer Use 之后，我可以直接告诉 Codex：

“打开这个软件，帮我检查当前设置，先不要修改。”

或者：

“查看这个文件夹里的素材，按照项目名称进行分类，操作前先告诉我分类方案。”

它还可以帮助我检查剪辑软件设置、整理本地素材、测试应用界面，以及完成跨软件的简单流程。

当然，Computer Use 能够影响电脑里的真实内容，所以任务范围必须说清楚。我的习惯是一次只让它操作一个软件，并且在提示词里明确写上“不要删除”“不要发布”“修改前先确认”。

二、第二类：连接资料和办公系统的插件

这一类插件看起来数量很多，但没有统一的“必装答案”。

选择的原则非常简单：你的资料在哪里，就连接哪里。

3. Google Drive：适合使用 Google 工作区的人

Google Drive 插件可以处理 Drive、Docs、Sheets 和 Slides 中的内容。

如果一个人的资料、文档、表格和演示文稿主要存放在 Google 工作区，那么它的优先级确实很高。

它可以帮助查找资料、总结文档、整理表格、读取项目文件，并根据云盘里的已有内容生成新的材料。

但我的实际感受是，不应该为了使用一个插件，专门把原来的资料全部迁移到另一个平台。

如果你的团队主要使用飞书，就继续围绕飞书建立工作流；如果资料主要保存在本地，就先使用本地项目文件和 Computer Use。

工具应该适应自己的工作方式，而不是让自己为了工具重新折腾一遍。

4. 飞书用户怎么选择

国内很多团队主要使用飞书，而不是 Google Drive 和 Slack。

飞书云文档、多维表格、群聊、日历和云盘，本身已经覆盖了大部分办公协作需求。

如果 Codex 插件目录或者所在工作区提供了可用的飞书插件、连接器，就优先选择与自己现有系统匹配的版本。

暂时没有直接连接时，也可以先通过 Chrome 处理飞书网页版，或者通过 Computer Use 操作飞书客户端。等工作流稳定以后，再考虑配置 MCP 或者定制插件。

我的建议是：先跑通一个真实任务，不要一开始就折腾复杂连接。

例如，可以先尝试把一篇文章的选题、标题、结构和发布计划整理到飞书文档或多维表格中。这个流程能够稳定完成，再继续扩展自动化。

5. Gmail 和 Slack：不是普通人必装

在以前的版本里，我把 Gmail 和 Slack 也放进了推荐清单。

后来重新看自己的使用习惯，发现这样写并不真实。

我平时使用邮件比较少，主要沟通渠道也不是 Gmail。即使安装了 Gmail 插件，它进入我日常工作流的机会也不多。

Slack同样如此。它适合本来就在 Slack 中协作的团队，但国内很多个人创作者和小团队主要使用飞书、微信或企业微信。

所以 Gmail 和 Slack 并不是不好用，而是只有当你本来就在高频使用它们时，安装才有意义。

插件应该连接你已经在使用的工具，而不是为了安装插件，强行增加一个新平台。

三、第三类：做项目以后才会用到的插件

普通人刚开始使用 Codex，通常是写内容、整理文件或者处理资料。

但当你开始让 Codex 制作网站、自动化工具或者智能体时，另外几类插件就会逐渐变得重要。

6. GitHub：不只是程序员才会用

以前我一直觉得 GitHub 是程序员使用的工具。

后来开始用 Codex 管理公众号排版代码、自动化脚本、提示词仓库和智能体项目后，我才发现，GitHub更像一个项目版本仓库。

它可以保存每一次修改，出现问题时还能查看改动，避免文件越改越乱。

如果你只是写文章、做简单表格，暂时不需要急着连接 GitHub。但只要开始做网站、脚本、插件或者长期维护的项目，GitHub 就会越来越重要。

7. Sites：把想法快速做成网页

Sites 更适合需要把内容变成网页的人。

例如制作课程介绍页、个人作品集、产品落地页、在线小工具，或者把一个想法快速做成可以分享的网页原型。

对内容创作者来说，它的价值在于让 Codex 不只帮助写文案，还能继续完成展示和交付。

不过，如果当前完全没有制作网站的需求，也没有必要为了“以后可能会用”提前安装。

8. Codex Security：正式项目再考虑

Codex Security 主要用于代码安全扫描、漏洞检查和修复建议。

对于刚开始用 Codex 写文章、整理资料或者做简单网页的人来说，它并不是高频插件。

只有当你开始制作正式网站、应用、客户项目，或者项目中涉及用户数据和商业交付时，安全检查才会进入高优先级。

所以它更像项目成熟之后补上的保险，而不是普通用户入门时必须安装的工具。

四、我现在是怎么选择插件的

重新整理之后，我现在不会再一次安装很多插件，而是按照任务逐步增加。

第一阶段，我会优先使用 Chrome 和 Computer Use。

因为这两个插件能够直接帮助我处理网页、软件、本地文件和真实操作，也是普通人最容易看到效果的组合。

第二阶段，再根据资料存放的位置选择 Google Drive、飞书连接方式或者其他知识库工具。

第三阶段，开始制作网站、脚本和智能体之后，再增加 GitHub 和 Sites。

至于 Gmail、Slack、Codex Security，则完全根据实际工作需要决定。

我现在使用 Codex 的一个明显感受是：

真正提高效率的，从来不是插件数量，而是有没有形成稳定的工作流程。

以前，我可能先在浏览器里收集资料，再复制到文档里整理，然后打开其他工具生成脚本，最后自己管理文件。

现在，我更希望形成一条连续流程：

Chrome 收集资料，Codex 完成整理和创作，资料进入飞书或项目文件，Computer Use 继续处理本地软件，需要做网页时再交给 Sites 或 GitHub。

当这些工具真正连接起来，Codex 才不再只是一个聊天机器人，而是开始像一个能够参与工作的助手。

最后

Codex 插件很多，但普通人没有必要全部安装。

对于大多数用户来说，可以先记住下面这个顺序：

先用 Chrome 和 Computer Use 解决网页与电脑操作；再根据自己的资料平台选择 Google Drive、飞书或其他连接方式；等开始做网站和长期项目以后，再考虑 GitHub、Sites 和 Codex Security。

插件只是入口，不是目的。

codex最近很火爆，所以教程也是鱼龙混杂。

在刚接触一个新的AI工具时，我一般不会急着跟着各种教程操作，也不会一上来就研究所有功能。我的第一步，是先找到它的官方网站、产品说明、帮助中心和更新日志，弄清楚这个工具到底擅长什么、官方推荐它处理哪些任务，以及目前有哪些限制。

接下来，我会重点看官方提供的案例和使用方法。因为一个新工具刚推出时，官方案例往往代表它当前比较成熟、比较稳定的能力。先照着官方流程完成一次，再把案例里的任务替换成自己的真实工作。比如官方演示整理文档，我就让它整理公众号资料；官方演示处理网页，我就让它检查内容后台；官方演示操作表格，我就拿自己的选题库和项目数据进行测试。

如果一个任务能够连续完成几次，我就把提示词、操作步骤和注意事项保存下来，慢慢变成自己的工作流。如果暂时不好用，也不用马上否定它，可以等模型或软件升级以后再测试。Codex就是一个很典型的例子，随着模型能力提升，很多以前不稳定的任务，现在已经变得更容易完成。

我认为，学习新工具最有效的方法，不是记住所有按钮，而是掌握一套可以反复使用的思路：先看官方文档，理解能力边界；再跑官方案例，验证核心功能；最后把相似的真实工作交给它。

如果你也在学习Codex和各种AI工具，我组建了一个交流群（v，hougeai666），欢迎加入我们一起交流。一个人摸索，容易在同一个问题上反复踩坑；大家分享真实的使用经验，往往能够学得更快，也能更早把新工具变成真正的生产力。