我用这套流程建了我的个人网站，从零到上线，全程没有找开发。不是因为我突然学会了写代码，而是因为整个链路变了。
Figma 一直没能解决的问题
设计师最熟悉的工具是 Figma，但 Figma 有一个根本性的限制：
它做的是产品的描述，不是产品本身。
Prototype 无论多精细，按钮背后没有逻辑，数据不会真实流动，用户交互也不影响任何系统状态。
从设计稿到可运行的产品，中间还有一条很长的链：前端实现、交互逻辑、状态管理、工程结构、部署上线。
这条链以前需要开发团队来走完。大多数设计师，就停在了 Figma 这一侧。
现在这条链变短了
过去一年，工作流里加入了 AI 工具之后，整个链路可以被压缩成这四步：
Claude → Figma → AI 编码环境 → Deploy
下面逐步拆解。
第一步：用 Claude 先把结构想清楚
很多人会直接打开 Figma 开始画界面。
我现在的习惯是先跟 Claude 对话，把以下内容搞清楚：
页面结构（有哪几个页面，每页放什么）
核心用户路径（用户进来之后走哪几步）
组件清单（需要哪些组件，每个有几种状态）
视觉规则（字号层级、间距、颜色角色）
这一步很关键。结构不清晰，后续的代码会直接反映这种混乱。
Claude 在这个阶段的作用不是代替你思考，而是帮你把思考显式化——把脑子里模糊的想法，变成可以执行的规格。
第二步：进 Figma，做结构，不追求高保真
拿到结构之后，进 Figma 做三件事：
确认模块顺序，页面布局走一遍
建组件体系（Button、Card、Input 这些先定好）
设定 Design Token（字号、间距、圆角、颜色变量）
这一步的目标不是做好看，而是让结构清晰、组件可拆分。
Figma 在这里的角色是“结构编辑器”，不是最终交付物。
第三步：选择你的 AI 编码环境
从 Figma 出来之后，需要进入一个“AI 辅助编码环境”把设计转化为真实系统。
这里没有唯一答案，目前主流有三种组合，本质上是同一类工具的不同形态：
| 组合 | 特点 | 适合谁 |
|---|---|---|
| Cursor | AI 深度集成，开箱即用，上手最快 | 想少配置直接干活的人 |
| VS Code + Claude | 灵活性高，可精细控制每一次 prompt | 已有 VS Code 习惯，或需要更细粒度控制的人 |
| VS Code + Claude Code | Claude 可主动读写文件，适合更复杂的 agentic 操作 | 项目结构较复杂，需要 Claude 自主处理多文件的场景 |
三种组合的工作方式大同小异：你提供清晰的规格文档，AI 生成组件化结构和工程代码。
无论选哪种，输入质量决定输出质量。把以下内容整理清楚再交给 AI：
页面结构说明
组件列表 + 状态描述
交互逻辑
视觉规则（直接引用你在 Figma 里定义的 token）
规格越清晰，生成质量越高。模糊的输入只会带来模糊的代码。
第四步：跑起来之后，开始真正的产品迭代
产品第一次运行起来，才是工作真正开始的地方。
这个阶段最明显的感受是：修改成本极低。
以前的工作流是：发现问题 → 改设计稿 → 沟通开发 → 等待实现 → 验证效果。
现在是：发现问题 → 直接改 → 刷新验证。
这不只是效率差异，是对产品的控制感完全不同。
Figma 的角色正在变
Figma 不会消失，但它正在从“设计终点”变成“产品输入层”。
设计稿不再是最终交付物。
URL 才是。
关于 Figma Make 这类工具
最近有不少讨论。
它的定位是：快速把设计转成可交互的产物，适合早期验证和方向讨论。
但如果目标是长期可维护的产品，还是需要进入工程化结构。
Claude 定义结构 + Figma 设计系统 + AI 编码环境工程实现，这三者构成一个完整闭环，是目前最稳定的链路。
最后说一句
这套流程的本质，是把设计师的工作边界往后延伸了一段。
不是说设计师变成了工程师，而是说：设计到系统之间那条过去需要外包的链，现在可以自己走完。
Intent → Structure → System → Iterate
这个闭环，以前需要团队。现在一个人可以跑通。
本文内容仅供个人学习、研究或参考使用，不构成任何形式的决策建议、专业指导或法律依据。未经授权，禁止任何单位或个人以商业售卖、虚假宣传、侵权传播等非学习研究目的使用本文内容。如需分享或转载，请保留原文来源信息，不得篡改、删减内容或侵犯相关权益。感谢您的理解与支持！