Jane Street 一名设计师最近写了一篇很有意思的博客：他现在做设计，用 Claude Code 的时间已经多过 Figma。

这句话容易被误读。它不是 Jane Street 官方宣布弃用 Figma，也不是 AI 已经能替代设计师和工程师。更准确的说法是：在一部分产品设计工作里，评审对象正在变。

过去是图、文档、线框图。现在可能是一段跑在真实代码库里的功能。

我更在意的是这个变化背后的问题：当设计师能先做出一个可试用版本，团队到底是在更快验证想法，还是更早把设计锁死？

变化不在工具名，而在评审对象

这位设计师并不是一开始就相信 LLM。

他提到，自己过去用过 GitHub Copilot、Cursor，也试过让 Gemini 写产品 brief、生成线框图。结果都不理想。原因很简单：那些任务他本来就熟，AI 给出的东西反而不如自己做。

转折发生在加入 Jane Street 之后。

Jane Street 长期使用 OCaml，前端体系里也有 Bonsai 这类并不常见的工具。对一个新加入的设计师来说，这些都不是顺手就能上手的技术栈。Claude Code 在这里的价值，不是替他做熟悉的事，而是帮他进入陌生代码库。

这点很关键。

AI 在你擅长的任务上表现一般，你会觉得它碍手碍脚。但在你不熟的领域，它可能变成脚手架：帮你找组件、读结构、改一点、跑一下，再继续试。

他举的核心案例，是给 Jane Street 内部的 JSQL 输入框加入 LLM prompt 能力。JSQL 是 Jane Street 内部使用的 SQL 方言，服务多个面向用户的工具。

这个设计不是停在 Figma 画面里。作者用 Claude Code 在真实环境中做出原型，连续几天试用，再调整 Submit 按钮、快捷键、文案、prompt，以及模型生成的确认信息。

这让设计评审从“你想象一下它会怎么用”，变成“你现在点一下试试”。

过去常见流程这次博客里的流程变化
Figma 画界面，文档解释逻辑Claude Code 直接改真实代码库评审对象从静态稿变成可运行原型
先说服工程师排原型设计师先做出能试的版本可行性验证提前
交互细节靠设计和工程来回沟通小改动可以边用边改微交互更容易被看见
交付物偏表达原型可放进开发环境试用反馈更接近真实使用

所以，Figma 在这里没有被“打败”。

真正被挑战的是一种默认流程：设计师先画，工程师再判断能不能做，用户最后才试到接近真实的东西。

对设计师有用，但前提是别把原型当生产代码

这类工作流最直接影响两类人：产品设计师，以及前端 / 产品工程团队。

对产品设计师来说，动作会变得更具体。以前要用图和语言争取工程时间，现在可以先做一个能点、能输、能报错的版本。尤其是内部工具、管理后台、数据产品这类场景，可运行原型比漂亮稿更能说明问题。

但这也意味着设计师要补一点新能力：会写可执行 prompt，能看懂基础代码结构，知道哪些改动只是原型，哪些已经碰到真实系统边界。

对前端和产品工程团队来说，重点不是阻止设计师碰代码，而是提前立规则。

哪些原型可以进开发环境？哪些必须完全重写？评审时看体验，还是顺手看实现？如果这些不讲清楚，AI 写得越快，团队越容易乱。

对象该怎么调整不能忽略的成本
产品设计师用 Claude Code 做低风险、可试用原型；把原型当 proposal，而不是交付物需要理解基础代码和系统边界
前端 / 产品工程团队约定原型准入、评审口径、重写规则避免实验代码混进生产资产
产品负责人用可运行原型做早期判断，而不是只看静态稿防止“能跑”被误判为“该做”

原文里最重要的边界，是 Jane Street 团队把这些原型定义成“活的 proposal doc”。

这个说法很克制，也很实用。

意思是：代码可以丢弃，评审重点是设计和用户体验。最终生产实现仍由工程师在另一个 feature 中接手，参考原型，但不直接把原型当生产代码。

这一条比“Claude 写了多少行代码”更重要。

作者提到过有些原型会产生 2000 行以上 diff，但这不能被当成普遍效率结论。大 diff 可能代表原型完整，也可能代表治理压力变大。没有代码评审、测试、权限和回滚机制托底，设计师直接提交大段改动，未必是进步。

Jane Street 的内部环境也不能直接外推。

它有成熟的工程文化，有内部用户场景，也有相对可控的试用环境。换到合规压力更重、发布链路更硬、设计和工程分工更割裂的公司，第一步不该是“让设计师都去写代码”，而是先划清实验边界。

最大风险不是代码质量，而是共创空间变窄

我不太买账的一种说法是：AI 原型越完整，设计协作就越高效。

事情没这么顺。

作者自己也提到，完整原型可能让评审者不知道该怎么参与。一个功能看起来已经差不多做完了，同事很容易只提小修小补，而不是重新讨论方案本身。

这和产品经理拿着一份细到按钮位置的 wireframe，让设计师“美化一下”很像。表面上是提高效率，实际可能把共同设计空间提前压扁。

还有一个更隐蔽的限制：设计师可能被 Claude 能产出的东西牵着走。

对成熟工具的小改动，这反而是优点。比如改输入框、加确认提示、调快捷键，能快速试错就够了。但对全新产品、复杂工作流、信息架构重做，过早进入代码层，可能会让团队错过更大的方案。

所以接下来该看的不是“Figma 会不会被替代”。这个问题太粗。

更值得看三件事：

  • 团队是否把 AI 原型和生产代码分开管理。
  • 设计评审是否仍保留开放讨论，而不是只验收一个已完成版本。
  • 设计师是否能在“快速做出来”和“重新想一遍”之间切换。

如果这三件事做不到，Claude Code 会让团队更快进入局部最优。能跑，能用，也能评审，但可能少了那一步真正改变方案的讨论。

回到开头那句话：一名 Jane Street 设计师更多用 Claude Code，而不是 Figma。

这不是设计工具的胜负表。它提醒的是，AI 编程工具已经开始进入产品设计的前半段。设计师不再只能拿图说服别人，工程师也不再只在最后接需求。

好处很实在：想法更快被使用和检验。

代价也很实在：团队必须重新保护评审、归属和共创空间。否则，原型越像成品，讨论越容易提前结束。