从Figma到Claude：Jane Street设计师的工程化原型工作流

设计工作流的范式转移

Jane Street 期权交易台设计师 Edwin Morris 近期分享了一个引人深思的转变：他使用 Claude 进行设计的时间已经超过了 Figma。这一变化并非简单的工具替换，而是设计工作流从 "静态表达" 向 "动态验证" 的根本性迁移。

传统设计流程中，设计师需要经历撰写需求文档、绘制 Figma 原型、与开发反复沟通、最终验收实现的漫长周期。而在 Jane Street 的新实践中，设计师直接在真实代码库中构建可运行的功能原型，通过自然语言描述需求，由 Claude 生成 OCaml 和 Bonsai 框架代码，实现从概念到可交互产品的无缝转换。

这种转变的核心价值在于：所有设计精力都投入到改进真实产品，而非消耗在 Figma 组件维护或文档格式化等 "中间工作" 上。

六步工作流的工程化实践

Jane Street 的设计 - 开发一体化工作流可归纳为六个关键步骤：

第一步：问题描述—— 用文字清晰描述待解决的问题和提案方案。这份描述既是设计思考的结晶，也是后续 Claude 会话的初始提示词。

第二步：环境启动—— 打开编辑器，启动构建服务和开发服务器，同时启动 Claude 会话，将问题描述作为输入提示。

第三步：可行性验证—— 快速实现基础功能，验证技术可行性。这一步的关键目标是 "证明这个想法可以实现"，而非追求完美实现。

第四步：无限迭代—— 在原型上进行任意次数的修改和优化。Morris 提到曾对一个功能进行了 50 多次调整，Claude 始终保持耐心响应，从不会因为频繁变更而降低质量。

第五步：用户验证—— 将变更推送到开发环境，邀请真实用户试用并收集反馈。由于用户面对的是可交互的真实功能，反馈质量远高于基于静态原型的假设性讨论。

第六步：正式提交—— 将最终版本作为 feature（Jane Street 内部的 PR 形式）提交，此时代码的外观和行为已经完全符合设计意图。

案例：JSQL 输入框的 50 次迭代

一个具体案例展示了这一工作流的效率优势。Morris 为内部 SQL 方言 JSQL 的输入框添加了 LLM 提示功能，这个原型涉及用户界面、数据模型和底层库的变更，最终产生了超过 2000 行的代码差异。

在传统流程中，这类变更需要经历：设计师绘制交互稿 → 撰写详细 PRD → 与工程师反复确认 → 开发实现 → 设计验收 → 可能的返工。而在 Claude 驱动的工作流中，设计师直接完成了从 Submit 按钮样式调整、键盘快捷键添加、文案优化、提示词调整到确认消息生成的全部迭代，"这些改进在以前的工作环境中可能需要数周的设计与开发来回，或者更可能的是根本不会发生"。

更重要的是，设计师能够在真实环境中 "生活" 数天，深度测试功能表现，这种验证深度是任何 Figma 原型都无法提供的。

原型标注规范与评审流程

这种工作流带来了一个独特的协作挑战：当评审者看到的是一个 "已经完成" 的功能原型，他们如何参与设计迭代？

Jane Street 的解决方案是建立明确的心理模型和标注规范：

原型即活文档—— 在 feature 描述中明确标注 "这是一个可丢弃的提案文档"，代码本身不是最终交付物，而是设计意图的可运行表达。

评审者的角色—— 评审者的任务是评估设计和用户体验，而非仅仅审查代码质量。这类似于评审 Figma 原型时的反馈方式。

代码所有权分离—— 最终的生产代码由工程师在独立 feature 中实现，参考原型但完全拥有代码所有权。这确保了原型代码的 "可丢弃性" 不会带来技术债务。

这种流程设计巧妙地平衡了设计探索的自由度与代码质量的保障，避免了 "原型直接上线" 可能带来的维护风险。

边界认知：何时不适合此工作流

Morris 坦诚地指出了这种工作流的局限性，这对希望借鉴的团队具有重要参考价值。

不适合从零到一的创意探索—— 当设计目标是探索全新产品的可能性空间时，Claude 驱动的迭代模式可能限制创造性思维。设计师容易被 "Claude 能做什么" 的隐性边界所约束，难以产生突破性的概念。这与 2011 年 "设计师是否应该写代码" 的争论形成呼应：一旦开始编码，大幅修改想法的心理成本会显著增加。

更适合成熟工具的优化迭代—— 当前实践最适用于已有明确方向的功能改进，而非颠覆性创新。

技术栈的学习曲线——Jane Street 使用 OCaml 和 Bonsai 框架，对于没有函数式编程背景的设计师而言，理解和引导 Claude 生成正确代码需要一定的学习投入。Morris 提到，如果没有 LLM 辅助，他在 Jane Street 的技术栈中贡献代码 "会感觉遥不可及"。

可落地实践清单

对于希望尝试类似工作流的团队，以下参数和要点可供参考：

技术准备

• 确保团队有可直接修改的代码库访问权限
• 建立快速本地构建和部署流程（缩短反馈循环）
• 准备技术栈相关的基础提示词模板

流程规范

• 建立原型标注模板，明确 "可丢弃" 属性
• 定义原型评审与代码评审的分离机制
• 设定原型代码规模上限（Jane Street 案例：2000 + 行 diff）

协作约定

• 设计师与工程师就 "原型即设计稿" 达成共识
• 建立从原型到生产实现的明确交接流程
• 保留 Figma 用于创意探索阶段的快速草图

适用性评估

• 优先在成熟产品的功能迭代中试点
• 避免在需要突破性创新的项目中完全依赖此模式
• 监控设计师的创造性产出是否受到工具能力边界的限制

结语

Jane Street 的实践揭示了一个重要趋势：LLM 正在模糊设计与工程的边界，让设计师能够直接操作 "真实材料"。这种转变不是要取代 Figma 在视觉探索和创意发散中的价值，而是为设计验证阶段提供了一种更高效、更真实的实现路径。

对于技术团队而言，关键在于建立清晰的边界认知 —— 何时使用 Claude 进行快速原型验证，何时回归 Figma 进行视觉探索，以及如何在两者之间建立顺畅的切换机制。最终目标是让设计师获得与工程师同等的 "构建能力"，同时保持设计思维的独立性和创造性。

参考来源

• Morris, E. (2025). "I design with Claude more than Figma now." Jane Street Tech Blog. https://blog.janestreet.com/i-design-with-claude-code-more-than-figma-now-index/
• Hacker News discussion (2025). "I design with Claude more than Figma now." https://news.ycombinator.com/

ai-systems