当 PRD 里只有一句“支持语音识别”：我如何用 AI 把它补成可开发规格

AI 写 PRD 的关键，不是一次生成一份看起来完整的文档，而是把原本隐藏在功能描述背后的问题，逐轮变成产研设计可以共同决策的显性问题。

我拿到这份 PRD 时，语音识别部分只有一个功能点：

用户点击语音按钮后，系统实时识别用户说话的内容，并将识别结果填入答案输入框。

从功能描述上看，这句话没有什么问题。

作为技术，我甚至可以立刻在脑中还原出一条开发路径：

text 复制代码

增加语音按钮
→ 请求麦克风权限
→ 建立语音识别连接
→ 接收识别结果
→ 将文字写入输入框

原始需求的业务目标也很清楚：用户在评估系统中通过语音回答问题，系统将语音实时转换成文字，并填入当前答案输入框。

但只要沿着这个流程多问几个问题，事情很快就没有那么简单了。

用户说到一半切换了题目，识别结果应该继续写入原输入框，还是立即停止？
用户点击提交时，服务端还有最后一段识别结果没有返回，是立即提交，还是等待识别彻底结束？
麦克风权限被拒绝后，用户还能不能继续用键盘作答？评估页面里的作答倒计时是否继续？
用户切换浏览器标签、最小化窗口、锁屏或者进入系统休眠后，网页还要不要继续采集声音？
识别过程中网络断开，是自动重连、允许手动重试，还是直接终止？

这些问题在原始 PRD 中都没有答案。

但研发一旦开始编码，就一定会被迫给出答案。

可能是开发人员根据经验顺手写一个处理逻辑，可能是在联调时临时找产品确认，也可能一直没有被发现，直到测试甚至上线之后才暴露。

这也是我在这次实践之后越来越强烈的一个判断：

AI 时代，第一版 PRD 可以很薄，但团队不应该再让一份只有功能意图的 PRD，以同样的状态直接进入开发。

问题不在于产品经理有没有一次性写出几十条边界条件，而在于团队有没有一套机制，把尚未定义的问题提前暴露出来。

这一次，我尝试用 AI 完成这项工作。

但我很快发现，真正有效的方法并不是给 AI 一个更长的 Prompt，让它一次生成所谓的"完整 PRD"。

真正有效的是：把"完整"拆成不同维度，让 AI 一轮一轮地检查。

一句话需求，不等于一个可以开发的需求

在这次实践里，我逐渐把一条需求分成了三个层次。

第一层是功能意图：

用户可以通过语音向输入框输入文字。

它说明了要做什么，但只覆盖正常路径。

第二层是行为规则：

当用户切题、提交、断网、拒绝权限或者切换输入方式时，系统分别应该做什么。

它决定产品在各种中断和异常状态下如何运转。

第三层是可验收规格：

在什么条件下触发，页面表现是什么，文字是否保留，倒计时是否暂停，资源何时释放，用户接下来可以做什么。

它决定研发和测试能不能对需求形成一致理解。

原始 PRD 只提供了第一层。

这并不意味着产品经理必须独立写出后面所有内容。像 WebSocket 心跳、MediaStream 释放、AudioContext 关闭，本来就不应该要求产品经理在第一版 PRD 中全部定义。

真正的问题是：

团队过去很容易把"功能意图"误认为"最终需求"，然后把剩下的决策留到开发过程中解决。

而 AI 给了我们一个新的选择：先用很低的成本把问题发散出来，再由不同角色共同完成判断。

第一次直接让 AI 完善 PRD，为什么不够

我最开始的做法很直接，大致是：

text 复制代码

我们要在在线评估系统中增加语音输入功能。

用户点击语音按钮后开始实时语音识别，
识别结果需要填入答案输入框。

请帮我完善这项需求，并生成一份完整的 PRD。

AI 很快给出了一份结构相当完整的文档：

业务背景；
用户目标；
主流程；
功能说明；
异常处理；
验收标准。

乍一看，这已经比原始 PRD 丰富很多。

但仔细阅读后，我发现了一个问题：

文档结构完整，不代表需求边界完整。

当我让 AI 生成"完整 PRD"时，实际上是把"什么叫完整"的定义权交给了 AI。

它会根据常见 PRD 模板补充章节，也可能想到权限不足、网络异常等常规问题，但它没有理由天然知道：

这是一个带作答倒计时的评估系统；
页面中存在多道可以切换和折叠的题目；
语音输入与键盘输入会同时作用于同一个答案；
服务异常可能影响评估公平性；
PC 和移动端的交互方式不同；
用户提交时可能仍有识别结果在异步返回。

我也尝试过继续追问：

还有哪些遗漏？再完善一些边界情况。再从技术角度详细一点。

这些提问会让文档继续变长，但新增内容往往比较随机，也容易重复。

我后来意识到：

不要不断要求 AI"更完整"，而要明确告诉它这一轮从哪个方向检查。

因此，我把整个过程重新整理成了六轮边界扫描。

下面的 Prompt 是我在事后复盘中整理出的结构化版本。真正重要的不是某一句固定话术，而是每一轮只检查一个相对独立的维度。

第一轮：先建立主流程和状态统一规则

第一轮我不再要求 AI 直接写 PRD，而是先让它建立一张需求地图。

text 复制代码

这是一个在线评估系统中的语音输入功能。

用户点击语音按钮后，系统获取麦克风音频，
通过语音识别服务实时转换成文字，
并将识别结果填入当前题目的答案输入框。

先不要生成完整 PRD。

输出：
1. 用户正常使用时的完整主流程；
2. 功能涉及的核心对象和外部依赖；
3. 功能运行过程中可能存在的状态；
4. 状态之间的主要转换关系；
5. 当前描述中尚未明确的业务约束。

这一轮的目的不是寻找所有异常，而是先建立坐标系。

例如，语音识别至少可能包含这些状态：

text 复制代码

未开始
→ 请求权限
→ 建立连接
→ 正在识别
→ 正在停止
→ 已完成

同时还可能进入：

text 复制代码

权限拒绝
设备不可用
连接失败
服务异常
浏览器不支持

这个过程带来了第一个重要变化。

以前我们把语音识别理解成一个按钮：

text 复制代码

开始 / 停止

建立状态基线后，它变成了一套持续运行的系统：

text 复制代码

当前处于什么状态
→ 发生了什么事件
→ 应该切换到什么状态
→ 数据和资源应该如何处理

只有先建立这个基线，后续讨论"切题""提交""断网"时，团队才不会各自脑补一套逻辑。

第二轮：按照完整生命周期寻找中断点

有了主流程之后，我不再笼统地问"还有什么异常"，而是让 AI 沿着功能的完整生命周期逐阶段扫描。

text 复制代码

请按照语音识别功能的完整生命周期，
检查每一个阶段可能发生的中断事件。

生命周期包括：
1. 页面初始化；
2. 用户点击语音按钮；
3. 请求麦克风权限；
4. 创建音频采集资源；
5. 建立语音识别连接；
6. 正在采集和识别；
7. 用户主动停止；
8. 用户提交答案；
9. 用户切换题目；
10. 用户离开当前页面；
11. 页面或组件销毁。

对每个阶段分别说明：
- 什么事件可能中断当前流程；
- 中断后系统应该进入什么状态；
- 已识别文字是否保留；
- 是否需要通知用户；
- 是否需要释放资源；
- 是否允许重新启动。

这一轮补出了很多原始功能描述中完全没有涉及的问题：

切换浏览器 Tab；
浏览器最小化或被其他应用遮挡；
系统休眠或锁屏；
切换路由；
刷新或关闭页面；
组件卸载；
提交答案；
切换题目；
用户主动停止识别。

例如，最终清单明确提出：当用户切换到其他浏览器 Tab 时，应停止语音识别，并清理 WebSocket、音频采集和媒体流，避免后台继续占用资源和产生费用。

"提交答案"则暴露出了一个很典型的异步时序问题。从用户视角看，输入框里已经出现了文字，似乎可以直接提交。但从系统视角看，语音识别服务可能还有最后一段结果尚未返回。如果点击提交后立即发送答案，就可能丢失最后几个字。

最终的处理规则是：

用户提交答案时，如果仍在识别，先停止识别，等待识别完全结束，再执行提交。

这一规则的目的就是避免提交不完整的识别结果。

这让我形成了一个很实用的判断：

凡是带有"初始化、运行、停止、销毁"过程的功能，都应该按照完整生命周期检查，而不能只描述用户看得到的主流程。

文件上传、视频播放、地图定位、在线会议、AI 流式回答，本质上都适用这一方法。

第三轮：先找依赖，再问每个依赖会怎么坏

生命周期扫描主要解决的是"什么时候会出问题"。

接下来还要解决另一个问题：

这个功能依赖哪些东西？每个依赖分别可能怎么失败？

于是我让 AI 先列依赖，再逐个进行故障模式分析。

text 复制代码

请列出语音识别功能依赖的所有系统、设备和资源。

至少包括：
- 麦克风设备；
- 麦克风权限；
- 浏览器媒体能力；
- 音频处理资源；
- 网络；
- WebSocket；
- 第三方语音识别服务；
- 页面和组件生命周期。

然后对每项依赖分别分析：
1. 初始化失败；
2. 权限不足；
3. 设备不存在；
4. 资源被其他应用占用；
5. 运行过程中被移除；
6. 连接超时；
7. 运行中断；
8. 长时间无响应；
9. 恢复后是否可以重试。

不要只描述错误名称，
还要列出系统行为、用户反馈和恢复路径。

这一轮补出来的内容明显更系统了。

网络和连接方面包括：

网络断开；
WebSocket 建立连接超时；
已建立连接长时间无响应；
服务端主动返回任务失败；
连接关闭或异常。

最终清单不仅列出了断网，还进一步区分了"连接建立超时"和"识别过程中长时间没有服务端响应"，并提出了超时、心跳、主动断开和资源清理等候选处理方式。

设备和权限方面又包括：

用户拒绝麦克风权限；
已授予的权限被撤销；
麦克风被其他应用占用；
没有检测到输入设备；
使用过程中设备被拔出；
浏览器不支持必要能力。

这里我得到了一条后来经常复用的方法：

不要直接问 AI"这个功能有哪些异常"，而要先问"这个功能依赖什么"，再逐项问"每个依赖可能怎么坏"。

"异常"是一个过于宽泛的概念。

但当依赖被拆成设备、权限、网络、连接、服务、页面环境之后，AI 就有了明确的检查对象，遗漏和重复都会明显减少。

第四轮：专门寻找"正在做 A 时，又发生了 B"

前三轮已经发现了很多环境和系统故障，但仍然缺少一类很常见的问题：状态冲突。

真实用户不会永远按照设计好的顺序操作。

他们可能连续点击按钮，可能正在连接时又点击停止，可能语音识别还没结束就开始打字，也可能在结果返回前切换题目。

于是我增加了一轮专门的并发与冲突扫描。

text 复制代码

请从用户快速操作、误操作和状态冲突的角度，
继续检查当前需求。

重点分析以下句式：

"正在执行 A 时，用户又执行了 B。"

至少包括：
- 正在申请权限时再次点击开始；
- 正在连接时点击停止；
- 正在停止时再次启动；
- 同时启动多个识别任务；
- 正在识别时开始键盘输入；
- 正在识别时修改已有文字；
- 正在识别时提交答案；
- 正在识别时切换题目；
- 最后一段结果尚未返回时离开页面。

请指出：
1. 哪些操作必须禁止；
2. 哪些操作需要取消前一个任务；
3. 哪些操作需要等待；
4. 哪些情况可能造成文字覆盖或结果错位；
5. 哪些规则必须由产品确认。

这一轮出现了几个非常关键的需求。

首先，同一时间只能存在一个识别任务。

如果新任务启动时旧任务仍在运行，就可能出现：

两个音频流同时采集；
两条 WebSocket 连接同时工作；
不同任务的识别结果写入同一个输入框；
旧任务没有释放资源；
用户无法判断当前操作对应哪一个任务。

最终清单因此增加了识别任务数量限制：启动新任务之前先检查是否已有任务运行，再决定停止旧任务还是阻止新任务。

其次，切换题目不只是界面切换。

如果识别仍在运行，服务端后续返回的文字可能写入新题目的输入框，造成答案错位。因此，最终规则要求在切题之前先停止当前题目的识别。

第三，语音输入和键盘输入是两个同时作用于同一份文本的数据源。

如果用户已经开始手动修改文字，语音结果继续增量写入，就可能发生：

光标位置改变；
用户刚修改的内容被覆盖；
识别文本插入错误位置；
用户不知道当前到底由谁控制输入框。

最终团队针对 PC 和移动端给出了不同的切换方式：PC 侧根据键盘或鼠标操作停止识别，移动端则在用户点击输入框后停止识别。

当需求中频繁出现"正在......时又发生......"这样的句式时，我意识到：

这个功能已经不再是一个按钮，而是一套状态机。

这时候，PRD 中不一定要写出完整状态机代码，但至少要把重要的状态转换规则定义清楚。

否则，同一个需求在产品、前端、后端和测试脑中，很可能存在四套不同实现。

第五轮：让不同角色分别审查，再补入真实业务背景

前几轮解决的是通用语音识别问题。

但一个需求真正能不能落地，取决于它所在的业务环境。

在这个案例里，语音识别并不是一个独立工具，而是在线评估流程的一部分。

页面还存在：

作答倒计时；
多道题目；
题目折叠和切换；
最终提交；
PC 和移动端；
键盘与语音两种输入方式。

这些业务背景会直接改变异常处理规则。

于是我让 AI 分别站在产品、设计、研发和测试的角度进行审查。

text 复制代码

这是在线评估系统中的语音输入功能。

业务中还存在：
- 作答倒计时；
- 多道题目切换；
- 题目折叠；
- 提交答案；
- PC 和移动端；
- 键盘输入和语音输入切换。

请分别以以下角色审查当前需求：
1. 产品经理；
2. 交互设计师；
3. 前端工程师；
4. 后端工程师；
5. 测试工程师。

每个角色只指出：
- 当前仍然没有定义的决策；
- 无法直接验收的描述；
- 依赖其他角色确认的问题；
- 可能互相冲突的规则。

针对每个异常，重点补充：
- 是否暂停作答倒计时；
- 已识别文字是否保留；
- 用户能否继续键盘作答；
- 使用弹窗、Toast 还是页面内提示；
- 是否允许重试；
- 恢复后是否自动继续识别；
- 用户下一步可以做什么。

这一轮是整个过程里最重要的一步。

因为 AI 可以发现：

麦克风权限可能被拒绝。

技术也可以判断：

浏览器会返回相应权限错误，前端可以捕获并停止识别。

但这还远远不是完整需求。

团队仍然需要回答：

权限被拒绝后，作答倒计时继续还是暂停？
用户是否仍然可以使用键盘回答？
使用普通 Toast，还是需要阻断式弹窗？
用户关闭弹窗后，页面处于什么状态？
是否提供权限开启指引？
用户重新授权后，是否自动恢复识别？
已经识别的内容是否保留？

这些不是单纯的技术问题。

这里我们团队内部会议（产品、研发、测试人员均在场）最终决定：

第三方语音服务异常时使用弹窗提示，并停止倒计时；
麦克风权限被拒绝或撤销时，同样使用弹窗，并停止倒计时；
未检测到语音输入设备时使用红色 Toast；
10 秒没有语音输入时使用蓝色 Toast；
PC 和移动端采用不同的输入方式切换规则；
浏览器不支持相关能力时使用通用错误提示。

这也是整次实践中，我认为最重要的结论：

AI 找到的是问题，团队决定的才是答案。

AI 可以帮助我们发现"权限异常"这个场景，却无法仅凭通用知识决定"是否暂停评估倒计时"。

后者涉及业务公平性、用户体验、异常责任和产品规则，必须由真实业务负责人确认。

第六轮：停止发散，把候选问题收敛成可执行规格

AI 很擅长发散，但如果一直追问，它也可以不断增加长尾场景。

因此，最后一轮不能继续问"还有什么遗漏"，而要开始去重、归类、定级和验证。

我最后使用的整理思路大致如下：

text 复制代码

请将当前所有边界场景去重并重新分类。

每一项统一包含：
- 场景名称；
- 所属阶段；
- 触发条件；
- 系统行为；
- 已识别文本如何处理；
- 作答倒计时如何处理；
- 用户反馈方式；
- 是否允许重试；
- 是否允许自动恢复；
- 优先级；
- 决策责任人；
- 技术验证状态；
- 验收标准。

决策责任人从以下角色中选择：
产品、设计、前端、后端、测试、共同决策。

技术验证状态只能是：
已验证、待验证、部分平台支持、无法可靠实现。

如果多个场景最终执行相同的停止和资源清理动作，
请提取公共规则，不要重复描述。

这一轮有三个目的。

第一，区分候选问题 和确认需求。

AI 提出的内容不应该自动进入开发范围。它只能先进入候选清单，再由团队判断：

是否真实存在；
是否属于当前版本；
是否值得投入；
是否有更简单的处理方式；
是否可以被稳定检测和验收。

第二，区分业务要求 和技术实现候选。

例如：

text 复制代码

业务要求：
页面进入后台后停止语音识别。

技术候选：
监听 visibilitychange、blur 等事件。

验证状态：
需要在目标浏览器和移动端进行验证。

AI 很容易给出 visibilitychange、beforeunload、ondevicechange 这样的 API 名称，看起来非常具体。

但"写出了一个 API 名称"和"这个 API 在目标环境中能够可靠满足业务要求"是两回事。

原始清单本身也提到，在页面刷新或关闭场景中，异步清理操作可能无法执行。

所以，AI 给出的技术细节应该被视为：

待验证的实现假设，而不是已经成立的事实。

第三，提取统一的系统动作。

在最终清单中，很多场景都会执行相似操作：

停止语音识别；
停止音频采集；
关闭 WebSocket；
释放 MediaStream；
关闭 AudioContext；
清理定时器和事件监听；
重置页面状态。

仅组件卸载这一项，就涉及停止识别服务、停止采集、关闭连接、释放媒体流、关闭 AudioContext 和清理监听器。

如果每一个需求条目都重复写一遍，不仅文档很长，代码也容易出现多套不一致的清理逻辑。

更合理的做法是先定义统一停止流程：

ts 复制代码

stopTranscription({
  reason: 'question-switch',
  preserveConfirmedText: true,
  pauseCountdown: false,
  notifyUser: false,
})

不同场景只需要决定：

为什么停止；
是否保留文字；
是否暂停倒计时；
是否提示用户；
是否允许重新开始。

这也是从"需求清单"继续走向"可维护技术方案"的一步。

以麦克风权限为例：一句异常描述如何变成完整决策

在整个案例中，"麦克风权限被拒绝"最能说明 AI 与产研设计应该如何分工。

最初，AI 可能只会写：

当用户拒绝麦克风权限时，提示用户开启权限。

这句话看起来合理，但仍然无法直接开发。

继续拆解后，它至少包含四个层次。

第一层：技术事件

浏览器请求麦克风失败，前端捕获权限相关错误。

最终清单中也记录了权限拒绝、权限被撤销以及不重复发起权限请求等处理要求。

第二层：系统行为

停止当前启动流程；
不创建语音识别连接；
清理已经创建的资源；
将语音按钮恢复到可理解的状态；
避免连续弹出授权请求。

这些主要由技术负责确认。

第三层：业务行为

作答倒计时是否暂停；
用户是否还能使用键盘作答；
已经填写的答案是否保留；
是否允许跳过当前题目；
是否影响本次评估结果。

这些必须由产品确认。

第四层：用户反馈

使用弹窗还是 Toast；
标题和正文是什么；
是否提供"重新尝试"；
是否提供"改用键盘"；
是否引导用户前往浏览器设置；
弹窗是否允许直接关闭。

这些需要产品和设计共同定义。

测试则继续把规则转成具体场景：

用户首次请求时拒绝；
用户选择永久拒绝；
用户授权后又在浏览器设置中撤销；
用户重新开启权限后再次点击；
不同浏览器的错误表现是否一致；
权限异常时倒计时是否真的暂停。

一条"权限被拒绝"的异常描述，最终变成了一组跨越产品、设计、技术和测试的决策。

这就是 AI 在这里真正发挥作用的地方：

它不是替团队作出这些决定，而是让团队意识到这些决定不能再被忽略。

这不是技术替产品写 PRD

写到这里，可能会产生一个误解：

产品只写了一个功能点，最后是不是技术借助 AI，把产品应该做的工作全部补了？

我并不这样理解。

产品经理不需要在第一版 PRD 里写出 WebSocket 心跳、AudioContext 生命周期或者不同浏览器的媒体 API 错误。

技术也不应该单方面决定：

服务异常时是否暂停倒计时；
权限被拒绝后是否允许继续作答；
已识别文字是否保留；
用户是否能够自动恢复。

更合理的职责分工是：

产品负责业务意图、范围和业务决策。

它要明确为什么做、谁使用、正常路径是什么，以及异常发生后，业务允许用户做什么。

设计负责状态反馈和恢复路径。

它要定义识别中、停止中、失败、无设备、无权限等状态如何表现，以及用户下一步如何继续。

技术负责可检测性、状态管理和实现风险。

它要判断哪些场景可以可靠监听，异步时序怎么处理，资源如何释放，多端和多浏览器是否支持。

测试负责把描述转成可复现、可观察的验收场景。

它要发现哪些规则仍然模糊，哪些状态组合没有覆盖，以及结果如何被验证。

AI 负责低成本发散、交叉审查、去重和整理。

它可以帮助团队快速获得一份候选问题集，但不拥有最终决策权。

所以，这次实践不是"技术替产品重写 PRD"，而是：

技术借助 AI，提前暴露了需求中尚未被定义的部分，再由产研设计共同完成决策。

最后得到的，也不应该只是一份更长的 PRD

最终形成的语音识别清单覆盖了页面可见性、网络连接、资源清理、权限与错误、用户交互、性能限制、体验优化和兼容性等多个维度。

但严格来说，它更像一份：

产研设计联合评审底稿。

因为其中同时混合了：

产品业务规则；
设计反馈形式；
前端事件和状态；
WebSocket 和音频资源处理；
测试触发条件；
会议决策。

它的价值是帮助团队把问题讨论清楚，而不是要求所有角色长期共同维护一份无限膨胀的文档。

评审完成后，更合理的做法是将结果拆成四类产物。

第一类是 PRD 补充：

业务场景；
优先级；
文本保留规则；
倒计时规则；
重试和恢复规则；
异常后的用户权限。

第二类是 交互状态说明：

语音按钮各状态；
弹窗和 Toast；
错误提示文案；
用户下一步操作；
PC 与移动端差异。

第三类是 技术方案：

状态机；
WebSocket 生命周期；
音频资源管理；
统一停止流程；
超时与重试；
兼容性验证结果。

第四类是 测试与验收清单：

Given / When / Then；
网络与权限异常；
快速重复操作；
切题和提交竞态；
浏览器与设备矩阵；
资源是否被正确释放。

因此，好需求并不等于把所有东西塞进一个巨大的 PRD。

真正重要的是：

所有关键问题都有明确归属，每一个团队成员都知道自己需要做出什么决定。

我最终沉淀下来的六轮边界扫描法

回过头看，这次实践可以归纳成一条相对稳定的流程：

text 复制代码

需求基线
→ 生命周期扫描
→ 依赖故障扫描
→ 状态冲突扫描
→ 多角色与业务审查
→ 去重、验证与验收固化

它背后的逻辑分别是：

先定义正常情况下如何工作。
再检查每个阶段可能在哪里被打断。
列出所有依赖，逐个分析它们如何失败。
检查"正在做 A 时，又发生 B"的状态冲突。
补入真实业务背景，让不同角色分别作出决策。
停止无限发散，将候选问题变成可开发、可设计、可测试的规格。

这套方法并不局限于语音识别。

同样可以用于：

文件上传；
在线支付；
第三方登录；
视频会议；
地图定位；
AI 流式生成；
消息推送；
长时间后台任务。

以文件上传为例，也可以使用相同的问题结构：

text 复制代码

生命周期：
选择文件、校验、上传、处理中、完成、取消。

依赖：
文件系统、网络、对象存储、后端任务。

状态冲突：
上传中删除、重复上传、切换页面、重新选择文件。

业务规则：
失败后是否保留记录，是否支持断点续传，用户能否继续其他操作。

验收规则：
进度如何展示，失败如何重试，刷新后状态如何恢复。

具体功能不同，但寻找遗漏的方法高度相似。

写在最后

我并不能证明这份语音识别清单覆盖了所有可能情况。

AI 也无法通过一个 Prompt，保证不遗漏任何边界。

但这次实践至少把过去依赖个人经验和会议临场发挥的需求检查，变成了一套可以重复执行的过程。

更重要的是，它改变了团队讨论需求的方式。

过去的需求评审经常从一句话开始：

大家看看还有没有什么问题？

这种问题很难回答，因为每个人都需要现场从零开始发散。

现在，AI 可以先生成一份候选问题清单，会议讨论则变成：

这个场景是否真实存在？
它属于当前版本吗？
这里应该暂停倒计时吗？
使用弹窗还是 Toast？
文字是否保留？
技术上能否可靠检测？
测试如何验收？

会议不再负责临时想出所有问题，而是负责判断、删除、修改和定级。

这就是我认为 AI 在产研协作中最现实的价值：

不是替产品写 PRD，不是替研发做技术设计，也不是替团队作出业务决策，而是把原本隐藏的问题，以足够低的成本提前摆到桌面上。

所以，我对 AI 时代 PRD 的理解最终变成了：

第一版 PRD 可以是一份简洁的需求意图，但不能以功能点清单结束。
AI 负责扩大问题的覆盖范围，产品、设计、研发和测试负责完成真实决策。
PRD 最需要升级的不是长度，而是它的形成机制：从一个角色写完后向下交付，变成团队围绕显性问题共同收敛出可执行规格。