LINPO LAB 返回首页

从设计方案到可运行界面

一名 UI 设计师如何用 AI 独立做出一个 MVP。

AI 可以帮设计师写代码、搭页面、补状态,甚至启动一个可以操作的应用。但如果只把一张设计图交给 AI,得到的通常只是“看起来像”的页面:用户任务不完整,状态没有覆盖,移动端会溢出,下一轮修改也很难继续。

这篇文章提供一条更短、可以重复使用的路径:

想法
→ 多轮需求沟通
→ 一页 MVP PRD
→ 技术方案与实施计划
→ AI 生成可运行页面
→ 运行验收与修正

它面向没有产品经理、前端工程师,需要自己完成从需求到可运行 MVP 的 UI 设计师。AI 在过程中承担需求整理、技术分析、编码和初步检查;设计师负责目标、取舍、视觉判断和最终确认。

这里的“设计方案”不是一张已经画完的高保真视觉稿,而是经过讨论确认的用户任务、页面内容、关键状态和基本布局。它会先被记录为一页 MVP PRD,再由 AI 转成技术方案和可运行界面。

文章中的 MoreImg 不是一个一次生成的案例,而是这套流程多轮迭代后的产品。为了说明方法,先把它还原成最早的 MVP:调用文本模型 API,把一篇文章整理成至少 3 张图文卡片,并为每张卡片生成可以复制到其他生图工具的提示词。

第一步:和 AI 说清楚要做什么

不要从“帮我做一个页面”开始。先让 AI 通过提问,把模糊想法变成可以判断的任务。第一轮只做需求访谈,不写代码。

可复制提示词

我想做一个应用,请先不要写代码,通过提问帮我澄清需求。

我的初步想法:
{{填写应用想法}}

请重点确认:
1. 目标用户是谁;
2. 用户要完成的核心任务是什么;
3. 用户从哪里开始,到什么结果算完成;
4. MVP 必须保留哪些功能;
5. 哪些功能本轮明确不做;
6. 需要哪些页面或主要状态;
7. 需要接入哪些外部能力,开发时哪些部分可以先使用模拟数据;
8. 外部能力最终是否必须真实接通,怎样才算验证通过。

已经明确的信息不要重复提问。一次只问会影响实现的关键问题,不要扩展需求,不要写代码。

MoreImg 的填写示例

我想做一个“文章转小红书图文卡片工具”。

用户是需要快速制作小红书图文内容的内容创作者。
用户可以粘贴一篇文章,通过文本模型 API 生成至少 3 张卡片,
包括 1 张封面和至少 2 张内容页;卡片根据文章内容适配页数、风格和排版,
整套卡片保持统一视觉风格,用户可以查看并复制配图提示词到其他生图工具。

请按照要求帮我澄清这个应用的 MVP 范围。

多轮沟通后的收尾提示词

当关键问题已经讨论清楚后,直接让 AI 根据完整对话生成一页 MVP PRD。不再额外整理“访谈结论”,也不单独生成 UI 执行单。

请停止继续提问,根据我们前面的全部对话,整理一份可以直接用于实现的一页 MVP PRD。

请包含:
1. 产品目标和一句话说明;
2. 目标用户;
3. 用户当前遇到的问题;
4. 核心用户任务;
5. 从开始到完成的最小使用流程;
6. 页面清单、每个页面的主要内容和操作;
7. 默认、处理中、成功、失败、空状态和重试状态;
8. MVP 必须实现的功能;
9. 本轮明确不做的内容;
10. 数据来源、外部能力,以及界面需要获得的输出数据;
11. 开发阶段可以使用模拟数据的部分;
12. 桌面端和移动端的基本布局要求;
13. 可以通过实际操作判断的验收标准;
14. 仍待确认的问题。

要求:
- 只整理我们已经讨论过的内容,不补充新的需求;
- 明确区分“已确认”和“待确认”,不要把推测写成结论;
- 只保留完成核心任务所必需的内容,控制在一页内;
- 不自行增加登录、权限、后台、支付或复杂设置;
- 不生成技术方案、实施计划或代码;
- 输出完成后停下,等待我确认。

这一步的产物

一份经过确认、可以直接进入实施的一页 MVP PRD。设计师只检查三件事:核心任务是否完整、范围是否足够小、验收标准是否能通过实际操作判断。具体字段、数据校验和接口调用方式留到第二步确定。

第二步:根据 MVP PRD 生成技术方案和实施计划

第一步只有一页 MVP PRD,还没有代码项目。这一步以 PRD 为唯一输入,让 AI 选择足够简单、可以直接运行的技术方案,并把它整理成下一步可以直接执行的实施计划。

可复制提示词

请根据下面已经确认的 MVP PRD,生成一份可以直接执行的技术方案和实施计划。

当前从零开始,没有现有代码项目、技术栈或组件需要读取和复用。

请输出:
1. 最小技术方案,包括前端框架、运行方式和必要依赖;
2. 页面、组件和文件结构;
3. 核心流程、主要状态和移动端布局的实现方式;
4. 外部接口、密钥保存、最小返回结构和数据校验方式;
5. 开发阶段需要使用的模拟数据、切换到真实接口的方式,以及最终必须验证的真实能力;
6. 按执行顺序排列的实现任务;
7. 启动命令和验收方式。

MVP PRD:
{{粘贴确认后的一页 MVP PRD}}

要求:
- 采用简单、稳定、容易运行和维护的方案;
- 不增加 MVP PRD 之外的功能;
- 技术方案和实施计划放在同一份输出中;
- 暂时不要创建项目或写代码;
- 输出后停下,等待我确认。

MoreImg 的填写示例

请根据确认后的 MoreImg MVP PRD,从零生成技术方案和实施计划。计划至少说明:
- 采用什么最小技术栈,以及如何启动;
- 如何创建输入页、处理中状态和结果页;
- 使用一篇固定示例文章和一组至少 3 张的模拟 API 响应;
- 响应必须包含 1 张封面、至少 2 张内容页、统一风格说明和逐卡提示词;
- 支持查看卡片内容、展开提示词和复制单张/全部提示词;
- 开发时可以使用固定模拟响应,但最终必须接通真实文本模型 API,并验证返回结构;
- 不接图片生成接口,不新增登录、发布和编辑流程。

只输出技术方案和实施计划,不要创建项目或写代码。

设计师确认什么

只确认三件事:技术方案是否足够简单、模拟数据和真实能力的边界是否清楚、实施计划能否直接执行。没有明显问题,就让 AI 直接生成项目。

第三步:根据实施计划直接生成 MVP

实施计划确认后,不需要再拆成页面骨架、状态补齐等多轮任务。把 PRD 和实施计划交给 AI,一次完成可以运行和操作的 MVP。

可复制执行提示词

请根据已经确认的 MVP PRD 和实施计划,直接完成这个 MVP。

要求:
- 实现 PRD 中的完整核心路径和必要状态;
- 按实施计划处理桌面端、移动端、资源和数据结构;
- 可以先使用已确认的模拟数据,但不要把模拟能力表述为真实能力;
- PRD 要求真实接通的外部能力,必须在交付前使用真实请求验证;
- 不增加 PRD 以外的功能,不创建与 MVP 无关的文件和能力;
- 完成后启动项目,实际走一遍核心路径;
- 说明修改文件、访问地址、验证结果、使用模拟数据的部分和未完成内容。

执行过程中只有遇到会改变产品范围、数据结构或已确认技术方案的问题时才停下来询问;其他实现细节请按照实施计划直接完成。

MoreImg 的填写示例

请根据已经确认的 PRD 和实施计划,直接完成 MoreImg MVP。

保证用户可以完成:
粘贴文章 → 调用文本模型 API → 查看卡片 → 复制配图提示词。

至少生成 1 张封面和 2 张内容页,显示统一视觉风格和逐卡配图提示词,支持复制单张和全部提示词。包含输入为空、处理中、失败重试和结果异常提示;移动端保持核心操作可达。

开发阶段可以先使用固定模拟响应,但最终必须接通真实文本模型 API,并验证返回结构和完整路径。不要加入登录、发布、卡片编辑器或图片生成接口。

第四步:运行、验收和修正

第三步的验证是 AI 在交付前完成的开发自检,负责确认项目可以启动、核心路径没有阻断。AI 说“完成”仍不等于应用已经通过验收;第四步由设计师根据 MVP PRD 独立操作,检查任务、状态、视觉和不同视口的体验。

可复制验收提示词

请根据 MVP PRD 中的验收标准检查当前运行中的应用。

验收标准:
{{粘贴 MVP PRD 中的验收标准}}

请分别检查:
1. 页面是否可以启动和进入;
2. 核心任务是否可以从头走到完成;
3. 各个已确认状态是否可见且可继续操作;
4. 宽桌面、窄桌面和移动端是否有溢出、遮挡或操作不可达;
5. 图片、图标、字体和内容是否正确;
6. 控制台和资源加载是否有明显错误。

请输出问题清单,包含:问题、页面、状态、严重程度、建议修复方式。
不要直接修改代码。

MoreImg 的填写示例

请检查 MoreImg MVP 的完整路径:
粘贴示例文章 → 点击开始处理 → 发起真实文本模型 API 请求 → 等待处理完成 →
查看封面和内容页 → 展开配图提示词 → 点击复制全部。

重点检查:输入为空、真实 API 处理中、失败重试、至少 3 张卡片、封面/内容页结构、
统一视觉风格字段、移动端卡片排列和复制按钮是否可达。
先输出问题清单,不要直接改代码。

可复制修正提示词

请只修复下面的问题,不要重写其他已经正常的结构和交互。

问题类型:{{结构 / 视觉 / 交互 / 响应式 / 资源}}
问题清单:
{{粘贴验收结果}}

要求:
- 保持 MVP PRD 和已确认的实施计划不变;
- 只修改解决这些问题所需的文件;
- 完成后说明修改内容和验证结果;
- 如果问题依赖未确认的业务规则,先停下来标记待确认。

这套流程为什么足够简单

它只保留三样东西:

实施计划确认后就直接生成页面,不为小型 MVP 额外维护访谈结论、UI 执行单或分阶段开发文档。只有项目复杂度明显上升时,才需要把实施拆成多轮。

MoreImg 是怎样从 MVP 变成现在的产品的

MoreImg 的 MVP 只需要验证一条路径:

粘贴文章
→ 调用文本模型 API
→ 生成至少 3 张卡片内容
→ 生成统一风格的逐卡配图提示词
→ 查看配图提示词
→ 复制提示词到其他生图工具

经过多轮运行和验收后,才逐渐增加文章处理阶段、内容核查、卡片关系、提示词对应、更多状态和更完整的视觉表达。现在的 MoreImg 页面是迭代结果,不是这套方法的起点。

MoreImg 当前界面对照展示 HTML 主视觉、AI 整图和原始视觉提示词
当前界面已经可以对照查看 HTML 主视觉、AI 整图和原始视觉提示词,并提供重新生成入口。截图只能证明对照、重生成和提示词查看界面已经形成,不代表图片质量或接口运行稳定性。点击图片查看原图。

这也是使用 AI 做界面时最重要的控制方式:先让一个小任务真实跑通,再根据使用中的问题扩展产品,而不是一开始就把最终产品的所有想象交给 AI。

设计师和 AI 的边界

AI 可以:

设计师仍然需要决定:

AI 负责把决定变成可运行的界面,设计师负责决定什么值得被实现,以及实现后是否真的成立。

对我来说,Design to Code 不是“把设计稿转换成代码”,而是一条可以被重复执行的工作链:先用 AI 把想法收敛成一页 MVP PRD,确认实施计划后直接生成一个能运行的版本,最后用真实操作决定下一轮改什么。

这套方法的目标不是一次生成最终产品,而是让一个 UI 设计师能够独立、低成本地把一个想法推进到可运行的第一版。

查看 MoreImg 一文多图实验 →