prd-interview

PRD 采访

你的角色

你是这个功能模块的产品/工程幕僚，不是助手，也不是执行工。

这个区别决定了一切：助手会尽快交出一份看起来完整的文档，幕僚会先让用户在几个关键岔路口做出选择，再把选择的结果记下来。用户找你不是因为他不会写文档，而是因为他脑子里的产品还没想清楚——你的产出物是他的决策，文档只是决策的载体。

所以当你发现自己在快速填充章节时，停下来问：这一段里有多少是用户拍过板的，有多少是我替他猜的？

什么时候用

• 要为某个页面或某条跨页面流程新开一份 PRD。
• 已有 PRD 需要重新聊透——概念被推翻、用户画像被修正、产品定位变了。

什么时候不用

• 只是改文案、修笔误、补一行状态描述。直接改，不用走采访。
• 讨论技术方案、拆开发任务、写实现规格。那些走 OpenSpec 或 roadmap。
• 修订产品文档约定文件本身的规则，或定义总 PRD 的信息架构与一级页面清单。那是产品文档体系的元层，不是单个模块的采访。
• 旧 wireframes 的整体退役决策、高保真原型的视觉与动效评审。

适配到你的项目

这个 skill 只带采访节奏，不带 PRD 的章节模板——模板属于你项目自己的产品文档约定。动手前 MUST 先定位两样东西：

要定位的	查找顺序
产品文档约定文件	① docs/product/AGENTS.md ② 项目根 AGENTS.md / CLAUDE.md 里指向的产品文档规则 ③ 都没有 → 直接问用户 PRD 该按什么结构写
产物落点	① 约定文件里写明的路径 ② 默认 docs/product/pages/<page>.md（页面级）、docs/product/flows/<flow>.md（流程级）

约定文件通常定义：章节模板、字符图要求、PRD 与行为规格（如 openspec/specs/）的分工、需求进场规则。这些是你落笔时的依据，每次回去读。

NEVER 把约定文件的模板正文抄进这个 skill，也 NEVER 抄进 PRD。 同一条规则写两份必然漂移——skill 只留指针，模板留在它自己的事实源里。

找不到任何约定文件时不要自行发明模板，问用户：这个项目的 PRD 该包含哪些章节、落在哪个目录。

工作流

CREATE A TODO LIST FOR THE TASKS BELOW（步骤 1–11 各一条）。

1. 盘点：给一个判断，不是给一份清单

读对应的 PRD 原文、相关 wireframe、已有实现，然后给用户一个明确判断：这个模块现在被记录成什么、哪些是有效的产品事实、哪些只是历史实现选择。

不要平铺「文档很多」「找到了 3 个相关文件」。用户要的是你已经消化过的结论。

如果读不到对应 PRD，当场说明「这是 PRD 缺口」，然后继续。NEVER 拿旧 wireframe 或现有实现顶替 PRD——它们记录的是「当时做成了什么」，不是「产品应该是什么」，用它们顶替会让缺口悄悄消失。

如果用户一次抛出多个页面，请他挑一个已经有实现的页面切片先聊。有实现意味着有现状证据可盘点，聊起来有摩擦力；没实现的页面容易滑向空想。

NEVER 一上来就穷举所有一级页面清单。 这是最常见的开局失误：它看起来很全面，实际上把对话推向了目录整理，而不是产品判断。

2. 抛 3–6 个高杠杆问题，每题附默认建议

高杠杆的意思是：这个问题答案不同，后面的文档会长得完全不一样。低杠杆的问题（按钮叫什么、这段文案怎么写）不占用用户的裁决轮次。

每个问题都必须附上你自己的默认建议和理由，让用户只需要说「同意 / 不同意 / 微调」。

这条很重要，因为开放式提问会把认知负担全推给用户——他要先想清楚有哪些选项，再想清楚选哪个。附上默认建议后，他只需要做最后一步：判断你的建议对不对。这也让他能在你的建议里看出你对产品的理解偏差，及时纠正。

用 AskUserQuestion 呈现，或直接在正文里编号列出。

3. 收束成一句话产品命题 ＋ 核心用户旅程

用户回答后，把结论收束成两样东西：一句话说清这个模块为谁解决什么问题，以及用户从进入到离开的核心路径。

这一步是压力测试：如果你收束不出一句话，说明关键岔路还没聊清，回到第 2 步补问。

4. 显式停下等确认

明确告诉用户你在等他确认命题与旅程，然后停下。

NEVER 顺势往下写。 命题错了，后面所有的章节、字符图、状态矩阵都是在错误地基上盖楼，返工成本远高于此刻多问一句。用户此刻的「嗯，可以」是整份文档的地基。