别急着装插件:先把 Codex 的 3 层能力分清

插件装得越多，Codex 不一定越好用。真正关键的是：先判断你缺的是流程、连接，还是一整套可安装能力。

第一次打开 Codex 的插件目录，很容易产生一种错觉：装得越多，Codex 就越强。

但真正用起来，你会发现另一个问题：Skills、Plugins、MCP 都能“扩展能力”，名字又经常一起出现。结果是，插件装了一堆，真正做任务时反而不知道该调用谁。

它们不是三个互相替代的选项，而是三层可以组合的能力。先把这一点分清，后面配置 Codex 会简单很多。

Skill 最适合解决的是：这件事我会反复做，而且每次都有相似步骤。

比如做一篇公众号文章，你可能每次都要经历：读取品牌规则、核对来源、设计原创结构、撰写正文、生成 HTML、检查排版。单次任务可以把这些全写进提示词，但重复十次，就会不断复制同一套要求。

Skill 的价值，就是把这套做法沉淀成一个可复用工作流。官方文档中，一个 Skill 通常以 SKILL.md 为核心，还可以带脚本、参考资料和模板。Codex 会先根据名称和描述判断是否匹配，再按需加载完整内容。

所以，Skill 不是“让模型突然学会一个新软件”，而是让它在某类任务里，稳定地按你认可的顺序工作。

有些任务不是流程问题，而是 Codex 根本拿不到需要的信息，或者不能执行那个动作。

例如，你想让它读取 GitHub Issue、查看 Figma 设计稿、查询内部知识库，或者控制浏览器检查网页。此时只写一份更长的 Skill，并不能凭空产生连接能力。

MCP 解决的是“连接”。它可以向 Codex 暴露工具、可读取资源和可复用提示，让 Codex 与本地项目之外的系统交互。

你可以这样理解：Skill 告诉 Codex“查完 Issue 后，按严重程度分类并生成修复计划”；MCP 则负责真正把 Issue 数据交给它，并提供查询或更新动作。

先给最小权限，确认流程跑通后再逐步放开，比一开始全部授权更稳。

Plugin 更像一个可安装、可分发的能力包。

按照 OpenAI 官方定义，插件可以把 Skills、Apps、MCP servers、Hooks 和展示资产组合在一起。也就是说，Plugin 不是 Skill 的另一个名字；Skill 可以是插件里的一个组成部分。

更适合装 Plugin 的情况：

① 已经有人把成熟工作流打包好，你希望直接复用；② 一个任务同时需要流程说明和外部应用连接；③ 想把团队统一能力一次安装给多个人；④ 需要集中管理版本、启用状态和分发入口。

例如，一个面向团队的内容插件，可以同时带公众号写作 Skill、素材库连接器、校验 Hook 和统一模板。使用者装一次，获得的是整套生产能力，而不是零散复制几份说明文件。

不过，插件包含的东西越多，越要先看清它要求的权限、外部连接和生命周期脚本。安装不等于自动信任，更不等于所有组件都应该默认开启。

真正做选择时，不用背定义，按下面三个问题走就够了。

第一问：我缺的是稳定做法吗？任务能完成，只是每次步骤不一致、容易漏项，用 Skill。

第二问：我缺的是外部数据或动作吗？必须访问 GitHub、Slack、Figma、浏览器或内部系统，用 MCP 或包含对应连接的插件。

第三问：需要被安装、共享和统一维护吗？自己试验，先从一个 Skill 开始；需要团队使用或组合多种组件，再做成 Plugin。

这不是保守，而是在减少配置、权限和排障成本。

场景一：每周把选题做成公众号文章。痛点是步骤重复、标准容易漏。先做 Skill，把调研、原创、写作、HTML 和 QA 固定下来。

场景二：文章必须读取公司 Notion 和 Slack 讨论。痛点变成外部上下文。原来的 Skill 仍负责写作流程，再通过 MCP 或应用连接拿到资料。

场景三：把内容系统交给整个团队。现在还要一起分发连接、模板和校验规则。把它们打包成 Plugin，会比让每个人手动配置更容易维护。

你会发现，这三个场景不是从 Skill、MCP、Plugin 中三选一，而是逐层增加：先有流程，再接外部能力，最后才打包分发。

Codex 真正变强，不是因为你把插件目录塞满了，而是因为你知道每一层能力为什么存在，也知道什么时候不该用它。

关注我，后面继续拆这类能真正落地的 AI 工作流。