检查AI拆出的研发任务是否遗漏依赖，关键是把“应有关联”和AI产出的依赖逐条比对，而不是只看任务数量或描述是否完整。评估前需要先锁定任务批次、依赖类型和统计口径，再计算遗漏率、误连率与关键路径断点数。依赖关系通常落在工作项关联与状态流转上，ONES可承载这类记录；本文围绕一套可复算的评估方法展开。
要点总览（TL;DR）
- 检查依赖遗漏的核心动作，是把人工梳理的应有关联清单与AI声明的依赖逐条比对，任务数量与描述完整度只作辅助参考。
- 建议成组使用四个指标：依赖遗漏率、误连率、关键路径断点数、依赖方向错误数，并事先锁定任务批次、迭代时间窗与任务类型范围。
- 应有关联从需求文档、设计说明、接口约定、测试用例、发布顺序五类来源梳理，每条记录前置任务、后置任务与依据出处。
- 证据不足的关联标为待确认，单独统计比例；分母为零时只记录绝对数并注明不适用比率。
- 结论只说明该批任务在当前口径下的依赖覆盖情况，样本量小或待确认比例高时应降低结论强度，用同口径多轮对比观察改进效果。
评估目标：要验证的是依赖覆盖还是拆解质量
本轮评估的对象是AI在某一批次中拆出的任务清单，以及这些任务之间声明的依赖关系。判定目标有三个：应有关联是否被识别、依赖方向是否正确、关键路径是否连通。三个问题都指向“依赖覆盖”，回答的是这批任务在依赖维度上是否完整。
任务粒度是否合适、工作量估算是否准确、负责人分配是否合理，属于拆解质量的其他维度，本次不纳入计算。把它们混进同一张评分表，会让依赖遗漏率失去解释力：一个任务拆得过粗，可能掩盖多条依赖缺失；拆得过细，又可能让依赖数量虚高。评估开始前应写一份目标说明，明确列出评估对象、判定问题和排除维度，作为后续取数与复核的共同依据。
判定问题可以写成三句可回答的话：这份任务清单中，需求、设计、接口、测试、发布五类应有关联各识别了多少？已声明的依赖中，前置后置方向颠倒的有几条？关键路径上是否存在没有前置任务支撑的环节？三句都能用清单和数字回答，评估目标就算界定清楚。
指标与范围：依赖遗漏检查评哪些项
依赖遗漏检查建议成组使用四个指标，分别覆盖“漏”“多”“断”“错”四种情况。每个指标都要事先写明公式、分子分母、单位和统计范围，避免不同批次各算各的。
| 指标 | 公式 | 分子 | 分母 | 单位 |
|---|---|---|---|---|
| 依赖遗漏率 | 遗漏的应有关联数 ÷ 应有关联总数 | 人工梳理后确认AI未识别的应有关联条数 | 应有关联清单中的关联总条数 | 百分比 |
| 误连率 | 错连或多连的依赖数 ÷ AI产出依赖总数 | 方向错误、对象错误或凭空的依赖条数 | AI在任务清单中声明的依赖总条数 | 百分比 |
| 关键路径断点数 | 关键路径上缺失依赖的环节数 | 关键路径中缺少必要前置或后置的环节 | 不设比率分母，按“处”计数 | 处 |
| 依赖方向错误数 | 前置后置颠倒的依赖条数 | 方向颠倒的依赖条数 | 不设比率分母，按“条”计数 | 条 |
统计范围需要提前锁定三件事：任务批次（哪一次AI拆解产出）、迭代时间窗（例如某个两周迭代内计划完成的任务）、任务类型范围（需求、开发、测试、发布是否全部纳入）。范围一旦确定，同一轮评估内不随样本调整而改变，否则分子分母会漂移。
分母为零时要单独处理。某个批次的任务之间确实没有依赖，应有关联总数为零，此时遗漏率不计算，只记录“应有关联0条、AI声明依赖0条”的绝对数，并标注“不适用比率”。AI产出依赖总数为零而应有关联大于零，误连率同样不计算，但遗漏率照常计算，因为此时遗漏情况恰恰最需要暴露。任务本身无依赖属于正常情形，不应被记成遗漏，也不应被排除出统计范围。
数据口径与证据：依赖关系从哪里取数
依赖检查需要两条数据线：一条是“应该有什么依赖”，来自需求与设计资料；另一条是“AI实际声明了什么依赖”，来自任务清单本身。两条线都落到同一条关联上，才能逐条比对。
应有关联的证据来源主要有五类。需求文档提供功能之间的先后与包含关系；设计说明给出模块划分与数据流向；接口约定明确服务之间的调用顺序；测试用例暴露被测功能对前置环境的依赖；发布顺序说明上线批次之间的约束。梳理时应把每条应有关联写成“前置任务—后置任务—依据出处”的三元组，出处精确到文档章节或接口条目，便于复核时回查。
AI产出的依赖记录形式通常有三种：任务描述中写明的“依赖某任务”“待某接口完成后开始”；任务之间的关联工作项；工作项上的前置、后置字段。三种形式可能并存，取数时应统一折算成关联条数，并注明来源形式，避免同一依赖被重复计数。
证据不足的关联标注为“待确认”，既不计入遗漏，也不计入正确，单独统计待确认比例。待确认比例过高时，本轮结论只能作为方向性参考。两类情形属于不可比：一是两批任务的类型范围不同，例如一批含测试任务、另一批不含；二是应有关联清单的梳理深度不同，一批细到接口、另一批只到模块。出现不可比时，应分批评述，不合并成一个总遗漏率。
计算与评估步骤：从抽样到复核的操作流程
一轮完整的依赖遗漏评估按以下顺序执行，每步都留下可回查的记录。
- 确定抽样范围与样本量。从目标迭代时间窗内选取AI拆解的任务批次，记录批次标识、任务条数、任务类型范围。样本量较小时全量检查；任务量大时按任务类型分层抽样，每层样本量在评估前写定，不因中间结果调整。
- 建立应有关联清单。按需求、设计、接口、测试、发布五类来源逐项梳理，形成“前置任务—后置任务—依据出处—依赖类型”的记录表。梳理人与AI拆解操作人分开，减少先入为主。
- 与AI依赖逐条比对。对每条应有关联，在AI产出中查找对应声明，标记“已识别”“未识别”“方向错误”“待确认”；对AI声明但应有关联清单中没有的依赖，标记“疑似多连”，回到证据来源确认。
- 按指标计算并标记争议项。代入四个指标的公式，记录分子分母与计算结果。比对中双方判断不一致的条目列为争议项，不先行计入任何一方。
- 人工复核与结论归档。由未参与前几步的评审人复核争议项和关键路径相关条目，确认后更新计数。归档内容包括评估目标说明、应有关联清单、比对记录表、指标计算表和结论说明，供下一轮对比。
记录表至少包含这些字段：任务编号、关联对象、依赖类型、依据出处、AI声明情况、比对结论、是否关键路径、复核意见。字段齐全后，指标可以随时复算，评估结论也能追溯到具体条目。
在ONES中，任务依赖落在工作项关联与状态流转上，评估时可从工作项的前置后置关联、迭代范围与评审记录取数；ONES Assistant可将PRD拆解为需求和任务，拆解结果仍需按上述口径人工核验依赖完整性。把比对记录与复核意见留在工作项和评审记录里，下一轮评估可以直接沿用同一口径。
例子：一个迭代批次的依赖遗漏核算
以下为演示情景，数字仅用于说明公式如何代入，不代表任何产品的实际表现。
假设某迭代批次中，AI拆出40条任务、声明60条依赖。人工按五类来源梳理出应有关联70条，逐条比对后发现8条未被AI识别，3条方向颠倒，另有5条AI声明但证据不足、标为待确认。
| 项目 | 数值 | 计算与说明 |
|---|---|---|
| 应有关联总数 | 70条 | 五类来源梳理后的关联总数，作为遗漏率分母 |
| 遗漏关联数 | 8条 | 比对结论为“未识别”的条目 |
| 依赖遗漏率 | 约11.4% | 8 ÷ 70 |
| AI声明依赖总数 | 60条 | 作为误连率分母 |
| 方向错误数 | 3条 | 前置后置颠倒，按条计数 |
| 误连率 | 5.0% | 3 ÷ 60，仅计已确认的方向错误，待确认5条暂不计入 |
| 关键路径断点数 | 2处 | 关键路径上有2个环节缺少必要前置 |
| 待确认比例 | 约7.1% | 5 ÷ 70，作为结论强度的限制说明 |
结果可以这样表述：该批次在当前口径下，依赖遗漏率约11.4%，关键路径存在2处断点，另有约7.1%的应有关联因证据不足待确认。这个结论说明的是该批任务的依赖覆盖情况，不能直接推出交付会延期或不会延期。若下一批次的任务类型范围不同，或应有关联只梳理到模块层级，两组数字不可直接比较，应分别列示。
解读与限制：结论能说明什么、不能说明什么
四个指标反映的是当前口径下的依赖覆盖情况。遗漏率低，说明在这批任务、这套证据来源和这个梳理深度下，AI声明的依赖与人工梳理的应有关联吻合度较高；它不保证交付无风险，因为风险还来自估算偏差、资源冲突、外部接口变更等本次未评估的因素。
结论强度取决于样本量和证据完整度。样本量小、待确认比例高时，应把结论写成“初步观察”，并注明适用范围，例如“仅覆盖本迭代开发类任务”。关键路径断点数是绝对计数，适合直接用于排期复核，不适合换算成比率与其他批次横向排名。
评估结果更适合用于改进流程，而不是给AI拆解打总分。把高频遗漏的依赖类型整理成检查清单，回填到拆解指令中，例如要求拆解时显式列出接口调用顺序和测试环境前置；把方向错误集中的环节加入人工评审的必查项。下一轮用同一口径复算，观察遗漏率和断点数是否变化，才能判断改进是否有效。单轮数字只描述当批情况，多轮同口径对比才构成趋势。
常见问题
AI拆出的任务之间本来就没有依赖，遗漏率该怎么算？
应有关联总数为零时，遗漏率不计算，只记录“应有关联0条、AI声明依赖0条”的绝对数，并标注“不适用比率”。任务本身无依赖属于正常情形，不应记成遗漏，也不应被排除出统计范围。反过来，AI声明依赖为零而应有关联大于零时，误连率不计算，遗漏率照常计算，因为这种情况恰恰最需要暴露。
人工梳理应有关联清单时，梳理深度不一致会带来什么问题？
梳理深度不同会让两批数字不可直接比较。例如一批细到接口条目，另一批只到模块层级，后者的应有关联总数天然偏少，遗漏率会被低估或高估。出现这种情况时应分批评述，不合并成一个总遗漏率。可行的做法是在评估目标说明里写明本轮梳理到哪一层，并在下一轮沿用同一深度，保证同口径对比。
比对时双方判断不一致的条目怎么处理？
这类条目列为争议项，不先行计入遗漏，也不计入正确。由未参与梳理和比对前几步的评审人复核，确认后再更新计数。争议项数量本身也值得记录：争议集中出现在某类依赖上，往往说明该类依赖的判定标准不够清晰，可以在下一轮评估前补充判定规则，或把这类依赖加入人工评审的必查项。
关键路径断点数为什么用绝对计数，不换算成比率？
关键路径上的环节数量因批次而异，换算成比率后分母含义不稳定，容易造成误读。按“处”计数可以直接用于排期复核：有几处断点，就对应几个需要补齐前置或调整顺序的环节。它也不适合与其他批次横向排名，因为不同迭代的关键路径长度不同。需要横向观察时，更适合看遗漏率和误连率的变化趋势。
评估结果如何用于改进下一轮的AI拆解？
把高频遗漏的依赖类型整理成检查清单，回填到拆解指令中，例如要求拆解时显式列出接口调用顺序和测试环境前置；把方向错误集中的环节加入人工评审的必查项。下一轮用同一口径复算，观察遗漏率和断点数是否变化，才能判断改进是否有效。单轮数字只描述当批情况，多轮同口径对比才构成趋势。
