技能与插件

Skills 和 Plugins 是 Codex 变成“工作流工具”的关键。模型只决定它会不会思考，技能、插件和工具决定它能不能按固定流程做事，能不能连接浏览器、设计稿、知识库、飞书、GitHub 和自动化系统。

这篇解决什么问题

本章延续原教程的概念说明，讲清楚 Skill、Plugin、MCP、Subagents 的区别，如何从一个固定流程沉淀 Skill，以及为什么“接入 DeepSeek / Minimax”不等于“拥有完整插件能力”。

技能和插件入口可能会出现在 App、项目设置或工具面板中。不同版本入口会变，但核心概念相对稳定。

不同插件会带来不同权限和外部系统连接。安装前先看它能读什么、写什么、需要哪些密钥。

连接外部服务前，要先想清楚它能读什么、能写什么、失败后怎么撤销。

适合谁

• 已经会用 Codex 做基础任务，想沉淀固定流程的人。
• 想接入 Figma、Notion、GitHub、浏览器、飞书或本地工具的人。
• 正在比较 Plus、CCX + CCSwitch、Codex++ 等路线的人。

前置条件

• 理解 Codex 基础任务和权限管理。
• 知道外部工具连接会扩大数据访问范围。
• 准备一个低风险插件或只读 MCP 先测试。

概念区别

Skill 是什么

Skill 可以理解成一份可复用的操作手册。它不一定提供新的外部能力，但会让 Codex 更稳定地按同一套步骤完成任务。

适合沉淀成 Skill 的任务通常有三个特征：

• 经常重复出现。
• 步骤相对固定。
• 输出格式有要求。

例如：

• PR 审查：先读 diff，再列风险，再给验证建议。
• 内容改写：先识别平台风格，再改标题，再输出多版草稿。
• 文档补全：先扫目录，再补缺失章节，再检查链接。
• 数据整理：先规范字段，再生成表格，再给异常清单。

一个好的 Skill 至少要写清楚：什么时候触发、输入是什么、执行步骤是什么、不能做什么、最后输出什么。

Plugin 是什么

Plugin 更像一个安装包或工具箱。它可以包含 Skills，也可以包含 MCP、脚本、工具配置、连接器或资源文件。团队需要复用同一套工作流时，Plugin 比散落的提示词更好维护。

你可以这样区分：

• Skill 解决“怎么做”。
• Plugin 解决“把哪些能力打包给别人用”。
• MCP 解决“怎么连接外部工具或数据源”。
• Subagents 解决“怎么把复杂任务拆给多个工作单元”。

所以不要把插件理解成“更高级的提示词”。插件一旦连接外部系统，就会带来真实权限和数据边界。

MCP 放在什么位置

MCP 是 Codex 连接外部工具的重要方式。常见场景包括：

• 浏览器测试：打开页面、点击、截图、检查 UI。
• 设计工具：读取设计稿、样式和组件信息。
• 知识库：读取 Notion、飞书、Google Drive 或本地资料。
• 数据库和内部系统：查询只读数据或生成报告。
• GitHub：读取 PR、issue、CI 日志并协助修复。

第一次接 MCP 时，建议只接一个低风险、只读工具。等你知道它能访问什么、日志在哪里、失败怎么排查，再逐步扩大范围。

Subagents 怎么理解

Subagents 可以理解成把复杂任务拆给多个子工作单元。比如一个任务里，主线负责实现，旁路线负责查资料，验证线负责跑检查和找遗漏。

它适合复杂任务，但不适合小白一上来就开很多。子任务越多，你越需要清楚的边界、文件范围和最终汇总机制。

从提示词到 Skill 的沉淀流程

1. 先手动跑通同一个任务 3 次。
2. 把每次都会重复说的话整理成步骤。
3. 写清楚输入、限制、输出格式和验证方式。
4. 用一个低风险项目试跑。
5. 根据失败点补充规则。
6. 再考虑打包成 Plugin 或接 MCP。

示例 Skill 骨架：

# 内容站文章优化

## 触发场景
当用户要求优化教程、博客、文档页面时使用。

## 步骤
1. 先读取目标文件和目录上下文。
2. 保留图片、链接和 frontmatter。
3. 补充结构、步骤、常见坑和验证方式。
4. 输出修改摘要。

## 限制
不要删除图片引用，不要改动无关文件，不要编造过期产品信息。

安装或启用前的检查

安装 Skill 或 Plugin 前，先问四个问题：

1. 来源是否可信，是否能看到说明和权限边界。
2. 它会不会读取密钥、客户资料、浏览器登录态或外部系统。
3. 它是只读、可写，还是能执行命令。
4. 出问题时能不能禁用、回滚或删除。

团队场景下，还要确认每个人的账号权限是否一致。一个人在本机能用，不代表所有成员都能用。

CCX + CCSwitch 为什么可能没有完整插件能力

CCX + CCSwitch 的重点是模型接入、协议转换和供应商切换。它可以让 DeepSeek、Minimax 等模型以更低成本跑起来，但这不自动等于 Codex 官方插件、Skills、MCP、自动化能力都完整可用。

简单说：模型能回答是一回事，客户端能加载插件、调用工具、管理权限，是另一回事。

Codex++ 为什么对想用插件的人更有价值

Redman 实测里，Codex++ 相比普通 CCX + CCSwitch，更适合想要插件能力的人。它的价值不只在于接 DeepSeek，而在于更接近桌面 App 的完整工作流。

但它仍然是第三方方案，版本兼容、稳定性、更新频率和安全边界都要自己评估。

操作步骤

1. 先明确你要解决的工作流：浏览网页、读设计稿、操作知识库，还是整理数据。
2. 判断用 Skill 就够，还是必须接插件 / MCP。
3. 从只读能力开始测试，不要一上来给写入和删除权限。
4. 让 Codex 用一个小任务验证工具是否可用。
5. 稳定后再把流程沉淀成 Skill 或插件配置。

适合先做 Skill 的场景

• 固定写作流程：小红书、X、公众号、YouTube 脚本。
• 固定审查流程：代码 review、SEO 检查、文档链接检查。
• 固定交付格式：周报、客户纪要、需求规格、测试报告。
• 固定资料整理：把网页、邮件、表格整理成结构化输出。

适合接 Plugin / MCP 的场景

• 必须读取外部系统里的真实数据。
• 必须操作浏览器、设计稿、GitHub、飞书、Notion、数据库。
• 需要把工具能力分发给团队成员。
• 需要把脚本、模板、连接配置和 Skill 打包到一起。

如果只是让 Codex 按固定格式写文章，Skill 就够了；如果要让 Codex 去飞书读数据、去浏览器点页面、去 GitHub 查 CI，就需要插件或 MCP。

常见坑

• 以为换模型就能获得插件能力。
• 插件接入太多，任务失败时不知道哪个工具出错。
• 没看权限说明，把外部系统的写权限直接放开。
• 把 API Key、Token、工作区密钥写进插件配置截图里。
• 把别人的 Skill 当成万能流程，不按自己的业务改输入和输出。
• 一次装太多插件，任务失败时不知道是模型、MCP、权限还是外部服务的问题。
• 没区分个人偏好、项目规则、Skill 和 Plugin，所有规则混在一起。

Redman 实测建议

新手先用 Skill 沉淀固定提示词，再逐步接 MCP 和插件。比如“X 长帖转 WordPress 草稿”“飞书多维表格整理选题”“YouTube 脚本生成”这些，都可以先从一份清晰的 Skill 文档开始，不要一开始就追求全自动。

延伸阅读

• 国内如何不充 GPT Plus 使用 Codex
• 连接第三方 API
• 自动化