以前做一个产品最容易卡在两个地方：
不会设计，做出来像半成品； 不会开发，设计稿只能永远躺在 Figma 里。
现在把 Codex 和 Figma 连接起来流程正在变成：
想法 → 梳理需求 → 生成或修改设计 → 开发真实页面 → 浏览器验证 → 回到 Figma 继续调整
Figma MCP 已经支持双向协作：Codex 可以读取 Figma 中的组件、变量、布局和素材，也可以把正在运行的网页捕获成可编辑的 Figma 图层；具备相应权限时，还能直接创建或修改 Figma 原生内容。
1️⃣ Codex 和 Figma 到底怎么分工？
很多人以为：
Codex 负责代码 Figma 负责画图
实际上，它们的分工更像这样。
Codex：需求分析＋开发执行
它可以帮助你：
-
梳理模糊想法
-
阅读 PRD 和项目代码
-
分析页面结构
-
编写和修改前端代码
-
运行构建与测试
-
根据设计反馈继续调整
-
检查最终改动
Figma：设计与评审工作区
它主要承载：
-
页面结构
-
组件和变体
-
颜色、字体与间距变量
-
自动布局
-
交互说明
-
产品评审和评论
-
多个设计方案
连接两者的是 Figma MCP。
它会把选中的 Figma Frame、组件、变量、布局和素材转换成结构化上下文，再交给 Codex理解和实现。需要注意，MCP 本身不会替你生成最终代码；真正负责适配代码仓库、复用组件并完成开发的仍然是 Codex。
2️⃣ 开始前，先确认账号和权限
你需要准备：
① ChatGPT 桌面端的 Codex 工作区，或 Codex CLI ② 一个 Figma 账号 ③ 一个简单的练手项目 ④ Git，用来保存和回退代码 ⑤ 明确的需求、PRD或参考素材
目前远程 Figma MCP 可以在不同套餐和席位上使用，但调用额度不同。Starter 用户以及付费团队中的 View、Collab 席位，读取类工具通常只有每月少量调用额度；Full 和 Dev 席位额度更高。
还要区分两个重要功能：
-
读取设计信息：Dev、Full 等席位可以根据权限使用。
-
Write to Canvas，直接修改 Figma 画布：需要 Full 席位，并且拥有目标文件的编辑权限。
Write to Canvas 当前仍处于 Beta，Figma 表示目前暂不额外收费，但未来计划改为按使用量计费。
3️⃣ 第一步：安装 Codex
已经安装的用户可以直接跳过。
macOS 或 Linux
Windows PowerShell
也可以使用 npm：
npm install -g
macOS 还可以通过 Homebrew 安装：
brew install –cask codex
安装后检查：
codex –version
启动 CLI：
codex
这些命令均来自 OpenAI 当前的 Codex 官方仓库。
截至 2026 年 7 月，原 Codex 桌面体验已经整合进 ChatGPT 桌面应用，Codex 项目、设置和工作流仍然保留。
4️⃣ 第二步：把 Figma 接入 Codex
在当前新版 ChatGPT 桌面端，一般可以进入：
Settings → Plugins → Figma → Install
完成 Figma 登录和授权后即可在 Codex 工作区中调用。
部分版本或 Figma 帮助页仍显示下面的入口：
左上角 Plugins → Figma 旁边的 + → Install Figma → Allow access
这是因为 Codex 在 7 月整合进 ChatGPT 桌面端后，插件管理位置发生过调整，实际界面可能随版本不同。
检查是否连接成功
打开一个你有权限访问的 Figma 文件：
选中 Frame → 右键 → Copy link to selection → 把链接发给 Codex
然后输入：
markdown
请通过 Figma MCP 读取这个设计节点。
暂时不要写代码，请告诉我：
1. 页面包含哪些模块
2. 使用了哪些颜色、字体和间距
3. 有哪些组件和变量
4. 哪些内容适合复用项目已有组件
5. 是否提供了移动端设计
无法确认的内容请明确标记，不要自行猜测。远程 Figma MCP 是基于链接工作的，链接应尽量指向准确的 Frame、组件或变体，而不是只提供整个文件的首页地址。
5️⃣ 实操一：从一个想法开始做网站
你可以输入：
帮我做一个宠物用品官网。
但这只能用来启动讨论，不能直接进入开发。
更稳的做法，是先让 Codex 像产品经理一样反问你。
直接复制这段提示词
markdown
我想制作一个宠物用品品牌官网，但需求还不完整。
先不要设计，也不要写代码。
请向我提问，帮助我明确：
1. 目标用户是谁
2. 核心产品是什么
3. 用户进入网站后的主要目标
4. 首页需要哪些模块
5. 是否需要商品详情、购物车或支付
6. 品牌风格与参考方向
7. 手机端有哪些重点
8. 第一版必须完成什么
9. 第一版暂时不做什么
10. 最终验收标准是什么
每轮最多问5个问题。
信息不足时继续提问，不要自行编造。
确认完成后，输出：
- 产品定位
- 页面结构
- 用户流程
- 内容清单
- 设计需求
- 开发计划一句话可以启动项目，但决定方向的，仍然是后面的提问、确认和取舍。
6️⃣ 让 Codex 在 Figma 中生成初版设计
原帖中直接要求：
在一个新的 Figma 文件中创建首页。
这不够稳定。
更适合小白的方式是：
-
自己在 Figma 中新建一个空白 Design 文件；
-
确认自己拥有编辑权限；
-
复制文件链接；
-
再让 Codex 写入画布。
markdown
请使用 Figma MCP，在下面这个空白文件中创建首页设计：
【粘贴Figma文件链接】
要求：
1. 使用Figma原生图层
2. 使用Auto Layout
3. 建立清晰的页面层级
4. 建立颜色、字体和间距变量
5. 包含桌面端与手机端页面
6. 图片位置先使用占位区域
7. 不编造Logo和品牌素材
8. 不增加尚未确认的功能Write to Canvas 可以创建 Frame、组件、变量和自动布局，但要求用户拥有 Full 席位及文件编辑权限。生成后仍需在 Figma 中人工检查，而不是把 AI 输出直接视为最终设计。
没有 Full 席位时，可以先让 Codex 输出：
-
页面结构
-
组件清单
-
设计规范
-
Wireframe 说明
然后由你在 Figma 中手动搭建，或改用已有设计稿进行读取和开发。
7️⃣ 实操二：把 Figma 设计稿变成真实网页
设计确认后，选中需要开发的 Frame，把链接交给 Codex：
markdown
请根据这个Figma Frame实现当前项目中的首页。
【设计要求】
1. 遵循布局、间距、颜色和字体层级
2. 优先复用项目已有组件和变量
3. 不创建重复的组件系统
4. 使用Figma提供的真实图片和图标
5. 同时适配桌面端与手机端
【工程要求】
1. 先检查项目技术栈
2. 先输出实现计划
3. 不安装没有必要的依赖
4. 不修改无关文件
5. 不添加设计稿中没有的业务功能
【验证要求】
1. 运行已有构建和测试
2. 检查文字溢出与横向滚动
3. 检查按钮、链接和交互
4. 对比页面与Figma参考
5. 输出修改文件及验证结果
无法实际验证的项目必须标记为“未验证”。官方建议 Codex 先获取准确节点的设计上下文和截图，再复用代码仓库现有的组件、Token、路由和数据模式，而不是直接照搬 MCP 返回的示例结构。
Figma 文件越规范，第一次生成的效果通常越稳定：
-
尽量使用 Auto Layout
-
组件不要全部拆散
-
图层名称清楚
-
使用变量或 Design Token
-
保留真实图片和图标
-
明确桌面端与移动端状态
8️⃣ 实操三：把截图变成原创产品
看到喜欢的网页，可以上传截图让 Codex分析，但不要让它直接照抄。
截图中看不到的业务逻辑和交互规则， 必须先向我提问，不要自行编造。
markdown
请分析我提供的网页截图。
不要逐像素复刻，也不要复制原网站的：
- Logo
- 品牌名称
- 文案
- 插画
- 产品图片
- 具有明显识别度的视觉资产
请只提取：
1. 信息层级
2. 页面模块
3. 配色逻辑
4. 字体层级
5. 卡片和按钮风格
6. 留白与间距
7. 图片使用方式
再结合我的产品需求，生成一套原创设计。截图只能提供视觉信息，无法告诉 AI：
-
按钮点击后发生什么
-
表单如何校验
-
数据从哪里获取
-
登录权限如何控制
-
手机端菜单如何展开
-
失败、空状态如何展示
9️⃣ 实操四：把 PRD 变成可评审原型
把 PRD 交给 Codex 后，不要马上要求它生成页面。
先让它找出需求里的漏洞：
markdown
请读取这份产品需求文档。
第一阶段只做需求分析，不要生成设计和代码。
请整理：
1. 用户角色
2. 每个角色能够执行的操作
3. 所需页面
4. 页面核心任务
5. 正常流程
6. 异常流程
7. 空状态和错误状态
8. 权限边界
9. 矛盾或模糊描述
10. 必须由我补充的问题
等待我确认后，再制作产品原型。确认需求后，再让 Codex通过 Figma MCP 制作页面或 FigJam 流程图。
使用 Write to Canvas 时，依然需要 Full 席位和编辑权限；Dev 席位更适合读取设计上下文，而不是直接修改画布。
🔟 把运行中的网页重新送回 Figma
这是 Codex + Figma 最有价值的能力之一。
传统流程是：
Figma设计 → 开发实现 → 设计稿逐渐过期
现在可以形成闭环：
Figma设计 → Codex开发 → 浏览器运行 → 捕获回Figma → 评审和调整 → Codex再次实现
可以对 Codex 说：
请启动当前项目的本地开发服务器。 使用Figma MCP的Code to Canvas能力， 把当前首页捕获到一个新的Figma Design文件中。 不要覆盖原始设计稿。 完成初次捕获后，告诉我如何继续捕获其他页面状态。
Code to Canvas 可以把浏览器中正在运行的页面转换成可编辑的 Figma Frame。首次打开浏览器时会自动捕获当前状态；其他页面、弹窗或错误状态，通常需要你操作页面，再使用工具栏中的“Entire screen”或“Select element”继续捕获。
创建或编辑自己 Drafts 中的捕获文件可以使用不同席位；要写入 Drafts 之外的现有文件，则需要 Full 席位和编辑权限。
1⃣1⃣ 做 App 和数据看板，也要加上边界
Codex + Figma 很适合制作：
-
待办工具
-
习惯打卡
-
简单记账
-
数据看板
-
产品落地页
-
运营后台原型
-
轻量 Web App
但“做出页面”不等于“完成成熟 App”。
移动应用仍可能需要：
-
Xcode 或 Android SDK
-
签名与证书
-
后端服务
-
登录和权限
-
推送通知
-
隐私政策
-
应用商店审核
-
长期维护
数据看板同样需要人来确认：
-
数据接口
-
指标口径
-
用户权限
-
数据隔离
-
分页与性能
-
敏感数据处理
1⃣2⃣ 做完后不要直接部署
最后把下面这段交给 Codex：
markdown
请对当前项目执行发布前检查。
先列出项目中真实存在的：
- build
- lint
- test
- 浏览器测试
- 部署脚本
然后执行可以安全运行的检查。
检查内容：
1. 构建是否成功
2. 是否存在终端或控制台错误
3. 是否存在横向滚动
4. 图片是否加载失败
5. 按钮和链接是否有效
6. 表单是否提供错误提示
7. 是否存在测试文案和占位数据
8. 是否泄露API Key或敏感信息
9. 页面是否符合Figma设计
10. 是否存在明显无障碍问题
不能实际验证的项目标记为“未验证”，
不要写成“已通过”。
不要执行正式部署、购买域名或创建付费资源。官方的推荐流程也要求使用真实浏览器对照设计，并结合 Playwright 等工具检查页面外观和交互，而不是只阅读代码就宣布完成。
生成出代码只能说明项目有了第一版；通过验证才说明它开始接近产品。
最后总结
Codex + Figma 的正确打开方式不是：
一句话 → 自动设计 → 自动开发 → 自动上线
而是：
① Codex追问，明确需求 ② Figma承载可编辑设计 ③ 人工确认页面和流程 ④ Codex实现真实代码 ⑤ 浏览器和测试工具验证 ⑥ 把实现结果送回Figma评审 ⑦ 确认后再部署上线
过去不会设计的人卡在 Figma，不会编程的人卡在代码。
现在 Codex + Figma 确实降低了从想法到原型、再到可运行页面的门槛。
但它降低的是实现成本，不是思考成本。
最终真正决定产品价值的，仍然是：
-
你解决了什么问题
-
谁愿意使用
-
需求是否清楚
-
数据是否可靠
-
代码是否经过验证
-
你是否愿意持续迭代
© 版权声明
文章版权归作者所有，未经允许请勿转载。
THE END
暂无评论内容