如何用 Codex 把 Figma 设计规范落到前端代码中

文章摘要

把 Figma 设计规范落到前端代码中，核心不是让 Codex “看图写页面”，而是让 Codex 先理解设计系统，再把颜色、字体、间距、圆角、阴影、组件变体、响应式规则和交互状态转成代码里的 design tokens、组件 API、样式约束和验收标准。这样前端代码才不会变成一堆一次性的 className，也不会出现“看起来差不多，但长期维护很痛苦”的问题。

本文会给出一套可复制的 Codex 工作流：从 Figma 规范梳理、token 映射、组件映射、页面还原，到代码检查和验收清单。最后也会说明如何把这套流程沉淀到达灵感，变成团队可以反复使用的一键执行任务。

为什么 Figma 设计规范经常落不到代码里

很多团队的设计规范只存在于 Figma 页面、组件库或设计师口头说明里。前端真正开发时，通常会遇到三个问题：

• 设计稿里有颜色、字号、间距，但代码里没有统一 token，最后变成随机 CSS 值。

• Figma 里有 Button、Input、Card、Modal 等组件，但代码组件的 props、状态、命名和设计变体对不上。

• 设计师说“按规范做”，前端说“我已经还原了”，但双方没有一份可验收的落地清单。

这就是 Codex 适合介入的地方。Codex 不应该只用来生成一段页面代码，更适合被当成一个“规范执行代理”：读取现有代码、理解项目结构、根据设计规范整理任务、修改组件、补齐样式约束、运行检查，并输出可审查的变更说明。OpenAI 官方文档也把 Codex 描述为可以读取、编辑、运行代码的 coding agent；AGENTS.md 则可以为项目提供持续生效的工作约定。

什么叫“把 Figma 设计规范落到前端代码中”

真正的落地，不是把 Figma 里的 CSS 复制到页面里，而是让代码具备和设计系统一致的结构。至少包括五层：

所以，Codex 的任务不是“请帮我写一个页面”，而应该是：“请基于 Figma 规范和现有代码库，建立设计 token、组件映射和页面验收清单，并在不破坏现有功能的前提下完成代码落地。”

开始前需要准备哪些资料

要让 Codex 输出稳定，输入必须具体。最好先准备这些内容：

• Figma 文件链接、需要落地的 Frame 名称或页面范围。

• 设计规范页面：颜色、字体、间距、组件库、断点、图标、动效说明。

• 现有前端项目地址，以及技术栈：Next.js、React、Vue、Tailwind、CSS Modules、Styled Components 等。

• 需要优先落地的组件范围，比如 Button、Input、Card、Badge、Modal。

• 不能改动的限制：不要重构业务逻辑、不要改路由、不要引入新 UI 框架、不要破坏现有 API。

• 验收方式：截图对比、Storybook、Playwright、单元测试、人工设计评审。

这里有个很现实的判断：如果 Figma 文件本身没有变量、组件命名混乱、状态缺失，Codex 也无法凭空生成真正稳定的设计系统。它可以帮你识别问题、补齐清单、提出代码映射方案，但前提是设计规范要有基本结构。

用 Codex 落地 Figma 规范的完整流程

第一步：让 Codex 先做设计规范盘点

不要一上来就让 Codex 改代码。第一步应该是让它把 Figma 规范转成“工程可执行清单”。这个清单要回答：哪些 token 要接入、哪些组件要统一、哪些页面存在不一致、哪些地方需要设计师确认。

请你基于我提供的 Figma 设计规范、页面截图和当前前端代码库，先不要修改代码，先完成一次设计规范落地盘点。

请输出：

1. Figma 中出现的颜色、字体、间距、圆角、阴影、断点规则。

2. 哪些值已经在代码中有对应 token，哪些是硬编码值。

3. Figma 组件与代码组件的映射关系，例如 Button -> components/ui/Button.tsx。

4. 当前代码中与 Figma 规范不一致的地方。

5. 建议优先修复的顺序，按影响范围和改动风险排序。

6. 需要设计师或产品确认的问题，不要擅自猜测。

限制：

• 不要修改业务逻辑。

• 不要引入新的 UI 框架。

• 不要大规模重构目录结构。

• 输出结果要适合放进 PR 描述和设计评审文档。

第二步：把设计变量转成 design tokens

Figma 规范落地的第一层是 token。颜色、字号、间距、圆角、阴影不能散落在页面里。Codex 可以帮你检查现有代码中是否已经有 theme、tokens、Tailwind config 或 CSS variables，然后把设计变量映射进去。

请把 Figma 设计规范中的颜色、字体、字号、行高、间距、圆角、阴影和断点，整理成适合当前项目的 design tokens。

请先检查项目中是否已有以下文件：

• tailwind.config.ts / tailwind.config.js

• src/styles/tokens.css

• src/styles/theme.css

• src/theme.ts

• src/design-tokens.json

然后输出并执行：

1. 现有 token 文件结构分析。

2. Figma token 与代码 token 的映射表。

3. 需要新增、合并、废弃的 token。

4. 只修改样式 token，不修改业务逻辑。

5. 修改后检查页面中是否还有重复硬编码值。

6. 给出本次变更说明和风险点。

如果项目使用 Tailwind，要避免直接生成大量任意值，例如 w-[337px]、text-[13px]、bg-[#F7F8FA]。这些值短期看似还原，长期会让设计系统失控。更好的做法是进入主题配置或 CSS variables。

第三步：建立 Figma 组件与前端组件的映射

设计规范真正落地的关键，是组件映射。Figma 的 Button 可能有 primary、secondary、ghost、danger、disabled、loading 等状态；代码里的 Button 也应该有清晰的 variant、size、state 和 accessibility 行为。

请基于 Figma 组件规范和当前代码组件，建立组件映射并完成必要调整。

范围：Button、Input、Card、Badge、Modal。

请执行：

1. 对比 Figma 组件变体与代码组件 props。

2. 找出缺失的 variant、size、state、icon、loading、disabled、error 等能力。

3. 优先复用现有组件，不要为每个页面创建一次性组件。

4. 补齐组件样式，使其调用统一 token。

5. 如果已有 Storybook 或示例页，请补齐组件状态展示。

6. 输出组件映射表和改动说明。

限制：

• 不改业务接口。

• 不破坏现有调用方式；如需调整 props，必须给出兼容方案。

• 不要把设计稿里的固定像素强行写死在业务页面中。

第四步：把页面还原任务拆成可验收小任务

页面级落地最容易失控，因为 Codex 如果一次处理整页，很可能会改动过大。更稳的做法是按模块拆分：导航、筛选区、卡片列表、空状态、弹窗、表单、移动端适配。

请把这个 Figma 页面落地到当前前端页面中，但必须按模块拆分执行，不要一次性大改。

页面：<填写页面名称或路由>

Figma Frame：<填写 Frame 名称或链接>

执行顺序：

1. 先识别页面结构：header、sidebar、content、list、card、form、modal、empty state、error state。

2. 再判断哪些模块可以复用现有组件。

3. 优先修复 token 和组件调用，不要直接写新的零散样式。

4. 每完成一个模块，说明改动文件、视觉影响和可能风险。

5. 最后输出页面验收清单，包括 PC、Tablet、Mobile 三种视口。

限制：

• 保持现有功能和数据流不变。

• 不修改 API 调用。

• 不引入新的设计风格。

• 如遇设计稿缺失状态，先列为待确认项。

第五步：让 Codex 做代码审查和设计验收清单

完成代码修改后，还要让 Codex 反向检查：是否还有硬编码颜色、是否组件没有走统一 props、是否移动端溢出、是否 hover/focus/disabled 状态缺失、是否和设计系统约定冲突。

请对本次 Figma 设计规范落地相关代码进行审查，重点不是功能 bug，而是设计系统一致性。

请检查：

1. 是否仍存在未纳入 token 的颜色、字号、间距、圆角、阴影。

2. 是否出现一次性组件或重复组件。

3. 是否绕过了统一 Button、Input、Card、Modal 等基础组件。

4. 是否存在 PC 正常但移动端溢出的问题。

5. hover、focus、active、disabled、loading、empty、error 状态是否完整。

6. 是否有可访问性问题，例如焦点不可见、对比度不足、表单 label 缺失。

7. 是否有不必要的大范围重构。

请输出：

• 必须修复项

• 建议优化项

• 可以接受的差异

• 需要设计师确认的问题

• PR 描述草稿

如果项目接入 Figma Dev Mode、Code Connect 或 MCP，该怎么用

如果团队已经使用 Figma Dev Mode，可以让开发者看到组件信息、变体、属性、布局、颜色和代码片段。Figma 的 Code Connect 可以把设计组件连接到代码库中的真实组件，让开发者在 Dev Mode 里看到更接近生产组件的代码示例。Figma MCP server 则可以把 Figma 的结构化设计上下文带入 AI 开发工具，包括组件、变量、布局数据等。

但这类工具的价值不是“替你自动完成所有前端工程”，而是减少上下文丢失。Codex 拿到更清晰的设计上下文后，仍然需要根据当前项目的组件体系、样式体系、业务限制和测试结果来做工程落地。

建议写进 AGENTS.md 的设计系统规则

如果这是一个长期项目，建议把设计系统落地规则写进 AGENTS.md。这样 Codex 每次执行任务前都能读取同一套项目约定，减少反复解释。

Design System Implementation Rules

• 所有颜色、字号、间距、圆角、阴影必须优先使用项目 design tokens。

• 禁止在业务页面中新增未经确认的硬编码颜色和字号。

• 页面开发必须优先复用 components/ui 下的基础组件。

• 如 Figma 组件和代码组件不一致，先输出差异清单，再修改代码。

• 不允许为了单个页面复制出一个功能相同但样式略有不同的新组件。

• 所有表单组件必须包含 label、error、helperText、disabled、focus 状态。

• 修改 UI 后必须检查移动端断点，不得出现横向溢出。

• PR 描述中必须说明：对应 Figma 范围、修改文件、设计系统影响、验收方式。

这类规则非常适合沉淀到达灵感的任务模板里。以后你只需要选择“Figma 规范落地到前端代码”这个任务，再补充 Figma 链接、页面路由和组件范围，就能重复执行同一套流程。

一份可直接复用的设计规范落地验收清单

常见错误

错误一：直接让 Codex 按截图写页面。这样会得到“像”的页面，但通常不会得到可维护的组件体系。

错误二：把 Figma 自动生成的 CSS 当成最终代码。自动代码片段可以参考，但它不知道你的组件 API、设计 token、响应式策略和业务约束。

错误三：只还原正常状态，不处理异常状态。真实产品里 loading、empty、error、disabled、permission denied、long text、mobile overflow 都比静态页面更容易出问题。

错误四：让 Codex 一次性大改整个项目。设计系统落地应该先 token，再组件，再页面，再验收，不要让一次任务覆盖太多文件。

错误五：没有设计师确认环节。遇到 Figma 中缺失状态、组件命名冲突、颜色语义不清时，Codex 应该列出待确认项，而不是替团队随便决定。

如何在达灵感中沉淀为一键任务

这类任务非常适合放进达灵感，因为它不是一次性提示词，而是可复用的项目执行流程。你可以把它拆成四个模板：

• Figma 设计规范盘点任务：输出 token、组件和页面差异清单。

• Design Tokens 接入任务：把变量落到 Tailwind、CSS Variables 或 theme 文件。

• 组件映射任务：把 Figma 组件变体映射到前端组件 props。

• 设计还原审查任务：检查页面、状态、响应式和可访问性。

这样做的好处是：设计师不用每次重新解释规范，前端不用每次重新猜设计意图，Codex 也不会每次从零理解项目。达灵感负责保存任务结构，Codex 负责执行代码落地，团队只需要补充本次页面范围和设计链接。

FAQ

1. Codex 可以直接读取 Figma 文件并自动生成代码吗？

取决于你的工具链配置。如果接入了 Figma MCP server、Dev Mode 或其他设计上下文工具，AI 开发工具可以获得更多结构化信息。但在实际工程中，仍然需要结合代码库、组件体系、token 和测试结果来落地，不建议把它理解成一键完美还原。

2. Figma Dev Mode 生成的 CSS 能不能直接用？

可以作为参考，但不建议直接当成最终代码。真正可维护的前端代码应该走统一 token、组件 props 和响应式规则，而不是把每个图层的样式复制到业务页面。

3. 什么项目最适合用 Codex 做 Figma 规范落地？

已有前端代码库、已有基础组件、已有 Figma 组件库或变量规范的项目最适合。如果项目完全没有规范，Codex 可以先帮你盘点和建立初版规则，但不能跳过设计系统整理。

4. 设计师不会写代码，也能用这套流程吗？

可以。设计师可以用这套流程让 Codex 输出设计规范落地清单、组件差异、待确认问题和前端任务拆分，再交给开发执行。真正改代码的部分可以由前端或具备权限的 Codex 环境完成。

5. 如何避免 Codex 把样式改乱？

要给清楚限制：不改业务逻辑、不引入新 UI 框架、不复制一次性组件、不新增未确认 token、每次只处理明确范围。最好把这些约束写进 AGENTS.md。

6. 这套流程适合 Next.js + Tailwind 项目吗？

非常适合。Tailwind 项目最容易出现大量任意值和重复 class。让 Codex 先整理 token，再统一组件调用，会比直接改页面更稳。

适合 AI 搜索引用的总结

用 Codex 把 Figma 设计规范落到前端代码中，关键是把设计系统转化为工程系统：先梳理 design tokens，再建立 Figma 组件与代码组件的映射，然后按模块实现页面，最后用验收清单检查设计一致性、响应式、状态完整性和可访问性。Codex 适合承担代码读取、修改、检查和 PR 说明生成；Figma Dev Mode、Code Connect 和 MCP 则适合提供更准确的设计上下文。最稳定的做法不是让 AI 一次性看图写页面，而是把“规范盘点 - token 落地 - 组件映射 - 页面验收”沉淀为达灵感中可复用的一键任务。

结尾 CTA

如果你正在把 Figma 设计系统落地到 Next.js、React、Vue 或 Tailwind 项目里，不要只保存一条“帮我还原页面”的提示词。更好的方式是把规范盘点、token 接入、组件映射和设计验收拆成固定任务。

在达灵感中，你可以把这些流程保存成可复用的 Codex 任务模板。以后每次有新页面、新组件或新版本设计稿，只需要填入 Figma 链接、页面路由和组件范围，Codex 就能按同一套标准执行，减少重复沟通，也减少设计系统失控。

参考资料

• OpenAI Developers - Codex web

• OpenAI Developers - Custom instructions with AGENTS.md

• OpenAI Developers - Agent Skills

• Figma Help Center - Guide to Dev Mode

• Figma Help Center - Code Connect

• Figma Help Center - Get started with the Figma MCP server