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

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 的理解是否正确

三、一套可落地的工作流

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

第一步：MVP 级 UI 原型

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

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

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

第二步：视觉审查与标注

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

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

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

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

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

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

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

可视化 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 画页面，再让它写文档。你可能会发现，整个开发过程的体感完全不一样。