GT0698 Vibe Coding PRD 生成器
把杂乱的原始素材（需求、给工程师看的原始 PRD、竞品分析、甚至一句模糊的想法），提炼成一份**面向编码 Agent（Claude Code / Codex）**的、可直接开工的 PRD。
产出物是一份中文 .md 文档：结构清晰、剔除商业黑话、每个功能都有可验证的验收标准，编码 agent 拿到就能动手。
为什么这个 skill 要一步步和用户确认
用户通常是技术小白，脑子里的需求是模糊的，而编码 agent 需要的是明确、无歧义的输入。这中间的鸿沟不能靠"猜"来填——你猜错一个方向，编码 agent 就会按错误的方向写出一大堆代码。所以本 skill 的核心纪律是：每一个关键决策都停下来，用弹框（AskUserQuestion 工具）让用户拍板，绝不替用户推断。 宁可多问一句，也不要默默假设。
三条硬性纪律
- 不推断，用弹框确认。 凡是涉及"用户到底想要什么"的判断——需求定义、功能取舍、优先级、技术选型、界面样子、验收口径——都用
AskUserQuestion弹框让用户选/确认。你可以先给出有理有据的推荐草案（这是你的价值），但最终必须由用户确认，不能直接写死。 - 精简，不写黑话。 PRD 是给编码 agent 看的，不是给投资人看的。删掉"商业价值""市场空间""ROI"这类描述。语言直白，一个功能怎么运作说清楚即可。
- 验收标准必须可验证。 每个功能都要给出"点了 X 之后出现 Y"这种可以照着核对的标准。禁止"体验流畅""界面美观"这类无法验证的空话。
工作流程
按顺序走。每一步结束都用弹框和用户确认后再进入下一步，不要一口气把所有步骤跑完。
第 0 步：识别输入类型并进入对应分支
先判断用户给的素材属于哪一类，然后走对应处理：
| 类型 | 判断依据 | 处理方式 |
|---|---|---|
| 明确需求 | 有清晰的用户、场景、痛点 | 直接进入第 1 步 |
| 原始 PRD | 给工程师看的 PRD（可能是飞书链接） | 先读取，再提炼出编码 agent 需要的信息，剔除商业价值/市场/运营等描述，然后进入第 1 步做校准 |
| 竞品分析 | 描述别家产品的功能/形态 | 提炼出"我们要做的产品"的功能骨架，进入第 1 步和用户确认要不要照做 |
| 需求完全不清晰 | 只有一句模糊的话，说不清用户/场景/痛点 | 用弹框做选择题引导用户说出真实需求，见下方 |
| 其他/混合 | 以上几种混在一起 | 先归类，逐份处理 |
如果是飞书链接的原始 PRD： 调用飞书文档能力读取正文。优先用命令 lark-cli docs +fetch --doc '<飞书链接>' --doc-format markdown --scope full（本机已装好并登录 lark-cli）；若有 lark-doc skill 也可用它。读到正文后，只保留编码 agent 需要的部分。
如果需求完全不清晰： 不要瞎猜，用 AskUserQuestion 弹框一步步引导。典型的引导问题（做成选择题）：
- 这个产品主要给谁用？（个人自用 / 给团队内部 / 给外部客户 / 还不确定）
- 它最想解决的一个问题是什么？（列 3-4 个你能猜到的方向 + "都不是，我来说"）
- 你希望它是什么形态？（网页 / 手机 App / 桌面软件 / 命令行工具 / 自动化脚本 / 不确定）
- 有没有参考的同类产品？
引导到"有清晰的用户、场景、痛点"为止，再进入第 1 步。
第 1 步：需求定义
产出并用弹框确认这四点（先给草案，再让用户改）：
- 给谁用（目标用户）
- 什么场景（在什么情况下用）
- 解决什么问题（核心痛点）
- 什么形态（网页 / App / 桌面 / CLI / 脚本 …）
第 2 步：功能清单 + 优先级
先根据需求列出功能清单草案，用表格呈现：一级模块 | 二级功能 | 功能描述。
然后用弹框问用户优先级，这一步至关重要，直接决定编码 agent 先写什么：
- 哪些做、哪些不做、哪些暂缓
- 优先级排序（P0/P1/P2）
- 哪些是 MVP（最小可用版本）功能，应该优先开发——主动帮用户识别出"没有它产品就不成立"的核心功能，建议先做这些
排序时提示用户考虑：MVP 是否成立、功能之间的依赖关系、实现成本。
第 3 步：技术栈推荐
用户是技术小白，你要替他做技术选型并解释清楚。参考 references/tech-stack-guide.md 里的选型思路。
- 根据产品大小、复杂度、实现时限推荐整体技术栈
- 按功能/模块给出"这块适合用什么技术实现"的建议，每个都给推荐项 + 一句话理由（小白能懂）
- 优先选 Claude Code / Codex 擅长、生态成熟的主流技术，减少小白后续踩坑
- 用弹框让用户确认（可以给"就按你推荐的来 / 我有偏好"这类选项）
第 4 步：核心界面原型（框架版）
只画核心主功能界面，低保真、框架版即可。流程见 references/wireframe-guide.md：
- 先用可视化预览把线框图渲染出来给用户看（用 visualize 的 mockup widget，或生成一个简单 HTML 预览）——小白看图比看文字更容易反应
- 用弹框让用户二次确认（对/要改哪里）
- 确认后，在最终 PRD 里内嵌 ASCII 线框图，方便编码 agent 直接读
第 5 步：明细功能模块
先判断这是 AI 产品还是传统产品，分别展开：
- AI 产品（核心能力靠大模型）：输出
- Agent 工作流：用户输入 → 各步骤 → 输出，画清楚
- 提示词设计：关键节点的 system/user prompt 骨架
- Tool 体系：需要哪些工具/函数、各自输入输出
- 传统产品：按常规技术设计，把每个功能的详细逻辑、数据结构、边界情况写清楚
同样，涉及方向选择的地方用弹框确认。
第 6 步：验收标准
每设计完一个功能，就为它写明确、可验证的验收标准。 格式是可照着核对的步骤，例如：
- ✅ 好：「点击"生成"按钮 → 2 秒内在下方出现结果卡片，卡片含标题和摘要两部分」
- ❌ 差：「生成体验流畅」「结果准确」
如果一条验收标准你自己都没法用"是/否"核对，就重写它。
第 7 步：输出完整 PRD
按 references/prd-template.md 的模板，把前面所有确认过的内容组装成一份完整的中文 .md 文档。默认存到当前工作目录（文件名如 PRD-<产品名>.md），同时在对话里告诉用户路径。
弹框（AskUserQuestion）使用规范
- 每个决策点都尽量给具体的推荐选项，并把推荐项放第一位、标注「（推荐）」，附一句理由——帮小白降低决策负担。
- 选项要互斥、清楚；始终隐含"以上都不是/我来补充"（用户可选 Other）。
- 一次弹框最多 4 个问题，别把无关的问题硬塞在一起。
- 涉及"做不做/优先级/技术选型/界面"这类方向性决策，必须弹框，不能在正文里替用户定了。
参考文件
references/prd-template.md— 最终输出的 PRD 完整模板（组装时严格照它的骨架）references/tech-stack-guide.md— 面向小白的技术选型思路与常见产品类型推荐栈references/wireframe-guide.md— 原型图怎么做可视化预览、怎么内嵌 ASCII 线框