---
name: Vibe Coding Prd
slug: vibe-coding-prd
category: AI Engineering
description: Vibe Coding Prd通过一问一答和岔路口建议，把说不清的想法访谈成可直接开工的PRD。适合在 Claude Code 或 Codex 里梳理新项目需求、补全约束并落盘成 prd.md 和项目说明书。
github: "https://github.com/Junliu1066/vibe-coding-kit/tree/main/skills/vibe-coding-prd"
stars: 169
forks: 1
install: "npx degit https://github.com/Junliu1066/vibe-coding-kit/tree/main/skills/vibe-coding-prd ~/.claude/skills/vibe-coding-prd"
installs_to: ~/.claude/skills/vibe-coding-prd
source_path: skills/vibe-coding-prd/SKILL.md
collection_size: 6
category_size: 3670
collection_url: "https://dirskills.com/collections/Junliu1066/vibe-coding-kit"
added: 2026-09-08T05:33:52.994Z
last_synced: 2026-09-08T05:33:52.994Z
canonical_url: "https://dirskills.com/skills/vibe-coding-prd"
---

# Vibe Coding Prd

Vibe Coding Prd通过一问一答和岔路口建议，把说不清的想法访谈成可直接开工的PRD。适合在 Claude Code 或 Codex 里梳理新项目需求、补全约束并落盘成 prd.md 和项目说明书。

**Install:**

```bash
npx degit https://github.com/Junliu1066/vibe-coding-kit/tree/main/skills/vibe-coding-prd ~/.claude/skills/vibe-coding-prd
```

## README

# 需求访谈 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 标 ✅ → 进入下方「出口门」。

---

## 岔路口建议库（给用户选项，别让他凭空想）

### 形态：它活在哪

| 形态 | 适合 | 代价 / 提醒 |
|------|------|-----------|
| **纯前端网页**（页面 + 表单，无后端、无服务器） | 展示型官网、留资、工具型小页面 | 最省心，能扔到任何静态托管；但"提交后存哪"要留作后续（先本地记录/发邮件） |
| **需要一台常开服务器**（有后端 / 数据库） | 要存数据、要登录、多人协作、定时任务 | 复杂度和维护成本跳一档——你得管这台机器，它挂了服务就停 |
| **可直接发的单文件 / 脚本** | 自己或少数人用的小工具 | 最简单；但没界面、要会运行，不适合给小白用户 |
| **零代码 / 自动化平台** | 完全不想碰代码、逻辑不复杂 | 上手快；但平台有订阅费、逻辑一复杂就难维护、且"看不懂里面发生了什么" |

> **默认推"够用的最简形态"。** 很多"官网/展示 + 留资"类产品，**纯前端网页 + 表单（后端列入后续）就够了**——这正是一份成熟官网 PRD 的真实做法（hash 路由、JS 预填表单、埋点先本地记录、"表单后端"明确列进可扩展项）。不要因为"显得正经"就给人加上他养不起的后端。

### 技术栈：抵制 AI 爱加料

形态定了，语言交给 AI。但要主动帮用户挡住这些"工程师条件反射"式的加料——单机小项目基本都不需要，逐个反问：

| AI 爱推荐 | 它解决的问题 | 替用户反问 |
|-----------|------------|-----------|
| Docker | 环境一致性 | 我就一台机器/一个人，需要吗？ |
| Nginx | 反向代理 / 负载均衡 | 我这访问量，需要吗？ |
| MySQL/PostgreSQL | 存大量数据 | 一个文件型数据库（SQLite）够用吗？ |
| Redis | 缓存加速 | 有人嫌慢吗？ |
| 微服务 / K8s | 大规模、多团队 | 我有几百台机器、几十号人吗？ |

---

## 产出物

- **`prd.md`** —— 照 `examples/PRD-模板.md`，颗粒度量力而行（小项目填核心几节即可）。
- **`项目说明书.md`** —— 照 `examples/项目说明书-模板.md`，作为后续每次对话都贴给 AI 的"活记忆"。
- **下一步（提议，不强求）**：HTML 交互原型——最便宜的需求验证器。

## 在 Claude Code / Codex 里怎么用

把本 Skill 作为 agent 的行为指令。它会访谈用户，并在访谈到位后，把 `prd.md` / `项目说明书.md` 写进当前项目目录。

> 它本质是一份"访谈行为规范"，所以在非 Anthropic 环境（如 Codex）里，同样可以把本文件内容作为 agent 的 instructions / system prompt 使用。

---

## 出口门（声称 S1 完成前必过 · 无论轻重模式都不打折）

> 以下约束来自项目治理配置 `harness.json`（`workflow.stages[S1].exit_gate`）和 `CLAUDE.md`。
> 在声称"需求阶段完成"之前，你必须逐条确认。未满足的项，继续执行直到满足，不得跳过。
> **全过之后，最后一步：在 `docs/进度账本.md` 把 S1 标记为「已完成、出口门 ✓」，并提示用户"可进入 S2 架构选型"。**

### 必须产出的文件

- [ ] `docs/prd.md` — 照 `examples/PRD-模板.md` 结构逐节填写
- [ ] `docs/项目说明书.md` — 照 `examples/项目说明书-模板.md` 结构填写（至少填「一句话」和「需求基准描述」）
- [ ] `docs/进度账本.md` — 已存在且 S1 各必经步骤为 ✅、跳过的`可选`步骤有留痕

### `docs/prd.md` 硬性检查

- [ ] 第 0 节「文档元信息」中，「文档状态」「版本」「产品名称」三项均已填写，不为空、非占位符
- [ ] 「版本」格式为 `v数字.数字`（如 `v0.1`）
- [ ] 「文档状态」为「草稿」「评审中」「交付版」之一
- [ ] 第 1.1 节「核心定位」已填写至少 10 个字的一句完整的话
- [ ] 第 1.2 节「明确不做」至少列出了 1 条边界
- [ ] 第 2.3 节「形态与资源约束」表格中，「它活在哪」已明确选定一项
- [ ] 第 9 节「验收标准」中至少 1 条，且每条都是具体可验证的（不是"系统正常"这种空话）
- [ ] 全文无 `{...}` 占位符残留（如 `{产品名称}`、`{日期}`）
- [ ] 全文无英文正文（代码、术语、URL 除外）

### `docs/项目说明书.md` 硬性检查

- [ ] 「一句话」已填写，不为空
- [ ] 「需求基准描述」已填写，覆盖场景/目标/约束/验收四要素

### 自检完成声明

全部打勾后，在输出末尾声明：
"✅ S1 出口门通过：prd.md / 项目说明书.md 已写、账本 S1 已标完成、无占位符、格式合规。可进入 S2 架构选型，或用 `vibe-coding-harness` 做最终质检。"