用原型驱动开发：用 AI 生成可交互原型替代 PRD
2026/6/25大约 7 分钟
为什么 PRD 总是理解不一致？
为什么开发做出来的东西和预期不一样？
为什么要在写代码前就暴露分歧？
原型驱动开发的答案：
用 AI 生成可交互原型替代 PRD。
问题：PRD 的理解陷阱
PRD（Product Requirements Document）有一个致命问题： " 它需要读者在脑海中"渲染"出产品。
┌─────────────────────────────────────────────────────────┐
│ PRD 的理解陷阱 │
├─────────────────────────────────────────────────────────┤
│ │
│ PRD 文档（静态文字） │
│ ┌─────────────────────────────────────────────────┐ │
│ │ "用户点击登录按钮后，弹出登录弹窗" │ │
│ │ "弹窗包含用户名和密码输入框" │ │
│ │ "点击取消后弹窗消失" │ │
│ └─────────────────────────────────────────────────┘ │
│ ↓ │
│ 每个人脑海中的"渲染"结果不同 │
│ ┌─────────────────────────────────────────────────┐ │
│ │ 产品经理：看到的是移动端样式 │ │
│ │ 设计师：看到的是暗色主题 │ │
│ │ 开发：看到的是桌面端布局 │ │
│ └─────────────────────────────────────────────────┘ │
│ ↓ │
│ 分歧暴露在开发后期 │
│ ┌─────────────────────────────────────────────────┐ │
│ │ "这和我想的不一样！" │ │
│ │ "需求不是这样的！" │ │
│ │ "为什么要返工？" │ │
│ └─────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘为什么 PRD 会失效？
原因 1：文字的抽象性
文字描述天然具有抽象性：
┌─────────────────────────────────────────────────────────┐
│ 文字的抽象性示例 │
├─────────────────────────────────────────────────────────┤
│ │
│ PRD 描述："简洁的登录界面" │
│ ┌─────────────────────────────────────────────────┐ │
│ │ 产品经理理解： │ │
│ │ - 少量输入框 │ │
│ │ - 清晰的标签 │ │
│ │ - 大的按钮 │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ 设计师理解： │
│ ┌─────────────────────────────────────────────────┐ │
│ │ - 极简风格 │ │
│ │ - 留白充足 │ │
│ │ - 色彩克制 │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ 开发理解： │
│ ┌─────────────────────────────────────────────────┐ │
│ │ - 代码结构简单 │ │
│ │ - 逻辑清晰 │ │
│ │ - 易于维护 │ │
│ └─────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘原因 2：语境缺失
PRD 无法传达所有上下文：
┌─────────────────────────────────────────────────────────┐
│ 语境缺失的问题 │
├─────────────────────────────────────────────────────────┤
│ │
│ PRD 写了什么： │
│ ┌─────────────────────────────────────────────────┐ │
│ │ - 功能列表 │ │
│ │ - 交互流程 │ │
│ │ - 验收标准 │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ PRD 没写什么（但在作者脑子里）： │
│ ┌─────────────────────────────────────────────────┐ │
│ │ - 设计风格 │ │
│ │ - 交互细节 │ │
│ │ - 异常处理 │ │
│ │ - 边缘情况 │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ 结果：读者只能"脑补"缺失的信息 │
│ │
└─────────────────────────────────────────────────────────┘原因 3：分歧暴露时机
PRD 最致命的问题是：分歧暴露得太晚。
┌─────────────────────────────────────────────────────────┐
│ 分歧暴露的时间线 │
├─────────────────────────────────────────────────────────┤
│ │
│ 传统流程： │
│ ┌─────────────────────────────────────────────────┐ │
│ │ │ │
│ │ 写 PRD ──→ 开发 ──→ 测试 ──→ 验收 │ │
│ │ ↑ │ │
│ │ │分歧在这里暴露！ │ │
│ │ │"这和我想的不一样！" │ │
│ │ │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ 问题： │
│ ┌─────────────────────────────────────────────────┐ │
│ │ - 代码已经写好 │ │
│ │ - 返工成本高 │ │
│ │ - 时间已经浪费 │ │
│ │ - 团队士气受损 │ │
│ └─────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘解决方案：原型驱动开发
原型驱动开发（Prototype-Driven Development）的核心思想：
用可交互原型替代静态 PRD，提前暴露分歧。
┌─────────────────────────────────────────────────────────┐
│ 原型驱动开发的流程 │
├─────────────────────────────────────────────────────────┤
│ │
│ 新流程： │
│ ┌─────────────────────────────────────────────────┐ │
│ │ │ │
│ │ 需求讨论 ──→ AI 生成原型 ──→ 原型评审 │ │
│ │ ↑ │ │
│ │ │分歧在这里暴露！ │ │
│ │ │"这和我想的不一样！│ │
│ │ ↓ │ │
│ │ 快速迭代原型 │ │
│ │ ↓ │ │
│ │ 达成一致 │ │
│ │ ↓ │ │
│ │ 开发实现 │ │
│ │ │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ 优势： │
│ ┌─────────────────────────────────────────────────┐ │
│ │ - 在写代码前暴露分歧 │ │
│ │ - 返工成本低 │ │
│ │ - 所有人看到的是同一个东西 │ │
│ │ - 可以快速迭代 │ │
│ └─────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘为什么是 AI 生成原型？
传统原型制作的问题
为什么以前没有用原型替代 PRD？
┌─────────────────────────────────────────────────────────┐
│ 传统原型制作的痛点 │
├─────────────────────────────────────────────────────────┤
│ │
│ 痛点 1：成本高 │
│ ┌─────────────────────────────────────────────────┐ │
│ │ 需要专业工具（Figma、Sketch） │ │
│ │ 需要专业技能 │ │
│ │ 制作时间长 │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ 痛点 2：迭代慢 │
│ ┌─────────────────────────────────────────────────┐ │
│ │ 修改需要重新设计 │ │
│ │ 交互逻辑调整复杂 │ │
│ │ 无法快速试错 │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ 痛点 3：只能看不能玩 │
│ ┌─────────────────────────────────────────────────┐ │
│ │ 通常是静态设计稿 │ │
│ │ 无法真实交互 │ │
│ │ 仍然需要"脑补"动态效果 │ │
│ └─────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘AI 带来的改变
AI 让原型驱动开发变得可行：
┌─────────────────────────────────────────────────────────┐
│ AI 原型生成的优势 │
├─────────────────────────────────────────────────────────┤
│ │
│ 优势 1：成本低 │
│ ┌─────────────────────────────────────────────────┐ │
│ │ 只需要自然语言描述 │ │
│ │ AI 自动生成可交互原型 │ │
│ │ 不需要专业技能 │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ 优势 2：迭代快 │
│ ┌─────────────────────────────────────────────────┐ │
│ │ 修改只需要调整描述 │ │
│ │ AI 重新生成原型 │ │
│ │ 可以快速试错 │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ 优势 3：真实交互 │
│ ┌─────────────────────────────────────────────────┐ │
│ │ 生成可交互的原型 │ │
│ │ 可以真实点击和操作 │ │
│ │ 不需要"脑补"任何效果 │ │
│ └─────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘实践：如何用 AI 生成原型
步骤 1：描述需求
用自然语言描述产品需求：
┌─────────────────────────────────────────────────────────┐
│ 需求描述示例 │
├─────────────────────────────────────────────────────────┤
│ │
│ 作为一个用户，我想要： │
│ ┌─────────────────────────────────────────────────┐ │
│ │ │ │
│ │ 1. 在首页看到一个登录按钮 │ │
│ │ │ │
│ │ 2. 点击登录按钮后，弹出一个登录弹窗 │ │
│ │ 弹窗包含： │ │
│ │ - 用户名输入框 │ │
│ │ - 密码输入框 │ │
│ │ - 登录按钮 │ │
│ │ - 取消按钮 │ │
│ │ │ │
│ │ 3. 点击取消按钮，弹窗关闭 │ │
│ │ │ │
│ │ 4. 点击登录按钮，验证用户名和密码 │ │
│ │ - 如果正确，跳转到首页 │ │
│ │ - 如果错误，显示错误提示 │ │
│ │ │ │
│ └─────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘步骤 2：AI 生成原型
AI 根据需求描述生成可交互原型：
┌─────────────────────────────────────────────────────────┐
│ AI 生成的原型结构 │
├─────────────────────────────────────────────────────────┤
│ │
│ AI 生成： │
│ ┌─────────────────────────────────────────────────┐ │
│ │ │ │
│ │ <html> │ │
│ │ <head> │ │
│ │ <style> │ │
│ │ /* 样式定义 */ │ │
│ │ </style> │ │
│ │ </head> │ │
│ │ <body> │ │
│ │ <!-- 登录按钮 --> │ │
│ │ <button id="loginBtn">登录</button> │ │
│ │ │ │
│ │ <!-- 登录弹窗（初始隐藏） --> │ │
│ │ <div id="loginModal" style="display:none"> │ │
│ │ <input type="text" id="username"> │ │
│ │ <input type="password" id="password"> │ │
│ │ <button id="confirmBtn">登录</button> │ │
│ │ <button id="cancelBtn">取消</button> │ │
│ │ </div> │ │
│ │ │ │
│ │ <script> │ │
│ │ /* 交互逻辑 */ │ │
│ │ </script> │ │
│ │ </body> │ │
│ │ </html> │ │
│ │ │ │
│ └─────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘步骤 3：原型评审
团队成员评审原型，暴露分歧：
┌─────────────────────────────────────────────────────────┐
│ 原型评审示例 │
├─────────────────────────────────────────────────────────┤
│ │
│ 产品经理： │
│ ┌─────────────────────────────────────────────────┐ │
│ │ "弹窗应该在屏幕中央，现在偏左了" │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ 设计师： │
│ ┌─────────────────────────────────────────────────┐ │
│ │ "登录按钮应该用主色调，现在是灰色的" │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ 开发： │
│ ┌─────────────────────────────────────────────────┐ │
│ │ "错误提示应该在输入框下方，不是弹窗" │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ ──────────────────────────────────────────────────── │
│ │
│ **分歧暴露！现在修改成本几乎为零！** │
│ │
└─────────────────────────────────────────────────────────┘步骤 4：快速迭代
根据反馈快速迭代原型：
┌─────────────────────────────────────────────────────────┐
│ 快速迭代流程 │
├─────────────────────────────────────────────────────────┤
│ │
│ 迭代 1：调整弹窗位置 │
│ ┌─────────────────────────────────────────────────┐ │
│ │ "弹窗居中显示" ──→ AI 重新生成 ──→ 再次评审 │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ 迭代 2：调整按钮样式 │
│ ┌─────────────────────────────────────────────────┐ │
│ │ "登录按钮用主色调" ──→ AI 重新生成 ──→ 再次评审 │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ 迭代 3：调整错误提示位置 │
│ ┌─────────────────────────────────────────────────┐ │
│ │ "错误提示在输入框下方" ──→ AI 重新生成 │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ 结果： │
│ ┌─────────────────────────────────────────────────┐ │
│ │ - 所有人对原型达成一致 │ │
│ │ - 分歧在开发前暴露 │ │
│ │ - 返工成本几乎为零 │ │
│ └─────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘对比：PRD vs 原型
成本对比
┌─────────────────────────────────────────────────────────┐
│ PRD vs 原型成本对比 │
├─────────────────────────────────────────────────────────┤
│ │
│ PRD 流程： │
│ ┌─────────────────────────────────────────────────┐ │
│ │ │ │
│ │ 写 PRD（2天） ──→ 开发（10天） ──→ 验收 │ │
│ │ ↑ │ │
│ │ │ │ │
│ │ 发现分歧，返工 │ │
│ │ ↓ │ │
│ │ 重新开发（5天） │ │
│ │ ↓ │ │
│ │ 总成本：17天 │ │
│ │ │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ 原型流程： │
│ ┌─────────────────────────────────────────────────┐ │
│ │ │ │
│ │ 描述需求（0.5天） ──→ AI生成原型（0.5天） │ │
│ │ ↓ │ │
│ │ 评审迭代（1天） │ │
│ │ ↓ │ │
│ │ 达成一致 │ │
│ │ ↓ │ │
│ │ 开发（10天） │ │
│ │ ↓ │ │
│ │ 验收通过 │ │
│ │ ↓ │ │
│ │ 总成本：12天 │ │
│ │ │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ 节省时间：5天（30%） │
│ │
└─────────────────────────────────────────────────────────┘质量对比
┌─────────────────────────────────────────────────────────┐
│ PRD vs 原型质量对比 │
├─────────────────────────────────────────────────────────┤
│ │
│ 理解一致性： │
│ ┌─────────────────────────────────────────────────┐ │
│ │ PRD：每个人都看到不同的"脑补"结果 │ │
│ │ 原型：每个人都看到同一个可交互的东西 │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ 分歧暴露时机： │
│ ┌─────────────────────────────────────────────────┐ │
│ │ PRD：开发后期才暴露，返工成本高 │ │
│ │ 原型：开发前就暴露，返工成本低 │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ 迭代速度： │
│ ┌─────────────────────────────────────────────────┐ │
│ │ PRD：修改文档需要重新撰写、评审 │ │
│ │ 原型：修改描述即可重新生成 │ │
│ └─────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘关键成功因素
1. 描述质量
AI 生成的原型质量取决于需求描述的质量：
┌─────────────────────────────────────────────────────────┐
│ 好的需求描述 vs 差的需求描述 │
├─────────────────────────────────────────────────────────┤
│ │
│ 差的描述： │
│ ┌─────────────────────────────────────────────────┐ │
│ │ "我要一个登录功能" │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ 好的描述： │
│ ┌─────────────────────────────────────────────────┐ │
│ │ │ │
│ │ "作为一个用户，我想要： │ │
│ │ │ │
│ │ 1. 在首页看到登录按钮 │ │
│ │ 2. 点击后弹出登录弹窗 │ │
│ │ 3. 弹窗包含用户名、密码输入框和登录、取消按钮 │ │
│ │ 4. 点击取消关闭弹窗 │ │
│ │ 5. 点击登录验证信息 │ │
│ │ 6. 验证成功跳转首页，失败显示错误提示 │ │
│ │ │ │
│ └─────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘2. 迭代思维
原型驱动开发需要快速迭代的思维：
┌─────────────────────────────────────────────────────────┐
│ 迭代思维的关键 │
├─────────────────────────────────────────────────────────┤
│ │
│ 思维 1：接受不完美 │
│ ┌─────────────────────────────────────────────────┐ │
│ │ 第一版原型不需要完美 │ │
│ │ 目标是快速暴露分歧，不是做出最终产品 │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ 思维 2：快速反馈 │
│ ┌─────────────────────────────────────────────────┐ │
│ │ 尽早让团队成员评审原型 │ │
│ │ 收集反馈并快速迭代 │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ 思维 3：拥抱变化 │
│ ┌─────────────────────────────────────────────────┐ │
│ │ 需求可能会变化 │ │
│ │ 原型可以快速调整 │ │
│ │ 这是优势，不是问题 │ │
│ └─────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘3. 团队协作
原型驱动开发需要团队协作：
┌─────────────────────────────────────────────────────────┐
│ 团队协作的关键 │
├─────────────────────────────────────────────────────────┤
│ │
│ 协作 1：全员参与评审 │
│ ┌─────────────────────────────────────────────────┐ │
│ │ 产品、设计、开发、测试都要参与原型评审 │ │
│ │ 每个人都有不同的视角，能发现不同的问题 │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ 协作 2：坦诚沟通 │
│ ┌─────────────────────────────────────────────────┐ │
│ │ 看到问题立即指出 │ │
│ │ 不要等到开发后才说"这不对" │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ 协作 3：达成一致 │
│ ┌─────────────────────────────────────────────────┐ │
│ │ 在开发前确保所有人对原型达成一致 │ │
│ │ 这是原型驱动开发的核心目标 │ │
│ └─────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘收尾金句
- 为什么 PRD 总是理解不一致？因为文字需要"脑补"
- 为什么开发做出来的东西和预期不一样？因为每个人看到的是不同的"脑补"结果
- 原型驱动开发：用 AI 生成可交互原型替代 PRD
- 在写代码前暴露分歧，返工成本几乎为零
- AI 让原型驱动开发变得可行：低成本、快速迭代、真实交互
- 好的需求描述是成功的关键
- 接受不完美，快速反馈，拥抱变化
- 全员参与评审，坦诚沟通，达成一致
- 从文字到原型，从脑补到实际
- 让所有人看到同一个东西
用原型驱动开发：用 AI 生成可交互原型替代 PRD
提前暴露分歧，降低返工成本