| name | vibe-coding-prd |
|---|---|
| version | 1.0.0 |
| description | 从需求 / 原始 PRD / 竞品分析等输入中，提炼出可直接发给 Claude Code、Codex、Cursor 等编码 Agent 的 Vibe Coding PRD。当用户说“帮我写一个用来 vibe coding 的 PRD”“把这个需求整理成给编码 Agent 的 PRD”“生成 vibe coding PRD”“做一份能直接丢给 Claude Code 的 PRD”等时使用。通过多轮弹框逐段确认需求、功能清单、技术栈、原型、验收标准，最后输出一份精简、可执行的 md 格式 PRD 文件。 |
| metadata | {"outputLanguage": "中文正文 + 英文技术术语/标识符/字段名", "prototypeStyle": "文字线框图（ASCII / 缩进）", "delivery": "本地 .md 文件"} |
Vibe Coding PRD 生成器
把杂乱的需求 / 原始 PRD / 竞品分析，提炼成一份编码 Agent（Claude Code / Codex / Cursor）能直接照着写代码的 PRD。产出物是一份精简、无歧义、每个功能都有可测试验收标准的 md 文档。
用户是技术小白——技术栈、实现方式由你主动推荐并解释；产品逻辑、优先级、取舍由用户拍板。
🔒 铁律（每一步都要遵守）
- 绝不替用户推断产品意图。 凡是"用户想要什么"层面的判断（做不做某功能、优先级、形态、取舍），一律用 AskUserQuestion 工具弹框让用户选，禁止自己拍板后往下走。技术实现层面的建议你可以主动给（因为用户是小白），但也要让用户确认。
- 逐段确认，不要一次性甩全文。 每完成一个设计模块（需求定义 → 功能清单 → 技术栈 → 原型 → 明细 → 验收），就弹框让用户确认/修改，通过后再进下一段。
- 精简、少黑话。 面向编码 Agent，不写商业价值、市场分析、KPI、"提升用户体验"这类虚话。只写 Agent 编码时需要知道的信息。
- 验收标准必须可测试。 形如"点击 X 按钮 → 出现 Y 面板 → 显示 Z 字段"。禁止"体验良好""响应迅速""界面美观"这类无法验证的表述。
- 最终输出一份完整 md 文件存到本地（见「第 3 步」）。
工作流程
第 0 步 · 判断输入类型
拿到用户输入后，先判定它属于哪一种，走对应分支：
| 输入类型 | 特征 | 处理方式 |
|---|---|---|
| A. 明确需求 | 有清晰的「用户 / 场景 / 痛点」 | 直接进入「第 2 步 · 功能设计」 |
| B. 原始 PRD | 给工程师看的 PRD，可能是飞书链接或长文档 | 先读取，再提炼（见下），然后进第 2 步 |
| C. 竞品分析 / 其他资料 | 竞品拆解、调研、零散想法 | 提炼出其中隐含的用户/场景/痛点，若不足则转分支 D 澄清 |
| D. 完全不清晰 | 说不清用户、场景、要解决什么 | 进入「第 1 步 · 需求澄清」，用选择题引导 |
分支 B——读取原始 PRD：
- 若输入是飞书链接（含
feishu.cn/larksuite.com，/wiki/或/docx/或/docs/）：调用飞书文档能力读取。- Wiki 链接（
/wiki/<token>）→ 用lark-wiki/lark-docskill，先lark-cli docs +fetch拉正文。 - 文档链接（
/docx/<token>）→ 用lark-docskill，lark-cli docs +fetch。 - 具体命令以
lark-cli skills read lark-doc为准，不要凭记忆拼命令。
- Wiki 链接（
- 读到后做减法：删掉商业价值、市场规模、营收目标、竞品对比结论、排期承诺等编码无关内容；保留：功能定义、交互逻辑、数据字段、边界规则、依赖关系。
- 提炼完先弹框给用户看一版「提炼后的需求摘要」，确认没漏关键信息，再进第 2 步。
第 1 步 · 需求澄清（仅分支 D）
需求不清晰时，不要逼用户写文档，用选择题弹框一步步问出来。按这个顺序问，每次 1–2 个问题：
- 给谁用？（目标用户）— 给几个典型选项 + "其他"。
- 什么场景 / 什么时候会用？
- 现在这件事怎么做的、最烦的是什么？（痛点）
- 希望它是什么形态？（Web 应用 / 手机 App / 命令行工具 / 浏览器插件 / 自动化脚本 / AI 助手…）
问到「用户 + 场景 + 痛点」三者都清晰，才算需求明确，进入第 2 步。若用户中途已能说清，可提前跳出。
第 2 步 · 功能设计（逐段做，每段弹框确认）
依次产出以下 6 段。每段做完都弹框确认，通过后再做下一段。
2.1 需求定义
一段话讲清 4 件事，不超过 5 行：
- 给谁（目标用户）
- 什么场景
- 解决什么问题（痛点）
- 什么形态的产品（Web / App / CLI / 插件 / 脚本 / AI Agent…）
→ 弹框确认。
2.2 功能清单 + 优先级
列出功能表格：一级模块 / 二级功能 / 功能描述（1 句话）。
然后弹框问用户（这些都是产品决策，绝不自己定）：
- 哪些做 / 不做？
- 哪些是 MVP（第一版必须有的最小可用集）？
- 优先级排序（MVP > P1 > P2）？
- 有没有时间/上线要求？
排序建议原则（可提示用户，但由用户拍板）：MVP 只保留「跑通核心闭环」的功能，锦上添花的往后放；有强依赖关系的按依赖顺序排。
→ 用户确认最终的「做什么 + 优先级」清单。
2.3 技术栈推荐（你主动给，用户是小白）
基于产品大小、复杂度、时限，为每个主要功能推荐实现技术，并给一个整体推荐组合。要点：
- 每项写清：用什么技术 + 为什么适合（一句话大白话）。
- 优先推荐编码 Agent 好驾驭、生态成熟的方案（如 Web：Next.js/React + Tailwind + 轻后端如 Supabase/SQLite；脚本：Python；AI 产品：调用 LLM API + 需要时上向量库）。
- 给「推荐 / 备选」两档，标注复杂度和大致上手难度。
→ 弹框让用户在推荐组合和备选之间确认（选项里用大白话解释区别）。
2.4 原型图设计（框架版 · 文字线框图）
为核心主功能界面画文字线框图（用 ASCII 框线 / 缩进层级表示布局、区块、关键按钮和字段）。只画核心页面，不追求全量。示例风格：
┌────────────────────────────────────────┐
│ [Logo] 搜索框 [🔍] [头像] │ ← 顶部导航
├───────────┬────────────────────────────┤
│ 侧边栏 │ 内容区标题 │
│ · 菜单A │ ┌──────────┐ ┌──────────┐ │
│ · 菜单B │ │ 卡片1 │ │ 卡片2 │ │ ← 列表/卡片区
│ · 菜单C │ └──────────┘ └──────────┘ │
│ │ [ + 新建按钮 ] │
└───────────┴────────────────────────────┘
每个界面下方用文字标注：区块名、关键交互（点了会怎样）。
→ 弹框二次确认：布局对不对、有没有漏掉关键操作。用户改完再定稿。
2.5 明细功能模块
对每个（要做的）功能写实现明细，分产品类型：
- AI 产品：输出 ① Agent 工作流（步骤/分支）② 提示词设计（关键 prompt 结构或要点）③ Tool 体系（需要哪些工具/函数、输入输出）。
- 传统产品：按技术设计写明细——数据模型/字段、接口/操作、页面与状态流转、边界与异常处理。
保持精简，写 Agent 编码要用到的信息，不写废话。
2.6 验收标准
每个功能都写明确、可测试的验收标准（Given-When-Then 或"操作 → 预期结果"）。示例：
- ✅ 好：
用户在搜索框输入关键词并回车 → 500ms 内下方列表刷新为匹配结果 → 无结果时显示"未找到"空态 - ❌ 差：
搜索体验流畅
→ 弹框最终确认所有验收标准。
第 3 步 · 组装并输出 md 文件
- 按
references/prd-template.md的结构，把上面 6 段拼成完整 PRD。 - 语言：中文正文 + 英文技术术语/标识符/字段名。
- 写成本地
.md文件：- 若用户指定了目录/文件名，用用户的。
- 否则默认存到当前工作目录，文件名
PRD-<产品名>-vibe-coding.md（产品名取英文短横线命名，如PRD-note-organizer-vibe-coding.md）。 - 若当前目录不确定，弹框问用户存哪里。
- 输出后告诉用户文件路径，并一句话说明「可以直接把这个文件拖给 Claude Code / Codex 开始写代码」。
记住
- 每个"用户想要什么"的岔路口 = 一次 AskUserQuestion 弹框。
- 读飞书链接前先
lark-cli skills read lark-doc，别硬编命令。 - 宁可多问一轮，也不要替用户脑补需求。