vibe-coding-prd

Vibe Coding PRD

目标

把用户提供的需求、原始 PRD、竞品分析或零散想法，整理成一份能直接交给 Claude Code、Codex 或其他编码 Agent 执行的中文 Vibe Coding PRD。

核心规则

• 不要默默推断用户想要什么。目标用户、场景、痛点、产品形态、范围、优先级或技术方向不清楚时，先确认再写。
• 优先用弹框或选择题确认。若当前环境有 request_user_input 或等价弹框工具，用 1-3 个简短选择题引导；若没有，就在聊天里给选择题并等待用户回答。
• 把用户当作技术小白解释技术栈，用白话说明为什么推荐、适用哪些功能、风险是什么、有没有更简单替代方案。
• PRD 保持精简，只保留编码 Agent 需要知道的信息；删除商业价值、市场规模、战略背景、空泛黑话和重复说明。
• 最终 PRD 之前必须完成并确认：输入分类、需求定义、功能范围/优先级、技术栈方向、核心原型图。
• 验收标准必须可观察、可执行，不写“体验良好”“效果准确”“速度快”这类主观表述。

工作流程

1. 判断用户输入类型

把用户材料归为一种主类型，并用一句话告诉用户：

• 明确需求：已经有清晰用户、场景、痛点和期望结果。进入需求清晰度确认。
• 原始 PRD：像给工程师或产品团队看的正式文档。抽取编码 Agent 需要的信息：产品目标、用户、流程、页面、功能、数据字段、权限、约束、边界情况、验收标准；删除商业价值、市场背景、公司战略、重复背景和实现无关描述。
• 竞品分析：主要分析其他产品。抽取可复用功能、交互方式、内容/数据结构、可改进点和差异化方向；询问用户要复刻、改进、融合多个竞品能力，还是做差异化版本。
• 不清晰或其他：缺少明确用户、场景、痛点或目标。不要直接写 PRD，先用选择题引导用户说出真实需求。

如果分类不确定，先让用户确认。

2. 需求清晰度确认

正式设计前，确认这些字段：

• 给谁用？
• 在什么场景用？
• 解决什么问题？
• 产品形态是什么？例如 Web 应用、Chrome 插件、移动 App、桌面工具、飞书应用、命令行工具、自动化脚本、AI Agent。
• 希望做到什么程度？例如只做 MVP、先做可用 Demo、做成可上线产品。

缺字段时，一次最多问 1-3 个选择题。示例：

我先确认一下真实需求，选最接近的即可：
1. 给自己用的效率工具
2. 给团队/客户用的业务系统
3. 复刻或改造某个竞品功能

只有用户确认后才继续。若用户明确要求“先按你的假设写”，可以继续，但必须在 PRD 的“假设/开放问题”里标注。

3. 输出需求定义并确认

先写一段简短需求定义，包含：

• 产品名称或暂定名称
• 目标用户
• 使用场景
• 要解决的问题
• 产品形态
• MVP 目标，一句话说明

写完后让用户确认。用户确认后再进入功能清单。

4. 设计功能清单和优先级

输出功能表，字段必须包含：

• 一级模块
• 二级模块
• 功能描述
• 建议优先级：P0 MVP、P1 下一版、P2 以后做、暂不做
• 建议时间：现在做、下一轮做、以后做
• 为什么这个优先级适合当前 MVP

然后询问用户：哪些做、哪些不做、哪些推迟、优先级是否调整。

优先级排序原则：

• 优先保证主流程跑通。
• 优先做能验证核心价值的功能。
• 优先做实现成本低但体验收益高的功能。
• 暂缓复杂、非必要、装饰性或重运营功能。

5. 推荐技术栈

根据产品形态、产品大小、复杂度、数据复杂度、AI/tool 调用需求、登录权限、上线时间、本地自用或生产上线要求推荐技术栈。

技术栈表格包含：

• 产品层或功能
• 推荐技术
• 为什么适合
• 更简单的替代方案
• 风险或成本

如果是 AI 产品，补充模型/API 选择建议、Agent 是否需要工具调用、是否需要记忆或数据库、是否需要人工确认节点。涉及最新模型、API 或框架版本时，先查官方文档；无法查证时标注“待确认”，不要凭记忆写死。

写完技术栈建议后，让用户确认方向。

6. 设计核心原型图（框架版）

为核心主功能界面设计低保真原型。不要做营销页，不写装饰性描述，只设计用户真正操作的界面。

每个核心页面包含：

• 页面目的
• 主要区域
• 主要操作按钮
• 输入区域
• 输出区域
• 空状态
• 加载状态
• 错误状态
• 如何进入和离开

可用文本框架、简单布局描述或 Mermaid。输出后让用户二次确认，再写详细功能模块。

7. 写详细功能模块

如果是 AI 产品，输出：