AI生成需求文档后，人工复核要回答的核心问题是：这份文档能否直接支撑开发和验收。复核应覆盖五类内容：需求来源与目标是否可追溯、范围与边界是否闭合、验收标准是否可判定、约束与依赖是否完整、表述与术语是否一致。建议按三轮推进，每项留证据、定负责人；目标冲突、关键依赖缺失、验收标准不可判定、合规风险、来源不可追溯应设为阻断项，未关闭不进入评审或开发。
要点总览（TL;DR）
- 复核以“能否据此开发和验收”为通过线，覆盖来源与目标、范围边界、验收标准、约束依赖、表述术语五类内容。
- 复核按三个时点推进：AI初稿产出后查忠实性，需求评审前补可开发性，开发启动前确认阻断项关闭。
- 每项检查记录结论、证据位置、复核人和时间，复核人与文档作者分离，记录随需求文档归档。
- 目标冲突、关键依赖缺失、验收标准不可判定、合规风险、来源不可追溯设为阻断项，未关闭不进入评审或开发。
- 复核结论作为需求评审的正式输入，未关闭阻断项在流转中保持可见，可借助工作项与文档评审承载。
谁在什么时点复核这份AI需求文档
复核不是一个人从头看到尾，而是按角色分工、分时点介入。AI初稿产出后先做完整性与忠实性检查，需求评审前补齐可开发性条件，开发启动前确认阻断项全部关闭。三个时点对应不同的复核深度，避免把问题拖到评审会上才暴露。
| 复核时点 | 主要复核角色 | 复核重点 | 前置输入 |
|---|---|---|---|
| AI初稿产出后 | 产品负责人、文档作者 | 来源可追溯、目标与范围、AI臆造内容 | 原始需求来源、AI生成稿 |
| 需求评审前 | 产品负责人、研发、测试 | 验收标准、异常场景、约束与依赖、优先级 | 初稿复核记录、技术约束材料 |
| 开发启动前 | 产品负责人、合规或安全、研发负责人 | 阻断项关闭情况、合规风险、放行签署 | 前两轮复核记录、遗留问题清单 |
角色分工上，产品负责人对需求来源、目标和范围负最终责任；业务方确认目标用户与场景描述是否符合实际；研发判断约束、依赖和优先级是否可执行；测试确认验收标准是否可判定；合规或安全角色在涉及数据处理、权限、外部集成时介入。复核人与文档作者分离，写稿的人不给自己签字。
前置输入至少要齐三样：原始需求来源（用户访谈记录、工单、业务方邮件、会议纪要等）、AI生成稿、相关约束材料（技术架构说明、合规要求、既有功能说明）。缺少原始来源时，复核无法判断哪些内容是AI补全的，应先把来源补齐再开始。
第一轮：来源、目标与范围复核项
这一轮判断文档是否忠实于原始需求、范围是否闭合。通过线是：文档中的关键结论都能回溯到来源，读者能清楚知道这次做什么、不做什么、为谁做。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 需求来源可追溯 | 每条关键需求结论标注来源，能对应到访谈记录、工单或业务方确认 | 来源链接或记录编号 | 产品负责人 |
| 目标与成功指标明确 | 写清要达成的业务目标，并有可判断是否达成的指标或观察口径 | 目标说明、指标定义 | 产品负责人、业务方 |
| 范围内条目列出 | 本次交付的功能与内容逐条列出，无“等”“相关”这类模糊收口 | 范围清单 | 产品负责人 |
| 范围外条目列出 | 明确不做的内容，避免开发阶段反复确认边界 | 范围外清单 | 产品负责人 |
| 目标用户与场景具体 | 描述到角色、使用情境和触发条件，不停留在“提升体验” | 用户角色说明、场景描述 | 业务方 |
| 与相邻需求边界清楚 | 说明与已有功能或其他在研需求的分工，避免重复建设或冲突 | 关联需求编号、功能说明 | 产品负责人 |
这一轮最常见的失败是“目标写了但不可判断”。例如只写“优化下单流程”，没有说明优化后哪个环节的什么指标应达到什么状态，复核时应退回补充。范围外条目同样要写，AI生成稿往往只展开要做的内容，对不做什么一笔带过，这会让后续评审反复拉扯。
第二轮：验收标准、约束与依赖复核项
这一轮判断文档是否具备可开发、可测试的完整条件。通过线是：研发能据此估算和实现，测试能据此设计用例并给出通过或不通过的结论。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 每条需求有可判定验收标准 | 验收条件写成可观察的结果，能明确判断通过或不通过 | 验收标准条目 | 测试、产品负责人 |
| 异常与边界场景有描述 | 覆盖输入异常、权限不足、并发、超时、空数据等与本次需求相关的场景 | 异常场景清单 | 测试 |
| 性能、安全、合规约束写明 | 涉及响应时间、数据范围、权限控制、留存要求时给出具体约束 | 约束说明、合规要求文档 | 研发、合规或安全 |
| 外部依赖与前置条件列出 | 依赖的系统、接口、数据、第三方服务及就绪时间写清 | 依赖清单、接口说明 | 研发 |
| 优先级与版本范围明确 | 每条需求标注优先级，说明本次版本交付哪些 | 优先级标注、版本范围 | 产品负责人 |
验收标准要避免“功能正常”“体验流畅”这类无法判定的表述。可判定的写法是描述操作、输入和预期结果，例如“提交表单后3秒内返回结果，失败时展示错误原因并保留已填内容”。异常场景不必穷举，但与本需求直接相关的边界必须覆盖，否则测试阶段会反复回问产品。
约束和依赖是AI生成稿容易漏的部分。模型通常围绕功能本身展开，对性能指标、权限边界、第三方接口就绪时间缺少信息。复核时由研发逐条确认：缺哪个依赖、什么时候能就绪、未就绪时需求是否降级交付。这些结论要写回文档，而不是停留在口头确认。
第三轮：表述、术语与AI痕迹复核项
这一轮处理文字层面的问题，目标是让文档可读、可执行，并清除AI补全带来的不可信内容。通过线是：术语前后一致、无自相矛盾、所有细节都能找到依据。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 术语前后一致 | 同一对象全文使用同一名称，与团队既有词汇表对齐 | 术语对照记录 | 文档作者 |
| 无自相矛盾或重复表述 | 范围、优先级、验收标准之间不冲突，重复段落已合并 | 修订记录 | 文档作者、产品负责人 |
| 无臆造细节、虚构数据或来源 | 所有数据、引用、用户反馈均能回溯到来源，无法回溯的标记待核实或删除 | 来源核对记录 | 产品负责人 |
| 数字、单位、字段名准确 | 数量、时间、比例、字段命名与来源或系统定义一致 | 字段说明、数据来源 | 研发、文档作者 |
| 格式与模板符合团队规范 | 章节结构、必填项、版本信息符合团队需求文档模板 | 模板对照 | 文档作者 |
AI痕迹中最需要警惕的是“看起来合理但没有出处”的内容：具体用户比例、竞品做法、技术方案细节、上线时间。这类内容一旦进入评审，容易被当成已确认事实继续传递。复核时的处理原则是逐条回溯，找不到来源就标记待核实，不默认采信。数字和字段名要对照系统实际定义核对，单位不一致会直接导致开发理解偏差。
每项检查的证据与负责人怎么留
复核记录的价值在于可交接：换一个人接手时，能看出每项检查是谁做的、依据是什么、结论如何。建议每项检查至少记录以下字段。
| 字段 | 填写要求 |
|---|---|
| 检查项编号与名称 | 与清单条目一一对应 |
| 复核结论 | 通过、需修改、阻断，三选一 |
| 证据位置 | 来源链接、会议记录、原型稿、数据截图的具体位置 |
| 复核人 | 实际执行复核的人，与文档作者分离 |
| 复核时间 | 记录到日期，便于判断结论是否基于最新版本 |
| 遗留问题 | 需修改但非阻断的问题及跟踪去向 |
证据形式按检查项选择：来源类检查留链接或记录编号，场景类检查留原型或流程图，数据类检查留截图并注明取数时间，约束类检查留合规要求或架构说明的引用位置。复核记录随需求文档一同归档，文档版本更新后，受影响的检查项要重新复核并更新记录，避免旧结论套在新稿上。
阻断项与放行条件
阻断项是那些一旦存在就不能进入评审或开发的问题。它们影响的是需求能否被正确实现和验收，而不是文字是否好看。建议将以下五类设为阻断项。
| 阻断项类型 | 判定情形 | 关闭方式 |
|---|---|---|
| 目标冲突 | 文档目标与业务方确认的目标不一致，或与既有产品方向冲突 | 业务方与产品负责人确认统一目标并更新文档 |
| 关键依赖缺失 | 核心功能依赖的系统、接口或数据未确认可用 | 依赖方给出就绪结论，或调整范围为降级方案 |
| 验收标准不可判定 | 核心需求没有可观察的通过条件 | 补充可判定验收标准并经测试确认 |
| 合规风险 | 涉及数据处理、权限、外部集成但未明确合规要求 | 合规或安全角色给出结论并写入约束 |
| 来源不可追溯 | 关键需求结论找不到原始来源 | 补齐来源，或删除无法确认的内容 |
阻断项的关闭要有明确判定：由谁确认、依据什么、记录在哪里。非阻断问题可以带条件放行，但要登记遗留清单，写明处理人和计划关闭时点，并在评审时说明。放行结论由产品负责人签署，涉及合规的由合规角色共同确认；签署记录与复核记录一并归档。
把复核清单接入需求流转
复核结论要成为需求评审的正式输入，而不是散落在个人文档里。具体做法是：复核记录与需求条目关联，评审时先看阻断项是否全部关闭，再看遗留问题的处理计划；未关闭的阻断项在流转中保持可见，需求状态不进入可开发。
在ONES中，这类管理动作可以由工作项与文档评审承载：需求以工作项形式记录状态和负责人，复核记录与需求文档关联存放，评审结论和放行签署随条目留痕。ONES Assistant可连接ONES Project、ONES Wiki与ONES TestCase，理解项目、工作项和Wiki页面等上下文，并围绕PRD质量检查和需求智能生成提炼待澄清问题与拆解建议，把结果保存为工作项或Wiki页面，减少复核结论在工具之间反复搬运。其知识问答和任务执行基于ONES权限体系，输出过程可追踪、结果可审计，便于复核记录随需求归档后仍能追溯。具体评审流程的配置方式以团队实际开通情况为准。
落地时可以先从阻断项清单开始：把五类阻断项做成需求工作项的检查字段，复核人逐项勾选并填写证据位置，全部关闭后才允许流转到评审状态。运行一段时间后，再补充非阻断问题的跟踪规则和复核记录的归档要求。
常见问题
AI生成的需求文档看起来结构完整，还需要逐项复核吗？
需要。结构完整只说明格式齐全，不能说明内容可信。AI生成稿常见的问题集中在来源、细节和判定条件上：具体用户比例、竞品做法、技术方案细节可能缺少出处；验收标准可能写成“功能正常”这类无法判定的表述；范围外条目不写，导致开发阶段反复确认边界。复核时逐条回溯来源，找不到依据的内容标记待核实，不默认采信。
复核人能否由文档作者兼任？
建议分离。文档作者对内容有先入判断，容易跳过自己写下的假设。产品负责人对来源、目标和范围负最终责任，研发判断约束与依赖是否可执行，测试确认验收标准是否可判定，合规或安全角色在涉及数据处理、权限、外部集成时介入。人手紧张时至少保证阻断项由作者以外的人确认。
非阻断问题可以带条件放行吗？
可以，但要登记遗留清单。写明问题内容、处理人、计划关闭时点和跟踪去向，并在评审时说明。阻断项则必须关闭后才能放行：目标冲突由业务方与产品负责人确认统一目标，关键依赖缺失由依赖方给出就绪结论或调整为降级方案，验收标准不可判定需补充可判定条件并经测试确认，合规风险由合规或安全角色给出结论，来源不可追溯需补齐来源或删除无法确认的内容。
需求文档在评审后又有修改，之前的复核记录还有效吗？
需要重新判断。文档版本更新后，受影响的检查项要重新复核并更新记录，避免旧结论套在新稿上。复核记录中保留复核时间，便于判断结论基于哪个版本。修改涉及范围、验收标准或依赖时，对应阻断项要重新确认关闭状态。
复核记录放在哪里，才能让评审和开发都用得上？
关键是让记录与需求条目关联，而不是散落在个人文档里。在ONES中，需求以工作项形式记录状态和负责人，复核记录与需求文档关联存放，评审结论和放行签署随条目留痕。ONES Assistant可连接ONES Project、ONES Wiki与ONES TestCase，理解项目、工作项和Wiki页面等上下文，围绕PRD质量检查和需求智能生成提炼待澄清问题与拆解建议，并把结果保存为工作项或Wiki页面，减少复核结论在工具之间反复搬运。具体评审流程的配置方式以团队实际开通情况为准。
