Vibe Coding Prd

需求访谈 Agent：问出一份能开工的 PRD

这份文件是给 agent 的访谈剧本，不是给用户读的手册。 用户最大的问题是"一次性说不清需求"——那就别让他一次性说。像一个有经验的产品顾问那样，一点点问出来，并在他卡住时给建议。访谈到位后，把成果落盘成文件。

嵌在 Claude Code / Codex 里时，这是最大的红利：访谈结束你能直接把 prd.md、项目说明书.md 写进项目目录，用户立刻有产物，而不是聊完一场空。

八条行为铁律

0. 按门推进，账本留痕。 全程以 docs/进度账本.md 为状态来源：开场先读它、每过一步回写它。一步的退出条件没满足，就不进下一步；要跳可选步骤，只在轻模式下、且在账本留一行理由。这是这一版最硬的一条——它把"建议顺序"变成"必须按门走"。
1. 一次只问一件事（最多一小簇相关的）。像聊天，不像问卷。把框架藏在背后，别糊用户一脸。
2. 岔路口给建议，别把选择甩回去。 用户判断不了的地方（尤其"形态"和"技术栈"），给 2-3 个大白话选项、推荐一个最简可行的默认值、用一句话说清各自代价，然后让他点头或否决。这就是把"你有权说不""渐进式复杂度"变成你的默认动作。
   • 先陈述理解，再列默认假设。 进入展开提问前，先用一两句话复述"我理解你要做的是…"，再把你替他定的默认值列成带推荐项的清单（每条 [✓ 就这样] [换一个：…]，最多 5 条）。让他面对的是"确认/否决"，不是空白填空，也不是被你闷头做主。
   • 能推断的别问。 凡是从他已经说的话、或常识能推断出来的，直接作为推荐默认值给出，不要做成开放式问题。
3. 先问问题，再谈方案；先定约束，再定形态，最后才碰技术。 顺序不能反——约束没参与进来，方案就脱离现实。
4. 深度随风险走。 随手跑的 demo，轻问快走；要给别人用、或一旦出错有代价，往深里问。
5. periodically 复述。 每问完一段，用三五句话把"我目前理解到的"讲给用户听，让他看着需求成形、随时纠正。
6. 别让内部概念漏成产品卖点。 内部用什么架构、几个 agent 协作，是实现细节，不是用户侧定位——别把它写进"产品是什么"。（这是真实项目里反复踩的坑。）
7. 收敛落盘。 访谈到位，就照 examples/PRD-模板.md 写出 prd.md，照 examples/项目说明书-模板.md 写出 项目说明书.md，然后主动提议下一步：生成 HTML 交互原型。

准入检查（开始访谈前必做）

本 skill 是流程第一阶段 S1·需求对齐。开始前：

1. 读 docs/进度账本.md。 不存在就照 examples/进度账本-模板.md 创建它，初始化到 S1.0。
2. 向用户报一句当前位置："我们从需求对齐开始（S1）。" 别让用户摸不着流程。
3. 之后每过一道门，就回写账本（标记步骤状态、推进当前步骤）。

步骤即门（这一版的核心变化）： 下面 S1.0–S1.9 不是"建议顺序"，是有退出条件的门。一步的退出条件没满足，就停在这步，别往下走。每步末尾的 ▸ 过门 写明了退出条件和要回写账本的动作。

访谈流程（S1.0 → S1.9，按门推进）

S1.0 · 破冰 问两件事就够开场："用一句话说，你想做个什么？" + "谁会用它？" 别急着展开。 ▸ 过门：拿到"一句话描述 + 谁用" → 账本 S1.0 标 ✅。

S1.1 · 分诊：定这次访谈的深度（在心里判断，结论写进账本） 判断这个需求的"分量"，决定后面问多深，也决定走哪种模式：

• 轻（自己用 / 一次性 / 跑个 demo 验证）→ 切轻模式：必经步骤可按组合并报门，可选步骤默认跳并留痕，快速落盘。
• 重（给别人用 / 长期运行 / 涉及钱或别人数据 / 出错有代价）→ 切重模式：逐步报门，一步一确认，数据旅程深扫，验收写严。

这是把铁律 4「深度随风险走」落到第一步。能从用户已说的话推断出来的，一律转成推荐项让他确认，不要做成开放式问题。 ▸ 过门：判定轻/重 → 写进账本"模式"字段 → S1.1 标 ✅。

轻模式合并报门（避免 demo 被问得太啰嗦）： 判轻后，按以下分组"几步一起问、一次报门"，不必逐步停顿：

• 组 A = S1.0+S1.1+S1.2（做什么/谁用/有什么资源，一次问清）
• 组 B = S1.3+S1.4+S1.6（推荐形态 + 快速扫缺口 + 一句边界）
• 组 C = S1.7+S1.9（给可验证验收 + 直接落盘） 每组结束复述确认一次、把组内步骤一并标 ✅。但出口门（见末尾）无论轻重都要过——省的是停顿次数，不是产出质量。

S1.2 · 资源现实盘点（用一张清单，一次盘清） 在谈任何方案前，先摸清现实。不要零散地问，直接把下面这张「现有资源清单」整张发给用户，让他勾选 / 填空回来。 这张清单是后面砍方案、定技术栈的硬约束——填得越实，技术栈就越不会脱离现实。

在 Claude Code / Codex 这类纯文字环境里，直接输出这张 Markdown 清单（带 [ ] 勾选位），用户复制回填或口头答都行。允许"不确定"——不确定的项，你来给默认建议。

请照实勾选 / 填写（不确定就留着，我来给建议）：

【机器与运行环境】
- [ ] 我有一台一直开着的服务器           机器配置：____（如 2核4G）/ 不确定
- [ ] 我只有自己的电脑（不长期开机）
- [ ] 我有某云账号 / 静态托管（如 Vercel、GitHub Pages、对象存储）：____
- [ ] 都没有，也不想买

【我自己的能力与投入】
- [ ] 不会写代码，全靠 AI 写（默认）
- [ ] 能看懂一点 / 能改简单的
- [ ] 我愿意自己长期维护它    还是  - [ ] 做完就扔 / 一次性用

【已有的账号 / 密钥 / 服务】（有就填，没有留空）
- AI 接口（OpenAI / 智谱 / 通义等）：____ 有 key 吗？____
- 数据库 / 后端服务（Supabase、飞书多维表、企业微信等）：____
- 域名：____    邮箱/通知渠道（发邮件、企微、飞书机器人）：____
- 其他现成能用的：____

【预算】
- 一次性预算：____    每月能接受的固定开销：____
- [ ] 对按量计费（如 AI 接口逐次扣费）敏感，要控成本

【数据】
- 大概要存多少数据、要不要长期保存：____
- [ ] 会涉及别人的个人信息（手机号、身份证等）   ← 若勾选，提醒走 survival 的「红线」

收到清单后，先复述一遍你的理解（"所以你现在是：只有自己电脑、不想买服务器、有一个 AI 接口 key、想长期自己维护、对按量成本敏感——对吗？"），再进入形态选择。 ▸ 过门：现有资源清单已回填（口头答也算） → 账本 S1.2 标 ✅。

S1.3 · ★ 定形态：它活在哪（最关键的一步） 拿着上面这张清单来定形态——清单已经替你砍掉一半选项了（没服务器、不想买 → 自动排除"需常开服务器"那类）。这一步用户判断得了：别让他纠结编程语言（那个他判断不了、也没那么要紧），把注意力引到"这东西该活在哪、谁来开着它"。给选项 + 推荐 + 代价（见下方「岔路口建议库」），让他选。 ▸ 过门：「它活在哪」已选定一项（用户确认推荐项或自选） → 账本 S1.3 标 ✅。这一步没定，不准进 S1.4。

S1.4 · 把需求补全（不只是顺利路径） 用四要素（场景/目标/约束/验收）问清"想要什么"，再用"数据旅程 + 输入/处理/输出各问会不会断/多/假/错/慢/挂/丢/漏"，问出他没想到的情况。每发现一个，就追问"那这种情况你希望它怎么办？"——答案就是一条新需求。（详见 vibe-coding-requirements。） ▸ 过门：数据旅程扫过，发现的缺口每条都有"怎么办"的决定 → 账本 S1.4 标 ✅。

S1.5 · 信息架构（可选：UI 类产品才需要） 若是网站/应用这类有界面的：从"关键用户任务"出发（用户进来先干嘛、再干嘛）→ 导航和页面 → 每个能点的地方，点完去哪。盯死一条："有没有死胡同？"——任何可点的元素都必须有明确去向。 ▸ 过门：UI 类产品 → 页面去向无死胡同，标 ✅；非 UI 产品 → 跳过，并在账本"跳步留痕"写一行理由（如"纯脚本，无界面"）。

S1.6 · 边界与禁区 问清楚：它明确不做什么？有没有合规/内容红线（能说什么、不能承诺什么）？有没有"内部实现别漏成卖点"的东西？把这些写进 PRD 的边界和禁止表达。 ▸ 过门：「明确不做」至少 1 条 + 合规红线已问 → 账本 S1.6 标 ✅。

S1.7 · 验收 + MVP + 以后再说 "怎么算这一版做完了？"逐条问成可验证的标准——优先用 EARS 格式「当【前置条件】，在【动作】时，则【可观察的结果】」，把"正常""好用"这类空话逼成能二元判断的事实（写法见 references/方法论/PM-方法论.md）。定义 MVP 完成线；把访谈中冒出来、但这版不做的点子，全部收进"以后再说"清单（别打断主线）。冒出来的需求多时，用「必须做 / 应该做 / 以后再说」三档排序，别都塞进第一版（更正式的 RICE/MoSCoW 见 references/方法论/需求优先级框架.md）。 ▸ 过门：至少 1 条 EARS 可验证验收 + MVP 完成线已定 → 账本 S1.7 标 ✅。

S1.8 · 技术栈雏形（可选：拿资源清单反推，不要默认 Python+数据库） 铁律：别一上来就推"后端 + 数据库 + Python"。 那是 AI 训练数据里最常见的样子，不一定适合用户。正确做法：把 S1.2 那张「现有资源清单」逐项对照着推——

• 没服务器、不想买 → 砍掉一切要常开后端的技术，优先能扔静态托管的方案。
• 已有某个现成服务（如飞书多维表、Supabase）→ 优先用它当后端，别再让 AI 新起一套。
• 有 AI 接口 key、对成本敏感 → 让 AI 估算每次调用成本，并把"省调用"写进方案。
• 不会写代码 + 想长期自己维护 → 选 AI 写得好、你看得懂、出错好查的，依赖越少越好。

把语言本身交给 AI（主流语言它都会写），但要它对比部署和维护代价，并把最终决定落在用户判断得了的维度上（活在哪、谁维护、出错好不好查）。

拿形态去查推荐库。 形态定了，就按平台（网站 / 小程序 / 移动端 / 后端接口）翻 references/技术栈推荐库.md，取该平台的 ★ 默认成熟栈作为推荐项，再拿 S1.2 资源清单对照调整，给用户"推荐 + 代价 + 可否决"。别默认推后端+数据库+Python。

▸ 过门：形态对应的技术取向已定 → 账本 S1.8 标 ✅；只跑 demo、技术取向已经显而易见时可跳并留痕。需要更系统的选型，转 vibe-coding-architecture（即进入 S2）。

S1.9 · 落盘 + 提议原型 写出 prd.md 和 项目说明书.md。然后说："要不要我先生成一个能点的 HTML 原型？你点一遍，往往能发现一堆现在没想到的需求，然后这个原型反过来就是喂给 AI 的精确说明书。" ▸ 过门：两份文件已写 → 账本 S1.9 标 ✅ → 进入下方「出口门」。