构建可交互的产品原型

前一章已经把调研材料收敛成了问题定义和最小方案。本章开始把这份方案变成可以点击、可以操作的产品原型。

我们会以“提高电商商品内容制作效率”为贯穿案例，依次完成四件事：澄清业务目标、选择核心流程、制作单页面原型，再扩展成结构完整的多页面应用。

原型的任务不是一次完成所有功能，而是让用户尽早看见方案、实际操作，并指出理解上的偏差。完成本章后，你会得到一个可以用于演示和测试的电商内容工作台。下一章将在此基础上接入真实的 AI 服务。

::: info ℹ️ 说明 本篇中可能会有一些业务的名词，如果你不懂可以询问 AI 获得解释。 :::

前面的小游戏帮助我们熟悉了 AI IDE：目标明确，输入和结果也比较容易判断。业务应用更开放一些。即使已经确定了方向，我们仍要把用户场景、核心流程和第一版范围说明清楚。

这一步可以称为需求的具体化：把“想解决一个问题”继续拆成“谁在什么情况下做什么，以及第一版怎样验证”。

举个例子，在课堂或个人项目中，我们经常是从最简单的可执行功能出发做产品和应用：

这些描述给出了功能方向，却还没有说明使用者、场景和成功标准。在真实项目中，我们通常从一个较宽的业务目标出发，再逐步缩小范围。

在企业级项目或创业项目中，产品经理和工程师往往是从更大的业务命题出发。例如，我们可以假定这样的一个场景：

这句话说明了目标，却没有说明运营当前怎样工作、时间花在哪里，以及怎样才算“更快”。如果直接把它交给 AI IDE，AI 只能自行补全缺失的信息：

这样的提示词可能生成一个结构完整的页面，但页面里的功能顺序、字段和交互很可能来自猜测。这里需要补上的不是更多技术细节，而是业务信息：

信息越具体，原型越容易用于验证。下面先从业务提问开始。

::: info 💡 先搞清楚：什么是需求？什么是业务？

需求描述用户希望完成的进展，以及当前遇到的阻碍。例如“运营希望缩短每个商品准备首版图文的时间”。

业务就是用户每天实际在做的事情、他们的工作方式。比如电商运营每天要做的事：上架商品、改价格、做图片、看数据……这些都是业务。

为什么要关注业务？ 理解业务可以帮助我们判断功能应该放在哪个环节，以及它是否真的减少了用户的工作量。

:::

从最简单的视角出发，你可以先问自己几个问题：

这些问题可以作为访谈提纲。接下来，我们向一线电商运营了解实际流程，并记录更具体的事实：

::: info 📋 真实业务采访结果

我们问了做电商运营的人，他们说了这些烦恼：

1. 事情太多太杂

2. 做内容不是一次做好，而是边做边试

::: 访谈会带来很多信息，但第一版原型不能同时解决所有问题。我们还需要整理材料、比较优先级，并选出一个适合本次验证的核心流程。

::: info 💡 为什么要“收敛”？

问题很多，但先做哪一个？

用户往往会提到多个问题。如果第一版全部实现，范围会迅速扩大，也很难判断究竟是哪项改动产生了效果。收敛，就是根据出现频率、影响程度和验证成本，先选择一个具体问题。

:::

通过上面的采访，我们发现运营遇到的问题有很多：被活动打断节奏、要管多个店、在上架/改价/做图/看数据之间忙来忙去……

如果一次处理所有问题，原型会变得庞大，也难以在课程时间内验证。

让我们把这些问题分分类（可以让 AI 帮忙），大致有三类：

对于本课程，最适合先验证的是第 3 类：内容制作问题。但“快速做内容”仍然比较抽象，我们继续了解具体阻碍：

::: info 📋 业务方提到的两个具体问题

问题 1：批量制作图文需要重复操作

问题 2：已有方案不容易复用

:::

基于这两个问题，我们把原型范围定为：帮助运营批量生成图文草稿，并保存可复用的方案。

它只做两件事（可以让 AI 帮忙细化，记得根据业务反馈不断删减功能）：

::: info 功能1：批量生成电商商品图和文案

这是做什么的？ 给系统一些商品信息，它自动帮你生成能在电商平台（如抖音、淘宝）上架用的商品图和文字。

输入

输出（生成的电商素材）

效果

:::

::: info 功能2：把好用的方案存成模板

输入

输出

效果

:::

回顾我们刚才做了什么：

为什么这样做很重要？

原型的价值不由功能数量决定。范围越清楚，我们越容易让用户完成一次任务，并观察方案是否有效。

产品和业务思维的核心：

这就是我们在写代码之前要想清楚的事。代码只是工具，理解用户、找准问题才是第一步。

::: info 💡 工具说明 AI IDE 的界面、可用模型和额度会持续变化。选择你当前能够稳定使用的工具即可；本章关注的需求表达、生成、检查和修改流程并不依赖某个品牌。需要使用命令行编程工具时，可以参考现代 AI CLI 工具。 :::

需求已经足够清楚后，我们先实现一个单页面，用较小的成本检查核心流程。

刚开始不必追求一次写出完整提示词。像向同事说明需求一样，先写清用户、任务和预期结果，再让 AI 帮助检查缺失信息。

先用自己的话描述想法，哪怕很粗糙也没关系：

接下来，可以把这段话交给一个通用对话模型，让它帮助整理结构、指出缺失信息，并生成适合 AI IDE 的实现说明。

你可以这样跟 AI 说：

AI 会返回一份结构化的需求和对应的提示词。你自己检查一遍，删减不需要的功能，确认无误后再拿去生成代码。

这样做的好处是：口述的东西是最真实的想法，可能会漏掉一些重要的细节。而 AI 帮你扩写的时候，可能会问"要不要支持批量上传？"这种没想到的问题，帮助你进一步验证。你可以根据反馈需要选择保留或删除不实际的功能，在反复修改中确定给 AI 的初版提示词。

如果前面的章节已经整理好需求说明，可以直接套用下面的格式交给 AI IDE，适合范围清楚、准备开始实现的情况：

如果你想更精细地控制代码生成过程，可以先让通用对话模型把需求整理成一份交给 AI IDE 的实现说明：

通常 AI 会生成类似下面的结构化提示词：

你可以把这份提示词稍作修改后，发给 AI IDE 生成代码。

如果你还不熟悉 AI IDE 的基本使用方式，建议先看附录中的IDE 基础教程，了解如何：

AI IDE 的界面和确认方式会持续变化，这里只保留一条稳定的工作流程：

如果 AI 停止运行，先查看它是否在等待确认，或者终端中是否已经启动了开发服务。不要只按教程寻找某个固定按钮。

完成第一轮生成后，可以得到一版包含主要结构的页面：

初版页面已经包含主要结构，但信息层级和间距还可以继续调整。此时可以通过具体描述和页面截图，让 AI 修改界面。调整以后，页面会更容易阅读和操作：

你可以根据需求继续删减功能，例如：“第一版暂时不需要批量导入，请先移除”，“左侧字段太多，请只保留完成核心流程所需的内容”。也可以参考成熟产品的信息结构和交互方式，但应重新组织品牌、文案和视觉细节，而不是直接复制页面。完成后可以得到：

在实际操作中遇到报错很常见。处理时先保留一个可以运行的版本，再把现象、错误信息和预期行为完整交给 AI。

可以先从三类情况入手：

页面变红、白屏，或终端出现错误信息时，复制相关日志并说明刚才进行了什么操作。发送前检查其中是否包含 API Key、账号或其他敏感信息。

比如按钮没反应、数据没显示、样式乱了，描述“现在发生了什么 + 预期是什么”，必要时加一张截图。

可以直接问 AI：“帮我检查一下这个功能有没有明显问题，需不需要调整。”

核心流程可以运行后，再检查导航、设置和列表等页面。初版中有些入口可能只有外观，还没有对应行为。

可以让 AI 对照需求列出尚未实现的页面，再按优先级逐个补充。每完成一个页面，都实际点击并检查关键交互：

等待片刻后，我们能够看到程序已经在之前的基础上补充了多个页面和可交互功能：

完成后，按真实使用顺序走一遍流程。记录无法点击、跳转错误或内容缺失的位置，再逐项修复。

有了多页面结构之后，我们从新用户的视角重新走一遍流程，检查输入、等待、结果、收藏和再次使用是否连贯。原型不需要拥有完整后台，但每个要演示的入口都应给出合理反馈。

让我们回顾最初的需求：

为了减少重复录入，可以准备一组测试数据，并在界面中提供“载入示例”的入口。这样每次刷新后都能快速复现同一条用户流程：

可以先准备一个正常示例，再补充信息缺失、图片格式不符等边界示例：

点击后得到结果：

如果结果立即出现，用户无法判断系统是否正在处理。可以加入一个短暂的加载状态，用来验证等待过程中的按钮、提示和占位内容：

走通生成功能后，我们还要确保模板库的功能正常，从页面的生成卡片上我们能够知道模版库收藏功能并没有实现，此时需要和 AI 进一步深入对话，“请你帮我确保需求 [此处粘贴上面的 2. 的内容] 正常，可以点击一个结果收藏对应的模板，点开后能看到生成参数”

第一次实现通常还会遗漏一些状态，可以结合截图逐项修正：

最后得到预期结果：

除了手动体验需求流程，你还可以让 AI 帮你直接做需求检查，例如：

AI 可以辅助生成检查清单，但最终仍要由你实际操作并确认结果。完成几轮检查后，原型就可以交给其他人试用。

参考本节课的提示词和内容，完成一次完整闭环：

完整闭环实践 业务梳理提示词生成 → 单页原型生成 → 多页原型生成 成果分享 截图你的程序分享给大家看 思考题 为下一节“接入大语言模型（LLM）和文生图能力”预留空间，提前思考：你的工作台里，可以怎样嵌入“AI 写文案 / 生成配图 / 生成脚本”等能力？

在下一节中，我们将在这个内容生产工作台的基础上，接入具体的 AI 能力（文字生文字、图片生文字、文字生图片），例如：