| name | vibe-coding-prd |
|---|---|
| description | Distills vague requirements, engineering-oriented PRDs, or competitor analyses into a lean "vibe coding PRD" that can be handed directly to coding agents like Claude Code / Codex. Triggers when the user says "help me write a PRD for vibe coding," or wants to turn requirements/a PRD/competitor analysis into a PRD for a coding agent to consume. |
Vibe Coding PRD 生成器
目标
把用户提供的原始素材（需求描述 / 工程向PRD / 竞品分析 / 模糊想法）转化为一份结构清晰、编码Agent可以直接理解并据此写代码的PRD。最终产出一份完整的Markdown文件，保存到当前工作目录。
核心原则（执行限制，必须遵守）
- 不要替用户做主观判断。 任何涉及"用户想要什么"的分支选择、优先级排序、技术栈取舍、原型确认，都必须用 AskUserQuestion 工具弹出选择题确认，不能自己脑补后直接往下走。
- 内容要精简。 避免黑话，避免写为工程师准备的商业价值/市场分析类内容，只保留编码Agent写代码需要知道的信息。
- 验收标准必须可操作、可验证。 禁止"体验良好""性能优秀"这类无法验证的表述，必须写成"点击X按钮后，出现Y"这种可直接验证的动作-结果对。
- 全程用中文（除非用户的输入是英文）。
- 不要跳步：只有在当前部分获得用户确认后，才进入下一部分。
工作流程
第一步：判断输入类型
读完用户提供的原始内容后，判断属于以下哪一种；如果拿不准，直接用 AskUserQuestion 问用户确认，不要自己猜：
- A. 明确需求：已经有清晰的目标用户、使用场景、痛点。→ 直接进入"第二步"。
- B. 原始工程向PRD：写给工程师看的传统PRD，包含背景/商业价值/竞品分析/KPI/详细交互稿等。→ 先做"提炼"：抽取出目标用户、场景、核心问题、功能清单、交互细节等编码Agent需要的信息，删除商业价值论证、市场规模、KPI、老板汇报向的内容，只保留会影响代码实现的部分。提炼完成后进入"第二步"。
- C. 竞品分析：一堆关于同类产品的功能罗列/截图/描述。→ 先用 AskUserQuestion 确认意图，例如问："这份竞品分析，你是想整体对标做一个类似产品，还是只借鉴其中部分功能？"（选项：整体对标做类似产品 / 只借鉴部分功能，我来挑 / 还没想清楚，帮我先理一理）。确认后合成为清晰需求，进入"第二步"。
- D. 完全不清晰（一句话、一个模糊想法、甚至只有一个关键词）：不要直接开始设计。用 AskUserQuestion 连续追问，尽量用选择题引导用户说出真实需求，例如：
- "这个产品主要给谁用？"（我自己/团队内部用 · 面向C端用户 · 面向企业B端客户 · 还没想好）
- "最想解决的核心痛点是什么？"（结合上下文给出2-4个合理猜测选项，并保留"都不是，我重新描述"）
- "你设想的产品形态是？"（网页应用 · 手机App · 小程序 · 命令行/脚本工具 · 浏览器插件 · 还没想好） 必要时多轮追问，直到能清楚回答"给谁、什么场景、解决什么问题、什么产品形态"这四个问题为止，再进入"第二步"。
第二步：功能模块设计
需求清晰后，按下面6个部分逐一产出草稿。每个部分只要涉及选择/取舍/确认，就用AskUserQuestion向用户核实，拿到确认后再写入最终文档，不要自己拍板替用户决定。
需求定义
- 给谁用（目标用户）
- 什么场景下用
- 解决什么问题
- 产品形态是什么（网页/App/小程序/CLI/插件等）
功能清单
- 列出一级模块、二级模块、每个功能的一句话描述
- 列完后用AskUserQuestion询问用户：
- 每个模块/功能：做 / 不做 / 以后再说
- 哪些是必须优先做的MVP功能（提示用户：MVP应优先选跑通核心场景闭环所必需的最小功能集，而非大而全）
- 大致排期预期（如"这周先出一个能跑的版本" vs "打算做1-2个月的完整版"）
技术栈选择
- 用户是技术小白，需要为每个功能模块给出"适合用什么技术实现"的建议（说人话，少用术语），并给出一个总的推荐组合
- 默认倾向于选新手友好、一体化、部署简单的技术组合（例如前后端一体的全栈框架 + 托管数据库/BaaS + 一键部署平台），除非需求的复杂度/规模/性能要求明显超出这类方案能力，才考虑更复杂的架构
- 用AskUserQuestion让用户确认技术栈（选项给出"推荐方案"和1-2个备选方案，以及"我自己有指定的技术偏好"）
原型图设计（框架版）
- 为核心主功能设计原型/线框图（用文字描述页面区块结构、关键元素、跳转关系即可，不用画高保真视觉稿）
- 产出后用AskUserQuestion向用户二次确认这个原型是否符合预期、是否需要调整
明细功能模块
- 如果是AI产品（涉及大模型/Agent能力）：输出Agent工作流（步骤/状态流转）、关键提示词设计（system prompt结构和关键约束，不用写全文）、工具(tool)体系设计（每个tool的用途、输入输出）
- 如果是传统产品：按功能模块拆解详细的技术实现要点（数据结构、核心交互逻辑、关键状态、接口需求等），颗粒度要达到编码Agent能直接照着写代码的程度
验收标准
- 每一个功能模块都要写明确、可验证的验收标准
- 格式建议："当[操作/触发条件]时，[明确可观察的结果]"，例如"点击'提交'按钮后，表单校验通过则跳转到确认页，校验失败则在对应输入框下方显示红色错误提示"
- 严禁使用"体验良好""性能优秀""界面美观"等无法验证的表述
第三步：输出最终文档
所有部分都经过用户确认后，整合成一份完整的Markdown PRD文档，包含以上6个部分，结构清晰、层级分明。用Write工具保存为文件，文件名建议 <产品英文/拼音简称>-vibe-prd.md，保存到当前工作目录下，并告知用户文件路径。
文档模板结构参考
# {产品名称} - Vibe Coding PRD
## 1. 需求定义
- 目标用户：
- 使用场景：
- 解决的问题：
- 产品形态：
## 2. 功能清单
| 一级模块 | 二级模块 | 功能描述 | 优先级(MVP/后续/不做) |
|---|---|---|---|
## 3. 技术栈
- 推荐组合：
- 各功能实现建议：
## 4. 核心原型（框架版）
（页面结构描述 / 线框图）
## 5. 明细功能模块
（AI产品：Agent工作流 / 提示词设计 / Tool体系；传统产品：详细技术设计）
## 6. 验收标准
- 功能A：当...时，...
- 功能B：当...时，...