我现在用 Claude 设计多于 Figma

背景

作者曾长期对大型语言模型（LLMs）持怀疑态度。在过去的工作中，无论是使用 Copilot 和 Cursor 来调整游戏代码，还是利用 Gemini 生成产品简报和线框图，结果往往不尽如人意，甚至不得不全部丢弃。这种挫败感主要源于作者试图让 AI 处理其原本就擅长的任务，而 AI 的表现反而不如人工。

然而，今年夏天作者加入 Jane Street 后，情况发生了转变。面对 OCaml 和 Bonsai 等全新且陌生的技术栈，AI 支持变得不可或缺。更令人惊讶的是，AI 不仅帮助作者克服了技术短板，更深刻地改变了其最擅长的领域——设计工作流。

核心内容

作者详细阐述了自己如何从依赖 Figma 和文档的传统设计流程，转变为以 Claude 为核心构建可运行原型的新工作流。

1. 新工作流的具体实践 传统的流程包括撰写规格文档、在 Figma 中制作高保真原型、编写提案以及与开发人员反复评审实现细节。现在，作者直接通过代码构建原型，具体步骤如下：

• 撰写描述问题和提案的文本。
• 打开编辑器，启动构建、服务器和 Claude，并将上述描述作为提示词（Prompt）。
• 快速实现基本功能，以验证可行性。
• 根据需要无限次迭代修改。
• 将更改推送到开发环境，直接向用户收集反馈。
• 提交一个在外观和行为上完全符合预期的功能特性（类似于 Pull Request）。

2. 原型优于线框图的优势 在真实代码库中构建原型带来了多方面的提升。作者分享了一个近期案例：为内部 SQL 方言 JSQL 的输入框添加 LLM 提示功能。

• 无限迭代：Claude 提供了免费且无限的迭代机会，无论作者如何改变主意或进行微调，AI 都能即时响应。
• 细节打磨：作者得以优化提交按钮、添加键盘快捷键、调整文案、调整提示词以及生成确认消息。
• 效率对比：这些工作若在过去，可能需要数天甚至数周的工程与设计来回沟通，甚至根本不会发生。
• 精力聚焦：所有精力都投入到了改进最终产物上，而非消耗在创建 Figma 组件或格式化文档等辅助性工作中。

3. 适用范围的扩展 起初，作者仅在处理小型任务（如 UX 小修补）时使用 AI。但在过去两个月里，随着模型能力的提升、作者自身熟练度的增加以及对范围（Scope）的精准把控，AI 已成功应用于大型功能开发。

• 除了 JSQL 提示功能外，还开发了其他六个涉及用户界面、数据模型和库变更的原型，其中部分代码变更超过 2000 行。
• 对于全新应用，作者甚至完全跳过 Figma，直接从设计初期就利用 Claude 进行视觉设计的迭代。

4. 设计师的赋权与挑战

• 赋权：工程师拥有将想法转化为概念验证（Proof of Concept）的能力，而设计师过去必须说服他人代为实现。通过 Claude，作者能将模糊的想法（如 JSQL 输入中的直接 LLM 提示）变为可实际使用的原型，极大地降低了他人评估想法可行性的门槛。
• 评审困境：这种工作流带来了一个新问题：评审者面对的是一个“完全成熟”的功能。这可能导致评审者丧失对功能设计的输入权，仅进行代码审查。这类似于产品经理给出详细线框图后，设计师仅负责美化，缺乏共同探索设计空间的机会。
• 应对策略：团队目前将原型视为“活体提案文档”，代码是可丢弃的。评审者的职责是提供关于设计和用户体验的反馈。最终，工程团队仍会接管该想法，在独立的功能分支中实现生产级代码，但会参考原型。

5. 对创造性思维的担忧 作者担心依赖 Claude 进行设计会将自己限制在“迭代思维”中，而非“流体创造性思维”。由于受限于 AI 能产生的结果，可能会错过全新的创意灵感。这种张力在 2011 年关于“设计师是否应该编程”的讨论中也曾出现过，当时批评者认为编程会限制对想法的大幅修改。

6. 回归本质的自由感 如果作者在没有 LLM 的情况下加入 Jane Street，可能会因不熟悉 OCaml 和 Bonsai 而更加局限于 Figma。现在，作者重新回到了“制作真实事物”的状态，感觉比以往任何时候都更自由，能够毫无顾忌地尝试各种想法。

关键要点

• 工作流范式转移：从“文档+线框图”转向“代码原型”。AI（如 Claude）使得设计师能够直接构建可运行的功能原型，而非静态的高保真图。
• 降低沟通成本：传统流程中，设计意图需要通过文档和反复沟通传达给工程师。新流程中，原型即文档，用户可直接体验，减少了误解和返工。
• 无限迭代与细节优化：AI 支持的低成本迭代允许设计师深入打磨交互细节（如快捷键、文案、反馈消息），这些细节在传统流程中常因成本过高而被忽略。
• 设计师的技术赋权：对于不熟悉特定技术栈（如 OCaml）的设计师，AI 填补了技术鸿沟，使其能够独立验证想法的可行性，无需依赖工程师的资源。
• 评审角色的重构：评审重点从“代码正确性”回归到“设计与用户体验”。需要明确区分“原型”（用于探索反馈）和“生产代码”（用于最终交付），避免评审者陷入被动接受。
• 创造性与迭代性的平衡：虽然 AI 提高了效率，但也存在将设计思维局限在“微调”而非“颠覆性创新”的风险。设计师需警惕被 AI 的能力边界所束缚。
• 工具适应性的动态变化：随着模型能力提升和使用者熟练度增加，AI 的应用范围可从简单的 UX 修补扩展至复杂的业务逻辑和界面实现，甚至完全替代传统设计工具。

意义与影响

这篇文章揭示了 AI 时代下设计角色和工作流的深刻变革。它表明，LLMs 不仅仅是一个辅助编码的工具，更是弥合设计意图与工程实现之间鸿沟的桥梁。

对于设计师而言，这意味着职业竞争力的重新定义。单纯产出视觉稿的价值可能在下降，而通过 AI 快速验证概念、深入交互细节以及理解技术可行性的能力变得至关重要。设计师正在从“视觉传达者”转变为“产品构建者”。

对于工程团队而言，这种变化要求调整协作模式。评审者需要适应从“代码审查”到“设计反馈”的角色转换，并理解原型代码的临时性。同时，这也提高了对设计提案清晰度的要求，因为任何模糊性都会直接体现在可运行的代码中。

对于产品设计方法论而言，传统的“设计-开发”串行流程正在被“设计-原型-反馈”的敏捷循环所取代。这种转变不仅加速了迭代速度，更重要的是，它让设计决策基于真实的用户反馈而非假设，从而可能创造出更符合用户需求的产品。然而，这也提醒行业需要关注过度依赖 AI 迭代可能带来的创新惰性，保持对突破性创意的追求。