作者用两个月时间为设计团队搭建 AI 工作流，包括一套可复用的 Claude skill、一个共享文档空间、一个实行版本管理的 skill 仓库，以及一条从 Claude Design 到 Claude Code、可于即时生成在线链接的原型制作流水线。文章总结了已经落地的做法与仍待推进的工作，并指出主要难点不在技术本身，而在于文档、沟通、推广和工程资源协调等设计运营工作。

整个过程比预想的更加曲折、缓慢，也更多地取决于人的因素。

当经理让我研究设计团队如何在日常工作中更好地运用 AI 时，我满怀信心地接下了任务。如今回想，当时的自信恰恰源于对其中困难的一无所知。

我任职于 Tripadvisor 的 B2C 产品设计团队，职责是提升设计团队的工作效能：使流程更加顺畅，工具更加完善，并减少从构想到执行之间的阻力。AI 看起来理所当然是值得投入的方向。无论是行业会议上的演讲、LinkedIn 上的帖子，还是各类文章，传递的都是同一信息：要么采用 AI，要么落后于人。

然而，没有人告诉过我具体应当如何实施。我所指的并非理论，而是具体的过程：耗费数周撰写无人阅读的文档；召开工程会议，却无人能就“完成”的标准达成一致；在 Slack 上发布消息介绍新的工作流，此后便是等待，期望有人愿意尝试。

本文记述的正是这段经历。

图 1：首次工作坊的成果，主题为设计团队在工具方面的痛点。

坦率地说，整个工作始于我为设计团队组织的一场工作坊。我希望了解，在现行设计流程中，哪些环节真正让设计师感到困扰。结果有些在意料之中（重复性工作耗时过多，与工程团队之间的反复沟通过多），也有些出乎意料（团队成员实际上已在各自使用 AI 工具，但方式各不相同，彼此之间也没有任何经验共享）。

最后一点才是真正的发现：我们面临的是碎片化问题，而非 AI 问题。每个人都在默默地、独自地重复造轮子，且未与他人分享。

图 2：询问 5 位设计师使用何种工具制作原型，会得到 5 种不同的答案。

因此，我并未采购特定工具，也未强制推行某种工作流，而是决定搭建一套共享的基础设施：

• 一套可复用的 Claude skill：即沉淀了团队知识的结构化提示词，可为 Claude 提供必要的上下文，使其发挥切实作用，而不仅是提供泛泛的帮助。

• 一个任何人都能理解并遵照执行的共享文档空间。

• 一个共享代码仓库，用于对 skill 实行版本管理，以便持续改进、派生（fork）和妥善维护。

• 以及一条此前并不存在的原型制作流水线：设计师先在 Claude Design（Anthropic 推出的 AI 设计与原型工具）中将初步构想形成设计，再通过 Claude Code 构建可运行的版本，最终生成在线链接，当天即可分享给产品经理，或交由真实用户测试。整个过程无需提交工程工单，也无需等待。

理论上看似简单，实践中却远非如此。

进展顺利的方面：已切实落地的成果

最先获得认可的 skill 是 Project Bio Writer（项目简介生成器）。它可将初步的项目构想整理为结构化的简报、假设、描述和原始指标，并可在最后选择自动创建跟踪工单。我将其分享给团队后，同事们确实开始使用。虽然并非所有人都在使用，也并非一经推出便得到采用，但使用者已足够多，该 skill 也因此得以沿用。

图 3：一键从 PRD（产品需求文档）生成跟踪工单。Project Bio skill 可生成简报、假设、描述和原始指标，并自动同步至工单跟踪系统。

我认为，它之所以成功，在于它解决了一个具体且容易引起共鸣的痛点。所有人都厌烦撰写项目简报，但也都清楚这项工作必不可少。一个能使其既快速完成、又保证足够质量的 skill，自然易于推广。

插画生成器是另一项切实的成果。我先为 Tripadvisor 的 3D 黏土风格素材开发了一个，随后又为 Viator（Tripadvisor 旗下的旅游体验预订平台）开发了一个。在向团队发布之前，我对其进行了充分的压力测试，为一个真实项目生成了约 100 张插画。我认为此举十分重要。我希望传达的不是“这是我做的 skill，祝你好运”，而是“这个 skill 已经在真实工作中经过了检验，靠得住”。

图 4：使用该 skill 生成的部分插画。

原型制作基础设施耗时最长，所涉及的环节也比我最初预想的更多：

• 第一项工作是将 Claude Design 接入 Tripadvisor 和 Viator 的设计系统。由此，生成的原型从一开始即符合品牌规范，组件与样式均准确无误，搭建原型的人员也无需了解相关资源的存放位置。为此，我们需要通过 AI 提示词对设计系统本身进行压力测试，检查组件的命名、结构和文档是否足够清晰，以确保 Claude 能够选用正确的组件，而不只是在技术上可供调用。

• 第二项工作是教设计师使用 Git。此事看似简单，但目睹一位从未接触过终端的人首次尝试克隆代码仓库之后，便很难再如此认为。对部分成员而言，学习 Git 是整个项目中难度最大的环节。

• 第三项工作是整理 Claude Code 的最佳实践，并开发一套部署 skill，使原型从可运行版本到部署上线的过程，不再依赖于每次准确记住一系列命令。

• 第四项工作解决的是最迫切的问题：内部制作的原型均位于公司 VPN 之内，因此，设计师即使做出了出色的作品，也无法提供给公司外部的真实用户使用。我们搭建了一套框架，将原型托管至外网，正是这一步使“在我电脑上能跑”变成了“这是链接，去试试吧”。由此得到的是可运行、可交互、可用于真实用户测试的原型，而不是仅有几处不可见的预设区域可供点击的 Figma 静态稿。

图 5：加快原型制作的基础设施：设计系统集成、面向设计师的 Git、部署 skill 与外网托管。

进展不顺的方面：仍在着力解决的问题

推广比开发更难。对此我早有认识，但直到在 Slack 上向全团队介绍一个新 skill 却无人回应时，才真正有了切身体会。

问题并不在于团队成员不重视。使用一个新工具，即便它确实有用，也需要跨越一定的启动门槛。使用者需要记得该工具的存在，需要有适用的任务，还需要对其足够信任，愿意在实际工作中加以尝试。若文档的技术难度哪怕只是稍稍超出其理解水平，便已是强人所难。

我是在碰壁之后才认识到这一点的。我分享原型搭建指南后，收到的反馈是其工程色彩过重，设计师难以按步骤操作。我是从自身视角撰写的，而我此前刚用两个月厘清这些问题，并未站在初次接触者的角度考虑。此后我重写了指南，现已明显改善。但我本应从一开始便照此撰写。

事实证明，从“我做出了一个东西”到“团队用上了这个东西”，其间的差距几乎完全源于文档与沟通，而非技术。真正落地的 skill 都具备清晰的文档，如实说明其能做什么、不能做什么，同时辅以我在 Slack 上的亲自提醒。而我放入仓库后便不再跟进的 skill，大多石沉大海。

写出文档，并不等于使用者能够真正理解和吸收。有人阅读了某个 skill 关于如何组织提示词、如何控制 token 用量的说明，却仍未真正领会，直至自己误用一次、看到后果，才明白其中的道理。直接告知最佳实践收效甚微；真正有效的是现场演示：在对方首次运行某个 skill 时在旁陪同，或展示一条提示词修改前后的对比，说明原版本如何将一半的上下文窗口耗费在开场白上。

我低估的另一方面是对工程团队的依赖。该项目中一些最有价值的部分需要投入切实的工程时间，而工程时间始终需要与其他优先事项竞争。如果路线图中没有明确的排期，从机制上讲，此类工作必然最先被推迟至下一季度，因为没有其他因素促成这一决定。

我制定的路线图假设各项工作可以并行推进，但事实并非如此，因为实际上并未为这些工作预留任何资源。如果此项工作重要到需要专门规划，就应当为其安排明确的排期，而非仅凭一项出于善意、承诺日后处理的约定。

最出乎意料之处

我原以为技术会是最大的难点，事实并非如此。

只要为 Claude 提供恰当的上下文，其能力便相当出色。要构建一个效果良好的 skill，关键在于深入理解问题，而非掌握某种特定的提示词技巧。插画生成器经过了多次迭代，用于设计评审和创意构思的 skill 也经过了数轮完善。但总体而言，技术发挥了应有的作用。

真正的难点在于技术之外的各个方面：

• 文档。

• 版本管理。

• 共享仓库，以及与运营团队就 skill 的存放位置和适当的治理结构进行的讨论。

• 在 Slack 上发布消息的时机，以及如何向工作繁忙的同事介绍新工具。

• 判断一项流程何时已足够成熟、可以分享，何时只是在以继续完善为由拖延。

• 以上正是设计运营（DesignOps）的工作内容。如今想来，我本不应对此感到意外。

在此背后，还隐含着一个更晚才显现的假设：一旦形成一套工作方式，便可适用于所有情况。事实并非如此。有些项目仍然只能使用 Figma，别无他选；有些项目完全不需要 AI；有时，使用 Figma Make（Figma 的 AI 原型生成工具）制作可测试原型，比使用 Claude Code 更快。此次试点的目的，并非代替设计师判断何种工具适合何种工作，而是确保他们在作出判断时有更多工具可供选择。

当前进展

我为自己设定了两个月的试点期，以检验工作能推进到何种程度。目前，我们已建成一个覆盖 Tripadvisor 和 Viator 两个品牌的共享 skill 库，每个 skill 均配有文档并实行版本管理；建成了一套原型制作基础设施，半数设计师正在积极使用；建成了一个共享文档空间，同事们会主动查阅，而非避而不看；团队已被要求将上述做法作为日常工作方式，并已开始落实。

上述工作均尚未完成。目前建成的仅是概念验证：方案切实可行，且使用者已足够多，足以证明其价值。若要使其成为整个团队的工作方式，需要切实投入工程时间，而不能仅依赖本已分身乏术的同事出于善意提供帮助。此为下一阶段需要争取的投入，所需资源也将多于过去两个月。

可以确定的是，设计团队的工作方式已与两个月前有所不同。习惯难以改变，AI 也无法取代判断力。但变化已足够明显：需要撰写项目简报时，设计师会使用相应的 skill；需要 3D 插画时，他们知道有现成的提示词可用；需要制作原型进行测试时，也有了一条此前并不存在的路径，可以直接生成在线链接。

就目前而言，这已足够。工具将不断更替，其速度可能超出我们的规划。关键在于，该工作流并不依赖于其中任何一种工具。因此，无论未来由何种工具取代 Claude Code，都能够直接接入现有体系，而无需推倒重来。

对开展类似工作的建议

如果能够回到起点，我会提醒自己以下几点：

• 从痛点出发，而非从工具出发。得到使用的 skill，解决的都是团队真实面临的问题；无人使用的 skill，则是先有解决方案、再去寻找问题。

• 撰写文档时，应面向了解最少的人，而非了解最多的人。阅读文档的将是初次接触相关内容的人，文档应当为他们而写。

• 共享仓库比想象中更重要。存放在个人文件夹中的 skill 无法持续积累价值；只有实行版本管理、配有文档、便于组织内其他成员查找的 skill，才能在使用中不断增值。

• 推广本质上是沟通问题。再出色的 skill 或工作流，若无人知晓，也无法发挥作用。应当发布、讲解、跟进并征求反馈，然后再重复这一过程。

• 应预见到工程依赖的耗时会超出约定。这并非因为有人失职，而是因为统筹排期本身即有难度，优先级也会发生变化。应将这一因素预先纳入时间规划。

• 最后，实际情况远比 LinkedIn 上人们所描述的更为曲折。从工作坊到全面推行，并不存在一条清晰顺畅的路径，也没有任何一套方法可以从其他公司原样照搬。各团队的工具、工作习惯和工程能力各不相同，在其他设计团队行之有效的做法，移植到本团队可能只会成为额外负担。真正需要做的，是找出真正便利团队工作的方法，而不是在原有事务之外再增加一项需要管理的新工作。

在这一过程中，有无人回复的 Slack 消息，有反复重写的文档，有一再改期的工程会议，也有几乎无人使用的 skill。但也有一些时刻，例如一次基于在线原型的用户测试，或某位设计师没有从零开始，而是直接选用了我开发的 skill，都会让人感到一切付出都是值得的。

在此谨向 Emiliano Esposito 致谢，他在事务繁多的情况下，搭建了使上述工作得以真正运转的工程框架。同时感谢 Kuldeep Salhan 审阅本文初稿，他的反馈使文章的表达更加清晰、有力。

如果您也在所在的设计团队中进行类似探索，我很希望了解您的心得：哪些做法行之有效，哪些未能奏效，您又会作何改变？

原文标题：

I spent two months building an AI workflow for my design team. Here’s what I actually learned.

原文链接：

https://medium.com/tripadvisor/i-spent-two-months-building-an-ai-workflow-for-my-design-team-heres-what-i-actually-learned-663abf48b287