Codex 新出了个「插件」功能,用完后我慌了!

说实话，前两天我自己在 Vibe 的时候，涉及到调用别的工具我就觉得很麻烦，一两个还行，要是多了呢？一会这个 MCP，一会那个新 MCP，然后还要 Skill，才能按照我想要的效果去执行，现在好了，这次更新解决了。

AI 工具的中间步骤你不要学习了，学习完它就更新了😂

Codex 昨天更新了：

👉 多了一个 Plugins（插件）模块

这次更新咋一看 “多了几个工具”，实际上它做了一件很重要的事：

👉 把 AI 从“对话工具”，变成了“能直接连工具干活的系统”

诶？懵了吧，脑瓜子嗡嗡的吧，怎么一会代码生成器、一会画布协作者，现在又干活的系统…..

一、Codex 这个「插件」到底是干嘛的？

先说结论，说官方的词我也看不懂：

插件 = 让 Codex 直接连接外部工具，并执行完整工作流。

也就是啥呢，以前你用 Codex：

• 写提示词
• 让它生成代码 / UI
• 或者帮你分析

本质还是“对话 + 生成”，现在插件出来之后，变成：

• Codex 可以连上 Figma、Notion、数据源等
• 直接读取真实数据
• 再执行一整套操作流程

这个插件里面包含了：

1. 读取设计（基础能力）Codex 可以直接读取，比如：

• Frame
• Auto Layout
• 组件结构
• Token

这是所有能力的基础

2. Code Connect Components（最重要），用来建立：Figma组件 → 代码组件的映射，比如：

• Button → React Button
• Card → UI组件

3. Create Design System Rules，自动生成设计规范，比如：

• 颜色体系
• 间距体系
• 字体规范

4. Generate Figma Design，AI 直接帮你生成页面

• 基于组件
• 基于设计系统

但不是乱生成，结合新的 MCP 能力，完全可以直接用你自己的规范和组件库来做了

5. Generate Figma Library，自动生成组件库

• 批量生成组件
• 自动结构化

你可以理解，以前这些都是零散的，单独用 MCP 来画图，或者生成代码，然后再用 Skill 来约束，让它更靠近自己的规范等等，现在你不用那么麻烦了，

这次插件更新，我感觉本质就是，把MCP、Skill、Rule这些拼在一起，形成一条完整的链路：设计 → 设计系统 → 页面 → 代码插件的结构大致如下：

my-plugin/ ├── plugin.json ├── skills/ │    ├── generate-ui.md │    ├── check-tokens.md │    └── ... ├── mcp/ │    └── config.json

二、插件的更新，又会有什么变化？

我现在感觉什么呢？

设计稿开始变成“输入”了，不是“交付”了，怎么理解，之前的设计稿是给开发看的，然后有问题就对接，然后总这样不是办法，于是你就出规范，出组件，让他们按照规范来，或者和开发对齐把组件和规范封装好等等。

现在，这些 AI 都正在干啊，你不觉得流程异常相似吗？

差别就是，现在的设计稿是给 AI 看的，如果你的插件足够完善，AI 看了就可以自己干完全部的工作。

现在，设计和实现之间那段 “翻译过程” 被大幅压缩了，之前你和开发来翻译，现在你和 AI 工具来回翻译，再到现在，你慢慢的不用翻译了，它自己完全可以搞定了！🤝

后续就是给它设计图，它能自动帮你跑完设计-开发-验收等全流程。你负责把控就行了。

三、插件到底怎么玩，不是“装上就完了”

Codex 里的插件，前面也说了，其实就是个工作流容器。官方定义很明确：插件是可安装的可复用工作流包，可以把 skills、可选 app integration、MCP server 配置打包在一起。

如果你要在 Codex 里用插件，正确方式不是“打开插件页面随便点一个能力”，更不是把你短期也用不到的全给装上，你首先要做的，就是先想清楚你要解决的问题是什么？

以 Figma 插件为例：

它的官方描述就是围绕三件事：设计实现、Code Connect 映射、设计系统规则生成。同时它声明自己有 Interactive / Read / Write 三类能力。

我大概试了一下，俺也不是专业版，没有无限次数，哪位有多次跑完的可以留言分享分享。

可以按这个顺序来试试：

🥊 第一步，不要先着急“生成页面”或者“转代码”，先处理规则和映射。

先用类似 Create Design System Rules 和 Code Connect Components 这种能力，把你的项目约束先建立起来。

前提是你要明确这些内容：组件怎么命名、目录怎么组织、哪些值不能硬编码、token 从哪来、优先复用哪些组件、哪些写法禁止出现。

然后是 skill。官方要求一个 skill 至少是一个目录，里面要有 SKILL.md，并且要写清楚 name 和 description。Codex 会先加载 skill 元数据，需要的时候再加载完整 SKILL.md。

这样后面 AI 生成出来的内容才更像你们项目自己的东西，而不是一个“长得差不多”的通用页面。这个顺序其实也符合 Figma 相关 skill 的官方设计思路：先把项目级规则写出来，再进入后续的 Figma-to-code 工作。

官方的 Skill 库：Create Design System Rules

https://github.com/openai/plugins/blob/main/plugins/figma/skills/figma-create-design-system-rules/SKILL.md

或者嫌麻烦，最简单的就是你直接对话，把你的标准化设计规范地址给它，让它先读一遍，然后让它给你总结，或者就有官方这个 Skill，根据自己规范情况来自行选择吧。缺点就是费钱，想省钱就得自己写🫣。

🥊 第二步，开始做具体页面工作。

这步才是把设计真正转成代码实现，但如果前面没有规则，没有组件映射，这一步通常只会变成 “生成一份能跑但不一定符合你们规范的代码” 。Figma 插件官方描述里也把它定位成 design-to-code workflow，而不是脱离系统单独存在的功能。

🥊 第三步，决定你的插件要不要连 Figma。

如果你的目标只是让 Codex 在代码阶段遵守设计规范，那你只需要 plugin + skills 就够了。但如果你的目标是把这套规范真正跑进 Figma → 代码 工作流里，那你就应该把 Figma 相关能力也一起打包。

最终，最理想的插件实际上应该是：

• 一个 design-system-rules skill
• 一个 generate-ui skill
• 一个 check-tokens skill
• 再配上 Figma 连接能力

这样它就不是一个“文档插件”，而是一个真正能跑设计到代码闭环的插件。

🥊 第四步，等这条链路跑顺之后，你再考虑把它变成自己的插件。

其实就是给插件套壳子。插件适合 “跨团队、跨项目、可安装、可分发” 的场景。如果你现在还在一个项目里频繁改规则，官方更建议先用 local skills 迭代，再打包成 plugin。

我估计看完有些人还是有点懵，还是不知道怎么下手，然后就去和 Codex 聊天了，聊到什么准备什么… 于是我又补了一段：

如果你要做“自己的设计规范插件”，你现在最该准备的内容清单

你至少要先准备这六样：

1. 设计原则比如你的系统最强调什么：一致性、组件复用、token 严格映射、页面结构优先。

2. token 规则颜色、字号、间距、圆角、阴影，哪些必须来自 token，哪些绝对不能硬编码。

3. 组件规则哪些组件是基础组件，哪些组件允许组合，哪些组件不允许 AI 随意新造。

4. 页面模式比如 dashboard、列表页、表单页、详情页，各自的结构骨架是什么。

5. 代码落地规则组件目录、命名规则、props 约束、样式方案、文件组织方式。

6. 校验规则生成后要检查什么：是否复用现有组件、是否违反 token、是否出现硬编码。

这些内容准备齐了再去搞插件，放心，不用你自己写，但是也不要直接就开始去 Codex 让它写，先去找免费的聊天软件聊，让它帮你完善，然后给你生成可以直接执行的 Prompt，比如我就喜欢先去用 GPT 聊，聊到最终要干的时候，再发给 Codex，很多人喜欢上来就开始和 Codex 聊天，当然也没问题，但是烧 Token 啊，土豪随意了。这个方法你也不用担心会不会两边聊的对不上，你只要把最终执行发给 Codex 后，你觉得它执行后的内容符合你的要求，你就让它把当前内容总结成一份 rule，就等于是保存一下目前核心内容的上下文。就可以了。

下面是我测试的我生成的SaaS Design Spec 

直接在对话@插件名称，输入：

按我的 SaaS design spec，设计一个用户管理后台首页，要有概览卡片、筛选、表格和批量操作。 

接着就会开始执行，自动连接 Figma 插件，需要你确认

Figma 文件在这里：SaaS Design Spec – User Management Homepage

我这次实际完成了：

• 新建了一个设计文件

• 画了完整后台首页壳层：顶部导航、左侧菜单、内容区

• 放了 4 张概览卡片

• 做了筛选区

• 做了表格工具栏和批量操作

• 做了用户表格和状态标签

这是我用SaaS Design Spec 没有连接设计系统生成的界面，纯靠文档的口头约束，这比我上个月研究半天生成的要好太太太多了啊，别说 AI 味了，一点点味道都没有啊。

临时我随便着了个组件库，试下最终效果。注意一下三点：

1. 把组件库放到你有可写权限的团队里并发布为 Library
• 最好放在你有 Full 权限的团队里面
• 如果只是文件，很多时候Codex 是只能看内容，但不一定能当成团队库自动导入
2. 在组件库文件里开启发布
• 确保组件是正式组件/组件集，不只是普通 frame
• 确保样式、变量、组件都发布到团队库
3. 在目标设计文件里启用这个 Library
• 打开我刚创建的这个文件：启用这个组件库

它的执行步骤跟设计师的思路一样，不会一次给你来个大而全，而是一步一步，一个模块一个模块的去搭建。

最后大概花了 7 分钟左右，处理各别组件，基本都调用了组件库的组件，但是部分细节还是有点小问题，我也让它反馈原因，主要还是名称没有对齐，以及md 里面没有涉及的描述信息。

最后，还有试过其他方向的小伙伴可以分享一下。

总结：

插件、Skill、MCP，到底啥关系？这么理解：

• Skill：怎么做事（方法）
• MCP：怎么连工具（通道）
• 插件：把这两者打包成一个可以直接用的流程

好了别光看，得动手，现在都不要动脑子了！

👉 如果觉得不错，随手点个赞、在看、转发三连吧，

👉 如果想第一时间收到推送，也可以给我个星标⭐～

👉 我们组了一群热爱探索的设计师→「设计师的 VibeCoding 实验室