乐于分享
好东西不私藏

AI 时代还要不要用 Figma/Pencil ?我的结论:看你是不是要交付给别人

AI 时代还要不要用 Figma/Pencil ?我的结论:看你是不是要交付给别人

哈喽,大家好,我是 Max King。

最近聊 AI UI 工作流,经常会绕到一个问题:

现在 AI 都能出图了,Codex / Cursor 也能写页面了,那 Figma 还要不要用?

这个问题我一开始也纠结过。

因为如果只是自己做一个页面,流程确实可以很短。

先写 UI Spec,再让 gpt-image-2 出一个参考图,然后把 UI Spec 和参考图交给 Codex / Cursor。页面跑起来以后,再截图对比,一轮轮修。

这样一套下来,很多页面已经能跑了。

那还要不要进 Figma?

我的答案是:看这个页面是不是要交付给别人。

如果只是自己做 demo,Figma 不一定是必经环节。

但如果这个页面要给老板看、给客户确认、给团队协作、给前端按稿还原,那 Figma 依然有价值。

不是因为它“高级”。

而是因为真实项目里,需要一个可以被确认、被标注、被讨论、被追踪的东西。

01

-MaxKing.cc-

自己做 demo,我确实不一定先打开 Figma

先说实话。

如果我只是自己做一个小页面,比如后台工具、测试页面、临时 demo,我现在不一定会先打开 Figma。

因为这个场景里,我自己就是产品、设计、前端和验收人。

我知道页面要干什么。

我知道哪些模块重要。

我知道第一版哪里可以接受。

我也知道后面哪里可以慢慢改。

这种情况下,完整走一遍 Figma,反而可能会拖慢节奏。

我更愿意这样跑:

UI Spec

参考图

Codex / Cursor 实现

截图修正

这套方式对个人开发者、小团队、内部工具,其实已经够用了。

尤其是你不是在做一个正式交付项目,而只是想先验证想法。

这时候最重要的是:页面能不能跑起来,结构是不是对,数据能不能接,状态有没有漏,后面能不能继续改。

Figma 在这里不是没用,只是它不一定是第一步。

但只要项目从“自己做着玩”进入“要交付给别人”,情况就完全不一样了。

02

-MaxKing.cc-

但只要进入交付,问题就变了

一旦进入真实项目,情况就不一样了。

因为真实项目不是你自己觉得差不多就结束。

老板要看。

客户要看。

团队要看。

前端要知道还原哪一版。

后面修改时,还要知道到底改了哪里。

这个时候,“感觉差不多”就不够了。

比如老板看了一个设计方向,说:

这个可以,就按这个做。

那前端最后做出来,不能完全变成另一个东西。

如果老板确认的是 A,最后页面落地像 B,中间就很难交代。

你不能说:

AI 觉得这样也挺好。

这在自己玩的时候可以,但在交付项目里不行。

交付项目里,设计结果需要被确认。确认之后,代码实现需要尽量还原。后面有修改,也要能说清楚改了哪里、为什么改、客户确认的是哪个版本。

Figma 不一定负责“创造”,但它很适合负责“确认”。

说到这里,就绕不开这两年很火的 vibe design。

03

-MaxKing.cc-

vibe design 适合探索方向,不适合直接交付

有人说,AI 时代应该打开格局,不要还停留在传统组件库、传统设计稿这种思路。

这个观点我理解。

AI 确实让 UI 表达更自由了。Canvas、3D、大屏、动态界面,都可以更快做出来。很多以前要设计师慢慢画的东西,现在 AI 很快就能给你一个方向。

这种 vibe design 很适合探索。

但探索和交付是两件事。

我现在会这样区分

探索阶段可以自由一点,先看感觉、方向、整体氛围,看有没有新的可能性。

交付阶段必须收敛,要能确认版本、还原模块、补齐状态、处理移动端、保证后续维护。

我的结论vibe design 适合探索方向,Figma 更适合在交付阶段做确认和对齐。

如果这些不收敛,后面就很容易变成:图很好看,代码不像;老板说不是这个感觉;客户说之前不是这样;前端说这里没法还原;最后大家一起返工。

所以我觉得,vibe design 和 Figma 不是对立关系。

它们只是处在不同阶段。

04

-MaxKing.cc-

Figma 在 AI UI 工作流里,应该放在哪?

我现在不会把 Figma 放在最前面。

也不会把它当成每次都必须经过的中转站。

我更愿意把它放在“确认层”。

UI Spec

视觉参考

Figma 确认 / 协作

Codex / Cursor 实现

截图修正

不是每个项目都必须走这一步。

但只要项目涉及别人确认,Figma 就很有用。

Figma 在交付里主要解决 4 件事

确认版本老板或客户到底确认的是哪一版,不要只靠聊天记录里的一张截图。

标注细节间距、字号、组件状态、交互说明,这些在 Figma 里更容易统一表达。

团队协作设计师、前端、产品、老板,大家至少看的是同一个页面。

减少扯皮效果不对时,可以回到确认稿判断:是设计稿没说清,还是实现偏了。

这就是 Figma 的价值。

不是为了显得流程专业,而是为了让交付过程有依据。

05

-MaxKing.cc-

我现在怎么判断要不要进 Figma?

如果是我自己做页面,我一般会这样判断。

可以先不进 Figma 的情况

个人项目。

临时 demo。

内部工具。

页面结构简单。

你自己就是最终决策人。

只需要快速验证一个功能。

这种情况下,直接用 UI Spec → 参考图 → 代码实现 → 截图修正,就可以。

但有些场景,我会建议进 Figma。

建议进 Figma 的情况

老板要确认。

客户要确认。

设计师和前端分工。

页面还原度要求高。

后面要长期维护。

需要沉淀组件规范或设计系统。

这种情况下,如果完全跳过 Figma,只靠 AI 出图和代码截图沟通,很容易出问题。

自己用,可以轻一点。交付别人,要正式一点。

这里的“正式”,不一定是流程复杂。

而是要有一个大家都认的确认稿。

06

-MaxKing.cc-

不要把 Figma 当成万能中转站

最后还有一点我想提醒。

Figma 有价值,但不要把它神化。

不是所有 AI UI 流程都要变成:

AI 出图

转 Figma

Figma 再转代码

这条路看起来完整,但里面有很多信息损耗。

AI 生成的是一张视觉图。转成 Figma 时,工具要猜图层。再从 Figma 到代码时,工具又要猜组件。最后进入真实项目,还要重新补状态、数据、响应式、接口。

如果 Figma 文件本身不是结构化设计稿,只是一个“从图片转出来的图层快照”,那它对落地帮助有限。

不要为了进 Figma 而进 Figma。Figma 应该承接一个已经相对清楚的结构。

也就是说,前面还是要有 UI Spec。

页面目标、模块结构、组件边界、状态、响应式,这些要先想清楚。

Figma 负责把这些东西变成可以确认和协作的设计稿,而不是替你补所有产品结构。

07

-MaxKing.cc-

我的结论

所以,AI 时代还要不要用 Figma?

我的答案是:

看你是不是要交付给别人。

自己做 demo,不一定非要先进 Figma。

但只要要给老板、客户、团队确认,Figma 依然很重要。

它不是古法。

它是交付过程里的确认层。

AI 可以帮你更快探索方向。Codex / Cursor 可以帮你更快实现页面。截图闭环可以帮你更快修正偏差。

但正式交付时,总要有一个大家都认的版本。

这个版本需要被确认、被标注、被讨论、被追踪。

这就是 Figma 现在仍然有价值的地方。

模板、Prompt 和示例领取

我把这套 AI UI 工作流里的模板、Prompt 和示例整理成了一份资料包。

进入公众号后台,私信我,发送关键词【UI工作流】,即可领取资料和示例。

下一篇预告

下一篇我会继续聊:image-to-code 不是没用,但我现在不会把它当主路径。

- END -

关于 MaxKing宝藏

我是 MaxKing,全栈开发者、量化交易实践者,也是 AI 重度用户。这里分享的不是遥远概念,而是我在真实使用、搭建和踩坑后留下的判断。

如果你想交流 AI 工具、个人知识库或自动化工作流,请查看公众号菜单栏「联系我」获取更多联系方式。