AI辅助生成可交互产品原型：从需求到Demo的实战方法

从参与Datawhale组队学习的实际经历来看，Easy-Vibe这个项目最让我有感觉的其实是task03。前几个task都在做头脑风暴、需求梳理和信息架构，到了task03，节奏突然从"想清楚"变成"做出来"。组里的要求很直接：把一个还没成形的产品概念，变成能点、能跳、能交互的Demo原型。这一篇就聊聊我在这一关上踩过的坑、用过的工具，以及最后摸索出来的一套AI辅助搭原型的打法。

1. 任务拆解：Easy-Vibe task03到底要交什么

1.1 组队学习的节奏与task03的位置

Datawhale的组队学习一向是"以练代学"，每个task都有明确的阶段性产出。Easy-Vibe项目在task01、task02阶段，基本上是在做选题验证：明确要解决什么问题、目标用户是谁、核心场景是什么。到了task03，题目"动手做出原型"，字面意思很清楚，就是把前面那些文字化的方案，变成可视、可点、可演示的东西。

这个转变很容易被低估。很多同学以为原型就是画几个框、拉几条线，但真实交付时你会发现，原型是团队内部统一认知的锚点。想要做"一个帮用户记录日常情绪的应用"，这句话在文档里怎么理解都行，一旦变成页面，就会出现一系列具体问题：首页是展示日记列表还是情绪曲线？打卡按钮放在底部Tab还是首页悬浮？这些细节在文档里模糊一点没人在意，但原型必须给出确定答案。

所以task03的任务不是"交付一个好看的图"，而是"通过原型把需求文档里没说清楚的地方全部暴露出来并给出临时决策"。我理解的正确交付物，应该包含三个层次：

1. 可点击的页面流转，覆盖至少一条核心用户路径；
2. 关键页面上的交互状态（空状态、加载状态、结果状态）；
3. 用真实或接近真实的数据填充内容，而不是满屏的"Lorem ipsum"。

做到这三点，才叫"动手做出原型"，而不是"动手画了一张漂亮的图"。

1.2 原型不是一锤子买卖，它是需求验证的加速器

参加组队学习最容易出现的误区，是把原型当成一个"期末作业"。实际上，task03在整个Easy-Vibe项目链条里，承担的是一个"验证加速器"的角色。前面我们假设用户需要一个功能，但那只是假设。原型做出来拿给队友、导师甚至潜在的种子用户看，他们会产生真实反馈："这个按钮我不太会点""这个页面信息太多了""我以为点这里会弹出日历"。

这些反馈的价值远高于任何头脑风暴。我在这次任务里最深的体会是：原型不是用来证明"我的想法可行"的，而是用来收集"我的想法哪里不对劲"的。 所以动手之前就应该明确，这次原型验证的核心问题是什么。

我们小组选的题目是一款面向自由职业者的轻量记账工具。task02写的需求文档里有一条核心假设：用户希望"用最少操作记录一笔收入或支出"。task03要做的事，就是做一个可交互原型来验证这句话。原型里我必须重点展示的，不是好看的图表，而是"一笔记账需要点几次屏幕"。如果原型做出来发现完成一次记录至少要点五次以上，那么这个假设本身就是有问题的。

1.3 先区分清楚：这里说的原型是产品原型

做task03之前，组里讨论过"原型"这个词的歧义。有人提到JS原型链，有人提到机器学习里的原型聚类算法KMeans，差点把方向带偏。实际上Easy-Vibe这个task里的"原型"，是产品设计领域讲的"Prototype"，也就是低保真或高保真的可交互模型。它不需要是完整可用的软件，只需要在形态和交互上足够接近最终产品。

把概念边界划清楚很重要。因为如果你跑到"用KMeans做原型聚类"的思路里去，最后交付的很可能是一堆数学结果，和产品验证毫无关系。组队学习的任务命名有时候比较概括，还是要回到项目本身的语境里理解。Easy-Vibe本质上是一个关于"如何快速把想法变成可体验产品"的实战项目，所以task03的原型，就是产品原型。

2. 工具选型：为什么我没有从Axure开始

2.1 传统原型工具和AI生成原型的差异

在动手之前，组里自然会产生一个经典问题：用Axure、Figma还是别的？我之前的习惯是Axure，拖拽组件、设置交互、生成预览，功能确实强大，但有一个致命问题：效率跟不上组队学习的节奏。Axure做高保真原型，一个页面从布局到样式到交互，熟练的话也要二十分钟到半小时。如果要做五个页面、三条核心路径，基本上一个下午就没了。

更麻烦的是，Axure做出来的原型和最终前端代码是脱节的。评审通过之后，开发还要照着原型重新写代码，中间的沟通成本和信息损耗很大。所以在task03工具选型时，我第一天就试了另一条路线：用AI大模型直接生成HTML/CSS/JS原型。方向是这样的——用自然语言描述产品需求，让模型生成一个浏览器里能直接运行的原型页面，然后再用对话迭代的方式继续加工。

这两种路线的差别，我用一个表格来对比：

当然，传统工具在视觉精细度和团队协作上有优势，Figma的多人实时编辑至今没有替代品。但task03的时间窗口只有几天，我们需要的不是生产级设计稿，而是快速可验证的交互原型。代码原型在这一目标下明显更占优势。

2.2 我试过的几条AI生成原型路线

确定"用AI生成代码原型"的方向之后，我又试了三条具体路线。

第一条是直接用ChatGPT这类对话式AI，让它一次生成一个完整的HTML文件。优点是门槛最低，浏览器直接打开就能看效果。缺点是上下文长度有限，当页面多了之后，让AI修改一个模块时容易把其他部分弄丢。

第二条是用专门面向前端生成的工具，比如v0.dev这类。它生成页面的视觉效果确实精致，交互组件也很丰富，但免费额度有限，而且生成的代码结构偏重React框架，对只想快速验证原型的我来说有点重。

第三条是本地IDE配合AI插件，比如在VS Code里用Codex或Continue插件来生成代码。这条路线的自由度最高，因为可以同时打开多个文件，AI可以同时看到整个项目结构。但要求你多少懂一点前端工程结构，对纯设计背景的组员不太友好。

最终我选择的是混搭方案：交互逻辑简单、以页面展示为主的部分，用单文件HTML+AI对话生成；涉及多页面状态切换和数据联动的地方，用本地IDE+AI插件来维护完整的代码目录。 这样既保证了速度，又控制了复杂度。

2.3 选型背后的三个判断标准

很多教程会直接告诉你"用XX工具就行"，却不说为什么。我这次选型没有盲目跟风，而是先立了三个判断标准：

第一，能否快速生成可点击Demo。这是task03的底线要求。原型做出来不能只是滚动看内容，按钮要能点、页面要能跳、表单要能有反馈。如果工具做不到这一点，就算页面再好看，也不符合任务目标。

第二，能否方便地接入假数据。产品原型需要让用户"信以为真"。如果页面里全是静态占位文字，体验会大打折扣。代码原型只需要在JS里定义一个数组，就可以渲染出充满真实感的列表，这个优势是传统原型工具很难比的。

第三，后续能否平滑过渡到正式开发。组队学习虽然以学习为主，但好的实践应该跟真实开发流程衔接。HTML代码原型可以直接拿去作为前端页面的起点，这一点让我觉得投入时间不亏。

这三个标准帮我快速过滤掉了那些看起来很好玩但和任务目标无关的工具。也建议每个参与组队学习的人都先自己想清楚标准，再选工具，而不是看别人用什么就跟着用什么。

3. 从需求文档到可交互原型的完整实操

3.1 把需求文档翻译成提示词

我踩的第一个坑，是以为AI能自动理解需求文档。实际用下来，直接把task01、task02写的用户调研报告和需求文档粘贴给AI，生成出来的页面完全没法用——太泛、太散、没有重点。AI不是产品经理，它不会替你从文档里提炼核心页面和交互流程。你得先把需求翻译成它听得懂的提示词。

我自己的提示词模板分四段：

1. 角色定义：告诉AI"你是一个资深产品设计师，擅长生成可交互的HTML原型"。
2. 页面清单：明确需要哪些页面，以及每个页面的核心功能模块。
3. 交互细节：描述关键交互动作，比如点击按钮后跳到哪个页面、表单校验规则等。
4. 视觉风格：给出主色、圆角、字体、间距等具体参数，而不是只说"简洁大气"。

以一个轻量记账工具为例，我实际使用的第一轮提示词是这样的：

text复制你是一个资深产品设计师兼前端工程师，请为我生成一个移动端H5产品原型，产品名称叫"轻记"。

页面清单：
1. 首页：展示本月收支汇总、最近5笔交易记录、底部Tab栏（首页/记账/统计/我的）。
2. 记账页：支持选择收入或支出、输入金额、选择分类、填写备注，底部有"保存"按钮。
3. 记完账的反馈弹窗：展示"记账成功"，并提供"再记一笔"和"查看流水"两个按钮。

交互要求：
- 底部Tab栏切换时，对应页面区域内容变化，但Tab栏本身固定。
- 点击首页的"+"按钮跳转到记账页。
- 保存成功后弹出反馈弹窗。

视觉规范：
- 主色：#4F6EF7，背景：#F7F8FA，卡片：#FFFFFF，圆角：12px，字体：系统默认无衬线字体。
- 页面宽度400px以内，手机竖屏布局。

这段提示词的效果明显比"帮我做一个记账App原型"好得多。AI生成之后，页面结构基本正确，虽然细节需要调整，但已经可以拿给组员讨论。

3.2 首轮生成后，如何进行对话式迭代

第一轮生成的原型通常只能算"骨架"，布局可能有，但视觉细节和交互状态都不够。接下来就需要一轮一轮地对话迭代。这里有一个我的独家技巧：每次对话只让AI做一类修改，不要一次性塞五六个问题。

比如第一轮生成之后，我发现首页的收支汇总太挤了，分类图标也不对，底部Tab栏的"统计"页面还没有内容。如果我把这四个问题一次性发给AI，它很可能改了这个坏了那个。更稳的做法是分多轮：

• 第一轮修改：调整首页卡片布局，让汇总数字更醒目；
• 第二轮修改：补充统计页的简易柱状图；
• 第三轮修改：修正分类图标为对应的SVG图标。

每轮修改都基于同一个对话上下文，AI对项目结构的理解是延续的。如果你开了新会话，忘了贴代码，那AI等于从零开始，效果会差很多。所以我习惯在本地开一个文件，把每轮修改后的完整代码都保存下来，防止对话上下文丢失导致崩溃。

3.3 给原型加上真正的交互逻辑

"能点能跳"是交互原型的最低要求。AI生成的HTML页面里，按钮默认是用<a>标签或onclick事件实现的。但对于稍微复杂一点的交互，比如"点击记账分类时高亮选中项""输入金额后自动格式化千分位"，AI默认生成的效果往往很粗糙。

我在这一步骤用了一个比较讨巧的办法：先让AI生成基础的页面切换逻辑，再自己用几行JS脚本来增强交互。 比如页面跳转，如果不引入路由库，最简单的方式是多个<div>模块，通过JS控制显示/隐藏。让AI自动生成这套逻辑，往往会写得混乱。于是我手动定义了切换函数：

javascript复制function showPage(pageId) {
  const pages = document.querySelectorAll('.page');
  pages.forEach(p => p.classList.remove('active'));
  const target = document.getElementById(pageId);
  if (target) target.classList.add('active');
}

这样无论是点击Tab栏、按钮还是其他元素，只要在onclick里调用showPage('statistics')，页面就能切过去。AI在这种"已有明确函数"的引导下，补全其他交互时就不容易跑偏。

另外，表单交互也很重要。比如记账页输入金额后，点击"保存"需要校验金额不能为空，否则给出提示。我让AI在保存按钮的事件里加了校验逻辑，再用alert()弹出提示。虽然粗糙，但对于原型验证完全足够。

3.4 用Mock数据让原型"有血有肉"

这是我认为task03最容易拉开差距的部分。大部分学员交的原型，页面里是空的或者只有"示例数据"。而真实可用的产品原型，一定要让用户产生"这已经是一个产品"的错觉。

我的做法是，在HTML里直接维护一个模拟数据数组：

javascript复制const mockData = {
  balance: 3256.80,
  income: 12800.00,
  expense: 9543.20,
  transactions: [
    { type: 'expense', category: '餐饮', amount: 38.50, note: '午餐', time: '今天 12:30' },
    { type: 'income', category: '项目收入', amount: 5000.00, note: '设计费', time: '今天 09:10' },
    { type: 'expense', category: '交通', amount: 12.00, note: '地铁', time: '昨天 08:45' }
  ]
};

然后让AI用render()函数把这个数组渲染到页面上。这样改数据只需要改这个对象，页面内容自动更新。评审的时候，组员可以通过修改这个数组来模拟不同场景，比如模拟"月初收入到账"或"月底支出超标"，原型表现出不同的界面状态，这才是有价值的验证。

4. 踩坑记录：AI生成原型最容易翻车的四个地方

4.1 提示词模糊，生成结果像"套模板"

这个问题在组里非常普遍。有人让AI"生成一个社区App的原型"，AI给出来的东西确实是个社区App，但和你的目标用户、业务场景毫无关系。原因很简单：AI在没有具体约束时，会倾向于生成它见过最多的那种通用模板页面。

解决办法是给提示词加约束。约束不一定是视觉参数，更多是内容层面的细节。比如你想要一个面向自由职业者的记账工具，必须告诉AI：用户记录的一笔收入来自于"某个项目"，而不是抽象的"工资"；用户最关心的统计维度是"本月的回款周期"，而不是"年度财务报表"。当AI接受到这些业务细节，它生成的页面才有针对性。

另外，我建议在提示词里加一句"不要让页面显得太像通用模板，可以增加一些和产品定位相关的文案细节"。这句话能有效抑制AI输出"欢迎使用本产品"之类的废话。

4.2 生成的前端代码一改就崩

对话式AI生成代码最大的问题，是它对自己上一轮生成的代码理解并不完整。有时候我只是让它改一下按钮颜色，它会把整个CSS重新输出一遍，然后某些样式就莫名其妙丢了。更离谱的是，有时候我让它在页面底部加一个抽屉弹窗，它直接重构了整个HTML结构，结果所有数据都渲染不出来了。

遇到这种情况，我的应对策略是拆分文件。不要试图让AI在一个巨大的HTML文件里维护所有逻辑。我更倾向于把JavaScript分离成一个独立文件，CSS也单独维护。这样一来，AI修改时涉及的上下文更集中，出错概率降低很多。

但即便如此，我也会在每个关键修改前给当前代码打一个快照。具体做法是在本地建一个versions文件夹，每轮修改前复制一份带时间戳的备份。这样即使AI改崩了，也能快速回滚到上一版。

4.3 高估了AI的视觉设计能力

很多同学一开始都以为AI能直接生成"高级感"的界面，但实际上，AI默认生成的页面就是普普通通的"工具感"界面——白色背景、蓝色按钮、四四方方的卡片。想要视觉上有记忆点，必须在提示词里详细定义设计规范。

除了颜色和圆角，我还会给出具体的间距规范、卡片阴影、字体大小。比如：

text复制- 页面左右边距16px，卡片之间间距12px；
- 卡片阴影：0 2px 8px rgba(0,0,0,0.06)；
- 主标题字号17px，字重600；次级文字14px，颜色#666；
- 按钮高度44px，主按钮背景色#4F6EF7，文字白色，圆角12px。

当这些参数在提示词里写清楚后，AI生成页面的视觉效果会直接上一个台阶。而且这类参数可以复用，下一次做别的原型，换个颜色就行。我在完成了task03之后，甚至整理了一份自己的"AI原型设计规范模板"，后面再遇到类似任务直接套用。

4.4 只做了"正常状态"，忘了空态和异常态

这是评测原型质量时最容易忽略的一点，但对用户体验的影响非常大。我们的记账工具原型在第一次演示时候，组员提了一个问题："如果用户还没有记过账，首页的收支汇总怎么展示？"我当场愣住，因为原型里只考虑了有数据的情况。

空状态、加载状态、错误状态，这三者在真实产品中非常重要。AI生成原型时，默认不会帮你考虑这些。所以你需要在提示词里明确提出来，比如"首页的收支汇总区域需要处理空数据的情况，当没有任何记账记录时，显示一张插画和文案'还没有收支记录，点击下方按钮开始记账吧'"。

同样，加载状态可以通过在JS里设置一个定时器，让数据在200毫秒后才出现，模拟真实的加载过程。错误状态则可以设计一个"保存失败"的弹窗，提示用户网络异常，让体验更完整。这些细节虽然要花一点额外功夫，但评审时给团队的观感完全不同。

5. 原型验收：怎么判断"动手做出原型"算完成

5.1 用任务脚本走查每条用户路径

在task03临近提交时，我开始做原型验收。最简单的验收方式不是自己觉得"做完了"，而是写一份任务脚本，让队友按脚本走查。我列了一个表格，把核心用户路径拆解成步骤，每走一步都要记录是否符合预期。

这样一张表走下来，问题一目了然。我建议每个组员都自己走一遍，因为原型里的问题往往是"做的人不会发现，用的人一眼就看到"。尤其是余额未更新这种数据联动问题，在演示的时候暴露出来会非常尴尬。

5.2 用录屏文件收集反馈

比文字反馈更有效的方式，是录屏。我用系统自带的录屏工具，把原型的关键操作路径完整录下来，然后配上一句话说明，发在群里。队友可以在没有实际打开原型的情况下，直观看到页面流转和交互效果。

这个做法的额外好处是，录屏视频可以反复看，比让队友自己点一遍更能聚焦细节。比如我录完发现，点击Tab栏的"统计"后，页面转换有一瞬间的布局闪动，这个在直接操作时不容易注意，但在视频里非常明显。于是我就针对这个闪动去让AI修复了过渡动画。

录屏还可以用来做异步评审。组队学习群里大家时间不固定，不一定能实时视频讨论。把录屏发出去，队友在自己方便的时间看，然后直接在视频下方评论，效率比约会议高得多。

5.3 让代码原型成为团队的沟通语言

task03做完后，我最大的感悟是：这个原型的意义远超任务本身。因为Easy-Vibe后面的task04、task05很可能需要继续迭代这个产品，如果task03只是交了一张静态图，后面等于从零开始。而现在我们手里是一个能跑的HTML原型，下一步无论是接后端接口，还是做更精细的视觉设计，都有了明确的起点。

代码原型这个"副产品"，本身就是团队沟通的语言。我们讨论"首页余额卡片要不要显示小数点后两位"，不再是一句抽象描述，而是直接指着页面上的数字说；讨论"统计页的数据周期"，可以直接在原型里切换不同周期的组件看效果。这种具体感是传统文档无法带来的。

我把整个原型代码推到了组内仓库，每个人都能拉下来跑。后续如果有组员想验证新的交互，直接复制一份代码改就行。我觉得这就是task03最理想的状态：不是做出一个"交差的作业"，而是做出一个"整个团队可以继续往上盖房子的地基"。

最后再分享一个小技巧：如果你想让AI生成的原型更稳定，记得把视觉规范写在提示词的最前面，然后才写功能需求。AI对上下文的开头部分注意力和遵循度是最高的，把最重要的约束放在前面，后面再怎么发散都不会跑出大框架。这个顺序看似无关紧要，实际操作下来，改动返工的次数能少三分之一。