| name | vibe-coding-prd |
|---|---|
| description | 将零散需求、明确需求、原始工程 PRD、竞品分析、会议记录或飞书文档提炼为可直接交给 Claude Code、Codex 等编码 Agent 的精简 Markdown PRD。用户说“帮我写一个用来vibe coding的PRD”、要求生成 Vibe Coding PRD、把需求转成开发提示/编码规格，或希望从现有材料提取可执行产品需求时使用。适用于 AI 产品和传统软件；需求不清晰时先用选择题澄清，关键设计未经用户确认不得自行定案。 |
Vibe Coding PRD
把用户材料转为编码 Agent 能直接实施、逐项验收的 PRD。保持精简、具体、少黑话，不保留与实现无关的商业叙事。
核心规则
- 不把猜测写成事实。缺少会改变产品范围、交互或实现的信息时，先询问并暂停相关设计。
- 优先使用客户端的结构化选择题/确认弹框；不可用时，使用编号选项。每轮最多问 3 个高影响问题，并给出推荐项及一句理由。
- 允许提出推荐，但必须标为“推荐”，并由用户确认；记录确认结果。
- 只在材料和已确认答案范围内工作。不要擅自增加用户、场景、功能、外部集成或非功能要求。
- 一次不必问完所有细节。先解决当前阶段的阻塞项，再推进。
- 除非用户明确要求一次性直接出稿，否则必须执行确认关卡。
- 读取并严格使用 PRD 模板 生成最终文档。
工作流
1. 接收并识别输入
先概括已收到的材料，再将其判定为以下一种或多种：
- 明确需求：至少有清晰的目标用户、使用场景、核心痛点。
- 原始 PRD：面向产品/工程协作的既有需求文档，常含背景、商业价值、排期等。
- 竞品分析：以竞品功能、流程、优缺点或截图为主，但未必表达用户自己的目标。
- 其他/混合材料：会议记录、想法、反馈、方案或多类材料混合。
- 需求不清晰：无法可靠回答“给谁、在什么场景、解决什么问题、做成什么形态”。
处理方式：
- 明确需求：进入步骤 2。
- 原始 PRD：提取编码所需的目标、角色、流程、范围、规则、数据、接口、异常、约束和验收信息；删除商业价值、市场宣传、组织过程及重复背景。若是飞书 Docx/Wiki 链接或 token，调用
lark-docskill 读取正文；若权限或内容不足，说明缺口并请用户补充。 - 竞品分析：只把竞品事实作为参考，不默认照搬。用选择题确认要借鉴的能力、差异化目标和明确不做的部分。
- 其他/混合材料：分别标注“事实、候选方案、待确认”，合并重复项后继续。
- 需求不清晰：进入澄清循环，不开始功能设计。
2. 澄清需求定义（确认关卡 A）
确保以下四项都有用户明确答案：
- 给谁：主要用户/角色。
- 什么场景：触发时机、使用环境、前后动作。
- 解决什么问题：现状、痛点、期望结果。
- 什么形态：Web、移动端、桌面端、插件、机器人、API、内部工具等。
信息不全时，用 2–4 个互斥选项引导；推荐项放第一并说明取舍，同时保留用户自由填写入口。不要用开放式大题一次索取整份需求。
输出一段“需求定义草案”，请用户确认或修改。未经确认，不进入功能拆解。
3. 设计功能与阶段（确认关卡 B）
输出候选功能表：一级模块、二级功能、功能描述、建议阶段、依赖、建议理由。阶段固定使用：
- MVP：验证核心闭环必需，没有它产品无法解决核心问题。
- V1：增强可用性、效率、稳定性或覆盖面，但不阻断核心闭环。
- Later：高成本、低频、依赖不确定或可延后验证。
- 不做：明确排除，防止编码 Agent 扩展范围。
给出推荐开发顺序，优先考虑核心闭环、依赖关系、风险验证和实现成本。随后逐项请用户确认：做/不做、何时做、优先级，以及排序需额外考虑的约束。用户确认后记录“范围基线”。
4. 推荐技术栈（确认关卡 C）
根据产品规模、复杂度、交付时限、运行环境、团队技术能力和已确认功能提出 1 个主推荐；只有存在实质取舍时再给 1 个备选。
面向技术小白解释：
- 每项技术负责什么。
- 哪些功能用它实现。
- 为什么适合当前项目。
- 主要代价、风险和未来扩展限制。
- 是否需要付费服务、账号、API Key、部署或数据库。
覆盖前端、后端、数据库、认证、文件/对象存储、AI 模型与编排（如适用）、部署、监控和测试；不适用项写“无需”。避免为小项目堆叠复杂基础设施。请用户确认主方案后再定稿。
5. 设计 ASCII 原型（确认关卡 D）
只画核心主流程页面/状态，每个界面使用 Markdown 代码块中的 ASCII 线框图，并标注：
- 页面/界面名称与目标。
- 主要区域、按钮、输入、输出和导航。
- 关键状态：空、加载、成功、错误；仅展示与流程有关的状态。
- 页面间跳转或操作结果。
图后列出待确认交互，要求用户二次确认。未经确认，不把原型视为最终规格。
6. 补全实现明细
先判断产品类型，可为 AI、传统或混合：
AI 产品必须补充：
- Agent 工作流：输入、步骤、分支、状态、失败/重试、输出。
- Prompt 设计：system/user 模板、变量、输出格式、边界和失败处理；不要虚构业务知识。
- Tool 体系：工具名、用途、调用条件、输入、输出、权限、超时/错误处理。
- 模型与数据：推荐模型能力、上下文来源、结构化输出、敏感信息和人工确认点。
传统产品必须补充：
- 页面/服务流程、业务规则、状态流转、数据实体与关键字段。
- API/第三方集成、权限角色、异常/边界情况、日志和必要的非功能要求。
混合产品： 同时包含相关部分，删除不适用项。
若实现细节仍存在会改变功能行为的歧义，返回对应确认关卡，不自行填补。
7. 编写可执行验收标准
为每个纳入范围的二级功能编写可观察、可复现的验收标准。优先使用 Given/When/Then 或清晰的操作链：
- 前置条件是什么。
- 用户先执行什么操作。
- 系统出现什么具体结果。
- 数据、状态或页面如何变化。
- 错误、空数据、权限不足等关键边界如何表现。
禁止使用“体验良好”“响应快速”“易于使用”“正常显示”等不可验证表述。若必须写性能指标，给出数值；数值未经用户提供时，作为选项请求确认。
8. 生成最终 Markdown PRD
只有 A–D 关卡均已确认，且必要实现歧义已消除后，才按模板输出完整 PRD。最终文档应：
- 自包含，编码 Agent 无需回看对话即可实施。
- 区分“已确认”“待确认”；原则上交付前清空会阻塞编码的待确认项。
- 保留 MVP / V1 / Later / 不做范围和推荐开发顺序。
- 包含 ASCII 原型、实现明细及逐功能验收标准。
- 删除商业价值、口号、过程记录、重复解释和无实现影响的背景。
- 使用具体名词、按钮名、字段名、状态名和错误行为。
默认将 PRD 直接以 Markdown 回复。若用户要求保存文件，则写入其指定路径；未指定文件名时使用 vibe-coding-prd.md。
完成前自检
- 能否明确回答给谁、何时使用、解决什么、产品形态是什么？
- 每个功能是否属于已确认阶段，并有做/不做结论？
- 技术方案和 ASCII 原型是否均得到用户确认？
- AI 产品是否有 Agent、Prompt、Tool；传统产品是否有流程、规则、数据和接口？
- 每个二级功能是否有可操作、可观察、含边界的验收标准？
- 是否存在任何未经确认的推断、空泛形容词或与编码无关的商业描述？