用 AI 写 PRD 的人越来越多，但真正会用的人不到 10%

最近，AI 成了产品经理们的“提效神器”，特别是写 PRD（产品需求文档）时。

但这产生了一个普遍的误区：很多产品经理上手第一步就是直接投喂一句话需求，然后下令：“帮我写一份完整的 PRD。”

看起来几秒钟就生成了洋洋洒洒几千字，但实际上，这种做法往往是“错得越快，错得越完整”。

一、 PRD 的本质：是“判断”而非“文字”

我们要明白一个核心逻辑：PRD 绝不是一篇文章，而是一连串产品判断的集合。

一份合格的文档背后，其实是产品经理对以下问题的深度思考：

• 核心受众： 需求到底在解决谁的问题？

• 业务目标： 为什么要做？想达到什么业务结果？

• 功能边界： 这版先做什么？哪些绝对不能碰？

• 验收标准： 怎么才算做好了？

• 异常流： 哪些流程必须补齐，防止系统崩溃？

如果这些判断没想清楚，AI 生成的内容虽然格式标准、用词专业，但它只是基于概率生成的“空壳”。没有灵魂的 PRD，只会让研发和测试在评审会上把你问得哑口无言。

二、 真实场景：为什么“一句话需求”不能直接变 PRD？

假设你收到一个反馈：“客户说审批节点太多，每次都要在群里催，能不能加个自动提醒？”

这只是一个需求线索。如果你直接让 AI 去写 PRD，AI 会自动帮你“脑补”规则，而这些脑补往往脱离业务实际。

在写文档之前，必须先拆需求。 你需要搞清楚：

• 是哪个流程审批慢？合同、财务还是人事？

• 提醒谁？审批人还是发起人？

• 触发频率是多少？两小时一次还是每天一次？

• 最关键的判断： 我们是单纯加个“催办提醒”，还是该从根本上重做审批流？

这些决策，AI 没法代劳，必须由人来做。

三、 重新定义分工：AI 做执行，人做判断

想要用好 AI，产品经理需要把工作链路重新拆解，明确人与 AI 的分工边界。

1. AI 适合做的（提效辅助）：

• 信息整理： 将凌乱的会议纪要转化为结构化大纲。

• 列追问清单： 帮你发现那些容易被忽视的盲点（如：如果用户断网了怎么办？）。

• 补全结构： 快速生成 PRD 的标准模板。

• 查缺补漏： 检查逻辑闭环，提供边缘情况（Corner Cases）建议。

2. 人必须做的（核心价值）：

• 目标定义： 判断这个需求是否值得做。

• 优先级排序： 在有限的资源下决定先切哪一块业务。

• 风险把控： 方案是否符合当前公司的业务现状和技术架构。

四、 进阶工作流：先拆需求，再写文档

一个专业且严谨的 AI 辅助工作流应该是这样的：

1. 输入混乱需求： 告诉 AI 原始的需求线索。

2. AI 拆解与追问： 让 AI 输出“已知事实”、“待确认信息”和“逻辑漏洞”。

3. 人为决策： 产品经理根据 AI 的提示，去调研、沟通并做出关键判断。

4. 整理成文： 将你明确的规则（如：超过 2 小时提醒、仅限合同审批、验收指标为审批时长缩短 30%）输入给 AI。

5. 生成 PRD： 这时 AI 才有足够的“弹药”去生成一份真正可评审、可落地的文档。

五、 写在最后

很多产品经理觉得自己的写作能力不够，所以依赖 AI。但实际上，产品经理的核心竞争力从来不是“写作”，而是“拆解需求”和“决策方案”的能力。

PRD 只是这些思考的投影。

一句话总结：先拆需求，再做判断，最后才轮到写文档。

不要把你的产品判断权“外包”给 AI，因为它不懂你的业务，只有你懂。