产品需求文档——PRD——是那一份说清「你在做什么、做给谁、怎么算成功」的文档。写好了，它能把一个模糊的想法变成团队和工程师不用开会就能动手的东西。这一页做两件事：先把 PRD 是什么、一份好的 PRD 包含哪些部分讲清楚；再诚实地讲那个没人提的部分——一份写在 Google Doc 或 Notion 里的 PRD，从你发布那一刻起就开始漂移，因为它里面没有任何东西，把一个决策连到依赖它的那些需求上。Draftlize 从根上修这个问题。
产品需求文档是一个功能或产品的真相源：它讲清你要解决的问题、你想要的结果、以及这个东西必须具备的具体行为。它存在的意义，是让动手做它的人不必从一条 Slack 消息里反推意图——PRD 的本质，剥掉仪式感，就是「对『我们在做什么、为什么做』这个问题，已经达成一致的那个答案」。
它不是讲「怎么做」的设计文档——那是工程设计文档的事。PRD 在它的上游：先定义清楚做什么和为什么，让怎么做有东西可服务。一份好的 PRD 短到能一口气读完，又决断到让两个读者读完后脑子里是同一幅画。篇幅不是优点；一份把取舍摊开讲明白的单页，胜过十页处处含糊。
格式并不神圣。亚马逊写六页叙事加一份新闻稿；一家创业公司可能在 wiki 里写半页。重要的不是PRD 文档长什么样——而是下面这些部分有没有被诚实地回答。下面就是这些部分。
八个部分。不需要的名字可以略过，但底下那个问题要答。无论你写在文档里、从一份 PRD 模板复制、还是在 Draftlize 里搭，骨架都是这一套——下一节讲的是：当每个部分不再是一段文字、而变成一张卡片时，会有什么不同。
用户的痛或业务的缺口，在任何方案之前先讲清。如果你不提自己那个功能就描述不出问题，那你是在为一个还没找到的方案找问题。这是为整份文档正名的那一部分。
这个产品必须达成什么，说人话。三个以内。目标是你之后砍范围时用的那把尺——任何不服务于某个目标的东西，都是该砍的候选。
那些诱人、但你这一轮刻意不做的东西。任何 PRD 里最被低估的一节，也是最能挡住「拖垮一次发版的范围蔓延」的一节。写下一个非目标，是一个决策，不是一个遗漏。
用用户的话写的具体场景——「作为 PM，我想从一份 spec 里引用某个决策，这样就不用再解释一遍。」它们把每条需求都拴回「一个人在做一件事」，让需求保持诚实。
产品到底必须做到什么，具体到能照着做、照着测。PRD 的主体。每条需求都该能追溯到一个目标和一个用户故事——两个都搭不上的需求，是装饰。
那些告诉你「成了」的数字——激活、留存、任务完成率，看目标暗示了什么。提前定，趁结果还没法影响你的选择。没有它们,「成没成?」就从一次读数，变成一场争论。
这份 PRD 所假设的那些决策、系统和其他工作。定价、一个必须存在的 API、另一份文档里做的某个决策。在静态文档里这是一张你会忘记回看的清单——而它正是决定「PRD 会不会随着事情变动而仍然成立」的那一部分。
那些你还不知道的事，诚实地写下来，而不是糊过去。一份假装一切都已敲定的 PRD 是在说谎；一份列出自己未知项的 PRD，恰恰告诉读者风险藏在哪。
这就是解剖。下面：为什么一份 PRD 从发布那天起就开始漂移——以及我们怎么应对。
同样这八个部分，为一个小功能填好——报表页的 CSV 导出。刻意写短：好的 PRD 该有多长取决于决策需要多少，而不是越长越好。
需要把报表数据拿到别处用的用户，只能一行行手动复制进电子表格——慢、易错、还是客服反复收到的抱怨。数据根本没有导出口。
1）任何用户都能一键把当前报表导出成 CSV。2）导出的文件和屏幕上看到的一致——筛选、排序、可见列。3）一万行的导出在五秒内完成。
定时或周期导出、XLSX 和 PDF 格式、以及导出当前筛选视图之外的数据——都有意推到后续版本。
作为分析师，我希望把筛选后的报表导出成 CSV，好在自己的电子表格里做透视，而不用重新录入数字。
报表工具栏上一个导出按钮；导出当前筛选、排序后的视图和可见列；CSV 为 UTF-8 且带表头行；完成时用 toast 提示；超过 5 万行的导出被拦下并给出明确提示。
60 天内手动复制粘贴的客服工单减半；上线一个月内，每周查看报表的活跃用户里至少 20% 用过导出。
报表 API 必须提供一个带筛选的导出端点（平台团队负责）。依赖「导出在所有付费套餐都包含」这个定价决策。
要不要包含被软删除的行？超大导出是否改成异步、完成后邮件通知的流程？
写在文档里，这个范例今天准、明天就在漂：改动「依赖」里的定价决策，上面那些需求没有任何东西会被告知——它们现在建立在一个已经变了的决定上。在 Draftlize 里每一节都是一张连着它所依赖决策的卡片，上游一变就把相关部分标成 stale，而不是让范例悄悄变错。
PRD 是某一刻所做决策的一张快照。然后产品往前走——价格改了、一个目标被砍了、API 上线时跟假设的不一样。文档不会跟着走。等到有人回头读它，已经有相当一部分悄悄错了，而你分不清错的是哪一部分，于是整份文档都不再被信任。
你在「目标」一节里定了定价。下游三条需求都假设了这个价。决策一改，那三条需求现在全错了——可一份 Google Doc 根本不知道它们是连着的，于是没人更新，直到一次构建出错、或一次演示让你尴尬。「依赖」一节本该接住这件事；但它是文字，所以接不住。
维护 PRD 是个跟「发版」抢时间的活，而发版永远赢。于是文档变成「第一天你怎么想」的记录，而不是「现在什么是真的」——团队于是不再打开它，这就把它存在的全部理由给废了。决策日志因同样的原因落得同样下场:靠手动，自律赢不了熵。
写在 Notion 或文档里的 PRD，是一份静态记录。解法不是更好的模板、也不是更强的自律——而是一个知道「某个决策变了」并且会去告诉「一切依赖它的东西」的 substrate。
| Draftlize | Google Doc / Notion / Confluence | |
|---|---|---|
| PRD 的每个部分 | 一张结构化、可寻址的卡片 | 一个标题加一段文字 |
| 之后还找得到 | 能从任意 spec 按 URL / ID 引用 | 埋在一份你得 grep 的文档里 |
| 决策变了，下游知道吗 | 自动标记 stale | 没有连接，悄悄腐烂 |
| AI 用得上吗 | 经 MCP 原生读 + 写 | 顶多读个纯文本 |
| 谁来保持一致 | substrate 自动追踪 | 全靠你的意志力 |
| 两条需求互相冲突 | 自动浮现 | 下次复盘才发现 |
在 Draftlize 里，PRD 不是一份长文档——每个部分都是一张结构化卡片:一个问题、一个目标、一个非目标、一条需求、一个成功指标。结构化、有稳定 ID、能从 spec 或 thread 引用，而不是埋在一个 wiki 页里。「依据决策 c-04」成了真实的引用，而不是模糊的记忆。
因为依赖是真实的链接、而不是清单里的几个名词，改掉一个上游决策，每张依赖它的卡片自动变 stale——就像构建系统让一个改动文件的所有下游失效一样。「依赖」一节许下的承诺，substrate 替它兑现。你一改，就当场看见自己改坏了什么。
Claude Code 或 Cursor，经 MCP，在起草下一条需求前读完每个相关决策，再把新决策按同样的形状写回去。PRD 不再是一份写给「永不回来的读者」的文档，而成了 agent 每一轮都来查的上下文——于是它记下的，是现在真正成立的东西，而不是上线那天成立的东西。
PRD 不是因为写得差才失败。它失败，是因为没有东西在「它的某个决策已经不成立」时告诉它一声。八个部分留着。让 substrate 替你把它们保持最新。
产品需求文档（PRD）就是对「我们要做什么、为谁做、怎么算做成了」这个问题的一致答案——它写清问题、目标、非目标、用户故事、需求、成功指标、依赖和待解问题，好让团队不用再从一堆 Slack 消息里拼凑意图就能开工。
产品经理负责它，但一份好的 PRD 是和工程、设计以及掌握业务背景的人一起写的。PM 的责任是让里面的决策清晰、且始终是最新的——而不是一个人闷头把它敲完。
PRD 定义做什么和为什么，在上游；技术（工程设计）文档定义怎么做，在下游。PRD 说「用户要能从一份 spec 里引用某个决策」，设计文档说这个引用怎么存、怎么渲染。一份 PRD 往往会派生出好几份设计文档。
BRD（业务需求文档）记录业务诉求和成功标准——公司为什么该投入。PRD 把它翻译成产品到底要做到什么。BRD 论证这笔赌注，PRD 让它可被构建。很多团队把两者合成一份。
在文档里，PRD 的每一部分都是散文，而且没有任何东西把一个决策连到依赖它的需求——所以决策一变，它就悄悄开始漂移。在 Draftlize 里每一部分是一张有类型、可寻址的卡片；上游决策一改，每张依赖它的卡片自动标记为过期，AI agent 还能经 MCP 直接读写 PRD，而不是去解析一堆纯文本。
建一个项目，用你已有的文档把它喂起来，让 agent 把 PRD 起草成结构化卡片——再替你把每个决策、以及每条依赖它的需求，保持最新。
用 $5 免费开始一键创建项目：这些章节会预置成结构化、互相链接的卡片。和 agent 一起回答它们——之后任何决策变了，依赖它的章节会自动标记过时，而不是悄悄失真。注册送 $5 额度，无需绑卡。