最近一直在尝试把 AI 用到需求分析工作中。现在这套方法已经相对稳定，写一份需求的时间，大概可以节省一半。

不过，这并不是把一句需求发给 AI，让它直接生成一篇 PRD。我的项目比较复杂，如果缺少上下文，它写得再完整，也很容易是错的。

先说一下我的项目背景

我现在所在的是一个100多人的大型 ToB 软件项目，涉及管理后台、设计端和 iPad 端。产品团队分成三个大组，每个组有6～7个人。

同一个组里，大家还能大概知道彼此正在做什么、功能方向是什么。跨组以后，基本就不具备这种沟通条件了，主要由更高层级的负责人进行协调。

即便在同一个组，也不可能详细了解其他人的每一份需求。我现在负责的模块还是由两个人共同维护的，也不是所有内容都由我一个人掌握。

而且项目已经进入持续迭代阶段，大部分需求都是在原有功能上继续优化。一个看起来很小的调整，背后可能已经有很多历史逻辑。

所以，在这个项目里用 AI，第一步不是让它写，而是先给它补上下文。

先让 AI 了解这个模块原来是什么样

我把这个模块已经完成的需求文档全部下载下来，再和相关的蓝图文档一起放进 AI 的项目文件夹，让它先学习现有功能。

这些资料可以帮助它了解：这个模块已经有什么功能、不同功能之间是什么关系、现有边界在哪里，以及我们过去通常怎样组织需求文档。

当然，这不等于 AI 已经完全理解了项目。历史文档本身也可能不完整，其他产品经理正在做的需求，它也未必知道。

但至少，它不再是完全从零开始猜。

每个新需求，再补充两类信息

接到具体需求分析任务后，我还是会先按照正常流程了解需求来源、用户痛点和用户期望。

在和用户沟通时，我会打开飞书妙记，保留完整的沟通记录。沟通结束后，我还会自己整理一份背景文档，写清楚需求内容、用户遇到的问题，以及我对功能实现方向的初步设想。

这两类材料的作用并不一样。

沟通记录保存的是用户说了什么，背景文档保存的是我作为产品经理怎么理解这件事。两部分一起交给 AI，它才能同时看到原始信息和我的判断。

我不会马上让它写 PRD

材料准备好以后，我会先让 AI 阅读项目文件，理解当前功能的现状和边界，然后输出一张“背景理解卡”。

它需要告诉我：它怎样理解需求背景、用户问题和本次范围，还有哪些地方不清楚。

我会明确要求它，遇到不懂的内容和可能阻塞后续写作的问题，一定要继续问，不能自己猜，也不能马上开始写正文。

这个过程通常会来回两三轮。它提出问题，我逐项回答；有些问题我自己也不确定，就继续找用户或者相关同事确认。

等背景、范围和关键决策基本对齐后，才进入需求文档的写作。

我现在觉得，这一步比让 AI 直接写一篇完整 PRD 更重要。因为如果它一开始就理解错了，后面写得越详细，返工反而越多。

需求文档分成两个阶段写

第一阶段，我只让 AI 输出文档的主体，包括背景、目标、范围、核心流程和核心功能需求。

这个阶段我主要检查两件事：它对核心功能的理解是不是符合我的预期，整篇文档的章节设置和说明逻辑是不是我想要的。

如果方向有问题，就在这里调整。因为内容还没有展开得特别细，修改起来比较轻。

主体确认以后，再进入第二阶段，补充异常情况、验收标准以及其他细节。

因为前面的方向已经对齐，第二阶段一般不会出现特别大的改动。

详细提示词可以看这篇：这两段提示词，让 AI 写的 PRD 更接近实际要求

AI 写完的内容，我不会直接复制

即便走完这套流程，AI 输出的文字还是会有比较明显的 AI 感。

它经常把内容拆得很碎，句子看起来都对，但放在一起不太像真正给同事阅读的需求文档。

说实话，如果同事发给我一份这样的文档，我心里可能也会想吐槽。

所以最后我还会自己再过一遍：合并细碎的表达，把它改成团队平时真正会阅读和使用的样子。

AI 可以帮我整理资料、搭建结构、补充细节，但什么内容应该写、功能边界怎么判断、最终文档能不能交付，还是要由我负责。

目前大概能节省一半时间

按照我现在的实际感受，这套方式大概可以节省一半的需求文档输出时间。

但对我来说，这已经很实用了。至少我不用把大量时间花在从空白文档开始组织文字上，可以把更多精力放在功能判断上，也能留一点时间继续探索其他 AI 实践。