Codex插件完全指南:从小白到专家看这一篇就够了

Codex 最强大的功能之一，就在于它极其丰富的插件——

Browser、Chrome、Computer Use、Documents、Spreadsheets、GitHub、Linear、Vercel、Supabase、Stripe、Notion、Figma……

这些插件每个都很强大，于是很多人都会犯一个错误：

把插件页当成应用商店，不管用不用得上，先装。

但 Codex 插件不是收藏夹。

它是你的工作流接口。

一个插件有没有价值，不取决于它名字多高级，而取决于：

它接进了哪一步工作？

它省掉了哪一步流程？

它能不能让流程复用？

如果这三个问题都是否定的，那再强的插件也没有用。

这篇我会按真实的工作场景，把 Codex 插件拆成一张从小白到专家的路线图。

读完你至少能判断三件事：

第一，刚开始到底先装哪几个。

第二，哪些插件现在可以先不碰。

第三，什么时候你已经从“会用 Codex”进入到“会把 Codex 接进工作系统”。

Codex 插件不是收藏夹，是工作流接口

一、按工作场景选，不按插件名称选

首先问自己一个问题：

“我有没有这个工作场景？”

Codex 插件大致可以按五类工作场景来选。

第一类，是网页和软件界面。

你需要让 Codex 打开网页、点按钮、检查页面、看后台、操作某个没有 API 的系统，就会用到 Browser、Chrome、Computer Use。

第二类，是文件。

你手里有 Word、Excel、PPT、PDF、模板、报告、合同、表格，就会用到 Documents、Spreadsheets、Presentations、PDF、Template Creator。

第三类，是沟通和项目流。

你每天在邮件、群聊、项目管理工具里追进度、找负责人、看遗漏，就会用到 Gmail、Slack、Teams、Outlook、GitHub、Linear。

第四类，是业务系统。

你要接数据库、支付、用户行为、内容后台、商品系统，就会用到 Supabase、Stripe、PostHog、Shopify、Airtable、Notion、Google Drive。

第五类，是设计和内容生产。

你要做图、做页面、整理设计稿、分析数据、输出内容资产，就会碰到 Canva、Figma、Data Analytics 这类插件。

所以别从“哪个插件最强”开始。

从“我现在卡在哪一步”开始。

你卡在网页操作，就找浏览器类。

你卡在文件处理，就找文档类。

你卡在协作推进，就找沟通项目类。

你卡在业务闭环，就找数据库、支付、分析类。

二、Browser、Chrome、Computer Use选谁

这三个插件看起来都像“让 Codex 操作界面”，但边界完全不同。

Browser 适合公开网页和本地网页。

比如你写了一个前端页面，要让 Codex 打开看看按钮有没有错位、页面有没有空白、移动端有没有溢出，就用 Browser。

它更像 Codex 自己带的一扇浏览器窗口。

适合看网页、测页面、抓公开信息、验证本地服务。

Chrome 适合需要你登录状态的网页。

比如你已经在 Chrome 里登录了某个后台、CRM、内部系统、LinkedIn、广告账户，Codex 需要沿用你的登录状态去查看、整理、操作。

这时候 Chrome 插件更合适。

但它也意味着权限更重。

所以不要一上来就把所有操作都交给 Chrome。

能用 Browser 做的，就先用 Browser。

只有确实需要你的登录态、Cookie、后台权限时，再用 Chrome。

Computer Use 适合最后一层兜底。

当一个任务既没有 API，也不是标准网页，还要操作本地软件、系统弹窗、桌面应用时，才考虑 Computer Use。

它更像让 Codex 真的去“看屏幕、点鼠标、敲键盘”。

能力强，边界也更敏感。

一句话记：

公开网页和本地页面，用 Browser。

登录后台和个人 Chrome 状态，用 Chrome。

桌面软件和系统界面兜底，用 Computer Use。

这三个不要混着乱用。

用错了，轻则效率低下，重则权限边界失控。

Browser、Chrome、Computer Use 怎么选

三、非程序员，先看文件类插件

如果你不是程序员，别急着研究 GitHub、Vercel、Supabase。

你最先能感受到价值的，反而是文件类插件。

Documents 处理 Word、报告、合同、长文、会议纪要。

你可以让 Codex 读文档、提炼结构、改写段落、整理版本差异、生成新文档。

Spreadsheets 处理 Excel、CSV、数据表。

它适合做表格清洗、合并、字段标准化、数据透视、指标计算、异常检查。

Presentations 处理 PPT。

不是让它“美化一下”，而是让它先帮你搭结构：汇报逻辑、页面顺序、每页观点、讲稿节奏。

PDF 插件适合读固定版式材料。

比如研报、白皮书、说明书、论文、扫描式资料。它的重点不是编辑，而是读取、提取、校对和转结构。

Template Creator 则更适合把你反复做的东西固化成模板。

比如周报模板、调研报告模板、会议纪要模板、客户复盘模板。

对普通用户来说，第一批值得装的插件通常不是“最炫”的，而是这些每天都能用上的：

文档、表格、PPT、PDF、模板。

因为它们不要求你理解复杂技术系统，也不需要上来就连接业务权限。

只要你每天都在处理文件，它们就能马上进入你的真实工作。

非程序员最先见效的文件类插件

四、沟通类插件，不是代替你聊天

Gmail、Outlook、Slack、Teams 这类插件，不要理解成“让 AI 替我聊天”。

它更像是一个工作助手。

比如：

上周谁答应了什么？

哪个客户还没回复？

哪个项目卡在谁那里？

哪些会议结论没有变成待办？

哪些邮件需要我今天处理？

这类插件最适合做三件事。

第一，搜索。

从大量邮件和聊天记录里找到关键上下文。

第二，总结。

把分散对话整理成结论、待办、负责人和截止时间。

第三，起草。

帮你写回复、跟进、确认、会议纪要，但最后发送前一定由人审核。

这里的边界很重要。

不要一开始就让 Codex 自动对外发消息。

先让它读、找、总结、起草。

等流程稳定之后，再逐步开放更高权限。

五、开发者第一套：GitHub、Linear、Vercel

如果你是开发者，或者正在用 Codex 做项目，GitHub、Linear、Vercel 基本就是第一梯队。

GitHub 管代码和协作。

它能帮 Codex 理解仓库、PR、issue、review comment、CI 状态和提交历史。

你不需要反复复制错误日志，也不需要一边看网页一边让 Codex 猜。

Linear 管任务和需求。

它把“要做什么、优先级是什么、谁负责、现在到哪一步”接进来。

Codex 才能从任务背景开始工作，而不是只看到一段孤立代码。

Vercel 管部署和上线。

它能让 Codex 查构建日志、部署状态、环境变量、域名、预览链接和线上问题。

这三个连起来，就是一条很典型的开发链路：

Linear 里有需求。

GitHub 里有代码。

Vercel 里有上线结果。

Codex 才能从“写代码助手”变成“项目推进助手”。

如果你只装 GitHub，不接任务和部署，它还是会有用，但常常只能解决局部问题。

如果你把任务、代码、部署都接起来，它就更容易理解完整上下文。

开发者插件链路：任务、代码、部署

六、OpenAI、Supabase、Stripe，有产品再装

有些插件看起来很高级，但并非适合所有人。

比如 OpenAI Developers、Supabase、Stripe。

OpenAI Developers 适合你真的在做 AI 应用。

你需要查模型调用、Agents SDK、API 报错、函数调用、结构化输出、工具接入，它就很有价值。

Supabase 适合你真的有数据库、用户系统、权限、SQL、Edge Functions、日志和后端逻辑。

Stripe 适合你真的要接支付、订阅、发票、退款、客户、webhook。

它们不是“学习 Codex 必装三件套”。

它们是你开始做商业产品之后的生产插件。

如果你还没有真实产品、真实用户、真实数据库、真实支付流程，先不用急。

过早安装这些插件，很容易让你陷入“系统感很强，但没有业务”的幻觉。

七、内容、运营、产品怎么选

如果你的工作更偏内容和运营，可以优先看这些：

Google Drive：适合团队资料都在云端文档里的人。它能帮 Codex 找文件、读材料、整理信息。

Notion：适合知识库、会议记录、项目文档、课程笔记都在 Notion 的人。

Airtable：适合把选题、客户、项目、素材、商品、内容排期做成结构化表的人。

Canva：适合经常做封面、社媒图、资料页、品牌物料的人。

Figma：适合产品和设计协作，要看设计稿、标注、组件和页面结构的人。

PostHog：适合已经有产品数据，需要看用户行为、漏斗、留存、转化的人。

这里也有一个判断标准：

如果你的资料只是零散存在，它们能帮你找和整理。

如果你的资料已经结构化，它们能帮你复用和分析。

如果你的资料既没有稳定位置，也没有命名规范，也没有标签，那插件只能帮你临时翻东西，不能自动变成知识系统。

所以，装插件之前，先问自己：

我有没有一个稳定的数据入口？

我有没有固定的命名和分类？

我有没有可复用的输出格式？

没有的话，先整理工作流，再装插件。

八、Skill、Plugin、MCP、Hook，不要混成一团

很多人看到 Codex 生态里的几个词，会有点乱。

Skill、Plugin、MCP、Hook，到底有什么区别？

可以简单这样理解。

Skill 是方法。

它告诉 Codex 某类任务应该怎么做，比如怎么转写公众号、怎么做代码审查、怎么生成长图、怎么跑发布流程。

Plugin 是能力包。

它把某些工具、技能、连接能力打包起来，让 Codex 能调用更完整的外部能力。

MCP 是连接协议。

它让 Codex 能和外部系统对话，比如数据库、浏览器、设计工具、项目管理系统。

Hook 是自动触发器。

它不是让你手动喊 Codex，而是在某些动作发生时自动执行，比如提交前检查、文件变化后整理、定时生成报告。

一句话：

Skill 决定怎么做。

Plugin 决定能用什么能力。

MCP 决定能连接什么系统。

Hook 决定什么时候自动发生。

小白阶段先别全搞懂。

先会用 Skill 和几个核心插件。

等你开始把流程固定下来，再去研究 MCP 和 Hook。

九、从小白到专家，按这个顺序

如果你完全不知道从哪开始，我建议按四个阶段走。

第一阶段：小白起步

先装：

Browser

Documents

Spreadsheets

PDF

这四个覆盖网页验证、文档处理、表格整理和资料读取。

它们最容易马上进入日常工作。

第二阶段：办公增强

按自己的真实工作场景考虑安装：

Presentations

Template Creator

Google Drive

Notion

Gmail 或 Outlook

这时候你开始从“让 Codex 回答”进入“让 Codex 整理资料、产出文件、沉淀模板”。

第三阶段：开发协作

如果你写代码或做项目，再上：

GitHub

Linear

Vercel

OpenAI Developers

这时候 Codex 不只是写代码，而是能理解任务、仓库、PR、部署和线上反馈。

第四阶段：产品商业化

如果你开始做真实产品，再接：

Supabase

Stripe

PostHog

Airtable

Shopify

这时插件的价值不再是“帮我做一件事”，而是把 AI 接进业务结果。

第五阶段：专家模式

专家不是装更多插件。

专家会做三件事：

把常用流程沉淀成 Skill。

把外部系统接成 MCP。

把重复动作做成 Hook。

到这一步，你就不只是使用 Codex，而是在搭自己的工作系统。

从小白到专家的 Codex 插件安装路线图

最后：别追求“大而全”，追求“适合自己”

插件页最容易制造一种幻觉：

只要我把能力都装上，Codex 就会自动变强。

但真实情况往往相反。

没有清晰任务，插件越多，越容易乱。

没有稳定输入，插件越多，越容易误判。

没有验收标准，插件越多，越难知道结果好不好。

所以安装之前，你必须要先自己判断——

我现在到底卡在网页、文件、沟通、代码、业务系统，还是内容资产？

我需要的是读取、整理、生成、验证、发送，还是自动化？

这个插件接进来以后，能不能让下次更省力？

你能说出它省掉哪一步，它就值得装。

说不出来，就先别装。

Codex 插件真正厉害的地方，不是把所有工具堆在一起。

而是把你原本分散的网页、文件、项目、数据和业务系统，接成一条可理解、可执行、可复盘的工作流。

从小白到专家，差距也不在插件数量。

而在你有没有把插件装进真实工作里。

Codex 高权限插件避坑表