很长一段时间以来，我对大模型（LLMs）持怀疑态度——每当我使用它们时，总是对结果感到失望。去年，我尝试使用Copilot和Cursor调整我构建的一个游戏，但它们都没有生成有效的更改。在之前的工作中，我试过使用Gemini来概述产品简报和生成线框图，结果却把它们全扔掉了。每次我尝试LLMs时，都是在我已经擅长的领域，而它们的表现都不如我好。今年夏天我加入了Jane Street，并发现AI的支持是不可或缺的。对我来说，有太多新的东西，很多方面我还不擅长，比如OCaml和Bonsai 。但一个很大的惊喜是它改变了我最擅长的事情：我的设计工作流程。我不再辛苦撰写规格文档、构建Figma模型、撰写提案并与开发人员审查实现，而是能轻松地构建出精确符合我想法的原型特性。在实践中，这样的流程看起来是：写下描述问题和我的提案，打开编辑器，启动构建、服务器和Claude，用我写的描述作为提示，确保基本功能正常运作以证明这是可能的，尽情迭代，推送更改到开发环境，询问用户的看法，提交一个我想要的样子和行为的特性（我们版本的拉取请求）。与模型和文档相比，实际代码库中的原型特性在几乎每一方面都感觉更好。想想我最近制作的一个原型，它为JSQL输入（JSQL是我们用于各种用户界面工具的内部SQL方言）添加了LLM提示。这个原型真的有效，我花了几天时间与它相处并进行测试。Claude给了我无限的迭代空间，即使我第50次改变主意或要求小调整，它也从不介意。我精细调整了提交按钮，添加了键盘快捷键，修改了文案，调整了提示，并添加了生成的确认消息。这些是工作流程的改进，在我之前的工作中，完成这些事情需要几天或几周的工程和设计反复，或者更可能根本不会发生。投入这个特性的所有精力都用于改善真实的工件，而没有任何的中间工作，比如创建Figma组件或格式化文档。到我达到这种工作流程花了一段时间。去年夏天加入时，我只用AI处理较小的任务，比如用户体验小问题修复。对于更大的想法，我仍在使用Figma和文档，当我尝试用Claude来制作这些东西时，它会失败。但在过去的两个月里，我使用Figma的情况大幅减少。通过一些改进模型的组合，我对它们的掌握，以及仔细选择合适的范围，AI现在也能处理大规模的项目——不仅是JSQL提示，还有半打其他原型，这些原型涉及用户界面、数据模型和库的更改，甚至包括一些2000多行的差异；我正在用它为全新应用实现互动原型，先在Figma中设计，然后对一些新应用我甚至完全跳过Figma，从一开始就用Claude迭代视觉设计。作为设计师，这让我感到很受鼓舞。工程师在有想法时可以创建工作概念证明，而设计师必须说服其他人帮我们做到这一点。像“在JSQL输入中直接进行LLM提示”这样的想法，我所提出的可行性在一开始就不清晰；让别人来构建原型可能浪费他们的时间。在其他情况下，我可能提议的东西并不能明确满足用户需求。通过使用Claude来实现这些想法，我让其他人更容易评估它们——他们可以直接使用它。但也有一个缺点：在这个工作流程中，审查者得到了一个完全成型的特性。这是否意味着他们对功能没有任何输入，只是被要求审查代码？审查不是最有趣的工作——在设计界，相当于从项目经理那里得到一个详细的线框图，然后被要求让它看起来好看。我希望我的提案尽可能清晰和完整，但我仍希望我的工程团队以对待Figma模型的态度来对待它，把它当作是我们可以一起在设计空间中迭代的东西。我们现在的解决方案是重新思考这些特性。我在描述中写下简短的提醒：原型是活文档，代码是可丢弃的，审查者的工作是提供关于设计和用户体验的反馈。最终，审查者仍然会接手这个想法，并在一个单独的特性中实现它，参考原型但拥有生产代码。实际上，我们还在摸索什么才是合理的、让人感觉良好的新工作流程。我还有一个担忧：与Claude设计让我远离灵活的创造性思维，陷入迭代的思维中，被限制于我所得到的结果。