AI复核项目建议时漏判关键依赖，通常不是单点失误，而是复核链路中某个环节没有把依赖信息带进来。常见原因有四类：输入缺少依赖信息、复核口径只覆盖单条建议、模型把表述完整当成依据充分、复核结论没有回写到项目状态。排查时按输入、口径、模型行为、回写的顺序逐层验证，先排除数据缺失，再检查规则与提示，最后确认结论是否进入跟踪。
要点总览（TL;DR）
- 漏判关键依赖通常来自四个环节：输入缺少依赖信息、复核口径只覆盖单条建议、模型把表述完整当成依据充分、复核结论未回写项目状态。
- 排查按输入、口径、模型行为、回写的顺序推进，先排除数据缺失，再检查规则与提示，最后确认结论是否进入跟踪。
- 处置对应四个动作：建议模板固定依赖字段、复核规则增加跨项比对、提示要求标注待确认依赖、结论写入项目状态与风险台账。
- 验证用已知含关键依赖的历史建议做回归测试，观察依赖类风险提前发现比例和上线前因依赖导致的变更次数。
- 回归测试未通过前不扩大自动复核范围，依赖字段必填、规则定期评审、回写纳入流程检查可降低复发。
漏判关键依赖的典型症状与影响范围
漏判关键依赖的表现，往往在建议被判定可行之后才暴露。复核阶段给出的结论是“可以推进”，但进入排期或上线准备时，团队才发现某个外部接口尚未就绪、所需数据要等另一团队交付、关键人力被其他项目占用。这类问题的共同特征是：单条建议本身读起来合理，缺失的是它与外部条件之间的连接。
可以把常见症状归为以下几类，便于对照排查：
- 建议被判定可行，但上线前才发现依赖外部接口或第三方系统，接口排期与项目排期不匹配。
- 建议中的任务拆分只写到本团队动作，未列出上游交付物，导致启动后等待输入。
- 数据来源被默认为“已有”，实际需要申请权限或等待数据生产方产出。
- 关键人力被重复安排，两条建议各自成立，合在一起却超出同一批人的可用工时。
- 依赖在复核结论中没有被标注为风险，直到跨团队协调会上才被提出。
影响范围首先体现在排期失真。依赖未进入复核，排期就按“无外部等待”估算，实际执行时出现空转和等待。其次是返工：建议在依赖确认后需要重新拆分任务、调整范围甚至更换方案。第三是跨团队阻塞，一个团队的启动条件掌握在另一个团队手中，而双方都没有在复核阶段对齐。依赖缺失还常伴随优先级排序失真——当两条建议的依赖条件不同，却按同一口径比较价值与成本，排序结果就会偏向看起来“独立可做”的那条，而非真正应优先推进的那条。
本文讨论的范围限于项目状态与风险识别中的依赖漏判，即复核结论与项目实际依赖条件之间的偏差。报告成稿质量、团队效能诊断等话题不在本文展开。明确这一边界，有助于把排查精力集中在复核输入、复核规则和结论回写上，避免把问题归因到无关环节。
原因假设与排查证据：四类漏判来源
漏判关键依赖的原因需要先作为假设提出，再用证据逐项排除或确认。以下四类假设对应复核链路的不同环节，排查顺序建议从输入开始，依次向口径、模型行为、回写推进。先排除数据问题，再看规则问题，可以避免在输入本身不完整的情况下反复调整提示词。
| 原因假设 | 典型表现 | 验证证据 | 排查顺序 |
|---|---|---|---|
| 输入缺失 | 被复核文本没有依赖字段，任务拆分只写本团队动作 | 抽查原始建议与任务拆分，核对上游交付、外部接口、数据来源、关键人力是否被记录 | 第一步 |
| 口径过窄 | 复核只评单条建议的合理性，未做跨建议、跨团队、跨时间窗比对 | 检查复核规则与检查项清单，确认是否存在跨项依赖比对要求 | 第二步 |
| 模型行为 | 表述完整被当成依据充分，对未写明的依赖不追问 | 构造含隐含依赖的样例复测，观察结论是否标注待确认 | 第三步 |
| 结论未回写 | 复核结果停留在评审记录中，未进入项目状态与风险台账 | 追踪一条已复核建议，检查其依赖是否出现在后续跟踪与风险清单中 | 第四步 |
假设一：输入缺失。复核的对象是文本，文本里没有的依赖，模型无从判断。验证方式是抽查若干条被判定可行的建议，对照其任务拆分与原始需求，看是否记录了上游交付物、外部接口、数据来源和关键人力。如果这些字段在建议模板中根本不存在，漏判就首先来自输入，而非复核能力。
假设二：复核口径过窄。有些复核规则逐条评价建议的合理性，关注目标是否清楚、方案是否可行、成本是否合理，却没有要求把多条建议放在一起比对。依赖恰恰常出现在建议之间：两条建议共用同一套接口、同一批人、同一段上线窗口。验证方式是检查复核规则与检查项清单，确认是否包含跨建议、跨团队、跨时间窗的依赖比对项。若没有，口径本身就决定了依赖不会被发现。
假设三：模型行为。模型在复核时容易把“写得完整”当成“依据充分”。一段建议如果结构齐全、措辞确定，模型倾向于给出可行结论，而对没有写明的依赖不作追问。验证方式是构造样例复测：准备几条表面完整、实际隐含外部依赖的建议，观察复核结论是否把隐含依赖标注为待确认，还是直接判定可行。复测结果能区分是规则没要求，还是模型执行时跳过了追问。
假设四：结论未回写。即使复核阶段识别了依赖，如果结论只留在评审记录里，没有写入项目状态和风险台账，依赖就会在后续跟踪中再次丢失。验证方式是选一条已复核建议，追踪其依赖是否出现在任务状态、风险清单和例会材料中。回写缺失会让复核成果无法被后续角色使用，也会让同类漏判反复发生。
排查顺序的意义在于缩小范围。若输入抽查发现依赖字段普遍缺失，应先补输入，而不是先改提示；若输入完整而复核规则没有跨项比对要求，应先扩展口径；若规则已要求、样例复测仍漏判，再调整提示与样例；若前三个环节都正常，问题就在回写与跟踪环节。
按环节处置：让依赖重新进入复核链路
确认原因后，处置动作应针对具体环节展开，避免一次性改动所有规则。以下步骤按输入、口径、提示、回写的顺序给出，每一步都有可检查的完成标志。
补全输入。在项目建议模板中固定依赖字段，至少覆盖四类信息：上游交付物及其提供方、外部接口及就绪时间、数据来源及获取条件、关键人力及其可用时段。字段设为必填，允许填写“无依赖”，但要求填写人明确确认。完成标志是抽查新提交的建议，四类字段均有记录或明确标注无依赖。
扩展复核口径。在复核规则中增加跨建议与跨团队的依赖比对项，例如同一接口是否被多条建议引用、同一批关键人力是否被重复占用、多条建议的上线窗口是否重叠。比对项应给出判断口径，例如“两条建议引用同一外部接口且就绪时间晚于各自计划启动时间”即标记为依赖冲突。完成标志是复核结论中能看到跨项比对的结果，而不只是逐条评价。
调整提示与样例。要求模型对未写明的依赖显式标注为待确认，而不是默认无依赖。提示中可加入判断规则：建议涉及外部系统、跨团队交付、数据申请或关键人力时，若文本未说明就绪条件，结论应包含待确认项。同时补充正反样例，帮助模型区分“表述完整”与“依据充分”。完成标志是用含隐含依赖的样例复测，结论能稳定输出待确认标注。
回写闭环。复核结论中的依赖项应写入项目状态与风险台账，指定责任人和确认时点。依赖项需要有状态，例如待确认、已确认、已解除，并在例会或跟踪节奏中被复查。完成标志是任取一条已复核建议，其依赖项能在项目状态和风险清单中被找到，且有明确的责任人与下次确认时间。
处置过程中有两类操作需要设置风险边界。修改复核规则或批量重跑历史建议前，先备份现有复核结论，保留可回退版本，避免新规则覆盖旧结论后无法对比。批量重跑应分批进行，先在小范围建议上验证新规则的效果，确认漏判减少且误报可控后再扩大范围。若重跑过程中发现结论大面积翻转，应暂停并回到原因排查，确认是规则改进还是口径漂移。
在依赖字段与结论回写这两个环节，ONES 的项目管理能力可以承载相应动作：依赖信息可以作为工作项字段记录，复核结论与风险项可以进入项目状态和风险跟踪，责任人与确认时点也能落到具体工作项上，便于后续复查。工具承载的是记录与流转，依赖判断口径仍需团队在复核规则中明确。
验证恢复与复发预防
处置完成后，需要验证漏判是否真的减少，而不是只看规则是否改过。验证的核心是用已知答案的样本做回归测试：选取历史上确实存在关键依赖、但当时被判定可行的建议，重新走一遍复核流程，比对结论是否命中这些依赖。回归测试应覆盖四类依赖——上游交付、外部接口、数据来源、关键人力，每类至少若干条样本，观察命中情况和误报情况。
除回归测试外，可以观察两类指标判断修复效果。一是依赖类风险的提前发现比例，即依赖在复核阶段被标注、而非在上线前才暴露的比例，该比例上升说明复核链路开始起作用。二是上线前因依赖导致的变更次数，包括因接口未就绪、数据未到位、人力冲突引起的排期调整，该次数下降说明漏判在减少。指标应结合项目数量看趋势，避免用单个项目的数据下结论。
复发预防需要把临时处置固化为流程机制：
- 依赖字段设为建议模板的必填项，并在提交前做完整性检查。
- 复核规则定期评审，随项目类型和外部接口变化更新跨项比对项。
- 结论回写纳入流程检查，跟踪节奏中复查依赖状态与责任人确认情况。
- 保留回归测试样本集，规则调整后用同一批样本复测，观察命中变化。
验证阶段需要设定停止点：回归测试未通过前，不扩大自动复核的适用范围。若在小范围样本上仍出现关键依赖漏判，应先回到原因排查，确认是输入、口径、提示还是回写环节仍有缺口，再决定是否推广。扩大范围应以回归测试稳定命中、误报在可接受区间为前提，避免把未验证的规则推到全部项目上，造成新的排期偏差。
常见问题
复核规则已经要求检查依赖，为什么还会漏判？
规则写了要求，不等于执行时真正比对。常见情况是规则只列了“检查依赖”这一项，没有给出判断口径，例如什么算依赖冲突、跨建议比对时看哪些字段。模型或复核人拿到模糊要求，容易逐条评价建议本身，跳过跨项比对。排查时先看规则是否包含可操作的比对项和判断标准，再用含隐含依赖的样例复测，区分是规则不具体还是执行时被跳过。
建议模板里加了依赖字段，为什么漏判仍然出现？
字段存在和字段被认真填写是两件事。如果依赖字段是选填，填写人容易留空或写“无”，复核时也就无从判断。可以把字段设为必填，允许填“无依赖”，但要求填写人明确确认；同时在提交前做完整性检查。另一个容易被忽略的点是字段粒度：只写“依赖外部接口”信息量不足，需要写到接口名称、提供方和就绪时间，复核才能判断排期是否匹配。
模型复测时表现正常，上线后还是漏判，问题可能出在哪？
复测样本和真实建议的差异是首要排查点。复测常用结构清晰的样例，真实建议往往表述零散、依赖藏在附件或口头约定里。可以扩大复测样本来源，直接取历史建议而非人工构造。其次检查回写环节：模型在复核时标注了待确认依赖，但结论没有进入项目状态和风险台账，后续跟踪中依赖再次丢失，表现上就像从未被识别过。追踪一条已复核建议的依赖去向，能快速定位是识别问题还是流转问题。
批量重跑历史建议时需要注意什么？
重跑前先备份现有复核结论，保留可回退版本，避免新规则覆盖旧结论后无法对比。重跑应分批进行，先在小范围建议上验证新规则的效果，确认漏判减少且误报可控后再扩大。若重跑过程中结论大面积翻转，应暂停并回到原因排查，确认是规则改进还是口径漂移。历史建议的依赖信息可能本身就不完整，重跑结论中出现的待确认项需要人工复核，不能直接当作最终判断。
依赖漏判和优先级排序偏差是什么关系？
依赖缺失会直接影响排序依据。两条建议如果依赖条件不同，一条独立可做、一条需要等待外部接口，按同一口径比较价值与成本时，排序容易偏向看起来能立即启动的那条，而真正应优先推进的可能是需要提前协调依赖的那条。把依赖信息纳入复核结论后，排序可以同时考虑价值、成本和启动条件，减少因信息缺失造成的顺序偏差。
