Claude / Codex × Figma × GitHub —— 我的 AI 设计工作流

前言

最近，我的设计工作流发生了一次根本性的重构：AI 成为设计生产的主力，Figma 退居为精修工具，而交付给工程师的不再是一份设计稿，而是一个 GitHub 仓库。

以往的流程是“需求 → 线框 → Figma 高保真 → 标注与切图 → 开发 → UI 走查 → 修改”，每个环节都在做信息的转译，每一次转译都会带来损耗。设计稿与最终产品之间始终隔着一层，走查就是为了弥补这层落差而存在的。

AI 工具的出现，正在填平这些落差。它弥补的是两种差距：一是信息差，需求、设计与实现之间不再需要层层转述，每个角色都能直接读懂上下游的语言；二是能力差，设计师可以借助 AI 写出可运行的代码，产品经理也能快速把想法变成可交互的原型，过去需要跨职能协作才能完成的事，如今一个人就能推进得更远。

这让研发流程中的每个环节都被拉得更近，其中变化最明显的是产品与设计。需求讨论、方案探索与原型验证可以在同一时间、同一份产出上完成，产品与设计之间的边界正在变得模糊，协作也从“交接”变成了“共创”。

现在，我用 Claude / Codex 配合 Figma 和 GitHub 完成从需求到交付的全过程。

团队协作从串行接力走向并行共创

变化不只发生在设计师个人身上，整个团队的协作方式也在被重写。

以前的团队工作流是一条串行的接力链：业务提出目标，产品整理需求，设计给出方案，开发实现，测试找问题，验收确认后上线，最后再收集反馈、验证效果。每一棒都要等上一棒跑完才能起跑。

这条链路有两重成本。一是跨团队成本：每一次交接都要开会对齐、写文档、来回确认，信息在传递中被稀释，问题往往到了下游才暴露，再一路返工回上游。二是技术壁垒：每个角色只能在自己的领域里发力，产品看不懂代码，设计改不了线上效果，业务想验证一个想法，要排上好几个团队的期。而反馈被放在最后一环，等到真正验证时，前面的投入已经很难回头。

现在的工作流更像一道乘法：业务 × 产品 × 设计 × 开发 × 测试 × 验收，再加上贯穿始终的反馈，才等于上线。这些环节不再严格排队，而是围绕同一份可运行的产出同时发生、相互放大：产品经理可以用 AI 直接做出可交互的原型去验证想法，设计师可以把方案做成能跑的 demo，开发更早参与设计系统的搭建，测试和验收在 demo 阶段就能开始，反馈也不再只出现在上线之后，而是融入每一次迭代。

之所以是“乘法”，是因为任何一个环节的提升都会放大整体的结果；反过来，任何一个环节缺位，结果都会大打折扣。AI 工具降低了每个领域的进入门槛，让每个人都有更多可能性和实践机会：产品可以碰代码，设计可以做交付，开发可以参与体验，业务可以亲手验证想法。分工依然存在，但边界已经可以跨越。

我的这套设计工作流，正是这种新协作方式在设计环节里的具体实践。

三件工具，各司其职

这套工作流由三类工具组成，它们的分工非常清晰。

Claude / Codex 本身并不是开箱即用的“设计工具”，它们的能力来自于安装的插件和 Skill。前端设计、动效、设计系统、无障碍审查、UX 文案等 Skill，相当于给 AI 装上了设计师的专业经验，让它的产出更有判断力，而不是千篇一律的模板化结果。

工作流全景

阶段一理解需求，用原型定方向

这一阶段的目标只有一个：用最低的成本，尽快确定产品的风格和设计方向。

拿到需求后，我会先和 Claude / Codex 一起把需求拆解清楚：用户是谁、要解决什么问题、哪些是决定产品体验的核心场景。然后只针对这几个核心场景，让它快速生成可交互的原型。

这里的关键是“只做核心场景”。核心场景承载了产品最主要的信息结构和交互模式，它们的风格一旦确定，其余页面基本都可以顺延。AI 生成原型的速度足够快，我可以在同一时间并行探索多个方向，对比之后再收敛，而不是像以前那样在一个方向上反复雕琢线框。

阶段产出：核心场景的原型，以及确认后的视觉风格与设计方向。它是阶段二两条线共同的起点。

阶段二高保真与设计系统并行推进

方向确定之后，这一阶段的两件事同时进行：在 Figma 里把核心场景做到高保真，同时把其中的设计决策沉淀为设计系统。两条线都由 Claude / Codex 驱动，彼此不需要排队等待，而是边做边互相校准。

用 Figma MCP 落地草稿，完成核心场景高保真

我不再从空白画布开始画。Claude / Codex 通过 Figma MCP 把核心场景直接生成为 Figma 上的可编辑草稿，图层、布局和组件结构都已经就位。

在这份草稿的基础上，我完成核心场景的高保真 UI 视觉：调整排版节奏、确定配色与字体、打磨图标与插画、处理关键状态。这一步是设计师审美和判断力最集中的地方，也是 Figma 在整个流程里最能发挥价值的地方。AI 解决了“从 0 到 1”的搭建成本，设计师把精力集中在“从 1 到 100”的品质上。

从核心场景中提炼设计系统

设计系统不必等高保真全部完成才开始。从方向确定的那一刻起，Claude / Codex 就从核心场景中提炼这个产品专属的设计系统，而不是先建一套通用规范再去套用。提炼的内容包括：

• 设计 Token：颜色、字体、字号、间距、圆角、阴影、动效曲线等基础变量
• 组件：按钮、输入框、卡片、列表、导航、弹窗等，以及它们的各种状态与变体
• 模式与规则：布局栅格、信息层级、交互反馈、空状态与异常状态的处理方式

两条线如何互相协作

• 高保真 → 设计系统：Figma 里每确定一个颜色、字号或组件状态，Claude / Codex 就把它同步为 Token 和组件规则
• 设计系统 → 高保真：已经沉淀下来的 Token 和组件，又成为后续高保真页面的基础，直接复用，不必重复绘制
• 冲突当场解决：视觉稿和规则对不上时，当下就决定是改稿还是改规则，而不是等到开发阶段才暴露

两条线汇合时，得到的是一套已经被高保真视觉验证过的设计系统。它不是一次性的产物，会跟着产品一起迭代，始终是产品当前设计语言的“唯一真相来源”。

阶段产出：核心场景的高保真视觉稿，以及经它验证、与产品同步演进的设计系统，同时存在于 Figma 与代码仓库中。

阶段三构建完整的产品形态

高保真视觉和设计系统汇合之后，就进入了“规模化生产”的阶段。我只需要给出清晰的需求描述，Claude / Codex 便会基于设计系统中的 Token、组件和规则，把核心场景之外的页面、流程与状态一一补齐，拼出完整的产品形态。

这种方式带来两个直接的好处：

• 一致性有保障：所有页面都来自同一套设计系统，不会出现各页面风格漂移、组件各写一套的问题
• 效率大幅提升：设计师不再逐页绘制，而是把精力放在需求梳理、关键决策和结果审核上

设计系统与需求描述，是这一阶段的两大输入：设计系统决定“长什么样”，需求描述决定“做什么”。

阶段产出：覆盖完整产品的页面、流程与状态。

阶段四以 GitHub 仓库交付可运行的 mock demo

最后的交付物，不再是一份 Figma 链接加标注说明，而是一个 GitHub 仓库。仓库里是 Claude / Codex 基于设计系统构建的 app 与 web mock demo，也就是阶段四的产品形态本身：真实的布局、真实的组件、真实的交互与状态切换。

对工程师来说，这意味着：

• 看到的就是要做的：不需要再从静态稿推测交互和动效，demo 可以直接运行和体验
• 拿到的就能参考：设计 Token 与组件以代码形式存在，可以直接对照甚至复用
• 更新可追溯：每一次设计调整都是一次提交，改了什么、为什么改，都清晰可查

方案的更新同样在仓库里完成。需求变化时，更新从设计系统开始：先调整设计系统，再同步到产品形态，最后提交到仓库，工程师即可同步到最新版本。

阶段产出：可运行、可追溯的设计仓库。

边开发，边设计，迭代交付

在这套工作流里，设计和开发不再是前后两个阶段，而是同时推进、相互校准的一个过程。AI 生成的原型从第一天起就是可运行的代码，设计师在 Figma 中精修视觉的同时，这些决策也被同步沉淀进设计系统和代码仓库；设计上的每一次调整，都能马上在可运行的 demo 里得到验证，而实现中暴露出的问题，又会立刻反馈回设计。交付也不再是项目末尾的一次性“交接”，而是一次次小步的提交：需求变化时，先更新设计系统，再同步到页面和仓库，工程师随时都能拿到最新的版本。设计、开发与交付在同一条回路里持续迭代，产品也在每一轮迭代中逐步打磨成形。

AI 能覆盖的设计范围

走完这四个阶段再回头看，AI 参与的早已不只是“画界面”。在目前的流程和产出中，它已经能覆盖从产品定义到前端交付的大部分设计工作：Product Design、UI/UX、视觉设计、品牌设计、营销策划、Motion Design、产品 Demo，以及前端交付。

这些工作过去分属不同的角色和工具：产品经理写需求文档，交互设计师画流程，视觉设计师出稿，品牌和市场团队各自产出物料，动效设计师在 AE 里做动画，工程师再把它们逐一实现。每多一次交接，就多一次信息损耗和等待。

现在，它们可以在同一条工作流里、基于同一套设计系统连续完成：品牌调性直接沉淀为设计 Token，营销页面复用产品的组件，动效以代码的形式随 demo 一起交付。产品、品牌与营销说的是同一种设计语言，用户在每一个触点看到的，都是同一个产品。

覆盖范围变广，并不意味着设计师可以什么都不管。恰恰相反，AI 拓宽了一个人能触达的领域，也要求设计师具备跨领域的判断力：知道好的品牌、好的动效、好的营销页面应该是什么样子，并在每个环节做出选择。AI 负责把可能性铺开，设计师负责收敛和定调。

四个关键转变

01设计方式从执行式转向命令式

以前的设计是执行式的：设计师亲手做出每一个页面、每一种状态、每一份切图，产出取决于手速，时间大多花在“怎么做出来”上。

现在的设计是命令式的：设计师描述目标、给出约束、提供设计系统，由 AI 执行产出，自己负责讲清需求、定明标准、判断结果。写好一条指令同样需要深厚的专业能力，只是重心从“画”转向了“定义”与“判断”。

设计围绕的核心也在改变。以前靠创意与灵感：找参考、做情绪板、反复推敲画面，好作品常常来自灵光一现，惊艳却难以复制和规模化。现在，我更多是在设计工作流：需求怎么拆、原型怎么验证、设计系统怎么沉淀、页面怎么批量生成、结果怎么交付迭代。工作流足够清晰，好结果就能稳定地反复产出。

创意依然重要，它决定方向和上限。灵感负责定调，工作流负责把它稳定地落到每一个页面上。

02Figma 从主力退居辅助

在过去，Figma 几乎承载了设计工作的全部：从线框到高保真，从组件库到交付标注。现在，大部分的搭建和生产交给了 AI，Figma 的角色收缩为两件事：精细化的细节设计，以及元素的确定与替换。

这并不是 Figma 变得不重要，而是它回到了最擅长的位置：一个需要设计师亲手把控品质的精修台。

03UI 走查基本消失

走查之所以存在，是因为设计稿和开发实现之间存在落差。设计师交付静态稿，工程师理解后再实现，落差在所难免，于是需要逐页比对 UI 和交互。

而在新的工作流里，交付的已经是接近真实产品形态的 mock demo。交互、状态、动效在交付前就已经被验证过，工程师对照的是一个可运行的参照物，而不是需要“翻译”的图片。落差在源头就被消除了，走查自然也就失去了存在的必要。

04交付物从设计稿变成仓库

设计师到底在做什么

当 AI 接管了大部分的绘制与搭建工作，设计师的价值反而更加清晰：理解需求、定义方向、做出判断、把控品质。

在这套工作流里，我花在“画”上的时间越来越少，花在“想”和“选”上的时间越来越多。核心场景的风格由我决定，设计系统的规则由我把关，AI 产出的每一个页面由我审核。设计师从执行者，变成了设计方向的决策者和设计系统的维护者。

交付方式从设计稿变成仓库，也意味着设计与开发之间的边界正在变薄。设计师交付的不再是“希望产品长成这样”的图片，而是“产品就是这样”的可运行方案。