Codex App Windows 版高级教程(四):Skills + MCP,教 Codex 学本事、连外脑

今天我们来说下 codex 里面的 skills（技能）和 MCP （连接外部工具的通道）。

这里是昨天那篇飞书cli 安装19个skills在codex app里面有显示出来。

输入/mcp显示你已经安装的mcp服务器

Codex 默认状态下什么都能干一点，但或许它干得不够专业。你让它写代码，它写；你让它审查代码，它审。但它不知道你们团队用的是 MyBatis 还是 JPA，不知道你们的代码规范是驼峰还是下划线，更不知道你的 Figma 设计稿长什么样。

这就是 Skills 和 MCP 要解决的问题。

Skills 是教 Codex”怎么干活”。你写一份操作手册，告诉它遇到某类任务该怎么做、该注意什么、该用什么工具。以后碰到类似的事，它就按你教的来。

比如昨天安装的飞书的skills，就是飞书团队开发的告诉agent，他们的产品如果给它使用。

MCP 是让 Codex”连上外部工具”。让它能读你的 Figma 设计稿、查你的 Sentry 错误日志、翻你的项目文档——不是靠你复制粘贴，而是它自己去拿。

一个是内功，一个是外接。这篇把两个都讲透，全程给配置代码和实战 Prompt，跟着做就行。

先搞懂 Skills 到底是什么

我用最直白的话解释：Skill 就是你写给 Codex 的一份”操作手册”。

想象你招了一个新人。他很聪明，什么都能学，但不知道你们公司的规矩——代码怎么写、测试怎么跑、文件怎么命名。你得写一份入职手册，告诉他”遇到这种情况该怎么做”。

Skill 就是这份手册。

技术上说，一个 Skill 就是一个文件夹，里面放一个 SKILL.md 文件（必须的），加上一些可选的脚本、参考文档、模板。

飞书里面除了SKILL.md

还有一个是references的文件夹，就是一些参考文档

Codex 看到你的任务，觉得跟某个 Skill 匹配，就自动把那份”手册”读进来，按里面的步骤做事。

和 AGENTS.md 有什么区别？

这是很多人搞混的点。

AGENTS.md 是”全局规矩”——不管 Codex 干什么任务，都得遵守。比如”用中文回复”、”不要改 main 分支的代码”。

Skill 是”专项技能”——只有碰到特定类型的任务时才激活。比如”写 Java 单元测试时按这个模板来”。

说白了，AGENTS.md 相当于公司制度，Skill 相当于岗位技能手册。两个不冲突，一起用效果最好。

Skill 的文件结构

最简单的 Skill，就一个文件：

my-skill/└── SKILL.md

复杂一点的，可以带脚本和参考文档：

my-skill/├── SKILL.md           # 必须的：指令 + 元数据├── scripts/           # 可选：要执行的脚本├── references/        # 可选：参考文档└── assets/            # 可选：模板、资源文件

SKILL.md 的格式很简单，开头是元数据（名字和描述），下面是具体指令：

---name: skill-namedescription: 什么时候该用这个 Skill，什么时候不该用。---具体的操作指令写在这里。Codex 被激活这个 Skill 后，会按照这里的步骤执行。

这里有个细节值得注意——description 字段非常重要。Codex 靠它来判断什么时候该自动激活这个 Skill。写得太模糊，该触发的时候不触发；写得太宽泛，不该触发的时候乱触发。后面实战部分我会专门讲怎么写好 description。你也可以看下飞书团队写的描述，都是教科书级别的，适合用来学习。

Codex 怎么发现和使用 Skill

两种方式。

第一种，你主动调用。在 Prompt 里用 $ 符号加 Skill 名字。比如你有个叫 Figma 的 Skill，直接写 $figma 就行。

CLI/IDE 里也可以用 /skills 命令查看所有可用的 Skill。

第二种，Codex 自动匹配。你不提 Skill 名字，但任务描述跟某个 Skill 的 description 匹配了，Codex 会自动激活它。这就是为什么 description 写得好不好很关键。

还有一个设计挺聪明的——渐进式加载。Codex 不会一上来就把所有 Skill 的完整内容全读进来（那会浪费上下文窗口）。它只先看每个 Skill 的名字和描述，等真正需要用的时候才去读完整内容。就像你不会把公司所有岗位的操作手册全背下来，只有轮到干某个活时才去翻对应的手册。

Skill 放在哪

这个问题看起来简单，但 Codex 的 Skill 存放位置有一套优先级机制，搞不清楚容易踩坑。

项目级（团队共享），放在项目根目录下的 .agents/skills/ 里。整个团队都能用，可以提交到 Git 版本管理。

D:\Projects\your-project\└── .agents\    └── skills\        └── java-test\            └── SKILL.md

注意这里是 .agents/skills/，不是 .codex/skills/。Skill 用的是 .agents 目录，跟之前 Subagent 文章里的 .codex/agents/ 不一样，别搞混了。

个人级（只有你能用），放在你的用户目录下的 .agents/skills/ 里。

C:\Users\你的用户名\└── .agents\    └── skills\        └── my-personal-skill\            └── SKILL.md

飞书安装就是在个人用户下面

管理员级和系统内置级就不用管了。管理员级是给企业 IT 管理员用的，系统内置的是 Codex 自带的几个 Skill（比如 $skill-creator 和 $skill installer）。

搜索顺序是：当前目录（就是你codex选择的目录，然后往上找）→ 父目录 → 仓库根目录 → 个人目录 → 管理员目录 → 系统内置，从最近的位置开始找。

同名 Skill 怎么处理？不同位置有同名的 Skill，它们不会互相覆盖——两个都会出现在列表里，你可以选用哪个。这跟之前 Subagent 文章里说的”自定义 Agent 覆盖同名内置 Agent”的行为不一样，注意区分。

实话说，大多数情况你只需要关心两个位置：项目级（团队共享，放 .agents/skills/）和个人级（私有技能，放 ~/.agents/skills/）。其他的知道有这回事就行。

实战一：用内置 $skill-creator 创建你的第一个 Skill

不用手动建文件夹，Codex 自带一个 Skill 创建器。打开 Codex App，在 Prompt 里输入：

$skill-creator

它会切到创建流程，让你按一个固定格式一行搞定：

名称 / 用途 / 用户会怎么提需求（1-3个例子） / 需要用到的工具或资料 / 放置目录（不填就默认）

下面我用一个真实场景演示——做一个”Spring Boot 接口文档生成”的 Skill：

spring-api-doc / 给 Spring Boot Controller 自动生成 API 文档，包含接口路径、请求方式、参数、返回值、校验规则，输出 Markdown 表格 / "帮我生成这个 Controller 的接口文档""把 UserController 的 API 整理成文档""生成接口说明" / 不需要额外工具 /

拆开说一下这行里每个斜杠之间填的是什么：

第一个是 Skill 名称，以后你在 Prompt 里 

$spring-api-doc 就能调用它。

第二个是用途描述，这直接决定了 Codex 什么时候自动匹配这个 Skill。写得越具体，触发越准——”给 Spring Boot Controller 生成 API 文档”比”生成文档”准确得多。

第三个是用户提需求的例子，给 1-3 个就行。Codex 会用这些例子来理解什么样的 Prompt 应该触发这个 Skill。

第四个是需要的工具或资料，大多数纯指令类的 Skill 填”不需要”就行。只有当你需要 Skill 执行特定脚本时才填。

最后一个是放置目录，不填就用默认路径。

回车之后，Codex 会自动帮你生成完整的 SKILL.md 和文件夹结构。直接用就行，也可以打开文件再调整细节。

对生成的结果不满意？直接打开 SKILL.md 手动改——它就是一个 Markdown 文件，没什么神秘的。或者再跟 $skill-creator 对话一轮让它帮你优化。

实战二：Java 后端项目的代码审查 Skill

场景：你们团队用 Spring Boot + MyBatis + Redis，每次让 Codex 审查代码都得在 Prompt 里写一大段要求——检查 SQL 注入、事务注解、缓存一致性……写烦了。

做成 Skill 之后，以后一句 $java-review 就搞定。

在项目根目录下创建：

mkdir -p .agents\skills\java-review

然后创建 .agents/skills/java-review/SKILL.md：

---name: java-reviewdescription: 当用户要求审查 Java 后端代码、做 Code Review、检查代码质量时触发。适用于 Spring Boot + MyBatis + Redis 技术栈的项目。不适用于前端代码、Python 代码或非 Java 项目。---# Java 后端代码审查## 审查清单按以下维度逐一检查，每个发现都要引用具体的文件路径和行号。### 安全类- SQL 注入：MyBatis 映射文件里有没有用 ${} 而不是 #{}- 接口有没有做参数校验（@Valid / @NotNull）- 敏感操作有没有权限控制### 事务类- @Transactional 注解有没有加在 public 方法上（private 方法上事务不生效）- 有没有自调用导致事务失效的场景（同一个类里 A 方法调 B 方法，B 的 @Transactional 不生效）- 事务里有没有做 RPC 调用或者其他耗时操作（长事务风险）### 数据类- SQL 有没有性能问题：全表扫描、缺少索引、N+1 查询- 批量操作有没有分批处理（大 IN 查询、批量插入）- Redis 缓存和数据库的一致性：先删缓存还是先改库？有没有缓存穿透/击穿/雪崩的风险### 代码质量- 异常处理：有没有吞异常（catch 了但没 log 也没 throw）- 空指针风险：有没有对可能为 null 的对象直接调方法- 资源关闭：IO 流、数据库连接有没有在 finally 或 try-with-resources 里关闭## 输出格式按优先级排序（P0 > P1 > P2），每个问题包含：1. 文件路径和行号2. 问题描述（一句话说清楚）3. 修复建议（给出具体代码）跳过纯风格类建议（比如变量命名、空行数量），只关注会导致 bug 或安全问题的地方。

使用的时候，直接在 Prompt 里写：

$java-review 审查我当前分支相对于 main 的改动

出来你创建的skills

Codex 就按你定义的审查清单逐项检查，输出格式也是你规定好的。

注意看 description 怎么写的——我写了三层信息：什么时候该触发（审查 Java 代码时）、适用范围（Spring Boot + MyBatis + Redis）、什么时候不该触发（前端、Python 不适用）。这样自动匹配才准确。

实战三：给 Spring Boot 项目写单元测试的 Skill

另一个高频场景。你让 Codex 帮你写单元测试，但每次都得交代一遍——用 JUnit 5、用 Mockito、测试类命名规范、断言用 AssertJ……

把这些固化到 Skill 里。创建 .agents/skills/java-unit-test/SKILL.md：

---name: java-unit-testdescription: 当用户要求为 Java 方法或类编写单元测试时触发。适用于使用 JUnit 5 + Mockito + AssertJ 的 Spring Boot 项目。不适用于集成测试、E2E 测试或非 Java 项目。---# Java 单元测试编写规范## 技术栈- JUnit 5（@Test, @DisplayName, @BeforeEach）- Mockito（@Mock, @InjectMocks, @ExtendWith(MockitoExtension.class)）- AssertJ（assertThat().isEqualTo(), assertThatThrownBy()）## 命名规范- 测试类：`{被测类名}Test.java`，放在 `src/test/java` 对应包下- 测试方法：`should_{预期行为}_when_{条件}`，用 @DisplayName 写中文描述## 测试结构每个测试方法按 AAA 模式：1. Arrange（准备数据和 Mock）2. Act（调用被测方法）3. Assert（验证结果）## 必须覆盖的场景1. 正常流程（Happy Path）2. 边界值（空值、空集合、最大值、最小值）3. 异常流程（参数非法、依赖抛异常）4. 如果方法有事务注解，单独测试事务回滚场景## 示例```java@ExtendWith(MockitoExtension.class)class UserServiceTest {    @Mock    private UserMapper userMapper;    @InjectMocks    private UserService userService;    @Test    @DisplayName("根据 ID 查询用户 - 用户存在时返回用户信息")    void should_return_user_when_user_exists() {        // Arrange        User mockUser = new User(1L, "张三", "zhangsan@test.com");        when(userMapper.selectById(1L)).thenReturn(mockUser);        // Act        User result = userService.getUserById(1L);        // Assert        assertThat(result).isNotNull();        assertThat(result.getName()).isEqualTo("张三");        verify(userMapper).selectById(1L);    }    @Test    @DisplayName("根据 ID 查询用户 - 用户不存在时抛出异常")    void should_throw_exception_when_user_not_found() {        // Arrange        when(userMapper.selectById(999L)).thenReturn(null);        // Act & Assert        assertThatThrownBy(() -> userService.getUserById(999L))            .isInstanceOf(BusinessException.class)            .hasMessage("用户不存在");    }}```## 注意事项- 不要 Mock 被测类本身，只 Mock 它的依赖- 每个测试方法只测一个行为，不要在一个方法里塞多个断言场景- 避免测试私有方法，通过公有方法间接测试

使用的时候：

$java-unit-test 帮我给 UserService 的 createUser 方法写单元测试

Codex 会按你定义的规范、命名方式、技术栈来写测试，不用每次重复交代。

实战四：安装现成的 Skill

除了自己写，你也可以安装别人做好的 Skill。Codex 内置了一个 $skill-installer。

比如安装 Linear 的 Skill（项目管理工具）：

$skill-installer linear

或者装别人 GitHub 仓库里的：

$skill-installer https://github.com/someone/their-skill

OpenAI 官方也维护了一个 Skill 仓库：

https://github.com/openai/skills ，里面有不少现成的可以直接用。

安装完之后，Skill 会进入你的用户级范围，所有项目都能用。最

稳的做法是用 /skills 命令确认是否生效。如果想让团队也能用，把对应的 Skill 文件夹复制到项目的 .agents/skills/ 下面就行。

有时候装了一个 Skill，暂时不想用但也不想删，在 

config.toml 里关掉就行：

[[skills.config]]path = "C:/Users/你的用户名/.agents/skills/some-skill/SKILL.md"enabled = false

改完重启 Codex 生效。

现在来聊 MCP

Skills 教会了 Codex 怎么干活，但它还是只能看到你项目里的代码文件。它看不到你的 Figma 设计稿、看不到你的 Sentry 错误日志、看不到你的项目管理工具里有哪些 Issue。

MCP 就是给 Codex 接上”外脑”。

MCP 全称 Model Context Protocol，是 Anthropic 最早搞出来的一个开放标准，现在 OpenAI 也支持了。你不用管底层原理，只需要知道：通过 MCP，Codex 可以连接外部工具和服务，直接从那些工具里读取信息或执行操作。

举个例子。你在 Codex 里说”帮我看看 Figma 上的首页设计稿”，没有 MCP 的话，Codex 只能说”我看不到你的 Figma”。接上 Figma 的 MCP Server 之后，它真的能去 Figma 把设计稿拉过来看。

MCP 的两种类型

STDIO 类型，在你电脑上启动一个本地进程。比如 Playwright（浏览器自动化）、Chrome DevTools 这种需要访问你本地环境的工具。

Streamable HTTP 类型，连接一个远程服务的地址。比如 Figma、Sentry 这种在线服务，你给 Codex 一个 URL，它通过网络去访问。

你不需要区分得太清楚，配置方式不同而已，后面实战里都会讲到。

MCP 配置在哪

MCP 的配置写在 config.toml 里——就是之前配 Codex 全局设置的那个文件。

个人级（所有项目通用），你的 CODEX_HOME 下的 config.toml。最简单的确认方法：打开 Codex App 设置页，点右上角”Open config.toml”。

项目级（只在当前项目生效），项目根目录下的 .codex/config.toml。需要项目被标记为”受信任”才生效。

App、CLI、IDE 扩展共享同一份 MCP 配置。你在 config.toml 里配一次，三个地方都能用，不用配三遍。

实战五：接上 Context7，让 Codex 查最新文档

这是我觉得最实用的一个 MCP Server。Context7 是一个免费的开发者文档服务，让 Codex 能查到各种框架和库的最新文档，而不是只靠训练数据里的旧知识。

场景很具体：你用 Spring Boot 3.x 的某个新特性，Codex 的训练数据里可能还没有。接上 Context7 之后，它能自己去查最新的文档。

在 config.toml 里加：

[mcp_servers.context7]command = "npx"args = ["-y", "@upstash/context7-mcp"]

配置好后/mcp可以看到

然后重启 Codex，然后你就可以在 Prompt 里这样用：

帮我查一下 Spring Boot 3.4 的 @HttpExchange 注解怎么用，给我一个完整的示例

Codex 会通过 Context7 去拉最新的 Spring Boot 文档，而不是靠记忆瞎编。

Windows 用户注意：你需要先确保 Node.js 和 npx 已经装好。如果用的是 WSL 模式，npx 路径可能需要写完整路径。

实战六：接上 Figma，看着设计稿写代码

这是前端开发者的刚需。以前的工作流是：打开 Figma → 截图 → 粘贴给 Codex → 让它猜着写。接上 Figma MCP 之后，Codex 直接去 Figma 读设计稿的布局、颜色、间距信息，精确到具体的设计 token。

Codex App 里最简单的接法：打开 App → 左上角点 Skills → 安装 Figma 相关的 Skills → 然后去 Settings → MCP servers → 在推荐列表里找到 Figma → 点 Install and authenticate → 按提示完成 OAuth 授权。

整个过程不需要手动改 config.toml，也不需要自己去 Figma 生成 token。

CLI 的接法：

codex mcp add figma --url https://mcp.figma.com/mcp

添加之后按提示完成认证即可，Codex 会走 OAuth 流程自动处理 token。

配好之后：

看一下这个 Figma 页面的设计 [粘贴 Figma 链接]，帮我实现这个登录页面

Codex 会自己去 Figma 拉布局、颜色、间距信息，然后写出对应的代码。

说一下状态：Figma MCP 目前仍处于 beta 阶段，具体的认证方式和调用额度以 Figma 当下的官方说明为准。团队如果要高频使用，最好先确认你们 Figma 套餐的权限范围。

实战七：接上 Playwright MCP，自动化测试浏览器

先澄清一个容易搞混的点：Playwright MCP 不是 Computer Use。

Computer Use 是 AI”看着屏幕操作”——截屏识别画面，模拟鼠标和键盘，跟人操作电脑一样。Playwright MCP 完全不同——它是通过编程接口控制浏览器，精确到具体的 DOM 元素。相当于 Codex 在后台跑了一段浏览器自动化脚本，而不是像人一样盯着屏幕点鼠标。

实际效果是：Codex 能打开网页、点击按钮、填写表单、截图——但走的是 Playwright 的 API，不是屏幕识别。速度更快、精度更高，但也只能操控浏览器，不能操控其他桌面应用。

这也是昨天我测飞书cli，codex就尝试使用过这个mcp来打开浏览器。

在 config.toml 里加：

[mcp_servers.playwright]command = "npx"args = ["-y", "@playwright/mcp"]

或者直接通过codex app 界面来安装也是可以的。

使用场景：

用 Playwright 打开 http://localhost:3000 ，截图看看当前页面的样子，然后帮我检查登录按钮点击后有没有正确跳转

这个对前端调试非常有用——Codex 能自己打开你的本地开发服务器，看到页面长什么样，验证交互逻辑对不对。本质上就是让 Codex 帮你跑了一次端到端测试。

实战八：接上日志平台 MCP，直接查线上错误

后端开发的常见场景：测试或运维说”线上报错了”，你得登上日志平台翻日志，找到错误堆栈，再回来对着代码排查。

现在可以通过 MCP 让 Codex 直接去你的日志平台查。国内主流云厂商都已经出了官方 MCP Server。

阿里云可观测 MCP Server，把 SLS（日志服务）、ARMS（应用监控）、云监控等可观测数据统一接入了一个 MCP Server。安装：

pip install mcp-server-aliyun-observability

config.toml 配置（STDIO 类型）：

[mcp_servers.aliyun-observability]command = "python"args = ["-m", "mcp_server_aliyun_observability"][mcp_servers.aliyun-observability.env]ALIBABA_CLOUD_ACCESS_KEY_ID = "你的 AccessKey ID"ALIBABA_CLOUD_ACCESS_KEY_SECRET = "你的 AccessKey Secret"

Windows 上如果 python 命令不可用，改成 py 或 python3。

配好之后直接问：

帮我查一下 SLS 里 user-service 项目最近 24 小时的错误日志，找出出现频率最高的那个，分析一下原因

腾讯云 CLS MCP Server，配置方式：

[mcp_servers.cls]command = "npx"args = ["-y", "cls-mcp-server@latest"][mcp_servers.cls.env]TENCENTCLOUD_SECRET_ID = "你的 SecretId"TENCENTCLOUD_SECRET_KEY = "你的 SecretKey"CLS_REGION = "ap-guangzhou"

用法一样——直接用自然语言让 Codex 去查日志。

海外团队用 Sentry：

[mcp_servers.sentry]command = "npx"args = ["-y", "@sentry/mcp-server"][mcp_servers.sentry.env]SENTRY_ACCESS_TOKEN = "你的 Sentry Access Token"

不管你用哪家的日志平台，MCP 的接入思路都一样：在 config.toml 里加一段配置，填上认证信息，重启 Codex 就能用。区别只是包名和环境变量不同。这就是 MCP 作为开放标准的好处——接口统一，换平台的成本很低。

实战九：接上 GitHub MCP，管 Issue 和 PR

Codex 本身能用 git 命令做基本的版本管理，但有些操作——比如创建 Pull Request、管理 Issue、查看 PR 评论——需要 GitHub API。

最简单的接法是用远程模式，不用装任何东西：

[mcp_servers.github]url = "https://api.githubcopilot.com/mcp/"

添加后 Codex 会引导你完成 OAuth 认证。

如果你更喜欢本地模式（用 Personal Access Token），可以按 GitHub 官方仓库 github/github-mcp-server 的最新说明来配。仓库地址：https://github.com/github/github-mcp-server ，里面有 Docker、npx、二进制文件等多种安装方式。

配好之后就能直接说：

看一下我们项目最近的 5 个 Issue，按优先级排序，然后帮我把第一个 Issue 的修复方案写出来并创建一个 PR

用 GitLab 或 Gitee 的团队注意：GitHub 官方 MCP Server 只支持 GitHub。GitLab 的话社区里有开源的 MCP Server 可以搜来用。Gitee 暂时没看到官方 MCP Server，但 Codex 本身能用 git 命令操作本地仓库，日常的 commit、push、branch 管理不受影响。

MCP 的高级配置选项

如果你需要更精细的控制，config.toml 里还有这些可选字段：

[mcp_servers.my-server]command = "npx"args = ["-y", "some-mcp-server"]startup_timeout_sec = 20      # 启动超时（默认 10 秒）tool_timeout_sec = 45         # 工具执行超时（默认 60 秒）enabled = true                # 设为 false 可以临时关闭required = true               # 设为 true 后，这个 Server 启动失败 Codex 也跟着启动失败enabled_tools = ["read", "search"]     # 只允许用这几个工具disabled_tools = ["delete", "write"]   # 禁止用这几个工具

enabled_tools 和 disabled_tools 这两个字段很实用。比如你接了 GitHub MCP，但只想让 Codex 读 Issue 和 PR，不想让它自己创建或删除，就用 disabled_tools 把写操作禁掉。

Skills + MCP 组合拳：这才是真正的生产力

Skills 和 MCP 单独用都有价值，但组合起来才是真正好用的地方。

场景：让 Codex 看着 Figma 设计稿，按照你的组件规范写 React 代码。

先接上 Figma MCP（让它能看设计稿），再写一个 react-component 的 Skill（告诉它你的组件规范）。

Skill 文件 .agents/skills/react-component/SKILL.md：

---name: react-componentdescription: 当用户要求根据设计稿或需求创建 React 组件时触发。适用于使用 React + TypeScript + TailwindCSS 的前端项目。---# React 组件开发规范## 技术栈- React 18+ 函数组件- TypeScript（所有 props 必须定义接口）- TailwindCSS（不使用内联 style）- 状态管理用 React hooks## 文件结构每个组件一个文件夹：ComponentName/├── index.tsx              # 组件代码├── types.ts               # 类型定义└── ComponentName.test.tsx # 测试## 编码规范- 组件名用 PascalCase- Props 接口名：`{组件名}Props`- 事件处理函数：`handle{事件名}`- 使用 cn() 工具函数合并 TailwindCSS 类名- 所有文本内容提取为常量，方便后续国际化## 响应式设计- 移动端优先（先写 sm: 断点）- 必须支持 sm / md / lg 三个断点

然后这样用：

看一下这个 Figma 页面 [链接]，用 $react-component 的规范帮我实现这个用户资料卡片组件

Codex 会去 Figma 读设计稿（MCP 的能力），然后按你的组件规范写代码（Skill 的能力）。两者配合，输出质量比单独用哪一个都高。

给国内团队的提示： 上面用 React + TailwindCSS 举例是因为 Codex 官方示例用的这套，不代表推荐。国内前端市场 Vue 的占有率远高于 React，尤其电商和企业级管理系统基本是 Vue 的天下。如果你们用 Vue + Ant Design 或 Vue + Element Plus，思路完全一样——把 Skill 里的技术栈换成你们实际用的就行。Skill 的价值不在于模板本身，而在于把你们团队的规范固化下来，不用每次重复交代。同理，MCP 那边如果你们用蓝湖或 MasterGo 而不是 Figma，等这些工具出了 MCP Server 也可以同样方式接入。

完整文件结构一览

# 个人级（你的用户目录下）C:\Users\你的用户名\├── .codex\│   └── config.toml              # MCP 配置写在这里└── .agents\    └── skills\                   # 个人级 Skill        └── my-personal-skill\            └── SKILL.md# 项目级（你的项目根目录下）D:\Projects\your-project\├── .codex\│   └── config.toml              # 项目级 MCP 配置（需要受信任项目）├── .agents\│   └── skills\                   # 项目级 Skill（团队共享）│       ├── java-review\│       │   └── SKILL.md│       └── java-unit-test\│           └── SKILL.md└── AGENTS.md                     # 项目全局规则

注意两个目录的区别：.codex/ 放配置文件（config.toml、agents），.agents/ 放 Skills。这个设计有点绕，但记住就好。

写在最后

Skills 和 MCP 的核心价值，一句话：让 Codex 从”什么都会一点的通才”变成”懂你项目规矩、还能调用外部工具的专才”。

我建议的上手路径：先用 $skill-creator 创建一个最简单的 Skill 体验一下。然后把你重复写最多的那个 Prompt 做成 Skill（比如代码审查、写测试）。再接一个 MCP Server（推荐先试 Context7，免费、无需认证、立刻有用）。等都用顺了，再试 Skills + MCP 的组合玩法。

说实话，Skills 的投入产出比非常高。写一次可能花 20 分钟，但之后每次用都能省 5 分钟的 Prompt 编写时间。用 10 次就回本了。

这篇里所有的配置代码和 SKILL.md 模板都可以直接复制使用。照着配了有什么问题，欢迎留言告诉我。

下一篇聊 Codex 的 Automations 和 Plugins——让 Codex 定时自动干活，还能把你的配置打包分享给团队。

以上觉得有用的话，关注下、点个赞或收藏、转发给你需要的朋友，如果想第一时间收到推送，也可以给我个星标⭐ 谢谢你看我的文章，下次见。