# AI 编程新思路：从 UI 倒推 PRD，让需求可视化


<!-- more -->

Vibe Coding 的常规流程大家已经很熟悉：写用户故事 → 输出 PRD → AI 生成后端 → AI 生成前端 → 演示验证。这个流程能跑通，但最终交付时往往发现 UI 交互体验和预期差距很大。问题出在哪里？出在 PRD 本身。

## 一、PRD 的根本困境

PRD（Product Requirements Document）对人类来说就不太友好。原因有三：

**文字描述天然模糊。** "用户点击按钮后弹出确认框"——这个描述看起来很清楚，但按钮的位置、大小、确认框的样式、确认后的跳转逻辑、异常处理……每一个细节都藏着分歧空间。PRD 写得越详细，阅读成本越高，到最后自己写的东西都不想看第二遍。

**审查效率极低。** 逐行审查一份几千字的 PRD，远不如看一眼页面原型来得直观。文字描述需要你在脑中"渲染"出界面，这个翻译过程本身就引入了理解偏差——你和 AI 的"脑内渲染"很可能完全不同。

**返工链条太长。** 发现一个交互问题，往往要从 PRD 改到后端接口，再改到前端组件，一套修改下来三四个小时，Token 消耗在千万级别。而问题的根源仅仅是最初对"按钮应该在哪里"这件事的理解不一致。

## 二、换一个方向：从 UI 入手

核心想法很简单：**既然最终要通过 UI 来验证，为什么不从 UI 开始？**

传统流程是 `PRD → 代码 → UI → 验证`，新流程改为：

`UI 原型 → 视觉确认 → 反向推导 PRD → 工程化实现`

这不是凭空想象。社区里不少实践者已经在走这条路：

- 有人用 Codex 生成一套 HTML 页面，再让 Claude 做图片识别来验证
- 有人习惯"永远先做 UI"，从界面倒推功能逻辑
- 近期流行的"让 AI 输出 HTML 而非 Markdown"趋势，本质上就是借助视觉形态来快速确认 AI 的理解是否正确

{{< image src="/pictures/note/ui-first-ai-workflow.svg" alt="UI-First 工作流对比图" caption="传统流程 vs UI-First 流程：核心差异在于验证节点的位置" >}}

## 三、一套可落地的工作流

基于社区讨论和实践反馈，整理出以下具体步骤：

### 第一步：MVP 级 UI 原型

不写完整 PRD，而是直接让 AI 生成若干 HTML 页面。这些页面应当包含：

- 所有主要页面和导航结构
- 每个页面的核心功能区域
- 标注性注释或说明文字（用 HTML 注释即可）
- 关键交互的简单 JS 演示（展开/折叠、Tab 切换等）

对 AI 的提示可以很直接："我要做一个 XX 产品，请帮我生成以下页面的 HTML 原型：首页、列表页、详情页、设置页。每个页面要展示核心功能和交互逻辑。"

### 第二步：视觉审查与标注

拿到 HTML 原型后直接在浏览器中查看。这一步的价值在于：

**审查速度提升一个数量级。** 看一眼就知道导航栏是否合理、信息密度是否合适、操作流程是否顺畅。对比在脑中"翻译" PRD 文字描述，效率天差地别。

**问题定位精准。** 发现缺少某个功能，直接在页面上标注："这里需要一个筛选器"，"这个区域应该显示最近操作记录"。AI 能直接理解上下文。

**保留对话历史。** 将与 AI 的交互记录保存下来，这些上下文在后续生成 PRD 时极其重要。

### 第三步：反向生成可视化 PRD

这一步是整个工作流的关键创新。将视觉材料和对话记录交给 AI，让其生成一份"可视化 PRD"。

这份 PRD 与传统 PRD 的区别在于：

| 维度 | 传统 PRD | 可视化 PRD |
|------|---------|-----------|
| 核心载体 | 文字描述 | 页面截图 + 交互标注 |
| 审查方式 | 逐行阅读 | 一眼判断 |
| 理解偏差 | 高（需要脑内渲染） | 低（所见即所得） |
| 与产品的差距 | 大（文字到 UI 有鸿沟） | 小（仅差工程化实现） |

可视化 PRD 包含：页面截图、交互流程说明、功能边界定义、数据结构概要。别人拿到这份文档，能直接想象出产品长什么样、怎么用。

### 第四步：交互演示（可选增强）

更进一步，可以让 AI 针对用户故事生成简短的交互演示：

- 口述整个操作流程："用户打开应用，看到首页推荐列表，点击某条记录进入详情，在详情页可以收藏和评论……"
- AI 基于原型页面生成演示视频或动效
- 结合可视化 PRD 重新整理

这样产出的 PRD 既有静态视觉又有动态演示，将理解偏差压到最低。

### 第五步：工程化交付

最后一步才是让 AI 的代码工程化能力介入，将"可视化 PRD"转译成最终产品。此时 AI 拥有：

- 清晰的页面结构和交互定义
- 前几轮对话中积累的上下文
- 经过视觉验证的功能边界

这些信息远比一份纯文字 PRD 更加明确和可执行。

## 四、实际收益分析

从社区反馈和实践经验来看，这套流程的优势集中在三个方面：

**减少返工。** 传统流程中"做完了才发现不对"的问题被前置到原型阶段。改一个 HTML 原型比改一套前后端代码快得多，Token 消耗也低一个量级。

**降低沟通成本。** 可视化 PRD 让所有参与者（产品、开发、设计）在同一份视觉材料上对齐认知。不再出现"我以为你说的是这个意思"的情况。

**加速验证闭环。** 从"想清楚要什么"到"看到它长什么样"的时间从几天缩短到几十分钟。你可以快速迭代多个方案，而不是把所有赌注押在一个可能理解错误的 PRD 上。

## 五、局限与适用场景

这套方法并非万能：

- **纯后端/基础设施类项目**不太适用，这些项目的核心不在 UI 而在架构设计和性能指标
- **需要大量数据处理的页面**可能需要额外的数据流描述来补充视觉原型
- **团队协作时**需要额外的工具支持来管理视觉材料和标注

但对大多数面向用户的 Web 应用、工具类产品、内容平台来说，UI-First 的工作流能显著提升 AI 辅助开发的效率和交付质量。

## 六、总结

AI 编程时代的核心矛盾，不是 AI 能不能写代码，而是我们能不能把需求表达清楚。传统的文字型 PRD 在人之间的沟通中就已经问题重重，交给 AI 执行只会放大这些偏差。

从 UI 倒推 PRD，本质上是用"人最擅长理解的媒介"（视觉）来替代"人最不擅长的媒介"（大段文字描述），从而在人和 AI 之间建立更准确的需求传递通道。

这个思路还在持续演进中。如果你也在做 Vibe Coding，不妨试一试：下次启动新项目时，先让 AI 画页面，再让它写文档。你可能会发现，整个开发过程的体感完全不一样。