| name | vibe-coding-prd |
|---|---|
| description | 将需求、原始 PRD、飞书/Lark 文档、竞品分析、头脑风暴笔记或模糊产品想法，整理成可直接发给 Claude Code、Codex 等编码 Agent 的精简 Vibe Coding PRD。当用户说“帮我写一个用来vibe coding的PRD”，或要求把材料提炼成编码 Agent 可执行的产品需求文档时使用；如果需求不清晰，也用于通过选择题引导用户澄清真实需求。 |
Vibe Coding PRD
概述
把杂乱的产品输入整理成一份紧凑、可执行的 Markdown PRD，供 Claude Code、Codex 或其他编码 Agent 直接用于开发。只保留设计和编码真正需要的信息，在关键产品选择上先让用户确认，并删除不影响实现的商业价值、市场背景和口号式描述。
执行规则
- 当用户意图、目标用户、使用场景或痛点不清楚时，不要自行推断用户想要什么；先提出澄清问题。
- 引导模糊需求时，优先使用选择题。选项要具体，并在合适时提供“其他 / 自己描述”选项。
- 当 Codex 环境提供
request_user_input工具，且需要用户确认时，优先用该工具弹框确认；如果不可用，则在聊天中用简洁的编号问题确认。 - 如果输入是飞书/Lark 文档 URL 或 token，先使用飞书文档 skill 读取内容再分析。如果文档内嵌表格、多维表格、画板等资源，遵循对应 Lark skill 的路由规则继续读取。
- PRD 要精简、面向实现。不要写商业价值、市场规模、OKR、愿景口号等对编码无帮助的内容，除非它会直接影响产品行为。
- 最终交付物必须是一份完整 Markdown 文档。
- 验收标准必须可观察、可测试。避免“体验良好”“流程顺畅”“高质量”“智能准确”等模糊表述。
工作流程
1. 判断输入类型
先判断用户提供的材料主要属于哪一种：
- 明确需求：已有清晰的用户、场景、痛点和希望实现的产品结果。可以进入功能设计。
- 原始 PRD：已经是写给工程师或业务方的 PRD。需要提炼编码 Agent 必须知道的信息，例如用户角色、核心流程、数据、页面、规则、集成、边界情况、约束和验收点；删除商业背景、价值论证、OKR、市场规模等内容。
- 竞品分析：材料主要是竞品功能、截图、体验观察或优缺点。需要转化为候选用户问题、参考流程、可借鉴功能、差异化选择和风险，并让用户确认要做哪个方向。
- 其他 / 不清晰：材料过于零散、只有想法或缺少用户/场景/痛点。暂停写 PRD，先引导用户澄清。
如果分类不确定，说明你判断的类型，并请用户确认后再继续。
2. 澄清真实需求
当输入不清晰时，一次最多问 3 个问题。优先围绕下面三点澄清：
- 主要用户是谁？
- 用户在什么场景下使用？
- 产品最先要解决哪个痛苦、耗时或容易出错的问题？
优先用选择题，例如：
- 用户类型：个人使用 / 团队内部 / 外部客户 / 运营销售客服 / 其他。
- 产品形态：网页工具 / Chrome 插件 / 飞书或 Slack 机器人 / 移动端小程序 / 后台系统 / 自动化脚本。
- 交付范围：1 天原型 / 1 周 MVP / 可上线 v1。
只有在用户确认真实需求后，才继续进入功能设计。
3. 设计功能模块
需求清晰后，先输出一版功能拆解草案，并要求用户确认优先级，再写最终 PRD。
草案必须包含：
- 需求定义：给谁、在什么场景、解决什么问题、做成什么产品形态。
- 功能清单：一级模块、二级功能、功能描述。
- 优先级建议：标注 MVP / 后续再做 / 本期不建议做。排序时考虑依赖关系、用户价值、实现成本，以及没有该功能产品是否仍可用。
- 明确确认问题：询问用户哪些做、哪些不做、哪些延后做，以及优先级是否需要调整。
用户没有确认或修改优先级前，不要输出最终 PRD。
4. 推荐技术栈
默认用户是技术小白。根据产品大小、复杂度、交付时限、部署方式、AI 能力和外部集成需求，为用户推荐实现技术栈。
对每个主要功能或模块说明：
- 推荐使用什么技术实现。
- 用通俗语言解释为什么适合。
- 如果存在明显取舍，给出更简单或更稳健的备选方案。
最后必须给出明确推荐，不要只列一堆并列选项让用户自己判断。
5. 设计框架版原型
为核心主功能界面设计框架版原型。可以使用简单 ASCII 线框图、页面清单、流程图或 Mermaid 图。
需要覆盖：
- 主入口页面。
- 核心任务流程。
- 重要设置、空状态、结果状态和错误状态。
- 关键页面之间的跳转关系。
原型只需要表达结构和交互，不要沉迷视觉风格。输出后必须请用户二次确认，再进入详细模块设计。
6. 输出明细功能模块
如果是 AI 产品，需要包含：
- Agent 工作流：触发条件、输入、推理步骤、工具调用、记忆/状态、输出格式、失败兜底。
- 提示词设计：system/developer/user prompt 结构、必要变量、输出 schema、必要示例。
- Tool 体系：工具名称、参数、权限、错误处理、每个工具何时使用。
- 模型与成本/延迟考虑：仅在会影响实现方案时写。
如果是传统产品，需要包含：
- 数据模型和关键字段。
- API 或服务职责。
- 前端页面行为。
- 权限和角色。
- 状态流转、校验规则、边界情况和集成点。
7. 写验收标准
每个纳入本期的功能都要写明确验收标准：
- 使用 “Given..., when..., then...” 或 “先点击 X，再输入 Y，然后出现 Z” 这种可测试表达。
- 包含必要的空状态、错误状态、加载状态、权限状态和边界状态。
- 不写无法验收的词。把“体验良好”改成具体行为，例如“10MB 以下文件在 5 秒内返回结果”或“错误提示展示失败字段和重试入口”。
最终 PRD 格式
最终输出一份完整 Markdown 文档，结构如下：
# Vibe Coding PRD：<产品/功能名称>
## 1. 需求定义
- 用户：
- 场景：
- 痛点：
- 产品形态：
- 本次目标：
- 非目标：
## 2. MVP 范围与优先级
| 优先级 | 一级模块 | 二级功能 | 功能描述 | 本期是否做 | 备注 |
| --- | --- | --- | --- | --- | --- |
## 3. 推荐技术栈
| 功能/模块 | 推荐技术 | 原因 | 备选 |
| --- | --- | --- | --- |
## 4. 原型图设计（框架版）
<页面结构 / 核心流程 / ASCII 线框图 / Mermaid 图>
## 5. 明细功能设计
### 5.1 <模块名>
- 用户故事：
- 交互/流程：
- 数据/状态：
- 规则与边界：
- AI 工作流/提示词/tool 体系（如适用）：
## 6. 验收标准
### <功能名>
- Given..., when..., then...
- 先点击...，再...，然后...
## 7. 给编码 Agent 的执行提示
- 开发顺序：
- 关键约束：
- 可能涉及的文件/模块：
- 不要开发：
每个部分都要短而清楚。材料很长时，大胆压缩，只保留会影响实现的信息。