PRD 需求采访

把模糊的页面或跨页面流程，聊成「产品命题、用户旅程、已确认决策」都清楚的 PRD。

什么时候用它

新页面 PRD

我准备为某个页面从零写 PRD，尤其是页面已有一些实现线索，但还没有清楚记录产品判断。

重聊流程

已有 PRD、线框图或实现已经跟现在的想法不一致了，我不想只修几句话，而是要重新打开关键假设。

梳理需求

我想先被追问，再让它落到 docs/product/pages/<page>.md 或 docs/product/flows/<flow>.md，避免 AI 直接代笔一份看起来完整、实际未经确认的文档。

不接

不要用它来复述已有 PRD、改文案、修笔误、补一行状态描述、写技术方案或拆开发任务。那些应该直接编辑，或交给 OpenSpec / roadmap 相关流程。

它会产出什么 / 你会看到什么

它会在关键决策点停下来等你确认，而不是一路写满整份文档。

• 现状判断：读取相关 PRD、线框图和已有实现后，说明哪些是真正的产品事实，哪些只是历史实现选择。
• 高杠杆问题：提出 3–6 个会改变文档走向的问题，每题附默认建议和理由，方便你只做最后裁决。
• 产品命题：把回答收束成一句话产品定位，以及从进入到离开的核心用户旅程。
• 确认后草稿：只写你已经拍板的内容；没聊清楚的地方显式标成「待讨论」。
• 用户视角评审：用只读子任务扮演 PRD 里写明的目标用户，指出看不懂、做不到或不想用的地方。
• 单文件提交：一次采访只产出一份 PRD；获得授权后，一次提交也只包含这一份文件。
• 绝不会做：偷偷替你决定产品问题、拿旧线框图顶替 PRD、把多个页面文档混进同一个提交。

前置条件 / 边界

前置

目标项目最好已经有产品文档约定。它会先找 docs/product/AGENTS.md，再看项目根目录的 AGENTS.md / CLAUDE.md；如果都没有，就会问你 PRD 应该落在哪里、按什么结构写。

默认落点

• 页面级 PRD 通常写到 docs/product/pages/<page>.md。
• 跨页面流程通常写到 docs/product/flows/<flow>.md。
• 如果项目约定了别的路径，以项目约定为准。

相邻能力分工

要做什么	交给谁
技术方案或实现规格	OpenSpec 流程
文案、错别字、小状态补充	直接编辑
产品文档体系本身的规则	项目文档约定

边界

• 如果一次抛出多个页面，先挑一个已有实现的页面切片聊，避免对话滑向目录整理。
• 如果确认后又推翻产品命题，先回到命题和用户旅程，不要直接在草稿上硬改。
• 如果子任务评审引用了 PRD 外的用户画像，丢弃那条意见，收紧提示后重跑。
• 如果现有实现做不到 PRD 要求，把它记录成产品缺口，不要让旧代码反向限制产品判断。