AI生成的研发报告在例会和决策前发现遗漏风险项，先不用急着改提示词。遗漏可能发生在四个环节：原始记录里没有这项风险、报告口径未覆盖这类风险、生成时输入范围或指令不完整、成稿后被删改压缩。按“数据源—口径—生成过程—成稿复核”的顺序倒查，每一步都用可观察的证据确认，找到断点后再补数据、补口径、补复核，并用历史报告回测验证。
要点总览（TL;DR）
- 遗漏风险项先分类再排查：真遗漏、口径外风险、表述弱化三类对应不同断点，按影响决策的程度排优先级。
- 倒查顺序从成稿往数据源走：先比初稿与终稿，再查生成输入范围与指令，再看模板口径，最后回到原始记录。
- 处置只修已确认的断点：补原始记录、在模板中固化风险类别与阈值、调整输入与指令、增加成稿前对照检查。
- 修正后用含遗漏案例的历史报告回测，并在例会前设对照检查点；连续两次同类遗漏说明口径或数据源存在结构性缺口。
先界定遗漏：哪些风险项算漏、影响多大
“感觉漏了”无法直接排查，需要先转成一份可核对的清单。做法是取三份材料做交叉比对：项目实际在跟的风险清单、最近几次例会的决议记录、过往同类报告。报告中未出现、但这三份材料中明确存在的风险项，进入候选遗漏清单。
比对后把候选项分成三类，后续排查路径不同：
- 真遗漏：原始记录中有该风险，报告完全未提及。这类需要追查生成与复核环节。
- 口径外风险：该风险客观存在，但不在报告模板定义的风险类别内，例如模板只写进度与质量风险，未设外部依赖风险。这类问题出在口径，不在生成。
- 表述弱化：报告提到了相关事项，但被写成普通进展或备注，未标为风险，或未写影响与应对。这类需要检查生成指令与成稿编辑。
随后按影响分级。直接影响例会决策的风险优先排查，例如会导致排期调整、资源追加或上线延后的项；仅需持续观察的项可以排在后面。分级的作用是确定排查投入的顺序，不必对每个候选项平均用力。
需要说明本文的范围：这里只处理报告文档产出环节的遗漏，即风险已被项目跟踪记录、却未进入报告的情况。风险本身是否被识别、判断是否准确，属于项目跟踪与风险识别的工作，不在本文展开。
按四个断点倒查原因并收集证据
四个断点对应一条从原始数据到成稿的链路。排查顺序建议从链路末端往前：先看成稿是否被改，再看生成输入，再看口径，最后回到数据源。原因是越靠前的断点影响面越大，先排除末端问题可以避免不必要的返工。
| 断点 | 原因假设 | 验证证据 | 排查顺序 |
|---|---|---|---|
| 输入数据缺项 | 需求变更、缺陷、进度偏差、外部依赖等原始记录中未登记该风险 | 在需求单、缺陷库、进度记录、依赖清单中检索该风险的关键词与相关条目；确认记录时间是否早于报告生成时间 | 第四步 |
| 识别口径缺失 | 报告模板或生成提示未定义风险类别、判定阈值与必填字段 | 查看模板的风险章节结构与提示词，确认该类风险是否有对应类别；确认是否有“影响程度达到某阈值必须列出”的规则 | 第三步 |
| 生成过程偏差 | 喂给模型的数据范围、时间窗、字段不全，或指令未要求逐项列出风险及依据 | 还原当次生成的输入清单：覆盖了哪些数据源、截止到哪一天、包含哪些字段；检查指令中是否有“逐项列出风险并注明来源”的要求 | 第二步 |
| 成稿复核缺失 | 初稿包含该风险，最终稿被删改或压缩 | 调取生成初稿与最终稿做逐段对比，定位删除或改写的段落及修改人 | 第一步 |
排查时注意一个常见误判：报告中出现了相关关键词，但写在“进展”或“备注”里，这属于表述弱化，断点在生成指令或成稿编辑，不在数据源。判断依据是原始记录中该事项是否已被标注为风险，以及报告是否写明了影响与应对动作。
每个断点确认后要留下证据，例如检索截图、输入清单、初稿与终稿的对比记录。证据的作用是让后续修正有明确对象，也便于在例会上说明报告修订的原因。
如果四个断点都排除了，再考虑一种情况：该风险在报告生成之后才被识别。这时遗漏反映的是报告生成时点与风险识别时点的时间差，处置方式是建立报告生成后的增量补充机制，而非修改生成流程。
按定位结果处置：补数据、补口径、补复核
处置动作与断点一一对应，只修已确认的环节，避免一次性改动全部流程导致无法判断哪项修正起了作用。
数据缺项。先在原始系统中补齐风险记录，写清风险描述、影响、应对措施与责任人，再重新生成报告。补齐时保留修改痕迹与修改时间，便于区分“报告漏了”和“记录补晚了”。
口径缺失。在报告模板中固化风险章节的结构：风险类别清单、每类风险的判定阈值、必填字段（描述、影响、概率、应对、责任人）。阈值要写成可判断的条件，例如“影响关键路径超过三天的事项必须列为风险”，避免“重要风险”这类无法核对的表述。
生成偏差。调整输入范围与指令。输入侧确认数据源覆盖需求、缺陷、进度、依赖四类记录，时间窗与报告周期一致；指令侧明确要求逐项列出风险并注明来源记录，对无法从输入中找到依据的风险不得自行补充。调整后先用一份已知内容的报告试生成，核对输出是否完整。
复核缺失。在成稿前增加风险项对照检查：以项目风险清单为基准，逐项确认报告中是否有对应条目、是否写明影响与应对，指定复核人并在报告上留下复核记录。
涉及覆盖原报告或批量重生成时，先备份当前版本并限定重生成范围，例如只重生成风险章节或只处理本次确认遗漏的项目。批量操作前先在一份报告上验证效果，确认无误再扩大范围；若重生成结果出现新的缺项，停止批量操作，回到断点排查。
在团队协作层面，这类修正动作需要落到具体的工作项与文档状态上。以ONES为例，风险记录可以作为工作项登记在项目中，报告作为文档关联对应的需求、缺陷与里程碑；补齐数据时修改的是工作项字段，重新生成与复核在文档上留下版本记录，复核人确认后文档状态流转到已评审。这样“哪条风险、何时补录、谁复核过”在系统里有据可查，例会前核对报告与工作项清单即可完成对照检查。
验证恢复并防止复发
修正完成后需要验证，而不是等下一次例会再看结果。验证方法是取同一批历史报告回测：用修正后的模板、输入范围与指令重新生成，与当时的实际风险清单逐项比对，确认此前遗漏的同类风险已出现在报告中，且影响与应对描述完整。回测样本应包含至少一份曾发生遗漏的报告，否则无法验证修正是否针对了问题。
验证通过后，把检查动作固化到日常流程中：
- 在例会前设置风险项对照检查点，明确由报告撰写人或项目助理执行，复核人签字确认。
- 把本次遗漏的原因记入模板或提示的维护清单，写明遗漏类型、断点位置与已做的修正，供后续维护参考。
- 设定复发信号：连续两次报告出现同类遗漏，或同一风险类别反复缺失，重新审视口径定义与数据源覆盖范围，而不只是补当次报告。
复发信号的意义在于区分偶发与系统性问题。偶发遗漏通常由单次数据补录延迟或个别段落编辑造成，补当次即可；反复出现的同类遗漏说明模板口径或输入范围存在结构性缺口，需要回到断点二和断点三重新调整。把这条判断规则写进维护清单，下次处理时可以直接对照，不必每次从零排查。
常见问题
报告里提到了相关事项但写在“进展”里，算遗漏吗？
这属于表述弱化，不算完全遗漏，但同样影响决策。判断依据有两条：原始记录中该事项是否已被标注为风险，报告是否写明了影响与应对动作。两条都满足而报告只写成进展，断点在生成指令或成稿编辑环节，处置方式是要求生成时逐项列出风险及依据，并在复核时对照风险清单确认表述完整。
四个断点都排查过，还是找不到原因怎么办？
考虑时间差：该风险可能在报告生成之后才被识别。这时遗漏反映的是报告生成时点与风险识别时点的间隔，处置方式是建立报告生成后的增量补充机制，例如在例会前用风险清单对报告做一次增量核对，而不是修改生成流程。另外确认排查证据是否完整，缺少初稿或输入清单时结论可能不准。
批量重新生成报告前要注意什么？
先备份当前版本并限定范围，例如只重生成风险章节或只处理本次确认遗漏的项目。批量操作前先在一份报告上验证效果，确认无误再扩大范围。若重生成结果出现新的缺项，停止批量操作，回到断点排查，避免把一次修正变成新的问题来源。
回测验证需要多少份历史报告？
没有固定数量要求，关键是样本中至少包含一份曾发生遗漏的报告，否则无法验证修正是否针对了问题。回测时用修正后的模板、输入范围与指令重新生成，与当时的实际风险清单逐项比对，确认同类风险已出现且影响与应对描述完整。样本覆盖不同风险类别时，验证结论更可靠。
偶发遗漏和系统性遗漏怎么区分？
看复发情况：偶发遗漏通常由单次数据补录延迟或个别段落编辑造成，补当次报告即可；连续两次报告出现同类遗漏，或同一风险类别反复缺失，说明模板口径或输入范围存在结构性缺口，需要回到口径与生成输入两个断点重新调整。把这条判断规则写进维护清单，下次处理时直接对照。
