Codex 扩展能力怎么选：Skills、MCP 与 Plugins 的分工实战|静沐暖阳

适用人群：已经会用 Codex，希望把重复流程、外部系统和团队能力组织起来的开发者。核心结论是：Skill 负责“怎么做”，MCP 负责“能访问什么”，Plugin 负责“如何安装和分发一整套能力”。三者不是互相替代，而是逐层组合。

很多人第一次扩展 Codex 时，会在 Skill、MCP 和 Plugin 之间来回犹豫：一段发布流程该写成 Skill，还是做成 MCP？接入 GitHub 后是否还需要 Skill？个人脚本什么时候值得打包成 Plugin？如果一开始边界没分清，常见结果是把业务步骤塞进连接器、把凭据写进脚本，或者为了一个简单检查维护过重的插件。

先用一句话分清三者

Skill：可复用的工作方法。它通常以 SKILL.md 为入口，还可以带脚本、参考资料和模板。适合发布检查、代码评审、故障诊断等“步骤基本稳定，但每次输入不同”的流程。
MCP：外部能力与数据通道。当 Codex 需要读取工单、搜索内部知识库、查询设计稿或调用远程服务时，用 MCP 暴露工具、资源或提示模板。
Plugin：可安装的能力包。它能把 Skills、MCP 配置、Hooks 和展示资源组合起来，通过统一入口安装、启用和分发。

可以把它们想成厨房：Skill 是菜谱，MCP 是通往冰箱和灶具的接口，Plugin 则是装好菜谱、工具和说明书的整套厨房套件。

三步选择法：先流程，再数据，最后分发

第一步，问自己“这件事是否只是一个可重复流程”。如果答案是肯定的，先做 Skill。比如每次发版都要检查变更日志、运行测试、查看 Diff、生成回滚说明，这些动作主要依赖本地仓库和命令，不必为了“看起来更工程化”而搭建服务。

第二步，检查流程是否需要仓库之外的实时数据或动作。如果 Skill 必须读取远程告警、更新项目管理系统、访问团队文档，就为这些能力接入 MCP。此时 Skill 继续描述顺序、判断条件和失败处理，MCP 只提供边界清晰的工具。例如：Skill 规定“先读告警，再定位提交，验证后才更新状态”；MCP 分别提供读取告警和更新状态的操作。

第三步，判断是否要让多人稳定安装。如果只是个人或单个仓库使用，保留本地 Skill 与项目配置通常更轻。需要跨团队发布、统一版本、附带连接器或 Hooks 时，再打包成 Plugin。官方文档也明确把 Skill 视为工作流的创作格式，把 Plugin 视为可安装的分发单元。

一个可落地的组合示例

假设团队要做“每日缺陷分诊”，可以这样拆：

Skill 写明筛选时间范围、去重规则、严重级别判断、输出格式和人工确认点。
MCP 提供 list_incidents、get_logs、update_ticket 等最小工具，不把“什么情况下关闭工单”的业务判断固化在连接层。
Plugin 打包该 Skill、MCP 映射和图标，让团队成员按同一版本安装。
自动化只负责按时触发；涉及关闭工单、发送通知等外部写操作，仍保留审批或明确的权限策略。

这种拆法的好处是可测试：没有外部连接时，可以用固定样例验证 Skill 的决策逻辑；连接器升级时，可以单独测试 MCP 返回结构；分发有变化时，只调整 Plugin 清单和版本。