最近在用 AI 做 vibe coding，走的是常规流程：先写用户故事和 PRD，然后后端，再前端，最后演示验证。东西能跑起来，但我逐渐发现一个核心问题——最终的 UI 交互体验很差。
PRD 本身对人就不太友好。命名、流程描述这类内容很难直观审查，自己写的东西都不想多看几遍，更别说指望 AI 严格执行了。结果就是最终产品与预期差距很大，而且不知道从哪里着手去改。
我试着换了个角度：能不能不先从 PRD 切入，而是从 UI 和交互切入？
具体来说，先明确要做什么，然后定义界面长什么样、用户如何操作，确认有哪些页面以及每个页面的核心功能。让 AI 生成页面之后，通过视觉快速判断哪里缺东西，再让 AI 基于这个页面去反向理解和转译 PRD。这比先写一堆文字描述要高效得多。
最近有个流行的做法是让 AI 直接输出 HTML 而不是 Markdown——本质上是借助视觉形态快速确认 AI 的理解是否正确。相比之下，逐行审查代码的效率确实很低。
而且从 UI 倒着推还有一个好处：减少误解和返工。目前我改一个交互点，往往要牵连后端逻辑一起调整，一套修改下来三四个小时，Token 消耗在千万级别（即使是国产模型，换成最先进的也得大几百万）。验证流程和后端测试这些环节一样也省不了。
基于这些经验，我设想了一套尚未实践的新工作流，这里写出来供讨论：
第一步，不写完整 PRD，而是先做一个 MVP 级别的描述。内容包括：若干 HTML 页面，页面上带有标注性注释或说明文字，甚至可以包含简单的 JS 交互示意。把这份材料交给 AI，告知需要调整的地方和关注的核心点。同时，把与 AI 的交互历史保存下来。
第二步，基于上述视觉材料和对话记录，重新生成一份 PRD。我把它称为“AI 时代的 PRD”——以可视化为核心，而非文字。别人一看这份 PRD，就能大致想象出产品的功能和样子。它与最终产品的差距基本只在于：功能的完备性、UI 交互细节的打磨，以及一些工程化内容。
更进一步，还可以让 AI 针对用户故事生成一个简短的交互视频：你口述整个操作流程，AI 输出演示视频，再结合文档重新整理。这样产出的 PRD 既有视觉又有动态演示，能大幅减少理解偏差。
最后，再借助 AI 的代码工程化能力，将这份“可视化 PRD”转译成最终产品。
这套思路我还没有真正落地，但感觉方向值得一试。
1 个帖子 - 1 位参与者