传统设计师的工作依赖 Figma 画原型、写文档，再找工程师实现。Jane Street 的一位设计师最近在博客分享了一种完全不同的方式：直接用 Claude Code 写代码，把脑子里想的功能做成可运行的原型，比 Figma 稿更高效。
从画图到写代码
这位设计师入职 Jane Street 前对 AI 持怀疑态度——之前试过 Copilot、Cursor、Gemini，都没能产生可用结果，原因是拿 AI 去做了自己本来就能做好的事。
真正改变想法的是两件事：第一，工作中要学 OCaml 和 Bonsai（公司内部技术栈），有太多新东西需要 AI 帮忙；第二，用 AI 做小修小改时发现效果不错，于是开始尝试更大的任务。
现在的典型流程是：先写一段描述问题和方案的文字，然后用这段文字作为提示词启动 Claude Code，边开发边迭代验证功能，把结果推到测试环境让用户直接试用，最后提交一个「特性分支」——整个过程完全跳过了 Figma。
一个具体例子是给内部 SQL 工具（JSQL）增加 LLM 提示功能。他花了好几天反复调整提交按钮、添加快捷键、修改文案、改进提示词，这些改动如果走传统流程，需要和工程师反复沟通、排队等排期，很可能根本不会发生。「AI 给了我无限的免费迭代机会，」他写道，「就算我改了 50 次主意它也不会烦。」
这套方法的真实代价
不过他坦承存在明显问题：审阅者拿到的是一个已经「做完了」的功能，相当于别人把详细线框图甩给设计师说「你把它美化一下」。他希望能保留共同迭代的空间，而不是让 AI 替他把探索阶段也走完了。
目前的解法是在提交描述里写清楚：原型是活的提案文档，代码是临时的，审阅者的职责是给产品和体验提意见，最终还是会另开分支由工程师重新实现。但这仍在探索阶段，什么样的协作方式最顺畅还不确定。
另一个更隐蔽的担忧是：用 AI 写代码容易让人困在「迭代思维」里，总是在优化已知可行的方案，而不是去寻找全新的解法。他把这比作 2011 年设计师学代码的讨论——当时也有人担心写代码会让设计师不敢大改想法。他的态度是：确实有这种风险，但比起担心，不如先动手，同时保持对自己创作状态的警觉。
编注：作者为 Jane Street 内部工具设计师，经验来自 OCaml/Bonsai 环境，样本为单一公司场景；正文未涉及 Figma 在团队协作中的其他用途。