如何让整个团队用 AI 进行原型设计（Prototyping）
摘要
本文由 AI 原型设计专家 Colin Matthews 撰写，分享了一套让产品团队系统化使用 AI 原型设计（AI Prototyping）工具的完整方法论。核心解决两个痛点：(1) 如何让 AI 原型看起来足够精致，可以展示给客户或高管利益相关者；(2) 如何在团队层面成功采用这些工具，而非各自为政。文章重点介绍了三种构建组件库 (Component Library) 的方法——截图法（最简单，零技术门槛）、Chrome 扩展法（推荐 Magic Patterns 工具）和代码法（效果最逼真，需要工程协助）——以及两种团队工作流：Baseline & Fork（基线复现→分叉探索）模式和产品开发生命周期（Product Development Lifecycle）六步集成法。作者提出了"中保真度"（Medium Fidelity）概念——AI 原型介于草图和精修稿之间——并详细说明了在发现 (Discovery)、路线对齐 (Roadmap & Alignment)、PRD 与 Mock、用户访谈 (User Interviews)、工程范围界定与交付各阶段中，应使用何种保真度、由谁负责、投入多少时间。文章还提供了多项节省 Token 和时间的实用技巧（如使用真实 Logo、Unsplash 图片等），并给出了组件库提示词模板、PRD 转原型提示词等可直接复制使用的模板。
正文
引言
自今年一月我首次分享了面向产品经理 (Product Manager, PM) 的 AI 原型设计指南以来，AI 原型设计工具已变得极为流行。如今，产品团队使用 v0、Bolt、Replit 或 Lovable 来快速构建原型以分享想法和获取反馈，已经比不用这些工具的情况更为普遍了。
在过去五个月中，我教了超过 500 位 PM 如何最佳利用这些工具（另外还有约 10,000 人通过免费在线闪电课学习），我发现在真实场景中使用这些工具时，人们最常提出两个问题：
- 如何让原型看起来足够好，可以展示给客户或高层利益相关者？
- 如何在团队层面成功采用这些工具，而不是许多人各自为政地使用？
这些常见问题正是产品、设计和工程团队难以摸索出 AI 工具的团队工作流的原因。没有交付指导或高质量的原型，AI 原型设计只能停留在探索和实验层面，难以运作化和规模化。
在本文中，我将带你了解三种创建组件库 (Component Library) 以持续产出高质量 mock 的方法；减少返工的团队工作流；以及原型应如何使用的逐步指南。我还会分享大量节省时间、Token (令牌) 和心力的技巧，适用于最流行的 AI 原型设计工具。本文将涵盖 v0、Bolt、Cursor 和 Magic Patterns，但这些技术适用于任何 AI 原型设计工具。
先来快速展示可能性——这是我只用一个 prompt 构建的 Airbnb 原型："Build a homepage and a listing details page."（构建一个首页和一个房源详情页。）
[此处原文含单 prompt 生成的 Airbnb 原型演示 GIF：首页和房源详情页]
让我们开始吧！
组件库 (Component Libraries)
组件库是你能带给团队的第一项重大改进。它让你能够在保持一致品牌和风格的同时，无需手动清理每个原型使其看起来像你的产品。构建组件库需要一些前期投入，但你也在构建可复用资产，这将极大提升你后续原型的质量，并在初次投资后节省时间。
使用 AI 原型设计工具构建组件库有三种不同的方法，每种在投入和产出上有不同的优势和取舍：
- 截图法 (Screenshots)
- Chrome 扩展法 (Chrome Extensions)
- 代码法 (Code)
[此处原文含三种方法的对比示意图：截图→最简单/中效果；扩展→中等/好效果；代码→最复杂/最佳效果]
让我们逐一了解并讨论各自的取舍。
方法一：截图法 (Screenshots)
截图法是开始构建组件库最简单的方法。你不需要任何技术背景，且适用于任何工具。
从向你喜欢的 AI 原型设计工具输入以下 prompt 开始：
你被要求根据截图使用 React 和 Tailwind CSS 创建一个组件库。
所有组件应为自定义制作，尽可能精确地匹配截图。
仔细遵循以下指引：
1. 分析提供的截图。
2. 识别截图中的不同 UI 组件。这些可能包括但不限于：按钮、输入框、导航栏、卡片、模态框、排版元素。
3. 对于每个识别出的组件：
a. 创建 React 函数组件。
b. 使用 Tailwind CSS 类来设置样式，匹配截图中的视觉设计。
c. 确保组件响应式且可访问。
d. 添加必要的 props 以支持自定义。
e. 包含简要注释描述组件的用途。
4. 创建完所有独立组件后，创建一个 index 页面，导入并展示每个组件及其示例用法。
请记住：仅使用自定义制作的组件和 Tailwind CSS 类。不要使用任何外部库或预构建组件。
尽可能精确地匹配截图中的视觉设计，同时保持良好的编码实践和组件的可复用性。
我们来用 v0 试试，重现 Google Calendar 的 UI。记得附带截图！
[此处原文含 Google Calendar 截图及 v0 生成的组件库结果 GIF]
一个快捷提示：你可能最终会得到一张重现截图的页面，而不是组件列表。这些 AI 工具非常擅长复现截图，所以你可能需要再推一把，发送类似 "不要展示复现 UI 的页面，index 页面应该列出组件库中的组件。" 的 prompt。
之后，你可以通过粘贴更多截图并附上 "也添加这些组件" 的 prompt 来继续添加组件。如果你想精炼组件，建议从这个 prompt 开始：
"列出截图与你实现之间的差异。如何能更精确地匹配设计？先不要写代码。"
这种技巧（称为"反思" Reflection）可以让你轻松利用 AI 快速做 UX 改进。
组件库完成后，暂停！你需要创建项目的 Fork (分叉)，然后在新的 project 中使用这些组件。你的 Fork 项目将自动复用你的组件，像搭乐高积木一样组装你的设计。这个方法同样适用于任何你喜欢的 AI 原型设计工具。
[此处原文含基于 Google Calendar 组件库生成的 AI 调度助手原型 GIF：带有深度工作时间段推荐功能]
花时间改进你的组件是值得的。每个使用这些组件制作的原型都有更好的视觉质量，对利益相关者的干扰更小，使讨论能够聚焦在被测试的具体元素上。
方法二：Chrome 扩展法
创建组件库的下一个选项是使用 Chrome 扩展。截至目前，Magic Patterns 是唯一支持直接从网页提取组件的工具。
使用扩展很简单：选择一个 UI 元素，提取其样式，将其转化为可复用组件。
[此处原文含 Magic Patterns Chrome 扩展操作演示 GIF：选取 UI 元素→提取→生成组件]
我喜欢同时发起多个提取操作，在短时间内创建尽可能多的组件。它们进入 Magic Patterns 后，你可以继续通过 prompt 进行精炼。
真正的魔力在于使用这些组件。来试试 prompt "Build me a channel view of YouTube."（给我构建一个 YouTube 频道页面视图。）
[此处原文含单 prompt 生成的 YouTube 频道页面结果 GIF]
方法三：代码法 (Code)
构建组件库的最后一种方法是使用真实组件代码。这种方法投入最大，但能产出与真实产品毫无区别的原型。你需要工程团队的协助，整体投入和复杂度取决于你的代码库和公司规模。这一选项在小公司或拥有技术背景较强的设计师和 PM 的团队中最为现实。
首先，你的工程团队需要设置代码仓库，让你能在本地运行前端应用而不必连接任何后端服务或数据库。可以通过创建一个新的客户端应用入口点，模拟 (Mock) API 响应来实现。本地环境跑起来后，你可以使用 Cursor 或 Windsurf 等 AI 代码编辑器进行原型设计。
[此处原文含使用真实代码模拟的 App 原型截图：所有信息均为客户端 mock，无服务器或数据库连接]
这种方法最适合你对 GitHub、分支 (Branch) 和基本终端命令比较熟悉的情况。
另一种利用代码获取更精确组件的方法是通过最近发布的 Figma MCP Server（Model Context Protocol Server）。如果你不熟悉，MCP 是一种允许 AI Agent 获取另一个应用中的信息或执行操作的协议。在本场景中，我们可以使用 Cursor Agent 调用 Figma 的 MCP Server 来获取详细样式信息，然后转化为组件。
Figma 目前支持四个 MCP 操作：获取代码、获取变量定义、获取图片、获取 Code Connect。
这实际上赋予了 Cursor 自主截取屏幕截图、提取设计 Token (设计令牌) 并从 Figma 的 Dev Mode 获取 CSS 的能力。
[此处原文含 Figma 设计系统与代码复现的并排对比截图]
以下是使用 Figma MCP 构建组件的步骤：
- 为你想要处理的设计启用 Figma MCP Server（偏好设置 → 启用 Dev Mode Server）。这会提供一个连接 URL。
- 在 Cursor 中，前往 Settings → MCP Tools → "Add a new MCP server"。粘贴 Figma 提供的 URL。
- 在 Figma 中右键点击组件，选择 "Copy as URL" 复制组件 URL。
- 要求 Cursor 将其生成为一个组件，并使 index 页面为组件列表。
目前我发现，如果已有 Cursor 可以模仿的现有组件，或提供清晰的代码格式指引，这种方法效果最好。
这一选项很新，但对于希望将现有组件库与 AI 原型设计工具结合使用的设计团队来说，这非常令人兴奋。
总结来说，组件库为你的团队提供了一套共享资产，使任何人都能轻松地用 AI 创建逼真的原型。你的组件库可以在整个团队中共享，轻松上手新成员，并保持高质量的视觉效果，用于直接与客户测试或在高级利益相关者会议上展示。
团队工作流 (Team Workflows)
现在你有了能快速创建逼真原型的组件，我们来谈谈团队工作流。我想涵盖两个工作流：
- 基线 (Baseline) 与分叉 (Fork)
- 产品开发生命周期 (Product Development Lifecycle)
工作流一：基线 (Baselines) 与分叉 (Forks)
基线与分叉是组件库策略的延伸。有了组件，你为团队成员提供了乐高积木般的构建块，让它们能轻松组装出漂亮的原型。"基线"更进一步，给你一份对当前产品体验的高质量复现，让团队成员能更轻松地通过简单 prompt 来实验新想法。分叉则建立在基线上，允许你在不消耗 Token 的情况下复制项目和其全部内容，同时防止你搞砸基线。
[此处原文含基线与分叉工作流示意图：创建基线→Fork1（实验A）、Fork2（实验B）、Fork3（实验C）]
这最好通过一个例子来解释。
假设我是 Airbnb 负责新 Experiences 产品的 PM。这是一个展示全球最独特和有趣体验的产品。使用基线和分叉，我将从复现当前页面开始，然后探索几个新想法。
用组件库创建初始页面花了我大约 20 分钟，主要是在打磨所有小细节，使原型真正看起来像 Airbnb。下面是效果：
[此处原文含 AI 生成的 Airbnb 原型截图，旁边附真实 Airbnb 网站截图作为对比]
现在有了这个页面，我将其视为"基线"。我不再做任何更改，而是创建 Fork。
在 Fork 上，我输入单条 prompt："修改这个页面，使其在显示体验列表之前先通过一个问卷来确定我可能喜欢的体验。保持 Airbnb 品牌风格。"
[此处原文含带问卷功能的分叉原型结果 GIF]
现在测试另一个想法：利用客户的历史旅行记录来推荐相关体验。
再次从基线创建 Fork。在新副本上，我输入 prompt："修改这个页面，根据我在 Airbnb 的历史旅行记录，向我展示可能喜欢的体验。每个推荐添加一个 UI 元素，显示'基于你的……之旅'。"
[此处原文含基于过往旅行记录的个性化推荐原型截图]
基线和分叉最适合在你想探索多个不同想法、而不必每次都重新构建起始页时使用。它们为你的团队在使用 AI 原型设计工具快速获得高质量结果方面提供了又一个助力。
工作流二：产品开发生命周期 (Product Development Lifecycle)
如果你实现了目前涵盖的所有内容，你将远远领先于一般的 AI 原型设计新手。但很有可能你的 PM 或设计师仍然在孤立地进行原型设计。为团队建立关于何时使用 AI 原型的共同理解，与知道如何获得好结果同等重要。
在深入产品开发生命周期之前，我想简要谈谈保真度 (Fidelity)。长期以来，我们有低保真度 (Low-Fidelity) 的草稿版 UI，以及精修完成品的高保真度 (High-Fidelity) mock。AI 原型设计引入了中保真度 (Medium Fidelity)——比餐巾纸草图好，但不如最终版 Figma mock。
[此处原文含 Reddit 中保真度 mock 示例：看起来大致正确，但存在多重按钮、padding 不一致等细节瑕疵]
你当然也可以用 AI 原型设计工具创建高保真度 mock——关键在于你投入了多少时间和精力。
基于上下文选择合适保真度，并就此与团队成员设定期望，这一点至关重要。例如，如果你在向工程师解释一个交互，中保真度完全没问题，花时间追求更高保真度是浪费。而如果你在向 CEO 争取数百万美元的新团队投资提案，一个可交互的高保真度 mock 可能值得花时间。
下面我概述了产品开发生命周期的六个主要步骤，以及原型如何被利用、应达到的保真度和由谁负责。我鼓励你将此作为一般指引，并在自己的公司中因地制宜地应用。
[此处原文含产品开发生命周期六步表格：发现→路线对齐→PRD与Mock→用户访谈→工程范围界定→交付，每步注明保真度、负责人和时间投入]
让我们通过 Reddit 上一个名为 "Reddit Answers" 的新功能，走一遍完整的开发生命周期示例。这将是一个生成式 AI 功能，允许用户提问并根据过往 Reddit 帖子和评论快速获得答案。
第一步：发现 (Discovery)
在发现阶段，你可以选择使用 AI 原型设计工具以中保真度快速表达一个想法。这通常只在内部使用，仅限于产品、设计和工程负责人之间。我们可以从类似下面的原型开始，大约只需 20 分钟：
[此处原文含 Reddit Answers 中保真度原型 GIF：提问界面和 AI 生成的带引用来源的回答]
这是内部沟通的出色资产，但我们可能不想将其展示给任何高管或客户。
[此处原文含该原型使用的完整 PRD prompt 模板，涵盖 Overview、User Stories、Implementation Phases、Design System 和 Data Model 等结构化内容]
第二步：路线图与对齐 (Roadmap & Alignment)
一旦我们强化了想法并希望建立更多内部支持，我们可能需要以高保真度制作一些东西来向利益相关者和客户展示。
我们将精炼初始原型，使用组件库，拿出一个更加精致的原型。这可能需要 20 到 60 分钟，取决于原型的复杂度。
[此处原文含 Reddit Answers 高保真度原型 GIF]
第三步：PRD 与 Mock
现在我们获得了建造这个新功能的内部支持，需要确定它具体如何运作。可以将之前的高保真度原型嵌入 PRD 中，并向团队现场演示，以开始产生问题和推敲边界情况。
我们可能听到类似以下的问题：
- 准确性评分是什么意思？
- 应该使用哪些外部来源？
- Reddit 内部是否有内容应当从回答中排除？
- 在纳入 AI 回答前，答案应如何审核？
使用原型进行沟通，比指望工程师读完你整篇 PRD 后多加几条评论要快得多、容易得多。与工程的这类讨论可能会持续两个小时或更多，跨越多轮讨论。
第四步：用户访谈 (User Interviews)
随着我们继续迭代想法，我们可以将高保真度原型带到用户访谈中。我们可以在开发周期非常早期就获得关于具体用户流程的反馈，而不是等待功能在生产环境中就绪。用户访谈可能需要三到五天来收集足够的反馈。
虽然直接用户访谈可能是收集反馈的最佳方式，但我们也可以通过调查问卷来扩展反馈收集规模。你可以将你喜欢的调查工具直接嵌入原型中，通过将其分享给真实用户来收集结构化反馈。
[此处原文含原型嵌入调查工具的示例 GIF]
第五步：工程范围界定与交付 (Engineering Scoping & Delivery)
需要记住，AI 原型设计工具生成的代码对你的工程团队来说基本没有用处（除非你的组件是用现有代码构建的）。它不遵循任何现有模式，不使用任何相同的代码库 (Library)，甚至可能不是用相同的编程语言写的。
原型的一个有用之处是用于记录非常具体的交互，比如动画。如果你希望加载动画完全和你原型中创建的一样，你的工程团队很可能可以将其作为实现时的起点。
在整个构建过程中，高保真度原型仍可以在有任何关于产品或功能的问题时，作为一个有用的沟通工具。原型设计对开发时间线影响不大，所以预计需要两到六周，取决于功能的复杂度。
附加技巧：在原型中使用真实 Logo
这一节很短但超级重要，因为我见过很多人遇到这个挑战。大多数 AI 原型设计工具宁愿画出一个"恐怖谷"般失真的 Logo，也不愿意使用真实版本。加上它们犯的其他 UI 小错误，这通常会让原型在展示给客户或高层利益相关者时感觉不可用。
简单的解决方案是粘贴你要使用的精确图片链接。查找 Logo URL 有两种方式：
- 在图片上右键，检查元素 (Inspect Element)，获取图片的 URL 或 SVG 内容。
- 使用 Logo 仓库，如 Brandfetch，它托管大多数公司的 Logo。找到你的 Logo 并获取嵌入链接。
[此处原文含通过 inspect element 复制 SVG 内容的截图，以及 Bolt 中使用该 SVG 渲染的正确 Logo 截图]
要纳入你的 Logo，只需粘贴链接或 SVG 文本，附带类似 "使用此链接将我的 Logo 添加到页头 (Header)" 的 prompt。
第二个选项是在 Brandfetch 等网站上查找 Logo 并复制嵌入链接。将其直接粘贴到你的 AI 原型设计工具中，就能瞬间获得干净的 Logo。
[此处原文含 Brandfetch 中 Airbnb Logo 页面截图，以及使用该链接生成的完美 Logo 截图]
你可以将这些方法用于任何想包含的图片——只需确保链接指向图片本身而非网页。URL 通常以 PNG 或 SVG 结尾。
最后一个技巧：如果你需要一些逼真的图片来填充原型，可以让 AI 工具从 Unsplash 抓取。它们在选择相关图片方面做得相当不错。以下再次展示 Airbnb 的例子，AI 基于 prompt "添加来自 Unsplash 的图片，选择与上下文相符的" 选择了这些图片。
[此处原文含 Unsplash 图片填充的 Airbnb 原型截图]
下一步行动
如果你想推动团队采用，从组件库开始建立视觉一致性，实施基线和分叉来加速迭代，并使团队就何时以及如何在产品开发生命周期各阶段使用不同保真度达成一致。这些不仅仅是锦上添花——这正是将那些只是浅尝辄止的团队，与那些将 AI 工具完全融入最佳实践和日常工作流以赋能产品的团队区分开来的关键。
试试这些工作流，随时与我分享你的进展。我期待看到你和你的团队在 AI 原型设计上不断进阶！
本文由 Colin Matthews 撰写。更多 Colin 的内容，请关注他的免费在线课程和 AI 原型设计课程（使用优惠码 LENNYSLIST 可减 $100）。你也可以为你的团队预订 Colin 的一日团队工作坊。