Codex App Windows 版高级教程(补充篇),Plugins 到底值不值得装?

之前有粉丝留言说让我把 codex app windows 高级教程系列做一个合集，我已经做成了合集。

不过我说过因为之前 Windows 版菜单里是找不到这个入口的，所以还缺少一个 plugins 的用法实操。

今天打开 Codex，在用 codex 帮我清理 C 盘的时候，发现侧边栏多了一栏。

技能和应用，点开后里面已经有 plugins 目录了，和 skills 已经分开了。

前几篇把 AGENTS.md、config.toml、Worktrees、Skills、MCP、Automations、Subagents 等都讲了一遍，从「用顺」到「多 Agent 协作」，今天把 plugins 在具体的做一个补充讲解。

补充篇有四件事我觉得值得讲清楚：

Plugins / Apps / MCPs / Skills 四个 Tab 到底是什么关系、

官方目录里哪些 Plugin 真的值得装、

MCP 会不会被 Skills 替代、

还有飞书和语雀这种国内工具怎么手动接进来。

点开 Plugin 面板，顶部有四个 Tab，Plugins、Apps、MCPs、Skills。

这是最容易搞混的地方。不搞清楚后面看配置会一头雾水。我这边再啰嗦说一下。

Skills，就是本地的 Prompt 工作流，本质是 Markdown 文件。你写一份操作手册，告诉 Codex 遇到某类任务该怎么做。比如生成 commit message、代码审查流程，这些都是 Skill。

MCPs，通过 MCP 协议连接的工具服务器。飞书 MCP、PostgreSQL MCP、Figma MCP，都属于这一类。

Apps 我第一次看也愣了一下。「这跟普通应用有什么关系？」

Apps 可以理解成 Codex 连接外部服务的集成层。OpenAI 现在在 ChatGPT 里也统一用 apps 这个叫法，旧文档里的 connectors 基本就是现在的 apps。

Codex 的 app 体系和 ChatGPT 是打通的，Gmail、Google Drive、Slack 这些都走这条路。但不是说你 ChatGPT 那边授权过就完全无感继承了，首次安装插件或者第一次调用某个 app 的时候，Codex 仍然可能提示你去 ChatGPT 里完成安装或登录。官方文档原话就是「Codex may prompt you to install or sign in to those apps in ChatGPT during setup or the first time you use them」。

ChatGPT里面的apps，就算这里连接过了，可能 codex 还是会让你再次登录一下。

所以 Codex 里的工具来源，主要就是三条路：Apps（ChatGPT 那边的授权集成）、你自己配置的 MCP servers，以及 Plugin 打包带进来的 skills / apps / MCP servers。

Plugins 做的事就是把这三条路打包成一个「一键安装」。装一个 Plugin，可能同时给你装进来一个 Skill、一个 MCP、一个 App 授权入口。

搞清楚关系之后，来看看官方 Plugin 目录里到底有什么。

截至我写这篇的时候，公开目录里有 20 多个 Plugin，基本全是海外 SaaS 工具。国内协作工具目前还没进 Plugin 目录，主要靠手动 MCP 接入。这点后面会讲怎么绕过。

我按国内读者的实际适用度筛了一遍。

GitHub 是唯一一个国内读者普及度最高之一的海外服务。装完能让 Codex 直接管理你的仓库、issue、PR。场景泛用，OAuth 授权无门槛。如果你只想试一个 Plugin，就试这个。

Figma 也值得试。国内设计团队用 Figma 的非常多，让 Codex 读设计稿生成前端代码、盘点设计系统，我自己试过几次，比我预期流畅。

Notion 看你自己情况。国内 Notion 用户比飞书语雀少得多，但有一批重度用户是真的离不开。装不装取决于你用不用。

build-web-apps 这个 Plugin 比较特别，值得单独说一下。它一个 Plugin 里同时打包了 Stripe + Supabase + Vercel 三个 MCP 加一套建站 Skill。是目前官方目录里最复杂的一个，展示了 Plugin 的能力上限。但三个工具国内用户都有门槛，境外支付、境外服务器，做出海产品可以玩，做国内产品就算了。

剩下的 Gmail、Google Drive、Slack、Linear、Sentry、Box、Hugging Face。。。国内大多数人工作中不用，装了大概率闲置。

安装流程很简单。侧边栏 Plugins，搜名字，点 Install，需要 OAuth 就按流程走，装完新建线程就能用。

调用有两种方式。一种是自然语言，直接用中文描述任务，Codex 自己判断该调哪个 Plugin。另一种是 @ 显式调用，输入框打 @ 会弹出已装 Plugin 列表，选一个指定它处理。大部分场景用自然语言就够了，除非你明确知道「这件事必须用这个 Plugin 做」。

首先向 codex 提问下 github 访问的目录是不是自己的 github，

确定好是自己的 github 目录后，就可以看下面的提示词了。

给三个 GitHub Plugin 的实操 Prompt，装完可以直接抄。

第一个，周会场景。

看一下我名下所有仓库,最近一周有新 issue 或者 PR 的列出来,按仓库分组,每条标注状态和 last update 时间。我周会要用。

我的项目目前没有 issue 和 pr ，但是它确实已经链接到我的项目里面去查询了。后面的我就不去执行了，大家根据自己的需要来用。

第二个，追踪开源项目。

看一下 [某开源项目] 这个仓库最近 30 天的 release notes,总结有哪些新特性、哪些 breaking change,用中文输出一份简要列表。

第三个，项目健康度检查。

检查我的 [你的仓库名] 项目:1. 有没有超过 30 天没人处理的 issue?2. 有没有依赖包几个版本没更新?3. 最近一次 CI 失败是什么时候、什么原因?生成一份健康度报告。

说到这里，要聊一个很重要的行业趋势，会直接影响你怎么用 Plugin。

去年 10 月，Simon Willison 写了一篇爆款文章，标题就叫「Claude Skills are awesome, maybe a bigger deal than MCP」。

https://x.com/simonw/status/1978935386496995811

他的核心观点我觉得说到了点子上。他说自己对 MCP 的兴趣在减退，因为能用 MCP 做的事，几乎都能用 CLI 工具替代。LLM 知道怎么调 cli-tool --help，你不需要花很多 token 在 prompt 里描述这个工具怎么用，模型需要的时候自己去查就行。

他举了个例子特别扎心。GitHub 官方 MCP 光是描述工具用法就要占几万个 token。你装几个 MCP，上下文窗口还没开始干活就被吃掉一半。。。

这波讨论的影响比很多人以为的要大。12 月 18 号，Anthropic 直接把 Skills 做成了开源标准，发布了规范和 SDK，Canva、Notion、Figma、Atlassian、Stripe、Zapier 都来做首发合作。

同月，OpenAI 也悄悄在 ChatGPT 和 Codex CLI 里加了 Skills 支持。两家都在押 Skills + CLI 这条路。

但我觉得更冷静的看法是这样的。

Skills 和 MCP 不是竞争关系，是不同的架构解决不同的问题。

需要「操作」的任务，CLI 加 Skill 更合适。创建 PR、发消息、部署、写文件，AI 在 bash 里直接调命令行就行，上下文开销小。

需要「结构化查询」的任务，MCP 还是不可替代。查飞书文档树、查数据库 schema、查 Figma 组件层级，这种嵌套的、强类型的数据，用 CLI 拼 JSON 会很痛苦。

有意思的地方来了。

Plugin 的设计已经对冲了这个风险。它是 Skills + MCPs + Apps 三合一打包。如果 MCP 继续主导，Plugin 里的 MCP 部分继续扩；如果 Skills + CLI 胜出，Plugin 里的 Skill 部分扩，MCP 部分缩。大概率的现实是混合态，Plugin 变成「工作流打包」的标准格式，底层协议是什么用户不关心。

所以以后你再遇到那种说 CLI 是否要取代 MCP 的问题就不用纠结了。答案就在 plugins 里面。

对你的直接启发就一句话，插件别装太多。

我自己的体感是，插件一多，Codex 在选择调用哪个工具的时候就容易犹豫，权限管理和认证流程也会变复杂。优先保留你高频常用的 2 到 3 个就够了。

回到国内工具这块。

这是很多朋友最关心的部分。官方 Plugin 目录短期内应该不会有国内工具，但飞书、语雀都有成熟的官方 MCP，手动配一下就能用。配完之后使用体验和 Plugin 装的完全一样，都在 Codex 的 MCPs Tab 里显示。

先说飞书。

很多人会第一时间可能会想到飞书之前不是发布过 CLI 了吗？还要用 MCP 吗？如果你还是有这个疑问就又回到了 CLI 能取代 MCP 吗？什么时候用 CLI ？什么时候用 MCP ？这些问题上来了。上面已经有过详细的解说了。

飞书官方开放平台有一个 MCP，包名是 @larksuiteoapi/lark-mcp。认准这个官方的，社区版有很多，质量参差不齐。

第一步，创建飞书自建应用。打开飞书开放平台，登录你的飞书账号，右上角「开发者后台」，点「创建企业自建应用」。

填个应用名字，比如「Codex 接入」，随便上传个 logo。

创建完进入应用详情页，左侧菜单「凭证与基础信息」，能看到 App ID 和 App Secret，这两个值后面要用。

第二步，给应用申请权限。左侧菜单「权限管理」，搜索并申请你需要的权限。读新版文档是 docx:document:readonly，读写新版文档是 docx:document，搜索文档是 search:docs:read，读知识库是 wiki:wiki:readonly，读写知识库是 wiki:wiki，发消息到群是 im:message，读用户基本信息是 contact:user.base:readonly。按你的实际需求选就行，不用全开，开了用不上的权限审批也容易被卡。

申请完在「版本管理与发布」里发布一个版本，等企业管理员审批。如果你自己就是管理员那就直接过。

第三步，配置到 Codex。打开 ~/.codex/config.toml，Windows 下是 C:\Users\你的用户名\.codex\config.toml，加上这段。或者你是在找不到位置，就去 codex app 设置里面直接打开

[mcp_servers.lark]command = "npx"args = [  "-y",  "@larksuiteoapi/lark-mcp",  "mcp",  "-a", "cli_你的AppID",  "-s", "你的AppSecret"]

如果你要让 MCP 以你的个人身份操作飞书，能看到你私有文档那种，加 OAuth 模式。

[mcp_servers.lark]command = "npx"args = [  "-y",  "@larksuiteoapi/lark-mcp",  "mcp",  "-a", "cli_你的AppID",  "-s", "你的AppSecret",  "--oauth",  "--token-mode", "user_access_token"]

用户身份模式需要先完成一次登录授权。首次配置时一般会弹浏览器让你登录飞书账号，授权完 Token 缓存在本地，后面不用再授权。如果没有自动弹出，可以手动执行一次 npx -y @larksuiteoapi/lark-mcp login -a cli_xxxx -s your_secret 先获取用户 token，再启动 MCP。

执行这个命令后弹出这个地址，报错了，原来是我的回调地址没有配置，需要在开放平台里面配置下。

打开安全设置，在重定向 URL里面输入：

http://127.0.0.1:3000/callback

然后点击添加按钮。

然后执行新的命令：npx -y @larksuiteoapi/lark-mcp login -a cli_xxxx -s your_secret --host 127.0.0.1

然后继续验证一下获取 token 会自动配置到 config.toml 里面。你不用去管这个token。

第四步，重启 Codex 验证。进任意线程，输入「请使用 lark MCP，帮我查看当前飞书登录用户信息」，能列出来就是接好了。

飞书常用的几个实操 Prompt。

读取我飞书知识库「产品文档」下的所有子文档,整理出每个文档的标题、最近修改时间、作者,按最近修改时间倒序生成一份表格。

根据我本地的 ./weekly-report.md 文件,在飞书「周报」文件夹下创建一个新文档,标题用今天的日期加「周报」,内容就用这个 Markdown。

搜索我飞书里最近一个月更新的、标题包含「AI」的所有文档,读取每个文档的前 500 字,生成一份「AI 相关文档速览」。

再说语雀。

语雀官方也出了自己的 MCP，仓库在 yuque/yuque-mcp-server，npm 包名是 yuque-mcp。认准 yuque 这个官方账号。

第一步，获取 Token。登录语雀，右上角头像，「个人设置」，左侧「Token」，「新建」，勾选需要的权限（读取文档、创建文档、读取知识库等），复制生成的 Token。这里语雀现在的个人token已经是需要收费了，就不演示了，感兴趣的朋友可以尝试下。

第二步，配置到 Codex。~/.codex/config.toml 加上。

[mcp_servers.yuque]command = "npx"args = ["-y", "yuque-mcp"][mcp_servers.yuque.env]YUQUE_PERSONAL_TOKEN = "粘贴你的Token"

或者用命令行快速添加。

codex mcp add yuque -- npx -y yuque-mcp --token=你的Token

第三步，重启验证。输入「列一下我语雀所有的知识库」，能列出来就是接好了。

语雀常用的几个实操 Prompt。

读取我语雀「读书笔记」知识库下的所有文档标题,生成一份目录清单,按创建时间排序。

在我语雀「技术积累」知识库下创建一篇新文档,标题是「Codex 使用心得」,内容从 ./codex-notes.md 读取。

搜索我语雀里所有提到「Agent」的文档,把每篇文档的核心观点提炼成一句话,最后生成一份「我对 Agent 的认知变化」的汇总。

顺着聊一下 Token 安全的问题。

上面两个配置里 Token 是直接写在 config.toml 里的，方便但不安全。config.toml 一旦同步到 Git 或备份到云端，Token 就泄露了。

更安全的做法是用系统环境变量。Windows 下设个环境变量 YUQUE_TOKEN，config.toml 里这样写。

[mcp_servers.yuque]command = "npx"args = ["-y", "yuque-mcp"][mcp_servers.yuque.env]YUQUE_PERSONAL_TOKEN = "${YUQUE_TOKEN}"

飞书那边也一样，App ID 和 App Secret 都可以用环境变量替代。养成这个习惯，少踩一个坑。

钉钉和企业微信这块，情况在快速变化。

钉钉官方已经有了 MCP 路线，open-dingtalk/dingtalk-mcp 这个仓库是钉钉开放平台团队维护的，支持日历、通讯录、任务、工作通知等能力。如果你公司用钉钉，可以去看看是否覆盖你的场景。

企业微信这边，WecomTeam 官方出了 OpenClaw 插件（@wecom/wecom-openclaw-plugin）和命令行工具（wecom-cli），走的更多是插件和渠道能力的路子，不是标准 MCP 协议，但能力在快速补齐。

坦率的讲，这两家比半年前强了很多，但和飞书、语雀比还是差一截成熟度。如果你当前的需求不是特别迫切，可以再观望一下；如果等不及，钉钉那个官方 MCP 已经能跑了。

最后聊聊我自己的使用边界。

值得装 Plugin 或者配 MCP 的场景，核心就一条，高频重复。你每天都要从飞书读文档、每周都要从 GitHub 拉数据、需要跨工具做的事（从 GitHub 拉 PR 整理完发飞书群），或者团队要共用一套工作流。这些场景下配一次，终身享受。

不值得的场景也很明确。只用一次的任务，直接开浏览器比配一遍还快。涉及生产环境破坏性操作的，AI 误删飞书文档、误发邮件都有实际案例。权限敏感的场景，给 AI 完整读写权限之前，想三遍。

坦率的讲，这篇写下来我自己也在反思一个事。

这几年 AI 工具爆发式增长，MCP、Skills、Plugins、CLI，每隔几个月就有一个新概念冒出来，每个都说能让你的工作流更高效。说实话有时候我自己也会恍惚，这些东西是真的在帮我，还是我在帮它们刷存在感？

但 1880 年代电力刚普及的时候也是这样。很多工厂主花大价钱买了发电机和电动机，装在自己的工厂里。装完发现生产效率并没有显著提升。因为他们只是用电动机替代了蒸汽机，但整个工厂的布局、流程、管理方式都没有变。

真正吃到电力红利的人，是最早想明白「电力能拿来干嘛」的那波人。

AI 也是一样。Plugin 再炫，不用就是占上下文。MCP 再强，配完不跑就是浪费半小时。工具不是越多越好，能解决你具体问题的才是好工具。

我自己现在常驻的就三个，GitHub、飞书、语雀。其他的试过，留下来的没几个。

如果你想上手，我的建议。

先装 GitHub Plugin，10 分钟内跑通，理解 Plugin 是怎么回事。然后根据工作性质加一个，设计师加 Figma，知识工作者配飞书或语雀。装到 2 到 3 个就停，多了管理成本上来，收益反而下降。国内工具老实手动配 MCP，配一次终身享受，不用等 Plugin 目录更新。

感谢你的耐心观看，如果觉得不错，希望能点个赞、转发、收藏三连吧，如果想第一时间收到推送，也可以给我个星标⭐～

谢谢你看我的文章，我们，下次再见。