补齐产品需求文档的输入输出与范围

这个场景能帮你做什么

产品需求文档（PRD）只列功能名称时，研发容易自行补业务规则。WorkBuddy 可以依据已确认需求检查触发、输入、处理、输出和范围，生成待确认缺口与修订草稿。

开始前需要准备什么

提供现有 PRD、确认过的需求证据、角色权限、流程说明、原型文字说明及本轮范围。给出当前版本和已经放弃的方案；未确认内容单列，不让 AI 把早期讨论恢复为正式需求。

具体怎么做

第一步：逐功能补齐任务边界

对每个功能检查使用者、触发条件、前置状态、输入内容、处理规则、输出和后续去向。说明明确不处理什么，避免开发人员把相邻任务一并实现。

第二步：连接界面、规则和数据

将原型中的按钮或页面状态对应到业务动作，检查数据从哪里来、由谁确认、失败如何显示。原型只展示结果时，隐藏规则标待确认，不由 AI 猜出。

第三步：检查例外与完成标准

补问空输入、重复提交、无权限、超时和取消后的状态。AI 产品还要明确可接受输出、不可用时的处理和人工接管。没有批准的阈值不要补数字。

第四步：按差异修订文档

输出旧描述、建议描述、依据和待确认项，仅更新确认过的内容。保留变更范围，使研发能分清本轮新增与旧版不变规则。

可以直接交给 WorkBuddy 的完整要求

请依据已确认需求检查现有 PRD，不创造新需求。
逐功能列使用者、触发、前置状态、输入、处理规则、输出、后续动作和不处理范围。
检查原型文字与业务规则、权限、数据来源是否对应，列正常、异常及取消路径缺口。
修订建议附依据；无法由资料确定的进入补问，不填成既定规则。输出差异表和修订草稿，保留版本与范围。

完成后会得到什么

一份补齐输入输出和范围的 PRD 草稿，以及产品、研发、测试分别需要确认的问题。它应使开发人员知道要实现什么，也知道哪些内容本轮不做。

结果应该怎么检查

从用户触发走到最终状态，检查每一步是否有输入和结果。逐项回看规则依据，确认没有新增未经讨论的审批、字段或功能。验收要求应能转成可执行测试。

遇到这些情况怎么处理

口头修改未入文档时先收集确认记录，不按 AI 判断选择版本。多份材料冲突时列出差异。只提供一个演示原型时，先生成补问与说明草稿，不声称需求已经完整。

哪些必须人工决定

产品确认业务规则和范围，研发确认可实现性，测试确认验收可执行性。AI 可查缺和起草，不自行扩大产品承诺。