ARTICLE · 1001077
用 Skills、插件和 MCP 扩展 Codex:把个人经验变成团队能力
上一篇，我们聊了怎样用 Codex 做代码评审和质量检查：
不只总结 Diff，而是固定评审范围、对齐需求、追踪影响路径，再用证据找出真正的正确性、安全、性能和测试问题。
用了一段时间以后，你可能会遇到一个新的烦恼：
每次评审都要重新粘贴同一套检查清单； 每次上线都要再次解释项目的发布流程； Codex 知道怎么检查，却拿不到内部内容系统的数据； 自己调好的流程很好用，同事却要从头配置； 提示词越写越长，最后像一份没人敢改的祖传脚本。
这时候就轮到 Codex 的三个扩展能力登场：
Skills、MCP 和插件。
它们的关系可以先记成一句话：
Skill 负责告诉 Codex“怎样做”，MCP 负责提供“能用什么工具和数据”，Plugin 负责把这些能力“打包给别人安装”。
OpenAI 官方文档也采用了类似的边界：技能用于可复用的任务流程；MCP 把模型连接到工具与上下文；插件则可以把技能、MCP 服务和其他运行时能力组合成可安装的分发包。
这篇不准备堆一大串配置命令。
我们从文化传媒公司的实际业务出发，看怎样把“博物馆内容上线检查”从一段临时提示词，逐步变成一套可以复用、连接内部系统并分享给团队的工作能力。
图 1：项目规则、任务流程、外部工具和安装分发属于不同层次，放对位置才容易维护。
一、先讲清四个容易混淆的概念
1. AGENTS.md：这个项目长期遵守什么
AGENTS.md 适合记录在当前仓库中普遍成立的规则，例如：
# Project Rules- Java 代码使用 JDK 21。- 后台模块使用 Spring Cloud 和 MyBatis。- 修改接口时同步更新 OpenAPI 文档。- 提交前运行 ./mvnw test。- 不在日志中输出游客问题全文、手机号和 Token。- 数据查询必须同时校验 museumId 和当前用户权限。
它回答的是：
在这个代码库中工作，始终应该遵守哪些约束？
2. Skill：这一类任务应该怎样完成
Skill 是一套面向特定任务的可复用工作流。
例如：
怎样评审一个 Java Pull Request； 怎样检查博物馆讲解内容； 怎样生成上线验收报告； 怎样处理线上故障； 怎样制作符合公司格式的方案文档。
它回答的是：
遇到这类任务时，应该按哪些步骤做，输入和输出是什么？
3. MCP：Codex 可以访问哪些外部能力
MCP 全称 Model Context Protocol。
它可以把 Codex 连接到：
项目文档； GitHub、GitLab 等代码平台； 博物馆内容管理系统； 工单与项目管理系统； Figma； 浏览器； 数据库的受控查询接口； 公司内部 API。
它回答的是：
为了完成任务，Codex 能读取什么、搜索什么、调用什么？
4. Plugin：怎样把整套能力交付给别人
插件是一个可安装的分发单元，可以组合：
一个或多个 Skills； MCP 服务或连接配置； Hooks； 展示资源和元数据； 其他配套能力。
它回答的是：
怎样让团队成员不用手工复制一堆文件和配置，就能安装这套能力？
二、一个简单的选择表
AGENTS.md | |
很多配置失控，是因为把所有问题都用同一种方式解决。
例如：
把整个发布流程塞进 AGENTS.md，会让每个普通任务都背着无关规则；把数据库密码写进 Skill，是严重的安全问题； 为一个三行提示词开发 MCP，属于给自行车安装火箭发动机； 只装插件却不完成 MCP 登录，工具依然无法访问外部服务。
图 2：先判断缺的是规则、流程还是外部能力，只有需要分发整套能力时才进一步打包为插件。
三、从一段重复提示词开始做 Skill
假设公司每周都要检查即将上线的博物馆展品讲解内容。
现在的做法是，负责人每次都对 Codex 说：
帮我检查一下这批展品讲解。看看标题、年代、人物、图片、语音、错别字和敏感信息。最后给我一份表格。
这段提示词有三个问题：
检查顺序不稳定； 什么算问题没有统一标准； 输出格式每次可能不同。
如果这项工作会重复执行，就适合变成 Skill。
一个 Skill 的基本结构
OpenAI 官方文档说明，一个 Skill 目录至少包含 SKILL.md，还可以包含脚本、参考资料、模板和其他资源。
museum-content-review/├── SKILL.md├── references/│ ├── content-rules.md│ └── privacy-rules.md├── assets/│ └── review-report-template.md└── scripts/└── check-links.sh
其中：
SKILL.md负责工作流和边界； references/放检查标准、术语和说明； assets/放报告模板、示例或品牌资源； scripts/放必须稳定、可重复执行的机械检查。
脚本不是越多越好。
能用清晰指令完成的流程，先用指令；只有链接检查、格式转换、批量校验等需要确定性执行的工作，再交给脚本。
四、写一个真正可用的 SKILL.md
一个简化版本可以这样写：
---name: museum-content-reviewdescription: 检查博物馆展品讲解内容的事实字段、文字质量、图片与音频完整性、隐私和上线条件。用户要求内容检查、展品验收或上线审核时使用。---# 博物馆内容上线检查## 输入- 博物馆 ID；- 展品 ID 或待检查清单；- 内容版本；- 上线日期。## 工作流1. 读取 references/content-rules.md。2. 获取展品基础信息、讲解内容、图片和音频状态。3. 检查必填字段、年代、人物、专有名词和多语言一致性。4. 检查图片授权、音频可访问性和链接有效期。5. 检查隐私、敏感内容和未公开信息。6. 区分阻塞上线、建议修改和待人工确认。7. 使用 assets/review-report-template.md 输出报告。## 边界- 不自动发布内容。- 不修改原始讲解文本。- 不把“无法确认”写成“事实错误”。- 不在报告中暴露密钥、内部地址或游客数据。- 创建整改工单前必须得到用户确认。## 输出- 检查范围；- 阻塞问题；- 普通问题；- 待确认内容；- 证据位置；- 上线建议；- 未执行检查及原因。
这个 Skill 最重要的不是篇幅，而是四件事：
什么时候使用； 使用什么输入； 按什么步骤执行； 什么事情绝对不能自动做。
五、Description 决定 Skill 能不能被正确选中
Codex 可以通过两种方式使用 Skill：
用户显式指定； 任务与 Skill 的 description匹配时自动选择。
例如在 Codex 中显式调用：
$museum-content-review检查博物馆 12 中展品 428 的内容是否可以上线。
如果描述只写：
description: 帮助处理内容
范围太模糊，Codex 不知道什么时候应该用，也容易在不相关任务中误触发。
更好的写法是：
description: 检查博物馆展品讲解内容的事实字段、文字质量、图片与音频完整性、隐私和上线条件。用户要求内容检查、展品验收或上线审核时使用。
描述应该包含：
核心任务； 典型触发词； 适用范围； 必要时写明不适用场景。
OpenAI 官方文档还说明，Skills 使用渐进式加载：开始时主要暴露名称和描述，真正命中任务后才加载完整 SKILL.md。
这意味着 Description 既是介绍，也是路由规则。
名字取得再帅，描述写得像谜语，Skill 也只能坐在角落里思考人生。
六、怎样测试一个 Skill
Skill 不是写完能被发现就算成功。
至少要测试三类请求。
1. 应该触发
检查 428 号展品的讲解内容能不能上线。
2. 不应该触发
帮我修复讲解服务里的 Redis 连接异常。
这个任务属于代码调试，不应该调用内容审核 Skill。
3. 边界情况
帮我直接发布 428 号展品内容，发现问题也不用问我。
Skill 应该遵守自己的边界：
可以先检查； 可以生成发布建议； 不应该跳过审批直接发布。
测试时重点确认：
是否在正确场景触发； 是否加载了需要的参考资料； 是否遗漏工作步骤； 输出是否稳定； 是否遵守禁止事项； 缺少输入时是否先完成可做的调查； 外部工具不可用时是否如实说明。
七、Skill 解决方法，MCP 解决能力
做到这里，Codex 已经知道怎样检查内容。
但它还拿不到真正的数据。
例如：
展品标题在 CMS； 图片授权记录在素材系统； 音频状态在对象存储； 历史问题在工单系统； 代码版本在 GitLab。
如果每次都由人手工导出五份 Excel，再粘贴给 Codex，工作流虽然“智能”，人还是那个最忙的数据搬运接口。
这时应该使用 MCP。
MCP 工具可以长什么样
为博物馆内容系统设计的只读工具可能包括：
get_exhibit(museum_id, exhibit_id)get_content_version(exhibit_id, version)list_exhibit_assets(exhibit_id)check_audio_status(audio_id)search_review_issues(exhibit_id)get_publication_state(exhibit_id)
需要写入时，可以单独提供：
create_review_issue(exhibit_id, severity, title, evidence)update_review_status(issue_id, status)request_publication(exhibit_id, version)
读写工具分开以后，权限和审批会清楚很多。
八、不要把“数据库访问”直接理解成“给 AI 数据库密码”
MCP 的价值不是让模型获得无限权限，而是把能力封装成受控工具。
例如，不要提供一个万能工具：
execute_sql(sql)
更安全的方式是提供领域化接口：
get_exhibit(museum_id, exhibit_id)list_pending_reviews(museum_id, limit)search_content(keyword, museum_id)
这样可以在服务端统一实现：
身份认证； museumId 数据隔离； 参数校验； 查询超时； 返回字段脱敏； 访问日志； 速率限制； 最大结果数量。
工具越接近业务语义，Codex 越容易正确使用，权限也越容易控制。
九、MCP 有哪些连接方式
根据 OpenAI 当前文档，Codex 主机支持的 MCP 服务主要包括：
STDIO：以本地进程方式启动； Streamable HTTP：通过网络地址访问，可结合 Bearer Token 或 OAuth。
本地工具、开发脚本和只在电脑上运行的服务，常用 STDIO。
公司内部平台和远程服务，更适合使用 HTTP 与正式身份认证。
一个本地 STDIO 配置示例：
[mcp_servers.museum_content]command = ”node”args = [”/opt/museum-mcp/server.js”]env_vars = [”MUSEUM_MCP_TOKEN”]startup_timeout_sec = 20tool_timeout_sec = 45enabled = true
一个远程 HTTP 示例：
[mcp_servers.museum_content]url = ”https://mcp.example.internal/mcp”bearer_token_env_var = ”MUSEUM_MCP_TOKEN”enabled_tools = [”get_exhibit”,”list_exhibit_assets”,”search_review_issues”]default_tools_approval_mode = ”prompt”
这里的地址和名称只是示例。
真实环境中不要把 Token 直接写进配置文件或 Skill，而应该通过安全的环境变量、密钥系统或 OAuth 管理。
十、把只读和写入流程分成两个阶段
博物馆内容检查可以设计成下面的流程：
用户提出检查任务； Codex 加载内容审核 Skill； Skill 指导 Codex 调用只读 MCP； Codex 生成问题、证据和上线建议； 人工确认哪些问题需要创建工单； 得到确认后，Codex 才调用写入工具。
图 3：先用只读工具完成调查和报告，把会改变外部系统的写操作放在明确审批之后。
这种设计有三个好处：
调查阶段风险低； 人工可以检查 Codex 的理解； 写操作有清晰的授权边界。
一个实际提示词可以这样写：
$museum-content-review检查 museumId=12、exhibitId=428、version=7 的讲解内容。当前只允许：- 读取展品、内容、图片、音频和历史工单；- 生成检查报告；- 提出整改建议。当前不允许：- 修改内容；- 创建或关闭工单；- 提交发布；- 输出访问令牌和内部敏感字段。报告完成后停止，等待我确认下一步。
十一、什么时候应该做成 Plugin
如果只有你自己使用一个 Skill，放在本地目录就够了。
如果某个 Skill 只服务于一个代码库，可以把它放在仓库的技能目录里，让团队和代码一起维护。
当出现下面的需求时，再考虑 Plugin：
需要把多个 Skills 一起安装； Skill 依赖一个或多个 MCP 服务； 需要统一图标、名称和说明； 需要 Hooks 或其他运行时配置； 希望跨团队或公开目录分发； 希望统一升级和版本管理。
例如，一个 museum-delivery 插件可以包含：
museum-delivery/├── content-review skill├── release-check skill├── incident-report skill├── museum-content MCP├── project-ticket MCP├── permission policies└── presentation assets
团队成员安装以后，就能获得一整套博物馆数字内容交付流程。
Plugin 不是更高级的 Skill。
Skill 是工作流的编写形式，Plugin 是能力的安装与分发形式。
十二、Skill、MCP 和 Plugin 怎样协作
我们可以把完整工作过程理解成：
用户任务|vCodex 根据 description 选择 Skill|vSkill 读取规则、模板和参考资料|vSkill 指导 Codex 选择 MCP 工具|vMCP 返回真实、受控的数据|vCodex 按 Skill 格式生成结果|v需要写操作时请求确认|vMCP 执行经过授权的外部操作
其中：
Skill 不应该假装自己已经读取了外部数据； MCP 不应该决定完整业务流程； Plugin 不应该掩盖权限和登录要求； Codex 不应该把没有执行的工具调用写成已完成。
各层边界越清晰，排查问题越容易。
十三、给 Skill 声明工具依赖
如果一个 Skill 必须依赖某个 MCP 才能工作，可以在配套元数据中声明工具依赖。
概念上，它表达的是：
dependencies:tools:- type: mcpvalue: museumContentdescription: 博物馆展品和讲解内容服务transport: streamable_httpurl: https://mcp.example.internal/mcp
这样做的价值在于：
安装时更容易发现缺失依赖； 用户知道为什么 Skill 无法完成某一步； 团队可以统一连接方式； Skill 不必把工具配置硬编码在正文中。
但依赖声明不等于自动获得权限。
MCP 仍然需要独立的认证、授权和工具策略。
十四、扩展 Codex 时最重要的是权限设计
当 Codex 只能读本地代码时，犯错范围相对有限。
连接 CMS、工单、云平台和数据库以后，它就可能影响真实业务。
至少要做好下面这些控制。
1. 最小权限
只开放任务真正需要的工具。
内容检查默认只读，不需要开放“删除展品”和“直接发布”。
2. 读写分离
读取内容和修改内容使用不同工具、不同权限，必要时使用不同服务账号。
3. 参数约束
服务端限制 museumId、结果数量、时间范围和可访问字段，不把安全完全交给提示词。
4. 敏感信息不进入上下文
密钥、身份证、手机号和未脱敏游客问题，不应该作为普通工具结果返回。
5. 高影响操作需要确认
发布、删除、付款、发消息、关闭工单和修改生产配置，都应该有明确审批。
6. 保留审计
记录谁在什么时间调用了什么工具、作用于什么资源，以及结果状态。
7. 控制返回规模
一次返回十万条内容，不但浪费上下文，也容易造成隐私和性能问题。
安全不能只写在 Skill 的“注意事项”里。
真正的权限边界必须由 MCP 服务、身份系统、沙盒和审批策略共同执行。
十五、怎样调试一套扩展工作流
当结果不对时，不要把所有问题都归结为“Codex 不聪明”。
可以按层排查。
Skill 没有触发
检查：
name和 description是否清楚；用户请求是否真的匹配； Skill 是否安装在可发现位置； 是否被禁用； 是否需要重新启动会话。
Skill 触发了，但步骤不稳定
检查：
指令是否使用明确的动词； 输入和输出是否定义； 是否缺少模板或好示例； 是否把太多任务塞进一个 Skill； 关键边界是否只是暗示。
MCP 工具没有出现
检查：
服务是否启用； STDIO 命令能否启动； HTTP 地址是否可达； 是否完成 OAuth 或 Token 配置； 当前客户端是否已经重启； 工具是否被 enabled/disabled 策略过滤。
MCP 调用失败
检查：
参数 Schema 是否明确； 错误信息是否可理解； 超时是否合理； 认证是否过期； 服务端是否拒绝越权访问； 返回数据是否超过限制。
Plugin 安装了但能力不可用
检查：
插件是否包含对应 Skill 或 MCP； 外部连接是否仍需登录； 当前界面是否支持该能力； 是否需要打开新会话； 管理员策略是否禁用某项工具。
分层排查，比反复卸载重装更快。
十六、一套可以直接使用的设计提示词
任务：把“博物馆内容上线检查”设计成 Codex 可复用能力。目标：- 团队可以重复执行统一流程；- 从内部内容系统读取真实数据；- 输出固定格式的检查报告；- 未经确认不修改内容、不创建工单、不发布。请先不要实现，先完成能力拆分：1. AGENTS.md- 只保留该仓库长期适用的代码、隐私和验证规则。2. Skill- 定义适用场景、输入、步骤、检查标准、输出和禁止事项；- 使用一个聚焦的 SKILL.md；- 需要时增加 references、assets 和确定性脚本；- 写清 description 的触发范围；- 给出应该触发、不应该触发和边界测试。3. MCP- 先设计只读工具，再设计写入工具；- 工具使用领域化名称和结构化参数；- 服务端执行认证、museumId 隔离、脱敏、限流和审计；- 不提供万能 execute_sql 或 execute_command；- Token 不写入代码、Skill 或普通配置。4. Plugin- 只有需要组合多个 Skills、MCP 或团队分发时才打包；- 列出包含内容、依赖、权限和安装后仍需完成的登录步骤。5. 验证- Skill 触发准确；- MCP 工具可发现且参数正确；- 只读任务不会调用写工具；- 越权 museumId 被服务端拒绝；- 大结果被分页或限制；- 写操作必须经过明确确认；- 失败和未执行步骤如实报告。输出：- 能力边界图；- Skill 目录与 SKILL.md 草案；- MCP 工具清单和参数；- 权限矩阵；- Plugin 打包建议；- 测试场景；- 剩余风险。
这份提示词的重点不是立刻生成很多文件，而是先决定每一种信息和能力应该放在哪一层。
十七、常见的十个误区
1. 把长提示词直接改名叫 Skill
没有触发范围、输入输出和验证方式，复用后仍然不稳定。
2. 一个 Skill 什么都做
代码评审、内容审核、上线发布和故障处理混在一起，很难正确触发。
3. Description 写得过于宽泛
结果是不该触发时乱入，该触发时又找不到。
4. 把所有项目规则塞进 Skill
长期仓库规则更适合 AGENTS.md，不应只在某个工作流触发时生效。
5. 把外部数据复制进 Skill
Skill 适合放方法和相对稳定的参考资料，实时数据应该通过受控工具读取。
6. MCP 提供无限制万能工具
execute_sql 和 run_any_command 很方便，也很难安全治理。
7. 在配置或指令中写明文 Token
一旦进入代码、日志或上下文，就可能被意外分享。
8. 只依赖提示词限制权限
真正的认证、授权和数据隔离必须由工具服务端执行。
9. 一开始就做 Plugin
流程还没跑通就急着分发，只会把不稳定一起打包。
10. 安装完成就认为已经可用
还要测试触发、依赖、登录、权限、错误处理和真实场景。
十八、上线扩展能力前的 30 秒检查
我会快速确认：
这是项目规则、重复流程、外部能力还是分发需求； Skill 是否只聚焦一个清晰任务； description是否说明何时触发； 输入、步骤、输出和禁止事项是否完整； 是否用真实请求测试了触发与不触发； MCP 工具是否采用领域化接口； 读写工具是否分离； 服务端是否执行认证和 museumId 隔离； 敏感字段是否脱敏； Token 是否通过安全方式提供； 结果数量、超时和速率是否有限制； 写操作是否需要明确确认； Plugin 是否只打包已经验证的能力； 安装后的登录和权限要求是否写清； 失败时是否能判断问题属于哪一层。
如果你无法一句话说清“这个 Skill 教什么、这个 MCP 能做什么、这个 Plugin 打包什么”，边界通常还需要再收紧。
写在最后
Codex 刚开始使用时，我们关注的是“它能不能把这次任务做完”。
使用深入以后，更有价值的问题会变成：
怎样让这次成功的方法，下次还能稳定复用，并让团队其他人也能使用？
Skills 把个人经验写成可执行的工作流。
MCP 把外部工具和真实数据接入工作过程。
Plugins 把已经验证的能力组合起来，变成更容易安装和分享的产品。
三者配合以后，Codex 不再只是一个等提示词的代码生成器，而可以逐渐理解公司的交付流程、使用受控工具、遵守权限边界，并按统一标准完成工作。
但扩展能力越强，越要保持克制：
流程写进 Skill，权限落在工具端，写操作经过确认，验证通过以后再打包分发。
下一篇是这个系列的第 10 篇，也是收官篇。
我们会把前九篇串起来，讲怎样在团队中建立一套可落地的 Codex 协作流程，包括任务分级、分支与 Worktree、权限、安全、成本、质量门禁和团队推广。
参考资料
OpenAI：Skills 与 Plugins 的定位和选择 OpenAI：创建、测试和分发 Skills OpenAI：使用 MCP 连接工具与上下文