AI生成的需求文档初稿在进入评审前，常出现“快速响应”“界面友好”这类无法验证的表述，或遗漏异常分支、与业务规则冲突。本文按歧义、不可测试、遗漏、上下文冲突四类症状定位具体句子，用证据区分成因，再逐条改写为可测试句式，并给出评审前自检与预防做法。
要点总览（TL;DR）
- 评审前把问题落到具体句子：歧义、不可测试、需求遗漏、上下文冲突四类分别标注，避免笼统判断整篇文档质量。
- 成因排查按输入材料、生成约束、初稿表达的顺序找证据，保留排除记录，不把单一原因直接当结论。
- 改写采用“角色—动作—对象—可观察结果—边界与异常条件”五要素句式，歧义词替换为可量化标准，验收口径与条目相邻。
- 修正后用可测性、唯一解释、上下文一致、验收口径齐全四项自检，并把约束固化到提示模板与评审前置条件中。
- 涉及业务规则变更的改写需回到业务方确认，文档编辑者不自行推定。
初稿进入评审前，先分清四类文档异常
评审会上常见的“这条没法测”“这里到底指什么”，往往在初稿阶段就已埋下。把笼统的“写得不好”拆成四类可分别处置的问题，才能让修正有明确对象。本文只处理文档产出层面的表述问题，需求价值判断、优先级排序和项目风险判断不在讨论范围。
四类症状的判断线索如下表，建议在评审前逐条对照标注。
| 症状类型 | 典型表现 | 判断线索 |
|---|---|---|
| 歧义 | 同一句话可被读成两种以上含义，不同角色理解不一致 | 出现“快速”“友好”“适当”“尽量”“合理”等无标准词；代词指代不明；条件与结论的修饰关系不清 |
| 不可测试 | 无法设计用例判断通过与否，验收时只能靠主观感受 | 缺少可观察结果；没有量化阈值；未说明输入与前置条件；结果描述停留在“支持”“优化”层面 |
| 需求遗漏 | 主流程写了，异常分支、边界值、权限差异没有交代 | 只描述成功路径；未提空值、超限、并发、失败重试；角色权限变化时行为缺失 |
| 上下文冲突 | 条目之间或与既有业务规则、术语表不一致 | 同一对象在不同条目中名称或口径不同；与现有流程文档、字段定义矛盾；前后置条件互相排斥 |
标注时以句子为单位，而不是以整篇文档为单位。一条需求里可能同时存在歧义和遗漏，分别打上标签，后续修正时逐项消解。这样做的价值在于：评审前就能把“感觉有问题”转成“第几条、哪句话、属于哪类问题”的具体清单。
定位成因：输入、提示还是初稿表达
看到歧义句就归因于“AI不行”，容易导致修正方向跑偏。更稳妥的做法是先列三类成因假设，再找证据逐一排除：上下文输入不足、生成约束缺失、初稿表达本身含糊。三者可能同时存在，排查顺序建议从输入开始，再到提示，最后落到逐句表达。
| 成因假设 | 验证证据 | 排查动作 |
|---|---|---|
| 上下文输入不足 | 初稿中的角色、字段、流程与输入材料对不上；关键业务规则在输入里找不到出处 | 回看提供给AI的需求背景、术语表、既有流程文档和字段定义，确认缺失了哪些信息 |
| 生成约束缺失 | 初稿普遍缺少验收标准、异常分支；句式松散，未按固定结构输出 | 回看提示中是否要求“每条需求包含角色、动作、可观察结果、边界条件”，是否指定术语口径 |
| 初稿表达含糊 | 输入材料完整、提示也有约束，个别句子仍出现无标准词或指代不清 | 逐句标注问题类型，统计集中在哪些句式、哪些模块，判断是模型表达习惯还是个别疏漏 |
排查时保留排除记录：每条假设写明“查了什么材料、看到什么、结论是成立还是排除”。例如回看输入后发现术语表未提供“活跃用户”的定义，而初稿多处使用该词，则可判定上下文输入不足成立，先补术语再谈改写。若输入完整、提示已要求验收标准，但初稿仍有若干句子含糊，则归为表达问题，进入逐条修正。排除记录本身也是评审材料，能让业务方看到问题出在哪个环节。
逐条修正：把需求改写成可测试句式
修正的目标是让每条需求都能被设计成用例并判定通过与否。推荐句式由五个要素构成：角色、动作、对象、可观察结果、边界与异常条件。改写时按“先补要素、再换词、后对齐”的顺序推进。
第一步：补齐五要素
以“系统应快速展示订单列表”为例，改写后为：“仓储管理员在订单查询页输入日期范围并点击查询后，系统在2秒内展示符合条件的订单列表，按创建时间倒序排列；无匹配结果时展示空状态提示；查询超时则提示重试并保留已选条件。”角色、动作、对象、可观察结果、边界条件均已落地，验收时可直接设计正常、空结果、超时三类用例。
第二步：替换歧义词并补量化标准
- “快速”“及时”替换为具体时限，并注明是接口响应、页面渲染还是任务完成时间。
- “友好”“易用”替换为可观察的界面行为，如提示文案出现位置、错误码展示方式。
- “适当”“合理”替换为阈值或规则来源，如“按现有权限矩阵执行”，并附上规则文档出处。
- “支持多种格式”列出具体格式清单，避免验收时对“多种”理解不一。
第三步：补齐遗漏并对齐上下文
遗漏需求按“主流程—异常分支—边界值—权限差异”四类补写。上下文冲突则回到术语表和既有流程文档逐条比对，统一对象名称、字段口径和前后置条件。需要强调的是，改写中若涉及业务规则变更，例如调整审批层级、改变计算口径，必须回到业务方确认，不能由文档编辑者自行推定；本文提供的是表述修正方法，不替代业务决策。
评审前验证与复发预防
改写完成不等于问题解决，需要用可核验的方式确认修正生效。建议在评审前由文档作者自检、需求负责人复核，形成两道检查。
评审前自检清单
- 可测性：每条需求能否设计出至少一个通过用例和一个不通过用例。
- 唯一解释：请一位未参与编写的同事阅读，确认其对角色、条件、结果的理解与作者一致。
- 上下文一致：对象名称、字段口径与术语表、既有流程文档一致，条目之间无前后置条件冲突。
- 验收口径齐全：正常路径、异常分支、边界值均有对应描述，量化标准写明单位与适用范围。
- 问题闭环：初稿标注的四类问题逐条有处理记录，未处理的注明原因和责任人。
把约束固化到生成与评审环节
预防复发的关键在于把检查动作前置。在提示模板中固定要求每条需求包含五要素和验收口径，并附上术语表与业务规则出处；在评审流程中把上述清单作为进入评审的前置条件，未通过自检的初稿不提交评审。对反复出现的同类问题，例如异常分支遗漏，可在模板中增加对应提示项，并在每次评审后更新问题类型统计，观察哪类问题在减少、哪类仍需加强。
当修正后的需求条目需要进入团队协作流程时，可以把条目状态、评审意见和处理记录留在统一的需求工作项与文档中。ONES Assistant 智能助手连接 ONES Project、ONES Wiki 与 ONES TestCase，能够理解项目、工作项和 Wiki 页面等工作上下文；其 PRD 质量检查与需求智能生成能力可提炼待澄清问题与拆解建议，帮助团队在需求澄清和录入阶段发现表述问题。修正后的条目可在 ONES 中保存为工作项或 Wiki 页面，评审过程可追踪、结果可审计，便于把自检清单中的处理记录与需求状态对应起来。具体可用版本与套餐范围需另行核验。
常见问题
AI生成的需求文档里，一句话同时存在歧义和遗漏，应该先改哪个？
建议先补遗漏，再消歧义。遗漏意味着条目缺少角色、条件或异常分支，补上之后句子的结构会发生变化，原先的歧义点可能随之消失或转移。例如“系统应快速处理退款”既缺边界条件（金额上限、失败重试）又含无标准词“快速”，先补“退款金额不超过5000元、失败时提示原因并保留申请记录”，再确定处理时限，改写一次即可完成。若先替换“快速”，补遗漏时又要重写整句，返工更多。
输入材料本身就不完整，是否应该等业务方补齐资料再改写？
可以分两步走。先把能从现有材料确认的部分改写为可测试句式，把依赖缺失信息的条目单独列出，标注“待业务方确认”及具体待确认项，例如字段口径、审批层级或异常处理规则。这样评审时讨论的是明确的待决问题，而非整篇文档的模糊表述。待确认项补齐后再完成对应条目的改写，避免因个别信息缺失阻塞全部修正工作。
改写后的需求条目如何判断已经达到可测试标准？
一个实用的判断方法是尝试设计用例：能否写出至少一个通过用例和一个不通过用例，且两者的差异来自需求中写明的条件。如果两条用例的区分只能靠“感觉差不多”，说明量化标准或边界条件仍不充分。另一种方法是请未参与编写的同事阅读条目，请其复述角色、触发条件和预期结果，若复述与作者理解一致，则唯一解释基本成立。两项检查都通过，条目即可提交评审。
在提示模板中固化约束后，同类问题仍反复出现，下一步该查什么？
先看问题是否集中在特定类型。若异常分支遗漏反复出现，检查模板是否只要求主流程描述，缺少对空值、超限、失败重试的提示项；若歧义集中在某类术语，检查术语表是否覆盖该词并有明确定义。其次看输入材料是否稳定提供，模板要求与输入材料不匹配时，约束难以生效。每次评审后按问题类型统计数量变化，可以判断哪类约束已起作用、哪类需要调整表述或补充示例。
修正需求文档时，哪些改动必须由业务方确认而不能自行处理？
涉及业务规则实质变化的改动需要业务方确认，包括调整审批层级、改变计算口径、新增或取消权限限制、修改状态流转条件。这类改动影响的是业务决策，超出表述修正的范围。表述层面的处理可以自行完成，例如把“适当”替换为已有规则文档中的阈值、统一对象名称、补充异常分支的描述结构。判断标准是：改动是否改变了业务行为的预期结果，若改变则需确认，若只是让原有规则表达得更清楚则可直接修正。
