定义
产品需求文档(PRD,Product Requirements Document,别名 to-do list / plan)是你交给 AI 编码助手的结构化输入——把一个模糊的产品概念拆成一个个具体 feature,写清视觉目标、功能支柱、约束条件,让 agent 逐一实现。三个信源的共识是:名字叫什么不重要,它是决定长周期定制项目能跑多远的前置因素——好输入决定好输出,产品需求文档的详尽程度直接框定了 agent 产出的上限。
术语判别:PRD 是产品行业通用术语,中文圈已有完整对等词”产品需求文档”,中文化为主,英文缩写作为别名保留。
各信源立场对照
| 信源 | 立场/侧重 | 锚点 | 采信 |
|---|---|---|---|
| Chase·Fable5 | 产品需求文档是长任务产出上限的前置因素:一个 21000 行 TypeScript 的 3D 游戏,背后只有一份人工写清视觉/功能/约束的产品需求文档 | 10:32 | 利益中性,推付费课但产品需求属通用共识 |
| Greg·完全解读 | 好输入决定好输出:把产品需求文档当成给人类工程师的说明书写,用交互式追问工具把它从粗糙逼到详尽 | 3:02 | 利益中性,无贴片推广属跨工具共识 |
| Chase·六个层级 | 反面警示:Level 1”提示工程师”给了详细产品需求文档却从不寻求反馈,交互纯单向——有好文档不等于会用 | 2:10 | 利益中性,推付费课但框架不依赖购买 |
分歧与共识
- 共识:三源一致把产品需求文档当作长任务的前置决定因素——不是可有可无的文档,而是产出上限的天花板;核心动作是”把模糊概念拆成具体 feature”。
- 侧重分歧:Fable5 强调产品需求文档决定能跑多远(结果视角);Greg 强调怎么把产品需求文档写好(用交互式追问工具从粗逼细,过程视角);六个层级则给了反面——产品需求文档再详细,若交互是单向的、从不寻求反馈,依然停在最低层级。
- 关联:Greg 的 Ralph Loop 是把产品需求文档拆出的每个 feature 用”测试+lint 过才前进”的自主循环逐一实现的具体做法,与产品需求文档是上下游关系。
怎么用
- 启动任何长周期定制项目前,先写产品需求文档:像给人类工程师写说明书那样,把产品拆成具体 feature,写清视觉目标、功能支柱、约束条件——别只丢一个模糊概念。
- 用交互式追问把产品需求文档从粗糙逼到详尽,再开工:并且交互要双向——持续给 agent 反馈,而不是下达一次详细文档就撒手(否则等于停在”提示工程师”最低层级)。
适用边界
- 交互若单向就停在最低层级:六个层级·2:10 明示”Level 1 提示工程师”给详细 PRD 却从不寻求反馈 ≠ “好输入等于好输出”——详细 PRD 配单向交互在长任务里仍失效,双向反馈是 PRD 真正发挥上限的前置条件。
- 只丢模糊概念等于没给 PRD:三源虽称之为 to-do list / plan / PRD,但名字不关键——关键是把模糊产品概念拆成具体 feature 并写清视觉目标 / 功能支柱 / 约束。只丢模糊概念即失效,这是 PRD 概念最常见的失效路径。
关联
- Ralph Loop — 印证:Ralph Loop 把 PRD 拆出的每个 feature 用”测试 + lint 过才前进”的自主循环逐一实现,二者是上下游关系(本页「怎么用」已点出)。
- forward-goal — 印证:PRD / 规划质量决定 forward-goal 模式能跑多远(forward-goal 页「定义」已点出)。