PRD 评审被打回怎么办？

先不要整篇重写，先判断被打回原因：目标不清、范围不清、流程缺失、字段缺失、验收标准不清或风险问题没列。逐项补齐后，再提交复审。

PRD 被打回后最快补哪几块？

优先补业务目标、本期范围、页面清单、核心流程、字段说明、验收标准和待确认问题。这七块能让评审人员快速判断方案是否可继续推进。

需求评审 · PRD 复审

可以先整理复审底稿，但需要标注假设、待确认项和不包含范围，避免把未确认内容写成最终需求。

不要急着整篇重写。先定位评审意见属于目标、范围、流程、字段、验收还是风险问题，再补一版能复审的需求文档。

评审人不知道这个需求解决谁的问题，也不知道这次上线要达成什么结果。

文档没有写清本期做什么、不做什么，导致会议里不断扩大讨论范围。

只写“支持上传”“支持审核”，但没有写做到什么程度算完成。

要补的内容	应该写清什么
业务目标	本需求解决什么问题，服务哪个用户角色，本次评审要确认什么。
本期范围	必须做、暂不做、后续再做分别列出来，避免需求越评越大。
页面清单	用户端、管理端、配置页、结果页、异常页分别有哪些。
核心流程	从进入页面到完成目标，中间经过哪些步骤，失败时如何处理。
字段说明	每个页面要展示、填写、校验和保存哪些字段。
验收标准	每个功能怎样算完成，测试人员或外包团队按什么口径检查。
待确认问题	账号、支付、权限、通知、第三方接口、数据迁移等还没确定的事项。

这版 PRD 根据评审意见补充了业务目标、本期范围、页面清单、核心流程、字段说明、验收标准和待确认问题。未确认的第三方账号、权限规则、通知方式和数据迁移方式已单独标注，复审时建议先确认这些边界，再进入开发排期。

通常不需要。先把评审意见分类，再补缺失部分。只有业务目标或范围整体变了，才需要重新整理结构。

把意见按目标、范围、页面、流程、字段、验收、风险七类归档。每条意见只放到一个位置，避免文档越改越乱。

可以先做复审底稿，但需要标注假设和待确认项。正式开发前，还要确认账号、接口、数据和验收口径。