从怀疑到依赖：大语言模型如何革新设计师工作流程？

曾经对大语言模型持怀疑态度很长一段时间Edwin Morris 对大语言模型LLMs持怀疑态度每次使用结果都让他失望。去年他用 Copilot 和 Cursor 调整自己开发的游戏它们都没能生成可用的修改方案。之前工作中他尝试用 Gemini 撰写产品简介和生成线框图最后也弃之不用。每次用大语言模型处理的都是他擅长的事情但它们的表现还不如他自己。加入 Jane Street 后情况改变去年夏天加入 Jane Street 后Edwin 发现 AI 支持不可或缺。有太多新东西要学还有很多技能不熟练比如 OCaml 和 Bonsai。但让他惊喜的是AI 极大地改变了他最擅长的设计工作流程。新的设计工作流程现在Edwin 不再辛苦地撰写规格文档、制作 Figma 原型、撰写提案然后和开发人员一起审核实现情况而是直接构建能实现想法的原型功能。具体做法如下1. 写下问题描述和解决方案建议2. 打开编辑器启动构建、服务器和 Claude将之前写的描述作为提示输入3. 实现基本功能证明方案可行4. 按需对功能进行迭代5. 将更改推送到开发环境询问用户的意见6. 提交一个功能请求让功能的外观和行为完全符合预期。新流程的优势与原型和文档相比在实际代码库中构建原型功能在各方面都更出色。比如他最近做的一个原型为 JSQL 输入框添加了大语言模型提示功能。这个原型切实可用他花了好几天时间使用和测试它。Claude 让他可以自由、无限制地进行迭代即使改变主意 50 次或者要求进行小调整它也不会受影响。他优化了提交按钮添加了键盘快捷键调整了文案优化了提示信息还添加了生成的确认消息。在他之前的工作中这些工作流程的改进可能需要工程和设计团队来回沟通数天或数周甚至可能根本无法实现。工作流程的转变过程Edwin 花了一段时间才形成这个工作流程。去年夏天刚加入公司时他只用 AI 处理较小的任务比如修复用户体验方面的小问题。对于较大的想法他还是使用 Figma 和文档用 Claude 尝试时也失败了。但在过去两个月里他使用 Figma 的情况大幅减少。由于模型的改进、他对它们的熟练运用以及对任务范围的合理选择现在 AI 也能处理大型任务了——不仅是 JSQL 提示功能还有其他半打左右的原型涉及面向用户的功能、数据模型和库的更改有些甚至有 2000 多行的代码差异他用它为全新的应用程序实现交互式原型在 Figma 中完成设计后直接使用对于一些新应用他甚至完全跳过 Figma直接用 Claude 从一开始就进行视觉设计迭代。新工作流程的影响与担忧作为一名设计师这让 Edwin 感到充满力量。工程师有想法时可以创建可行的概念验证而设计师则需要说服别人为他们实现。通过使用 Claude 将想法变为现实他让其他人更容易评估它们——可以直接使用。但这种工作流程也有缺点审核人员拿到的是一个完全成熟的功能。这是否意味着他们对功能没有任何发言权只是审核代码呢审核并不是最有趣的工作在设计领域这就相当于从产品经理那里拿到详细的线框图然后被要求把它做得更美观。他希望尽可能清晰、完整地提出建议但仍然希望工程团队成员像对待 Figma 中的原型一样对待它把它当作可以一起在设计层面进行迭代的东西。目前他们的解决方案是换个角度看待这些功能。他在描述中写了一个简短的提醒原型是动态的提案文档代码是可丢弃的审核人员的工作是对设计和用户体验提供反馈。最终审核人员仍然会接手这个想法并在单独的功能中实现它参考原型但负责生产代码。实际上他们仍在探索这种新工作流程中哪些做法是合理且令人满意的。此外Edwin 还有一个担忧就是用 Claude 进行设计会让他无法保持流畅、有创意的思维而陷入迭代式的思维模式局限于他认为 Claude 能实现的结果。对于成熟的工具来说这种迭代式的改变没问题但在处理新事物时可能会让他错过一些想法。过往经历对比2011 年 Edwin 刚开始从事专业设计工作时有很多关于设计师是否应该编码的讨论。批评者认为一旦开始编程就不太可能对想法进行重大改变。但他喜欢制作网站也喜欢编程所以他继续编写代码。后来像 React 这样的前端框架变得普遍前端开发变得更加复杂和其他人一样他决定专注于设计。他仍然会用 React 做一些个人项目这确实有助于他与开发人员交流但他在工作中几乎所有时间都花在了 Figma 和文档上。如果在大语言模型出现之前加入 Jane Street他想他会更依赖 Figma。至少他对 JavaScript 还有一些经验而 OCaml 和 Bonsai 对他来说完全陌生从技术层面做出贡献会让他觉得遥不可及。相反现在他又开始制作实际的产品再次在实际环境中工作让他感觉棒极了。他感觉比以往任何时候都更自由可以大胆尝试。