Day 062 · AI 生成 PRD 很快，PM 怎么审得过来？

我现在基本不自己写 PRD。

通常是先和 AI 讨论需求、Scope、流程和产品规则，再由 AI 整理成阶段文档。后面需求有变化，也会继续让 AI 修改。

生成 PRD 已经不是问题了。

真正困扰我的是：

AI 生成得太快、太多，但我未必真的审得过来。

一份文档可以在很短时间内变得结构完整、内容详细。背景、目标、流程、异常情况、验收标准，看起来什么都有。

但文档越长，我越难一直保持同样的注意力。

有时前面还会认真看，后面逐渐变成快速扫描。有时因为需求已经讨论过几轮，也会下意识觉得：这些内容都是基于之前的对话整理的，应该不会偏得太远。

真正的问题往往到开发时才出现：

某条规则和另一处冲突；
两个状态之间无法流转；
AI 为了补全流程，自行决定了一种处理方式；
一个原本暂定的想法，被写成了正式需求；
Scope 在展开过程中慢慢变大；
验收标准看似完整，实际无法判断是否通过。

这时当然还可以改。

但影响的已经不只是一份文档，还可能包括设计、代码、测试，以及其他基于这份 PRD 继续生成的内容。

所以我现在关心的，不再是怎样让 AI 把 PRD 写得更完整，而是：

PRD 主要由 AI 生成以后，PM 应该怎样审，才能真正发现问题？

AI 让写作和思考分开了

以前 PM 自己写 PRD，写作和思考往往发生在一起。

一个流程怎么走、一条规则怎么写，通常已经在动笔的过程中想过一遍。

现在，AI 可以直接把讨论展开成完整文档。整理、补充和表达都快了很多，但也带来一个变化：

文档写完了，不代表其中的每一个判断都被认真确认过。

AI 生成的内容还有一个很容易让人放松警惕的特点：它通常读起来很顺。

明显的语病和结构问题不多。更常见的情况是，某个局部判断其实不准确，但放进完整的段落里，仍然显得相当合理。

于是审查很容易变成：

结构齐不齐；
表达顺不顺；
内容看起来是否完整。

而不是：

产品真的应该这样运行吗？
这里是不是多了一条我们没有决定过的规则？
开发会不会把这句话理解成另一种意思？

不能简单规定哪些章节看、哪些章节跳过

最直接的解决办法，好像是只认真看重点：

Scope；
产品规则；
状态和权限；
异常流程；
验收标准。

背景、解释和示例可以快速略过。

但这里有一个绕不开的问题：

在还没看之前，怎么知道新的决定被写在了哪里？

AI 可能在普通的流程说明里补上一句：

如果生成失败，系统将自动重试，并用新结果覆盖原结果。

看起来只是一条异常处理，但它实际上决定了：

是否会产生额外调用；
原来的结果是否保留；
用户是否知道系统发生了重试；
连续失败时会不会继续执行；
用户能否恢复之前的内容。

所以，并不存在一份完全安全的“跳过清单”。

所有新增内容至少需要被扫描一次。但这也不意味着每次都必须从第一页开始逐字重读。

更现实的做法，是先把真正需要 PM 判断的地方暴露出来。

AI 不应该只交付一份完整 PRD

如果每次修改后，AI 都重新输出一份完整文档，PM 还需要自己找：

哪些地方变了；
哪些是新增内容；
哪些只是重新表达；
哪些地方出现了新的产品决定。

文档更新得越频繁，这件事越难坚持。

所以，一次完整的 PRD 交付，至少应该包含两部分。

第一部分：当前版本的完整 PRD

它负责保存需求，供产品、设计、开发和测试继续使用。

第二部分：本轮审查摘要

它不需要重新总结整份文档，只需要说明：

本次新增了什么；
修改或删除了什么；
哪些流程、状态和规则受到影响；
哪些内容来自已经确认的决定；
哪些是 AI 为了补全流程提出的；
哪些仍然只是假设；
哪些问题还没有答案。

完整 PRD 是工作文档。

审查摘要告诉 PM：这一轮到底应该先看哪里。

否则，每次修改都要求重新阅读整份 PRD，最后很容易变成依赖一句“应该没什么问题”。

决定、假设和建议，需要明确分开

AI 生成的 PRD 难审，还有一个原因：不同性质的内容经常被写成同一种确定语气。

例如：

用户可以保存三份简历；
用户可能有保存多份简历的需要；
为了控制一期范围，暂时只允许保存三份简历。

它们分别可能是：

已确认的产品规则；
尚未验证的用户假设；
当前阶段的取舍。

但如果都被平铺在正文里，设计和开发看到的可能都是“正式需求”。

所以，我希望 AI 在生成文档时，明确区分：

已确认决定
暂定方案
待验证假设
未解决问题
AI 补充建议

具体叫什么并不重要。

重要的是，AI 补出来的内容不能因为进入了 PRD，就自动变成已经确认的需求。

根据 PRD 生成一个简单 demo，是很有效的审查方式

只看文字，有些问题确实很难发现。

流程写在文档里可能很顺，但真正放到界面上，就会立刻暴露出问题：

用户不知道下一步该做什么；
页面缺少一个必要状态；
某个操作其实需要确认；
两种状态在界面上无法区分；
异常发生后，用户没有办法继续；
原本看似简单的规则，实际需要很多额外交互。

所以，在有了阶段 PRD 后，我觉得一个很有效的做法是：

让 AI 根据 PRD 快速生成一份简单 demo，再把 demo 和文档放在一起审。

这个 demo 不需要追求完整设计，也不需要达到正式开发质量。

它的作用是把文字里的需求变成一个能点击、能流转、能看到状态变化的东西，帮助 PM、设计和开发确认：大家理解的是不是同一个产品。

审查时可以选择几个具体场景：

用户如何开始一个任务；
正常情况下怎样完成；
数据缺失时会发生什么；
AI 无法给出可靠结果时怎样处理；
用户能不能取消、重试或返回；
状态变化以后，页面会显示什么；
用户刷新或中断后，是否还能继续。

PRD 里不容易察觉的空白，在 demo 里通常会明显很多。

但 demo 不能代替 PRD

demo 很适合检查流程、交互和状态是否说得通，但它无法完整表达所有产品规则。

例如：

权限判断；
数据要求；
边界条件；
不容易在界面中展示的异常；
外部依赖；
验收标准；
暂时没有实现的后续逻辑。

一个 demo 也可能看起来很顺，却掩盖了背后的规则不完整。

所以更合适的方式不是“做完 demo，就不用认真看 PRD”，而是：

用 demo 检查产品是否真的能走通，用 PRD 检查规则、边界和异常是否被说清楚。

两者应该互相验证。

如果 demo 中出现了 PRD 没有写过的行为，需要回到文档确认：这是实现时的临时选择，还是应该正式加入产品规则。

如果 PRD 里写了一条重要规则，却无法在 demo 中找到对应的反馈或操作，也需要继续调整。

不同内容可以采用不同的审查深度

在知道本轮变化之后，并不是所有内容都需要投入同样的时间。

必须认真确认的内容

凡是新增或改变产品行为的，都需要逐条看：

Scope 和 non-goals；
产品规则；
状态和权限；
自动化条件；
不可逆操作；
失败和恢复方式；
外部依赖；
验收标准；
关键假设。

这里需要确认的不是文字是否合理，而是：

用户实际会经历什么；
开发会怎样理解；
是否与其他规则冲突；
出错后能否恢复；
这是不是已经作出的决定。

可以快速检查的内容

如果只是重新组织已经确认的内容，可以看得快一些：

调整文档结构；
统一术语；
补充说明和示例；
把已确认流程整理成表格；
根据规则生成验收标准初稿。

快速检查的重点是：AI 有没有在改写过程中改变原意，或者顺手增加新的判断。

可以抽查的内容

格式化和机械展开的内容，可以采用抽查：

编号整理；
表格转换；
重复模块的相同结构；
按固定格式生成测试样例。

前提是 AI 已经明确说明了修改范围，生成规则相对稳定，而且出错的后果较低。

如果连它具体改了什么都不知道，就很难真正放心地轻审或抽查。

小改动不要重新生成整份 PRD

修改一个状态、一条规则或者一个字段时，让 AI 重新生成整份 PRD 看起来很方便。

但整份重写也会制造新的审查工作：

本来没有要求修改的内容可能一起被改变；
新旧两版都很完整，反而看不出差异；
PM 需要重新检查大量已经确认过的内容。

更稳妥的方式是：

只修改受影响的部分；
列出修改前后的差异；
说明连带影响了哪些流程和规则；
重大决定同步进入 decision log；
已确认的内容不要每次重新推导。

完整 PRD 当然仍然要维护，但更新它不应该等于每次重新生成一遍。

AI 生成 PRD 的效率，不能只看生成速度

当 PRD 主要由 AI 来写以后，生成内容已经不是瓶颈。

新的瓶颈是：人能不能可靠地发现其中的变化、假设和问题。

对我来说，一份更容易审的 AI PRD，至少应该做到：

本轮变化看得见；
决定、假设和建议分得开；
AI 自行补充的内容被标出来；
高风险变化可以快速定位；
可以根据 PRD 生成简单 demo，检查流程和理解是否一致；
demo 里发现的问题，会重新写回文档；
已经确认的内容，不会在每次更新中被重新改写。

AI 已经解决了“怎么快速生成一份 PRD”。

现在真正需要解决的是：怎么让人审得动，也审得出问题。