夜雨聆风全网最全 Codex 插件使用指南：从入门到榨干
打开 Codex 的插件页，最容易让人卡住的地方，不是插件太少，是名字太多。
Browser、Chrome、Computer Use、GitHub、Gmail、Slack、Linear、Vercel、Documents、Spreadsheets、PDF、Canva、Supabase、Stripe、PostHog……每个看起来都有点用，每个又像暂时用不上。
所以这期不按“插件列表”讲。
更好的看法是：插件在回答一个问题，Codex 能不能进入你的真实工作现场？
你在浏览器里看网页，它需要能看网页。你在 GitHub 上改 PR，它需要能读仓库和评论。你在 Gmail、Slack、Linear 里处理事情，它需要能进这些工具。你在做表格、PPT、PDF、Word，它需要懂这些文件的结构，而不是只把文字复制出来。
插件最有用的地方就在这里：Codex 不只在对话框里给建议，它能进到任务发生的地方。
读完这篇，你不需要记住每个插件的介绍。你只需要能判断：我现在该装哪几个，哪些看起来很强但可以先放着。
目录
先按任务选，不按插件名选
我会把 Codex 插件分成几类。
看网页和操作界面的：Browser、Chrome、Computer Use。
处理文件的：Documents、Spreadsheets、Presentations、PDF、Template Creator。
接入沟通和项目流的：Gmail、Slack、Teams、Outlook、GitHub、Linear、Vercel。
接入业务系统的：Google Drive、Notion、Airtable、Supabase、Stripe、Shopify、PostHog。
面向设计和内容的：Canva、Figma、Data Analytics。
这样看就清楚了。你不用问“这个插件高级吗”，只要问“我有没有这个工作场景”。
没有场景，插件再强也只是占地方。有场景，一个插件就能少掉很多复制、粘贴、截图、来回切窗口。
Browser、Chrome、Computer Use：三个都能看网页，但不是一回事
很多人会先被这三个绕住。
Browser 是 Codex 自带的应用内浏览器。它适合看本地开发页面、公开网页、网页预览。比如你让 Codex 改一个前端页面，它可以打开 localhost，点按钮，看控制台报错，截图检查布局。做网页、调 UI、验证前端改动时，Browser 很顺手。
Chrome 是让 Codex 使用你的 Chrome 状态。它的重点是“已登录”。你要让 Codex 看后台系统、CRM、LinkedIn、公司内网页、某些需要登录的页面，就该想到 Chrome。它比 Browser 更贴近你的真实浏览器，也更需要注意权限，因为它可能接触到历史记录、登录态、网页内容。
Computer Use 更像远程操控电脑。它可以看屏幕、点桌面软件、打开系统设置、操作那些没有 API、没有网页接口、没有插件的地方。它很强，但不要把它当默认选择。能用 GitHub 插件，就别让它点网页里的 GitHub；能用 Gmail 插件，就别让它在浏览器里慢慢找邮件。Computer Use 适合处理那些“只剩图形界面能走”的任务。
一句话：
本地页面和公开网页，用 Browser。
需要你的登录态，用 Chrome。
要碰桌面软件和系统界面，用 Computer Use。
Documents、Spreadsheets、Presentations、PDF：非程序员也能立刻用上的一组
这组插件容易被低估。
Documents 负责 Word、文档、报告、备忘录这类东西。它不只帮你写一段话，还能按文档结构改、批注、整理版本，让内容更接近能交付的稿件。
Spreadsheets 负责 Excel、CSV、表格分析。普通聊天模型也能解释表格，但麻烦往往藏在公式、格式、工作表结构、列名清洗、图表和汇总里。销售表、预算表、数据清洗、月报底稿，都可以交给它先处理。
Presentations 负责 PPT 或演示稿。它适合把一堆材料压成结构，把页面拆成标题、要点、讲述顺序，再做成可继续编辑的文件。对经常做汇报的人，这比“给我一份大纲”更有用。
PDF 插件负责读、做、检查 PDF。PDF 的问题是版式固定，很多时候不能只看文字。你要核对合同页、报告版面、扫描出来的资料、导出的手册，PDF 插件比普通文本读取可靠。
Template Creator 更偏长期使用。你已经有固定格式，比如周报模板、客户方案模板、研究卡片模板，就可以把它做成可复用的模板。下次直接让 Codex 按你的格式生产，少讲一遍规则。
这组插件适合一类人：不一定写代码，但每天都被文档、表格、PPT、PDF 缠住。
Gmail、Slack、Teams、Outlook：把沟通流接进来
沟通类插件解决的是“信息散在各处”的问题。
Gmail 可以帮你查邮件、总结线程、找待回复事项、起草回信。适合邮箱里有客户、合作、账单、通知的人。
Slack、Teams 面向团队沟通。它们能把频道里的进展、争议、待办、负责人整理出来，也能帮你草拟回复。省下来的主要是判断成本：你不用在几十条消息里猜“现在到底卡在哪”。
Outlook 面向使用微软体系的邮箱和日程场景。对公司邮箱在 Outlook 里的用户，它比 Gmail 更贴近工作现场。
这类插件有一个共同边界：越接近真实沟通，越要小心权限和误发。让 Codex 总结、查找、起草都很好用；发送之前，最好自己过一眼。
GitHub、Linear、Vercel：开发者最该先看的三件套
如果你用 Codex 写代码，GitHub 插件几乎是第一梯队。
它能看仓库、PR、Issue、review comment、CI 结果，能帮你定位失败的检查、整理代码审查意见、准备改动。没有它，Codex 只能在本地猜上下文；有它，Codex 能看到协作现场。
Linear 负责需求和任务。它把产品需求、bug、项目进度接进来。你可以让 Codex 读 ticket、拆任务、更新状态、把实现计划对齐到项目管理里。它补上的，是“代码为什么要这样改”的背景。
Vercel 负责部署、构建日志、项目配置和线上排障。前端项目上线后，问题常常不在代码编辑器里，而在部署日志、环境变量、构建失败、域名、保护设置。Vercel 插件让 Codex 能看到这些信息，少一点“你把报错复制给我”的中转。
这一组装起来，Codex 就能覆盖一条常见开发链路：从任务，到代码，到 PR，到部署。
OpenAI Developers、Supabase、Stripe：做产品时再装
OpenAI Developers 插件适合正在接 OpenAI API 的人。它能查官方文档、帮你理解 API、Agents SDK、模型调用、错误排查。写 AI 应用时，它比泛泛搜索更直接。
Supabase 插件适合项目用了 Supabase 的人。数据库、表结构、SQL、权限、Auth、日志、Edge Functions，这些东西一旦和代码分开看，就很容易断。插件的意义是让 Codex 能同时理解应用代码和后端状态。
Stripe 插件面向支付、订阅、发票、退款、客户管理。支付系统最怕“看起来能跑，其实漏了关键步骤”。它能把产品、价格、支付链接、订阅、Webhook、文档建议这些环节串起来。
这几个插件不必提前装。你真的在做 AI 应用、后端数据库、支付系统时，它们才会变成刚需。
Canva、Drive、Notion、Airtable：内容和运营会更有感
Canva 面向设计、社媒图、演示、品牌素材。它把“想法”接到可编辑设计里，不只给你一段提示词。
Google Drive 适合资料散在 Docs、Sheets、Slides、文件夹里的团队。它像一个入口，让 Codex 能从云端文件里找上下文。
Notion 适合知识库、会议纪要、项目文档。它最好用的地方有两个：从旧资料里找答案，把新信息整理回知识库。
Airtable 适合运营表、内容库、客户库、项目台账。它介于表格和轻量数据库之间，适合让 Codex 查询、更新、分析结构化记录。
这类插件的判断标准很简单：你的工作材料在哪里，Codex 就应该接到哪里。材料在 Notion，就别每天把 Notion 内容复制出来；材料在 Drive，就让它直接读 Drive。
Data Analytics、PostHog、Figma：有明确需求再碰
Data Analytics 听起来人人都需要，但它更适合有数据分析习惯的人。比如产品用量、KPI、Notebook、语义层、仪表盘。只是偶尔看一个小表格，Spreadsheets 就够了。
PostHog 适合产品团队。它关心用户行为、实验、功能开关、错误、漏斗、留存。你没有埋点体系，它就派不上大用场；你已经在用 PostHog，它能让 Codex 帮你从数据里找产品问题。
Figma 适合设计到开发的协作。它让 Codex 能理解设计稿，辅助把界面落到代码里。对不做 UI 的人，可以先跳过。
这一组别被名字吓到，也别被名字吸引。它们的专业性只有在专业场景里才会变成体感。
Skill、Plugin、MCP、Hook：记四句话就够了
Skill 是工作方法。比如你希望 Codex 总按某个流程写稿、审稿、查资料，就把方法写成 Skill。
Plugin 是安装包。它可以把 Skill、应用连接、MCP、资源打包在一起，方便安装、分享和管理。
MCP 是连接外部系统的通道。GitHub、文档、数据库、搜索、内部工具，很多能力都靠这类连接打通。
Hook 是自动触发的动作。比如在某些生命周期里执行检查或流程。它很有用，但更偏进阶用户，安装时要看清楚权限和行为。
对普通用户来说，先记住：Skill 像方法，Plugin 像套装，MCP 像接口，Hook 像自动化开关。
我会怎么推荐你装
如果你只想先试试 Codex 插件：
Browser、Documents、Spreadsheets、PDF。
这套能覆盖网页验证、文档、表格、PDF，日常体感最明显。
如果你是开发者：
Browser、GitHub、Linear、Vercel。
这套能覆盖本地页面、代码协作、任务管理、部署排障。
如果你主要处理沟通和运营：
Gmail 或 Outlook、Slack 或 Teams、Google Drive、Notion、Airtable。
这套更像把 Codex 接进你的信息流。
如果你在做商业产品：
OpenAI Developers、Supabase、Stripe，再按需要加 PostHog。
这套别一上来全装。等你真的碰到 API、数据库、支付、用户行为分析，再装会更清楚。
我的建议很直接：少装一点，但装到你的工作流里。
插件页不是收藏夹。你装一个插件，最好能立刻说出它帮你少做哪一步：少复制一段上下文，少翻一次 PR，少查一轮邮件，少打开一个后台，少手动检查一个页面。
说得出这一步，它就有价值。
说不出，先放着。
资料与边界
这篇按 2026 年 6 月 28 日可查到的官方文档和本地 Codex 插件信息整理。Codex 插件还在快速变化，插件数量、名称、连接方式、权限说明都可能更新。安装涉及外部账号的插件时，建议看清楚授权范围，尤其是邮箱、浏览器、团队沟通、支付、数据库这类高敏感工具。
参考资料：
OpenAI Codex Plugins Build a Codex Plugin Codex Skills Codex Customization Codex Browser Codex Chrome Extension Codex Computer Use OpenAI Developers Codex Plugin Codex Security Plugin
