AI生成的需求文档出现遗漏，先别急着改提示词。遗漏可能来自四个环节：原始来源里没有、来源有但没进入生成输入、进入输入后在生成中被压缩改写、生成后评审口径不一致。定位时先把遗漏项逐条列清并回溯到来源，判断它断在哪一层，再用同一批遗漏项复现一次生成，确认原因是否稳定出现。本文按“界定症状—逐条回溯—按因处置—验证预防”的顺序展开，适用于初稿进入需求评审前的诊断场景。
要点总览（TL;DR）
- 先界定症状与范围：把遗漏拆成整条需求缺失、子场景缺失、约束条件缺失、验收标准缺失四类，并锁定初稿对应的输入快照与评审版本。
- 逐条回溯四类原因假设：来源本身缺失、来源存在但未进入输入、生成过程压缩改写、评审口径不一致，每类都要有成立或排除的证据。
- 按断点处置：补来源、完善输入清单与分段投喂、在提示中要求逐条对应来源并标注出处、统一遗漏判定检查项，修正时不覆盖原稿。
- 用原遗漏项清单核对修正稿，再用新一批需求抽样验证，确认修正对同类问题有效而非只对单例生效。
- 把确认的遗漏项与原因固化为生成前输入检查和生成后覆盖核对两组检查项，降低复发概率。
遗漏出现在哪一层：先界定症状与范围
“有遗漏”是评审会上最容易出现也最难处理的判断，因为它把整条需求缺失、某个子场景没写、约束条件丢失、验收标准缺失混在一起说。诊断的第一步是把这种笼统感受拆成可核对的具体条目，否则后续回溯没有基准，讨论容易变成对文档整体质量的争论。
建议先把遗漏分成四类症状，逐条记录：
- 整条需求缺失：来源中独立存在的一条需求，在初稿中找不到对应段落。
- 子场景缺失：主流程写了，但异常分支、边界条件、角色差异等子场景没有覆盖。
- 约束条件缺失：性能、权限、合规、兼容性等限制性描述在初稿中消失或被弱化。
- 验收标准缺失：需求描述存在，但缺少可判定的完成条件，评审时无法确认是否满足。
同时要把“遗漏”与另外三种情况分开。表述歧义是内容在但读法不唯一；不可测试是写了但无法验证；与业务上下文冲突是内容与既定规则矛盾。这三类问题需要不同的处置动作，混入遗漏清单会干扰原因判断。分类时以“来源中是否存在对应信息”为基本判据，而不是以评审者的主观印象为准。
诊断范围也要一次定清：哪一份初稿、对应哪一次生成的输入材料、面向哪个评审版本。AI生成往往经过多轮，若不确定初稿对应的输入快照，回溯就失去参照。把范围写进诊断记录，例如“v0.3初稿，输入为需求池导出清单与三次访谈纪要，评审版本为评审会前定稿”。最后形成一份按类型归类的遗漏项清单，每条包含编号、症状类型、初稿位置、期望来源，作为后续所有核对的基准。
逐条回溯：四类原因假设与排除证据
拿到遗漏项清单后，对每一条提出原因假设，并用证据成立或排除，避免把猜测直接写成结论。四类假设对应信息流的不同断点，验证方式各不相同。
| 原因假设 | 断点位置 | 验证证据 | 排除条件 |
|---|---|---|---|
| 来源本身缺失 | 需求来源材料中就没有该信息 | 在需求池、访谈纪要、工单、历史文档中检索不到对应描述 | 在任一来源中找到明确表述 |
| 来源存在但未进入输入 | 输入材料清单不完整或内容被截断 | 来源中有，但生成时投喂的材料清单、分段内容中找不到 | 输入快照中能定位到该段原文 |
| 生成过程压缩或改写 | 输入有，输出丢失或变形 | 输入段落与初稿对应段落逐句比对，发现合并、省略、条件被删 | 初稿中存在语义等价的完整表述 |
| 评审口径不一致 | 内容存在但未被识别为覆盖 | 初稿中有相关内容，评审检查项或判定标准未将其计入 | 按统一检查项核对后确认确实缺失 |
验证顺序建议从来源开始向外推。先查来源，是因为如果来源本身没有，后面所有环节都无从谈起，此时补充生成技巧没有意义。来源比对要覆盖全部输入渠道，包括口头确认后补记的纪要，这类信息最容易只存在于个人记忆中。确认来源存在后，再核对输入材料清单与实际投喂内容，重点看长文档是否被分段截断、附件是否被遗漏、表格类需求是否只传了部分行。
第三类假设需要更细的比对方法。把输入中与遗漏项相关的段落和初稿对应段落并排阅读，观察三种典型变形：多条需求被合并成一句概括、限定条件在改写中脱落、示例替代了规则本身。这类丢失在长输入和条目密集的文档中更常见，因为生成过程倾向于压缩重复结构。比对时以条目为单位，而不是以章节为单位，否则概括性丢失很难被发现。
第四类假设常被忽略。初稿中其实写了相关内容，但评审者按自己的检查习惯没有找到，或者团队对“覆盖”的判定标准不同，比如一方要求写出异常分支才算覆盖，另一方认为主流程写到即可。验证方法是让评审者按统一检查项重新核对，并记录判定依据。若按统一口径核对后内容确实存在，问题就落在评审规则而非生成环节。
单条遗漏的原因确认后，还要做一次复现：用同一批输入、同一提示重新生成一次，观察该遗漏是否稳定出现。稳定复现说明原因在输入或生成规则层面，可以针对性修正；时有时无则提示与输入长度、条目顺序或提示表述的稳定性有关，处置时要增加冗余检查而不是只改一处措辞。
按原因处置：修正输入、提示与检查规则
原因确认后，处置动作要与断点对应，避免用同一种方法应对所有遗漏。下面按四类原因给出动作清单，并标注操作风险。
来源缺失时，先补充需求来源材料再重新生成，包括补做访谈、调取历史工单、确认口头约定。这里有一条明确边界：不要用生成内容反推需求。初稿中看似合理的补充可能引入未经确认的业务假设，反而掩盖真实缺口。补充材料应标注来源与确认人，便于评审时追溯。
输入未覆盖时，完善输入清单并调整投喂方式。具体动作包括：列出本次生成必须包含的材料字段（需求编号、角色、触发条件、约束、验收口径），对长文档按需求条目分段投喂而不是整篇上传，投喂后回读一遍确认关键段落完整。分段投喂会增加操作步骤，但能显著降低截断风险；若材料量很大，可先按模块拆分生成再合并，合并时保留条目编号以便核对。
生成被压缩时，调整提示中的保留要求。有效做法是要求逐条对应来源并标注出处，明确“每条需求独立成段、约束条件不得合并、缺少来源支撑的内容标注待确认”。这类要求会增加输出长度，需要在提示中同时说明结构格式，否则模型可能用概括换取篇幅。调整后应先用一小批已知条目测试，确认保留要求生效再用于全量生成。
评审口径不一致时，统一遗漏判定标准与检查项。把“整条缺失、子场景缺失、约束缺失、验收标准缺失”四类写成评审检查表，每条遗漏记录判定依据和对应来源位置。口径统一后，误判会明显减少，剩余争议也能聚焦到具体条目而非整体印象。
处置过程有一条共同的风险边界：不直接覆盖原稿。每次修正保留版本号和修改说明，原稿与修正稿并存，便于比对差异和回退。若修正涉及大范围重写，先在小范围条目上验证效果，确认后再推广，避免一次改动引入新的遗漏。
当遗漏项需要逐条跟踪修正状态时，可以把清单落到工作项或文档评审流程中管理。ONES 支持在工作项中记录需求条目、关联文档与评审状态，修正过程中的每条遗漏可以对应一个待办项，从提出、补充材料、重新生成到评审确认形成可查的记录。这样做的价值在于把“哪条遗漏、由谁补、补到哪一步”变成可见状态，而不是散落在会议记录里。
验证恢复与复发预防
修正完成后，先用原遗漏项清单逐条核对修正稿是否覆盖。核对以来源为依据，不以“读起来完整”为标准，每条记录覆盖状态与对应段落位置。全部条目通过后，再用一批新需求做抽样验证，确认修正对同类问题有效，而不只是对已知条目打了补丁。抽样应覆盖不同来源渠道和不同文档长度，因为压缩类问题在长输入中更容易出现。
验证未通过时要有回退路径：保留修正前版本，回到原因判断环节重新核对断点，确认是处置动作不到位还是原因判断有误。不要在同一稿上反复叠加修改，版本混杂会让后续比对失去基准。
复发预防靠检查项固化，而不是靠记忆。建议建立两组检查项：
- 生成前输入检查：材料清单是否齐全、长文档是否分段、关键字段是否包含、口头确认是否已书面化。
- 生成后覆盖核对：逐条需求是否有对应段落、约束条件是否保留、验收标准是否可判定、异常分支是否覆盖。
把每次确认的遗漏项及原因记录成规则条目，例如“涉及权限的需求必须单独列出角色与操作范围”“性能约束不得与功能描述合并”。这些规则积累后可以直接进入提示模板和评审检查表，让同类遗漏在下一轮生成前就被拦住。对于需要长期维护的需求文档，可将检查表与文档版本关联，在评审前按表核对并留存记录，使遗漏诊断从一次性排查转为可重复的流程动作。
常见问题
AI生成的需求文档遗漏了需求，是不是改提示词就能解决？
不一定。提示词只影响生成环节，如果遗漏的根因是来源材料里本来就没有这条需求，或者长文档投喂时被截断，调整措辞不会让缺失的信息凭空出现。建议先按四类假设逐条回溯，确认断点位置再决定动作：来源缺失就补材料，输入未覆盖就完善清单与分段投喂，生成压缩才需要调整提示中的保留要求，评审口径问题则要统一检查项。
同一批输入重新生成，遗漏有时出现有时不出现，说明什么？
时有时无通常提示问题与输入长度、条目顺序或提示表述的稳定性有关，而不是固定的输入缺失。这类情况处置时要增加冗余检查，例如在提示中明确逐条对应来源并标注出处、对长文档按需求条目分段投喂，同时在生成后按覆盖核对表逐条检查，而不是只改一处措辞就认为问题已解决。
评审会上有人说遗漏、有人说写到了，怎么判断？
先确认双方是否按同一套检查项核对。常见情况是初稿中确有相关内容，但一方要求写出异常分支才算覆盖，另一方认为主流程写到即可。处理方法是把整条缺失、子场景缺失、约束缺失、验收标准缺失四类写成统一检查表，让评审者按表重新核对并记录判定依据与对应段落位置。按统一口径核对后内容确实存在，问题就落在评审规则而非生成环节。
修正遗漏时可以直接在原稿上改吗？
不建议直接覆盖原稿。每次修正保留版本号和修改说明，原稿与修正稿并存，便于比对差异和回退。若修正涉及大范围重写，先在小范围条目上验证效果，确认后再推广。验证未通过时回到原因判断环节重新核对断点，避免在同一稿上反复叠加修改导致版本混杂、失去比对基准。
怎么确认遗漏问题已经修好，而不是只补了这一条？
分两步验证。第一步用原遗漏项清单逐条核对修正稿是否覆盖，以来源为依据记录覆盖状态与段落位置。第二步用一批新需求做抽样验证，抽样应覆盖不同来源渠道和不同文档长度，因为压缩类问题在长输入中更容易出现。两步都通过，才说明修正对同类问题有效；只对已知条目生效，说明处置动作还停留在打补丁层面。
