AI 正在改写设计团队的评审与学习制度

10 月 10 日，设计协作平台 Figma 发布文章，整理了 Figma、Sephora、Mercari 和 Atlassian 四家公司推动团队使用 AI 的四个案例。四家公司分别调整了内部培训、经验分享、跨专业协作和设计评审，希望把少数人的 AI 使用经验转化为团队共同具备的工作能力。

这些案例都基于一个现实。AI 最先改善的是个人生产效率。熟练使用工具的设计师可以迅速制作原型，开发者也能生成过去需要设计参与的界面。但个人完成得更快，并不代表团队已经能够理解、复用和检验这些成果。当成员掌握程度不同，制作过程又难以追溯时，完成度较高的结果反而容易掩盖判断依据。AI 扩大了个人的工作范围，原有的培训与评审制度却仍然建立在相对稳定的专业分工之上。

Figma 首先处理的是内部设计师之间的能力差异。Figma 不仅是一款设计软件，也拥有自己的产品设计团队。负责设计运营的 Jake Geller 发现，团队成员对 AI 的熟悉程度并不一致。有人已经用 Figma Make 制作原型或尝试开发插件，也有人尚未形成稳定的使用方法。统一安排一次大型培训，只能介绍工具功能，很难覆盖成员各自面对的问题。

他由此发起名为 AI Collective 的内部试点。团队先收集设计师希望学习的内容，再将参与者分成五个小组，每组围绕一项能力展开，例如使用生成工具制作原型、编写插件或接触代码。小组每周活动一小时，连续进行六周，并通过 Slack 延续讨论。建议的活动结构是二十分钟讲解，四十分钟实践。

这项工作并不是为了让所有设计师掌握同样的工具，而是把学习从一次性的功能讲解改为围绕实际任务展开的持续练习。AI 工具更新很快，个人使用方法又高度依赖具体工作，团队很难依靠一份统一教程建立共同能力。小组学习提供的是同伴支持、问题反馈和可复用的实践过程，解决的是成员“如何真正开始使用”，而不只是“是否知道工具存在”。

全球美妆零售商 Sephora 面对的不是设计师培训，而是企业内部的经验传播。该公司的技术高级副总裁 Sneha Narahalli 定期组织双周论坛，让不同岗位的产品建设者分享他们使用 AI 完成的工作或个人项目。这里的参与者并不限于设计师，也包括技术人员和其他参与产品建设的成员。

论坛最初只展示完成度较高的成果。分享者呈现一个已经运行的应用、一套自动化流程或一项成熟的实验，却很少解释中间经历了什么。缺乏经验的成员虽然看到了结果，仍然不知道应该从哪里开始，甚至会因为他人的成果过于完整而感到难以参与。

Sephora 随后改变了分享方式。展示者不仅要说明最终做成了什么，也要介绍尝试过哪些方法、哪些方法没有奏效，以及如何调整。变化看似只是增加了过程说明，实际改变了团队能够积累的知识类型。最终成果只能证明某种方法在特定条件下成功过，失败过程才能帮助其他成员识别限制、减少重复试错。对生成式工具而言，后者尤其重要，因为同一套提示或流程更换模型、数据和任务后，结果可能完全不同。

Mercari 的案例涉及另一种问题。Mercari 是起源于日本的二手交易平台，文章介绍的是其首席设计师 Aki Alkhatib 所在团队的实践。AI 让设计师能够接触代码，也让开发者可以直接生成界面，原有的岗位边界因此变得松动。但工具降低的是执行门槛，并不会让人自动获得另一个专业领域的判断能力。

Mercari 为此安排跨专业训练。设计师学习工程基础，尝试编写代码、使用 AI 编程工具和建立 GitHub 仓库；开发者则学习视觉层级等设计原则。目的不是把设计师培养成工程师，也不是让开发者取代设计师，而是让双方能够利用 AI 完成相邻领域的初步工作，并理解这些结果应当接受什么标准的检查。

一名开发者可以利用生成工具制作基础界面，再运用视觉层级知识改善信息重点，随后交给设计师审查。设计师也可以修改代码或建立简单原型，再由工程人员检查性能、结构和维护问题。AI 允许工作的起点来自更多岗位，但最终质量仍然依赖专业人员的判断。跨专业训练改变的是协作接口，而不是取消专业分工。

企业协作软件公司 Atlassian 调整的则是设计评审。该公司的首席设计官 Charlie Sutton 发现，团队开始使用 AI 原型工具以后，设计师仍然习惯先花较长时间讲解背景、目标和方案逻辑，直到评审后段才展示原型，有时甚至没有可以直接操作的版本。原型已经更容易制作，评审顺序却没有随之改变。

Atlassian 因而要求设计师在评审开始时先提供可点击原型，让参与者直接操作，再解释研究背景与设计依据。过去团队只能根据页面和口头描述想象交互过程，现在可以更早检查流程是否连贯、反馈是否清楚，以及设计在实际操作中是否符合预期。要求每次评审都带来原型，也迫使成员持续练习使用新的制作工具。

这种方法仍有明显边界。完成度较高的原型容易让人产生方案已经接近成立的印象，团队可能过早围绕现有实现讨论细节，而忽略问题定义是否准确。先体验原型有助于暴露交互问题，却不能替代用户研究、业务条件和设计理由。合理的评审不是让原型压过依据，而是需要检验两件事：方案在操作层面能否成立，以及它是否回答了正确的问题。

四个案例分别位于团队工作的不同环节。Figma 处理成员如何学习，Sephora 处理个人经验如何成为组织知识，Mercari 处理专业边界松动后的协作质量，Atlassian 处理原型生产加快后的评审方式。它们并非一套可以直接复制的管理方案，却共同指向了 AI 进入团队后出现的新瓶颈。制作结果正在变得容易，理解过程、传播经验和建立共同判断并没有因此同步发生。

对设计团队而言，今后的评审对象也不能只有最终界面。团队还需要了解方案由哪些资料和约束生成，设计师接受或放弃过哪些方向，哪些部分经过用户验证，哪些部分只是模型提供的暂时答案。如果生成过程始终停留在个人对话窗口中，团队看到的就只有一个表面完整的结果，既无法复盘其中的判断，也很难把经验用于下一次工作中。