原文：Forget Figma, AI is the new Design tool
小声 BB
本文在翻译过程中确保意思传达准确的前提下，会加入很多本人的个人解释和一些知识补充(使用引用块&&括号标注) ，像这样
（我是一个平平无奇的知识补充块）
AI 正在快速融入每个开发者的日常，正在逐步模糊每个工种的边界。每个前端开发可以上游摸索，去接触产品、UI 的工作内容；产品和 ui 设计师也能往下游探索，增加自己一点基础的开发能力，更好地去落地自己的天马行空的想法，可以做一些尝试，比如：
- 用 ai 反哺自己的设计
- 去思考一些 ui 开发的新的合作方式。比如开发定了技术栈之后，ai 直接通过工具生成 component，让开发去接入到项目
- 直接通过 ai 工具做到自主开发（随着 ai 能力的进一步提升，目前 gemini3 做到的落地页等静态界面已经令人咋舌）
🎊如果觉得文章内容有用，交个朋友，点个赞再走~ 🎊
正文
当我在 2019 年加入 Booking.com 的时候，会不会写代码对 UX 设计师来说不是"加分项"，而是硬条件。你根本没办法在不会写代码的情况下被 Booking.com 录用。那时候，这在我看来还是一个"异类要求"，甚至有点极端。
六年之后，这件事正在变成常态。像 Linear、Vercel、Cursor 和 XAi 这样的公司，已经悄悄重写了设计师的岗位描述，开始招聘所谓的 "design engineer（设计工程师）"。他们想要的是既能设计、又能动手构建并上线的人，而不是只会在界面上推像素的人。
现在，我们讨论的已经不是那个老掉牙的问题------"设计师到底应不应该写代码"。在那些做出顶级产品的公司里，这艘船早就已经开走了。AI 终于让一项过去几乎不可能学会的技能，变成了真正可行的东西。设计师，甚至任何人，现在都可以去做真正的软件，而不只是画一个 mockup。
接下来，我们设计和构建产品的方式，正在迎来一次大的转变。
以前，我们是在 Photoshop 里设计软件，那本质上是一个为印刷而生的工具。后来 Figma 出现了，这是一款为屏幕而生的工具，一切都随之改变。现在，媒介又在发生变化。屏幕已经不再是最终的产品了，真正可运行的软件才是。
这个转变暴露出一件我们谈得还远远不够的事情：我们当前工作流里的瓶颈到底在哪里？
如果 AI 已经让任何人都有能力直接构建产品，那为什么我们还要花大量时间在那些为静态界面设计而生的工具里？这些工具产出的，最终只是 mockup，而不是真货。
Figma 的瓶颈，以及用静态工具设计的隐性成本
我真的非常喜欢 Figma。我曾经发过一条推文，说它是我们这个时代最伟大的发明之一，而且我是认真的。它的性能、像 auto-layout 这样的功能、实时协作能力，再加上它在 Sketch 之后接力、共同推动的那场变革，一起革新了我们设计和构建软件的方式。
而现在，另一场革命正在发生，只不过这一次，主角不再是另一款设计工具，而是 人工智能。
我们先实话实说，一般产品设计实际上是怎么走的：
你会在 Figma 里花上好几天时间，打磨一个流程和一堆界面，反复调整 auto-layout 的设置、拆组件、微调像素、制作组件和各种变体。某种程度上，你是在搭一台复杂的"鲁布·戈德堡机器"（Rube Goldberg machine）。
然后你把这些界面串成一些 prototype，连上一些半成品的交互，这些交互从来都不是真的"感觉很对"。
用户在测试时，走的是一条你为他们脚本化好的理想路径，一切都在完美条件下发生：他们不能真正搜索、不能真的登录、不能体验到网络变慢的情况，也看不到当数据加载失败时会发生什么。
做完用户测试之后，你回到 Figma 继续打磨。
接着就到了 handoff（交接）这一步------真正的痛苦从这里开始。
围绕这一环，我们甚至造了一整套流程：设计规格文档（design specs）、developer mode、红线标注（redlines）、设计 token......
我们一厢情愿地认为，只要我们写的文档足够多、标注足够详细、Figma 文件组织得足够干净整齐，这个从设计到实现的"翻译过程"就会变得无比顺畅。
但事实是：从来没有顺畅过。
几周以后，你终于看到真正被搭建出来的版本。
但这时候你会发现：间距不太对、交互手感有点笨拙，而且还有几十个你完全没考虑过的边缘场景（edge cases），原因是你一直是在用完美的占位数据（perfect placeholder data）做设计。
于是你开始提各种 ticket，等下一次 sprint。
等你跟工程师来来回回沟通了几轮、各种改动终于落地时，你已经花了好几周时间，去交付一个如果你一开始就直接构建、完全可以在几天内测试并打磨完成的东西。
这不是文档的失败，而是静态设计本身无法回答这些问题；问题也不是 Figma 这个工具本身。真正的问题是：
我们把静态界面和半成品 prototype 当成了设计流程的终点，而它们从根本上不具备回答那些最关键问题的能力------
比如：
-
这个东西用起来，真的舒服吗？
-
这些交互，真的说得通吗？
-
当用户做了意料之外的操作，或者当系统出现异常时，流程会不会直接崩掉？
静态设计会产出理论化、耗时的文档；
而可运行的软件，给你的是事实真相。
Cursor 的设计负责人 Ryo Lu 把这件事讲得特别直接：
用代码设计，"让我们真的可以和 app 互动。比起 Figma 里的一张图，这种感觉真实太多了。"
在一条推文里，一位叫 @aydaoz 的设计师说：
"我愿意花 1000 美元买 Linear 的 design system 文件，但它大概值不止这些。"
Linear 的创始设计师 @Griveau 回复说：
"说实话，我们的 Figma 文件还挺乱的。我们也没有遵循什么严格的 design system。我们更多是把 Figma 当成草图工具，最终的产品都是在代码里做出来的。"
AI 作为新的设计工具
如果说过去十年是关于设计屏幕、打磨像素、掌握 auto-layout，那接下来十年，就是关于如何把想法几乎瞬间变成产品。
在过去的 6 个月里，我设计并上线了 3 个产品------而且在这之前，我完全没有先在 Figma 里把它们画一遍。
这不是因为 Figma 变糟了，而是因为 AI 让这一步变得不再必要。
旧的流程要退场了，新的工作流已经在这儿了
我们现在的工作流，还没有真正跟上今天已经可以做到的事情。
传统的软件设计和构建流程，大概长这样：
研究（Research） > 头脑风暴 / 概念（Ideate） > 在 Figma 里设计 > 做 Prototype > 评审（Review） > Handoff > 工程实现（Engineering） > QA > 调整优化（Refinement） > 更多 QA > 最终交接 > 上线（Deploy）
每一个箭头，都意味着几天甚至几周的时间。
每一次交接，都伴随着上下文信息的丢失、理解的偏差和翻译错误。
而有了 AI 之后，工作流可以变成这样：
Research -> Build -> Test -> Refine -> Deploy*
你并不是在跳过环节，而是在把它们折叠起来。
设计和产品变成同一件事。
你不再是画一个界面然后"希望它能 work"，而是直接把这个界面做出来，并在真实环境里一轮一轮打磨。
代码是新的画布
设计工具在"模拟"产品；
AI 直接把产品"做"出来。
Figma 会帮你"模拟"一个按钮。
Claude Code 会帮你"构建"一个真正的按钮：
有 hover 状态、有点击逻辑（click handler）、有加载状态、有错误处理，还有可访问性（a11y）属性。
在 2025 年，最强的设计工具已经不是视觉编辑器，而是那些能生成代码、能理解上下文的 AI agent，它们让设计师可以从"静态界面思维"转向"结果与系统思维"。
像 v0、Lovable、Replit、Cursor，还有命令行工具形态的 Claude 和 OpenAI 的 Codex，这些工具不是帮你生成 mockup，而是干脆让 mockup 这一步变得不再需要。
正如前面提到的，这其实类似于当年 Figma 替代 Photoshop 时发生的事情：
Photoshop 是为印刷而生的，屏幕只是事后的附加场景；
Figma 是为屏幕而生的，实时协作是它的原生能力。
工具和媒介对齐了之后，所有人突然都能干得更快、更好。
现在，代码就是媒介，而 AI 正在让代码变得像 Figma 里的像素一样"好上手"。
当你的画布变成代码时，一切都会变：
-
你的 prototype 不再是"近似"，而是跑在真实设备上的"成品预览"；
-
你的 edge case 不再只是写在注释里的情况，而是真的被处理掉；
-
你的交互不再只是被录成动效，而是实际可用的行为逻辑；
-
你的"设计稿"不再只是实现规范，而是可以直接部署的软件。
AI 正在让代码变成新的设计画布。
用代码来做设计
我认识很多设计师是很怕代码的，甚至完全不想碰它。
别怕，这不代表你要变成工程师。
用代码设计，只是把"代码"当成你的设计媒介，就像你现在把 Figma 当成你的设计媒介一样。
你依然是在做设计：你还是在想着用户、在解决问题、在让体验变得自然顺畅、有趣好用。
唯一的区别是：你操纵的东西变了。
在 Figma 里，你操作的是 vectors、frames 和 layers。
在 AI + 代码的世界里，你操作的是 components、states 和 behavior。
只是这一次，你产出的不是静态图片，而是真正可运行的软件。
实际上到底改变了什么？
你从"画出来"变成"说出来"
在 Figma 里，你通过摆放矩形和选择颜色来表达你的意图。
在 AI 里，你通过对话来表达你的意图，例如：
"表单验证要做成 inline 的，不要统一显示在顶部。"
"loading 状态用 skeleton，而不是用 spinner。"
两者本质上都是设计；一个使用视觉编辑器，一个使用语言。
你开始在真实约束下工作
Figma 允许你设计出在现实中几乎不可能实现的界面。
当你在代码中做设计时，现实会立刻给你反馈。
你不能随便"假装"一个 API 响应是怎样的，你要么真的连上这个 API，要么就得好好地 mock 它。
借助代码，你可以看到各种条件逻辑、边缘场景和状态变化，实际上是如何影响 UI 和整体体验的；这些是 Figma 永远揭示不了的。
这种"阻力"其实是一种特性，而不是缺陷。
它会逼着你在设计阶段就把难点想清楚，而不是在开发阶段再返工。
你迭代的节奏，从"天"变成"分钟"
在 Figma 里：
你做一个改动 → 导出 prototype → 发链接 → 等反馈 → 再改 → 再导出......
用 AI 的时候：
你改一行 → 刷新浏览器 → 直接看到效果。
再改 → 再刷新 → 再看。
整个反馈循环紧到离谱，你可以在原来做完一个 Figma prototype 的时间里，试十套完全不同的方案。
你不用再把时间花在对像素、调整 frame、拖来拖去 node 上，而是可以把更多时间花在：
去找用户验证、发现什么真的有效、解决真实世界的问题上。
你上线的，就是你设计的那一个版本
在我看来，最深刻的变化在于这点：
当你"设计完"的那一刻，其实也基本意味着"已经构建完成"。
没有 handoff，那些你反复考虑过的细节不再需要被别人"翻译"。
如果你花了一个小时调一段 micro-interaction 的时间曲线，这段节奏会以完全相同的方式出现在生产环境里。
你的设计决策不再是"被实现"，而是直接被部署。
用代码设计所需要打好的基础
用代码做设计，并不意味着你要变成一个开发者。
设计师不用去理解算法或数据结构，也不用去背一堆语法细节。
如果设计师能搞明白 auto-layout，或者能在 Figma 里把 prototype 串起来，他们其实已经有了很好的基础，可以去理解以下这些概念：
-
HTML 结构
内容是怎么被组织起来的（标题、段落、列表、按钮）。你可以把它想象成 Figma 的图层结构，只不过它是语义化的"容器套容器"。
-
CSS 基础
东西是怎么被"长相化"的：颜色、尺寸、间距、布局。这是和我们在 Figma 里所做的事情，对应度最高的一块。
-
组件化思维（Component thinking）
界面是由可复用的部分堆起来的。其实设计师早就习惯在 Figma 里用 components 来思考了。
-
状态（State）
界面会根据数据发生变化，例如：loading、error、success、empty 等状态。
-
Tailwind 工具类（utility classes）
这是一套"样式词汇表"。在 Figma 里你拖一拖控制来调整间距，在 Tailwind 里你写 space-y-4；在 Figma 里你调字体大小，在 Tailwind 里你写 text-lg。本质上是一样的，只是一个是拖动控件，一个是写 class。
-
英文，或者你的母语
用 AI 做设计的起点，还是你已经熟悉的东西：语言。英文也好，母语也好，都是你的新工具栏。你就是用它来描述你想要什么，就像你对队友解释你的设计一样。
这些基础完全可以在一个周末里，通过 YouTube 或 Google 的教程学到一个大概。
你不会立刻变成专家，但已经足够去"艺术指导"AI，去告诉它你想要什么。
有点像你学了一点摄影术语之后，就可以更好地指导一个摄影师；你不需要成为 Tyler Mitchell，但至少你要知道 aperture（光圈）是什么意思。
更好的消息是：跟 Figma 不一样，AI 是"对话式"的。
当你错误地使用了一个 class，或者误解了某个概念时，它会用很自然的方式纠正你：
"实际上，space-y-4 控制的是子元素之间的垂直间距。如果你想控制元素内部的内边距，你需要的是 py-4。"
现在用 AI 做设计的真实情况
我们要先把话说清楚：AI 现在擅长什么、不擅长什么。
AI 在结构和功能上的能力非常强。它可以：
构建表单、处理路由、管理 state、连接 API、实现校验逻辑、创建响应式布局------这些过去都需要工程师来做。
但 AI 目前仍然在一些视觉细节上表现一般：
-
间距可能"还行"，但不够精致；
-
字体层级也许"能用"，但不够有设计感；
-
颜色搭配可能没问题，但会让你觉得"还不够有品牌味儿"。
这就是懂一点 HTML、CSS 和 Tailwind 会显得特别有价值的地方。
你不需要从零写所有代码，但只要知道 space-y-6 会改变垂直间距，或者 text-xl font-semibold 会调整字重与字号，你就能在 AI 生成的基础上加一层"人的判断"，把"AI 糊出来的东西"提升成有意图、有美感的作品。
移动端环境目前还是慢半拍。
今天的 AI 工具在 web 场景表现最佳，还没有很好地深度整合 Xcode 或 Android Studio 这种原生应用环境。
这并不代表设计师不能做移动相关体验------你完全可以，但目前预期应该更多是基于 web 或跨平台框架来做。
虽然今天用 AI 设计还有不少短板，但 AI 在飞快变好。而那些掌握基本原理的设计师，总是能做出比完全不懂这块的人更好的产品。
Figma 仍然更适合做什么？
我们得说清楚一点：代码并不是在所有场景都比 Figma 更好。
-
早期探索
当你需要在一小时之内尝试十个完全不同的方向时，Figma 会更快。你可以迅速画草图、尝试不同视觉风格，然后把不行的版本扔掉。
-
视觉设计系统工作
比如定义颜色体系、字体层级、组件库等等，这些依然是在视觉编辑器里更直观、更自然。
-
对齐干系人
当你需要给一堆人看二十个选项，好让他们给反馈、拍板时，Figma 比你去构建二十个可运行 prototype 高效得多。
-
纯视觉设计
比如插画、图标集、营销图等，这些场景下用代码根本不是正解。
所以，这个变化不是"从 Figma 切换到代码"，而是从 "Figma 是最终设计产物" 转变成 "Figma 是发散和构思的工具" 。
Figma 更像是你的 sketchbook，而不是最终的 blueprint（蓝图）。
心智模式的转变
最难的部分，其实不是学习新工具，而是改变你对"设计是什么"的理解方式。
在 Figma 的思维模式里，设计就是把你的意图写成一份尽可能全面的"文档"：
你为每一种状态画界面，为每个交互写注释，精确地标注每一个尺寸。
你的目标是尽可能完美地把你的愿景传达出去，好让别人能够按图施工。
在代码的思维模式里，设计则是直接去塑造那个"东西本身"。
你不是在写一个按钮的说明书，而是在真的构建这个按钮。
你不是在定义一个表单应该如何验证，而是在具体地实现这个验证逻辑。
你的目标，是让产品本身变好，而不是让文档完美无缺。
这要求你用一个全新的方式去信任自己。
你不能再躲在"设计稿是这样的"后面。
你无法再把那些真正困难的决策全部推给"实现阶段"。
你必须亲自把它做对。
但回报也非常实在：
当它真的能跑的时候，你知道它是真的行------
不是理论上、不是"希望如此"、也不是"只要工程实现得没问题就没事"。
而是那种：确确实实、可以测量、无可否认地行得通。
你开始对"结果"负责，而不是对"产物"负责。
而这，恰恰就是设计本来就应该走向的地方。
在这篇文章的下一部分（第 2 部分）里，我会从"概念"走向"实战"，具体展示我如何用代码来做设计。
我们会一起过一遍我现在用的完整工作流：
从搭建开发环境、使用 Git，到使用像 Claude CLI 这样的 AI 工具，再到通过 Vercel 或 Replit 部署在线 prototype。
在开始之前，你需要准备这些东西：
Git + GitHub*
用于版本管理和团队协作。如果你还没有 GitHub 账号，先去注册一个，然后下载 GitHub Desktop。你还需要在本地安装 Git。
Node.js + npm*
Node.js 让你可以在浏览器之外运行 JavaScript，也是大多数现代 web 项目的基础。安装 Node 的同时也会顺带安装 npm（Node 包管理器），你会用它来安装各种框架、库和依赖。去官方站点下载并安装最新版本即可。
VS Code 或 Cursor
这是你的开发工作空间，可以把它当成新的 Figma，只是这里没有图层。
我个人用的是 VS Code，并配合 Claude CLI 的插件一起用。
Claude CLI
这是你在设计和写代码时的 AI 搭档。如果你还没有账号，可以先注册一个 Claude 账号，然后开启 CLI 使用。
Vercel 或 Replit
这是用来部署你作品的托管平台，可以让你一键把项目变成在线可访问的产品，不需要自己管服务器，也不用做复杂配置。注册一个账号，你就可以用一条命令把你的构建部署出去。
Tailwind CSS
一套 utility-first 的 CSS 框架，让你可以用最少的精力做出干净、响应式的界面。
就这些。
有了这套基础，你就可以在一小时之内，从一个想法走到一个真实可用、可在线访问的互动 prototype。