一个设计师把 Figma 用得越来越少了 🤔 他改用 Claude Code,直接在代码里画原型。
写这事的人叫 Edwin Morris,在 Jane Street 做产品设计——就是那家以 OCaml 出名、对工程要求高到离谱的量化公司,他去年夏天才入职,在期权台。
先说他原来的做法。要做一个功能,流程很固定:写需求文档,在 Figma 里把高保真稿一点点搭出来,写提案,再拉着工程师一起 review 实现。问题就出在这条链上——设计稿交出去,是静态的图;工程师照着实现,中间总有理解的缝隙,做出来常常跟脑子里想的不是一回事。每改一版都要等上好几天:你得排进工程师的时间,他做完你再看,看完再提,提完再等下一轮。设计和工程之间那道墙,特别厚。
现在换了个活法 ⚡ 他把要解决的问题描述清楚,打开编辑器和 Claude,直接在真实代码里一版一版迭代原型,推到开发环境,收用户反馈,最后交上去的是一个已经能跑的完整功能——不是一张图,是能用的东西。设计稿和实现之间那条缝,被直接焊死了。
有几个细节挺能说明问题。他给公司内部那套叫 JSQL 的 SQL 方言做了个 LLM 提示功能;为了写这些,他靠 Claude 边做边把 OCaml 和 Bonsai 框架学了。这一点别轻轻放过——OCaml 是出了名难啃的函数式语言,Bonsai 又是 Jane Street 自家那套硬核前端框架,放在以前,一个设计师根本碰不到这层,得整个翻译成需求再丢给工程师。现在他能自己探到这一层了。他做的原型,小到一个交互上的细节修正,大到两千多行的 diff 都有。用他自己的话说,Claude 给了他「免费的、无限次的迭代,我改第五十遍主意它也不嫌烦」。那些以前要磨好几天甚至几周的细节,现在几个小时就走一遍。
我读下来最大的感受是,变的其实是「设计师」这个角色本身。过去设计师的产出是「描述」——一份规格、一张稿,真正落地交给会写代码的人;现在这条分工线在模糊。当一个设计师能自己探到 JSQL、OCaml 这种层面,他交付的就不再是一份让别人去实现的说明书,而是直接能进生产的东西。Claude 没把他变成工程师,但把那道「我只能想、不能做」的门槛拆掉了一大半。这是好事,也是这篇文章真正的张力所在。
因为他没把这篇写成吹稿,这正是我觉得它值得看的地方 👀 他老老实实摆出了两个代价。
一个是想象力的问题。跟着 Claude 一版一版往下改,思路会不会被「能实现的东西」悄悄框住?设计本该先发散、再收敛——可当生成原型的成本低到几秒钟,你很容易直接跳到「能跑通」的那一版。你能想到的方案,慢慢只剩下 AI 容易帮你做出来的那一类,边界是被工具的能力划的,不是被你的想象力划的。最危险的不是它做不出某个方案,而是你压根没去想那个方案——因为手边这条路太顺了,顺到你忘了停下来问一句「有没有更好的做法」。便宜的迭代会奖励「快速试错」,但有些设计上的好东西,是要先慢下来空想出来的。
另一个更微妙。当他交上去的已经是个成形的功能,同事在设计决策上还插得进话吗?一张草图,大家会七嘴八舌改;一个能跑的成品,很多人第一反应是「都做出来了就这样吧」。东西越完整,讨论和 review 的空间反而越小,沉没成本越高,大家越不好意思让你推翻重做。他还顺手翻出那个老问题——设计师到底该不该写代码。
我的看法是:直接在代码里做设计,省掉 Figma 到工程之间那道反复横跳的墙,快是真的快 🚀 但「原型即成品」也意味着,讨论发生得更晚、更少;等东西已经做出来,再想推翻重来,成本和心理门槛都高了一截。摩擦被工具抹到几乎没有的时候,值得回头看一眼:被抹掉的那部分摩擦里,有没有本来就该留着、对最终结果其实有用的东西?
转给那个还在 Figma 里画一周才出一版的设计师朋友。
来源 · 评论区取 ↓
关注 @svtransit1 · 写给真在用 AI 的人
#AI #ClaudeCode #AI工具 #AI编程
原始来源：https://blog.janestreet.com/i-design-with-claude-code-more-than-figma-now-index/
关注 @svtransit1 · 每 3 小时一篇 AI 前线 · RSS