Get PRD
概述
get-prd 将模糊的请求在一次连续会话中转化为一份经审批的PRD。它合并了通常分开运行的三个工作流：
- 设计树访谈 — 将每个决策映射为一棵树，逐轮按边界推进，并在每个问题后给出建议。这是使访谈收敛而非漫谈的机制。
- 意图提取 — 捕捉用户真正想要的东西，而非他们以为自己应该想要的，每一步都附带明确的置信度数字。这是防止Agent默默地填补空白的纪律。
- 规范编写 — 将需求以结构化的工件形式记录下来，包含边界、成功标准和审批门控。这是下游规划所消耗的交付物。
合并它们的原因是分开会丢失上下文。当访谈和规范编写是两种不同技能时，第二个技能是冷启动的：它会重新询问第一个技能已经学到的东西，或者默默假设从未给出的答案。基于过时摘要编写的PRD比没有PRD更糟糕，因为它看起来具有权威性。
合并带来的两个后果，都是设计使然：
- 此技能篇幅较长。 它承载了所有三个阶段完整的方法论，而不是将工作委托给其他技能。请按顺序执行步骤；不要跳过模板。
- 此技能绝不委托访谈。 访谈机制在此处。不要调用其他技能来进行提问。
输出是一份完整的PRD，保存到 docs/PRD.md（或 docs/prd/<name>.md），经过用户批准，可供 get-tasks 和 get-design 使用。
对于新用户或早期阶段的概念，get-prd 将想法提炼的探索视角、非功能性约束映射以及核心实体/数据关系定义直接整合到文档中，因此无需单独的架构或细化技能。
何时使用
在以下情况使用此技能：
- 用户正在启动一个新的应用、系统、功能或重大变更，且尚不存在需求文档
- 用户说 "get prd"、"bikin PRD"、"buat PRD"、"mau bikin sistem baru" 或 "mau develop X"
- 用户请求接受盘问、访谈或压力测试以形成规范
- 需求是常规且未充分明确的（“给我建一个仪表盘”、“让它更快”），而你无法陈述“完成”意味着什么
- 你将要规划或构建一个需要超过一天时间，且没有书面需求存在的事情
何时不使用：
- 修复bug、修正拼写错误、重命名和机械性操作
- PRD或规范已存在，且用户只想更改其中一小部分 — 直接修改文档
- 纯粹的信息请求（“这是如何工作的？”）
- 用户明确希望跳过文档并直接开始构建 — 尊重其意愿，但提出一次风险
- 非交互式上下文（CI流水线、定时运行、自主循环）。此技能需要一个活跃的、有回应的用户。如果在非交互式上下文中需求未明确，将其标记为阻塞项，而不是猜测。
流程
get-prd 分八个阶段运行。每个阶段都有一个退出条件。在退出条件未满足时，不要进入下一个阶段。
0. 范围门控 -> 这是一个功能还是多个？
1. 假设种子 -> 我认为他们想要什么，我有多大把握？
2. 构建树 -> 存在哪些决策，哪些处于前沿？
3. 逐轮提问 -> 询问前沿，一轮一轮地
4. 意图探测 -> 想要 vs. 应该想要
5. 复述 -> 用他们的话把它说出来
6. 差距检查 -> PRD需要哪些访谈未产生的内容？
7. 编写并门控 -> PRD，然后一个明确的“是”
访谈者的通用原则
- 自然语言匹配： 始终使用用户偏好的语言进行对话。如果用户用印尼语发起对话（例如 "bikin PRD aplikasi absensi"），则全程用印尼语进行温暖的访谈，同时保持标准行业技术术语不变（acceptance criteria, schema, endpoint, payload）。如果他们用英语，则用英语进行。绝不要强迫一个用其他语言提问的用户接受英语访谈。
- 共情且非胁迫的语气： 用户带着原始、未成形的想法到来时，绝不要审讯或让他们因缺乏技术术语而感到不适。耐心引导：将他们的业务问题转化为技术选择，并始终附上你推荐的回答（
-> Rekomendasi: ...），这样他们只需做出反应，而不是从零开始头脑风暴。 - 针对模糊/早期创意的3个黄金问题： 当用户提出一个简短的一句话创意（例如 "mau bikin SaaS seperti Notion untuk resep masakan"）时，在讨论技术栈之前，先围绕三个人性化支柱锚定前沿：
- 目标用户与情境： Siapa yang menggunakan, di mana, dan dalam situasi apa?
- 北极星用户体验旅程： Apa satu alur aksi terpenting dari awal sampai tuntas yang wajib sukses di aplikasi ini?
- 最小可行产品范围确定： Fitur apa yang mutlak harus ada di hari pertama, dan apa yang sengaja ditunda ke tahap berikutnya?
阶段0：范围门控
大多数请求描述的是一个功能。如果是这样，一行话说明并进入阶段1。此阶段是为了处理例外情况而存在的。
检测。 当单个请求捆绑了多个可独立测试的功能时，在编写任何内容之前进行分解：
- 请求命名了具有各自消费者或数据的独立功能（身份认证、计费、通知、报告）
- 验收标准可以聚类成可以独立发布和验证的组
- 一个功能可以被裁剪或替换，而无需重写其他功能的需求
当检测到时，在任何访谈轮次之前提出一个功能映射。 小型且可审查的——一个模块表格加上一个构建顺序，而不是一个项目计划：
# 功能映射: [项目名称]
| 模块id | 职责 | 依赖项 |
|---|---|---|
| identity | 账户、会话、SSO | - |
| billing | 计划、发票、支付 | identity |
| notifications | 电子邮件和Webhook广播 | identity |
| reporting | 使用量仪表盘 | billing, notifications |
构建顺序: identity -> billing, notifications -> reporting
映射规则：
- 稳定的模块id。 短横线命名，只选一次，永不重命名。下游规划通过这些id选择工作项。
- 依赖方向，无循环。 箭头单向指向。如果两个模块彼此都需要对方，则它们是一个模块。
- 接口存在于边界。 映射记录了
billing依赖于identity；它们之间的契约属于提供者模块的PRD。
映射需要门控。 在你在任何单个模块上进行访谈之前，要求用户批准模块边界、依赖方向和构建顺序。映射搞错了代价高昂；审查十行内容则不然。
然后 每个模块按构建顺序 运行阶段1-7，每个模块生成其自己的 docs/prd/<module-id>.md。不要为多模块项目编写一个单一的PRD。
退出条件： 要么请求是单一功能（明确说明），要么功能映射已获批准。
阶段1：假设种子
在问任何问题之前，写下你目前对需求的理解以及一个诚实的置信度数字。
假设：你想要一种方式在站会上回答“我们做得怎么样？”，而“仪表盘”是你首先想到的惯例。
置信度：~30% - 缺失：目标用户是谁、这里的“指标”指什么、以及成功是什么样子的
规则：
- 假设只写一句话。如果你不能用一句话写出来，说明你还未形成理解。
- 置信度数字是一个0到100的百分比。它迫使你诚实：如果你无法预测用户对你接下来三个问题的反应，那么这个数字就是错的。
- 低于约70%时，在同一行附加一个简短理由，说明仍未解决的内容。这精确地告诉用户访谈需要揭示什么。
- 每轮之后更新假设和置信度。
退出条件： 一个带有置信度数字的假设已记录在案。
阶段2：构建设计树
在问任何问题之前，映射决策空间。每个决策分支到依赖于它的决策上。
目标：个人实验追踪器
|
+-- 什么算作一个实验？ (定义单元)
| |
| +-- 哪些字段描述一个实验？ (确定schema范围)
|
+-- 数据来自哪里？ (输入源)
| |
| +-- 手动输入还是导入？ (交互模型)
|
+-- 实验何时“完成”？ (生命周期)
|
+-- 什么信号结束它？ (成功定义)
前沿 是那些前提条件已经确定的决策：你现在 可以 问的问题，而无需猜测你尚未听到的答案。
两条规则使这一切生效：
- 在一轮中询问整个前沿。 当多个问题相互独立时，不要一问一答。独立问题一起回答更快，并且用户能看到决策空间的形状。
- 一个答案依赖于另一个未解决问题的提问属于后面的轮次。 现在问它会锁定错误的框架。
事实是你的工作，绝不是用户的。 当一个前沿问题需要环境中的事实（文件系统、现有代码、某个库的API、配置值）时，分派一个子Agent去查找。不要询问任何你可以自己查到的信息。不要因此阻塞本轮：探索是一个未确定的前提，只有依赖于它的下游问题才会等待。现在就询问前沿的其余部分。决策是用户的；事实是你的。
退出条件： 树已映射，第一个前沿已识别。
阶段3：逐轮提问
询问当前前沿。每个问题格式严格如下：
**Q1 - <问题标题>**: <问题正文，可能是多段，通常列出候选选项>
-> <你推荐的答案，附带产生该答案的推理>
规则：
- 为每个问题编号。
Q1、Q2、... 每轮重新开始编号。 - 始终附上推荐。 用户对一个错误推荐的反应比从零开始生成答案要快。这也能让你对一个假设做出承诺，并且可以被明显地证明是错的。
- 等待答案，然后再问下一轮。
- 每轮之后重新计算前沿。 已确定的决策将前沿向外推移，并解除依赖于它们的未解决问题。
- 记录更正。 当用户推翻一个推荐时，同时记录决策和推理，因为PRD的“技术决策”部分会引用它。
为什么推荐很重要，以及它的失败模式：
- 用户可以在几秒钟内对一个错误猜测做出反应，但可能需要几分钟才能从无到有地生成一个答案。
- 它暴露了 你的 假设，而这正是访谈的目的。
- 风险是谄媚 — 一个礼貌的用户为了表示赞同而同意你的猜测。通过明显地表现出愿意犯错来缓解，偶尔推荐一个你预料用户会反驳的方向。如果每个推荐在第一次尝试时就被接受，要怀疑是谄媚所致。
为什么一次只问一轮，而不是一次性问完所有问题：
- 第三个问题通常依赖于第一个问题的答案；一次性问完所有问题会锁定错误的框架。
- 用户进行仔细思考的精力是有限的。一轮一轮地花费。
- 一批十五个问题读起来像是一份调查问卷，而非访谈，并且会被草草浏览。
退出条件： 本轮的问题已被回答，并且前沿已重新计算。
阶段4：意图探测（想要 vs. 应该想要）
最危险的答案是用户说出了深思熟虑的答案 听起来 像什么，而不是他们真正想要的回答。注意观察：
- 与最佳实践谈话模式相匹配的答案（“我想要它可扩展”、“清晰架构”）但没有具体细节
- 遵从惯例的答案（“大多数应用都这样做的方式”、“标准方法”）
- 诸如“我大概应该...”、“我想我应该...”、“好的工程实践说...”之类的短语
- 作为目标的流行词 — 当“现代”、“可扩展”或“健壮”替代了具体结果时
当你听到这些中的任何一个时，问：
“如果你不需要向任何人证明你的选择，你实际上会想要什么？”
这一个问题通常比之前五个问题做得更多。每当出现表示高水平的回答时，至少运行一次。同时记录所述的回答和探测出的回答 — PRD应反映后者。
退出条件： 如果任何表示高水平的回答出现，则至少运行了一次探测，并且真实的回答已记录在案。
阶段5：复述意图
当树基本确定时，将你现在认为用户想要的内容写回给他们。保持简洁，使用他们的语言，并结构化以便于他们逐行确认或修正。
以下是我现在认为你想要的内容：
- 成果: <一行>
- 用户: <一行 - 谁受益>
- 为什么是现在: <一行 - 发生了什么变化>
- 成功标准: <一行 - 我们如何知道它成功了>
- 约束条件: <一行 - 约束性的限制>
- 超出范围: <一行 - 我们明确不做什么>
是 / 否 / 完善？
规则：
- “超出范围”是不可协商的。 一半的误解是在什么 不 被构建上无声的意见分歧。
- 总共五到八行。如果更长，说明访谈还没结束。
- 尽可能使用用户的词汇；他们的语言是共享的契约。
退出条件： 一份使用用户语言的具体复述已记录在案。
停止条件
当 以下两者都 成立时，你已完成访谈：
- 你能预测用户对你接下来三个问题的反应吗？ 如果能，你们已有共识。
- 前沿是否为空？ 所有可及的决策都已做出。
阶段6：差距检查
在编写PRD之前，对照PRD所需的内容来审查访谈记录。寻找：
- 非功能性需求： 性能、安全性、可访问性、合规性、规模预期、部署环境
- 外部依赖： 第三方API、服务、认证提供商、支付网关
- 数据模式： PRD是否应包含核心实体定义？如果需要，它们现在足够稳定吗？
- 异常处理： 错误、失败模式、降级行为
- 角色和权限： 谁可以做什么
对于每个差距，要么问一个关于它的问题（如果它属于当前前沿），要么在PRD中记录它为“待确定：等待[原因]”。
退出条件： PRD的每个部分都有内容或显式的待确定标记。
阶段7：编写并门控
编写PRD。使用用户在访谈中同意的确切措辞和决策。
PRD有标题、边界、成功标准、超出范围的项目、以及技术决策部分。它没有章节编号、故事点估算或冲刺计划。
始终在底部包含一个审批门控：
本PRD是否准确并准备进入下一阶段？ 输入
yes或指出需要更改的内容。
不要假设同意。等待一个明确的“是”。
误解与边界
- 这不是一个计划。 PRD不包含估算、任务、地点或发布日期。那是下游步骤的事情。
- 访谈不是闲聊。 每轮必须使前沿收缩。如果一轮过去后新问题比已解决的问题更多，你就偏题了。
- 非交互式上下文会阻塞。 如果需求未明确且用户不在场，将缺失信息标记为阻塞项。不要猜测。
- 此技能确实总是编写文件。 它输出
docs/PRD.md或其模块变体。如果文件已存在，它会询问是否覆盖——除非用户显式要求根据相同上下文重写。 - 置信度是可见的。 假设框中的置信度数字是一个暴露工具，而非仅用于调试。它告诉用户你认为自己距离正确有多远。
平台与集成
- 适用于： Claude Code、Cline、Cursor、Codex CLI 以及任何支持自定义技能/指令的AI编码Agent。
- 输出： 写入
docs/目录。 - 下游技能： 由
get-tasks（任务分解）和get-design（技术设计）消费。 - 文件位置：
docs/PRD.md或docs/prd/<module-id>.md。