AI给出的进度百分比和风险提示与实际不符，往往不是模型本身“算错”了，而是输入数据、完成口径或推断边界出了问题。本文围绕项目状态与风险判断，说明如何把模糊的失真感受收敛为可核对症状，按数据、口径、推断三层验证原因，再分层处置并用同一批样本回测，恢复可信判断。
要点总览（TL;DR）
- 先把“AI判断不准”收敛为可核对症状：进度数值偏差、延期漏判、状态误判、风险等级波动，并固定一个可复现样本作为排查基准。
- 按数据层、口径层、推断层依次排除原因：先核对工作项原始记录，再核对完成定义与进度计算规则，最后检查AI结论是否有证据引用。
- 处置对应已确认的原因，未确认的假设不提前修改；批量改状态前先备份或小范围试点，并保留回滚条件。
- 用同一批失真样本回测，统计判断与原始记录的一致率、延期识别命中与误报情况，未达标时回到原因表继续排查。
- 把复核发现写回工作项模板与状态更新规则，状态更新责任到人、定期抽查AI结论，减少同类失真复发。
失真表现与影响范围如何界定
排查的第一步是把“AI判断不准”转成可以逐条核对的具体症状。笼统地说失真，无法确定该修数据、修规则还是修推断逻辑；只有落到某条工作项、某个时间点、某个结论上，才能形成排查基准。
常见的失真症状可以归为四类，每类对应不同的判断类型：
| 症状 | 典型表现 | 涉及的判断类型 |
|---|---|---|
| 进度数值偏差 | AI给出的完成百分比高于或低于实际已完成的工作项数量 | 整体进度 |
| 延期漏判 | 已超过计划日期的工作项未被识别为延期，或延期天数与实际不符 | 里程碑达成、延期预警 |
| 状态误判 | 已完成的工作项被标为风险，或已关闭的事项仍出现在待办风险中 | 风险提示 |
| 风险等级波动 | 同一项目在相近时间点生成的风险等级忽高忽低，缺少可解释的变化依据 | 风险提示 |
症状清单建立后，需要界定影响范围：哪些项目使用了这类判断，哪些角色据此做决策。项目经理可能依据延期预警调整排期，研发负责人可能依据风险提示调配人力，管理层可能依据整体进度判断是否追加资源。范围界定清楚，才能判断失真是一次性的数据异常，还是影响多个项目的系统性问题。
随后固定一个可复现的失真样本：选择一条或一组工作项，记录AI当时给出的结论、生成时间、涉及的原始工作项记录，以及人工核对后的真实状态。样本要能重复触发同类判断，后续的原因验证和恢复回测都以它为基准。样本数量不必多，关键是结论与原始记录能一一对应。
原因假设与逐条排除证据
失真原因不能凭印象下结论。建议按数据层、口径层、推断层三层列出假设，每层给出验证动作和可观察证据，按“先查原始数据，再查口径，最后查推断逻辑”的顺序排除。顺序的意义在于：数据本身错了，后面两层的分析都建立在错误输入上。
| 层级 | 原因假设 | 验证动作 | 可观察证据 |
|---|---|---|---|
| 数据层 | 工作项状态更新滞后 | 对比工作项最后更新时间与实际完成时间 | 状态更新时间明显晚于代码提交、评审通过等实际完成节点 |
| 数据层 | 必填字段缺失 | 抽查样本工作项的负责人、计划日期、状态字段 | 关键字段为空或使用默认值，AI只能按缺失值推断 |
| 数据层 | 多系统数据未同步 | 核对同一工作项在项目系统与代码、测试系统中的状态 | 两处状态不一致，或同步存在明显时间差 |
| 口径层 | 完成定义不一致 | 询问团队对“完成”的理解，对照工作项模板 | 有人认为开发完成即完成，有人要求测试通过才算完成 |
| 口径层 | 进度计算规则与团队理解不同 | 用样本工作项手工复算进度，与AI结果比对 | 按工作项数量、按工时、按故事点计算，结果差异明显 |
| 推断层 | 把评论文本当事实 | 检查AI结论引用的文本来源 | 结论依据来自讨论中的推测性表述，而非状态字段 |
| 推断层 | 缺少证据引用 | 要求AI说明结论对应的工作项或文档 | 结论无法定位到具体记录，或引用范围过宽 |
| 推断层 | 对模糊描述过度归纳 | 对比模糊描述与AI给出的确定性结论 | “可能下周完成”被归纳为“按计划完成” |
验证时以证据为准，不以“感觉像”作为排除依据。例如怀疑状态更新滞后，就调出样本工作项的操作记录，看状态变更时间与评审、测试通过时间的间隔；怀疑口径不一致，就让参与判断的成员分别说明自己理解的完成标准，记录差异点。每排除一类假设，都要留下对应的核对记录，避免后续处置时重复排查。
三层假设可能同时成立。实践中常见的情况是：状态更新滞后导致数据层失真，完成定义不一致放大了偏差，AI又缺少证据引用使问题难以被发现。排查记录应标明每类原因是否成立、证据是什么，为下一步处置提供依据。
按原因分层的处置步骤
处置动作对应已确认的原因，未确认的假设不提前修改，避免引入新的失真。三层处置可以并行准备，但执行时建议先修数据、再统一口径、最后调整推断与复核机制。
数据层处置
- 补全必填状态字段：明确负责人、计划完成日期、当前状态为必填项，字段为空的工作项在进入判断前先补齐。
- 设定更新时限：约定工作项状态在完成当天或次日更新，超时未更新的工作项在周度核对中列出。
- 核对跨系统同步：对项目系统与代码、测试系统之间的状态映射逐项确认，发现不一致时先修正同步规则，再重新生成判断。
口径层处置
- 统一完成定义：把“完成”写成可判断的条件，例如开发完成、测试通过、验收通过分别对应什么状态，写入工作项模板。
- 固定进度计算规则：明确整体进度按工作项数量、工时还是故事点计算，规则变更时同步通知依赖该判断的角色。
推断层处置
- 要求结论附来源：AI给出的进度或风险判断应能对应到具体工作项或文档，无法定位来源的结论不作为决策依据。
- 设置人工复核节点：在里程碑评审、周度风险确认等环节，由项目经理核对AI结论与原始记录，复核意见留痕。
- 限制无依据推断：对描述模糊、缺少状态字段支撑的事项，要求AI标注不确定性，不输出确定性结论。
涉及批量修改工作项状态时，操作风险最高。批量改状态可能覆盖原有记录、触发通知或影响其他报表，执行前应先备份相关数据或导出当前状态，选择一个小范围项目试点，确认修改结果与预期一致后再扩大范围。若试点中发现状态被错误覆盖或下游判断出现新的偏差，停止扩大并回滚到备份状态，重新核对修改规则。
在ONES中，工作项状态、负责人、计划日期等字段构成判断的基础记录，Wiki页面可承载完成定义与进度规则的说明。ONES Assistant 能够理解项目、工作项、迭代和 Wiki 页面等工作上下文，基于相关数据回答问题并执行后续操作；其输出过程可追踪、结果可审计，便于在复核环节对照结论与原始记录。基于指定 Wiki 页面组提问时还可附上引用来源，适合把完成定义、状态更新规范作为判断依据固定下来。具体的数据刷新时效与复核节点配置，需结合团队实际部署情况确认。
恢复验证与复发预防
处置完成后，用最初固定的失真样本回测：对同一批工作项重新生成进度与风险判断，逐条与人工核对结果比对。回测要覆盖四类症状，分别记录整体进度是否一致、里程碑达成判断是否正确、延期是否被识别、风险提示是否存在误报。
验证指标建议聚焦三项：
- 一致率：AI判断与原始工作项记录一致的比例，按判断类型分别统计。
- 延期识别命中：实际已延期的工作项中，被AI正确识别为延期的比例。
- 误报情况：被标为风险但经核对无实际风险的工作项数量及原因。
回测记录应保留样本、判断结果、人工核对结论和差异原因。若一致率仍未达到团队可接受的水平，回到原因假设表检查是否有未排除的层级，而不是直接调整AI输出。
复发预防要把复核发现转成规则：状态更新责任到人，明确每个工作项的更新义务；定期抽查AI结论，例如每周抽取若干条风险提示核对来源；把复核中反复出现的口径分歧写回工作项模板或Wiki说明，让下一次判断有据可依。
当失真在数据层已排除后仍持续出现，例如状态字段完整、更新及时、口径统一，但AI结论仍频繁偏离原始记录，说明问题可能出在推断逻辑或判断所依赖的数据范围上，此时需要升级处理，由产品配置或技术支持人员核对判断规则与数据接入范围，避免团队在反复手工修正中消耗排查精力。
常见问题
AI判断的进度和实际差得不多，还需要按三层排查吗？
偏差小也要先确认方向。如果AI给出的进度持续略高于实际，常见原因是部分工作项状态更新滞后，数据层修好即可；如果偏差只出现在个别项目，更可能是完成定义不一致。建议仍按数据、口径、推断的顺序各查一遍，每层留下核对记录。偏差小但方向稳定，往往说明规则层面有系统性偏移，比偶发的大偏差更值得处理。
团队对“完成”的理解不一致，统一口径时应该由谁定？
完成定义属于团队约定，通常由项目经理牵头，研发、测试负责人共同确认，再写入工作项模板或Wiki说明。关键是让定义可判断：开发完成、测试通过、验收通过分别对应哪个状态，避免用“基本做完”这类描述。定义确定后同步给依赖AI判断做决策的角色，规则变更时一并通知。
批量修正历史工作项状态，风险主要在哪里？
风险集中在三点：覆盖原有状态记录导致追溯困难、触发大量通知干扰团队、影响依赖这些状态的报表和判断结果。执行前导出或备份当前状态，选一个小范围项目试点，确认修改结果与预期一致后再扩大。试点中出现状态被错误覆盖或下游判断出现新偏差时，停止扩大并回滚到备份状态，重新核对修改规则。
回测时一致率达到多少才算判断恢复可信？
没有统一阈值，取决于判断被用于什么决策。用于里程碑评审和资源调配的判断，一致率要求应高于仅作参考的周报数据。建议按判断类型分别统计：整体进度、里程碑达成、延期识别、风险提示各设一个团队可接受的水平，并同时看延期识别命中与误报情况。一致率未达标时，先回到原因假设表检查是否有未排除的层级，不直接调整AI输出。
数据层问题都排除了，AI判断仍然偏离，该怎么处理？
状态字段完整、更新及时、口径统一，但结论仍频繁偏离原始记录，说明问题可能出在推断逻辑或判断所依赖的数据范围上。此时需要升级处理，由产品配置或技术支持人员核对判断规则与数据接入范围。在ONES中，ONES Assistant 的输出过程可追踪、结果可审计，便于复核时对照结论与原始记录；具体的数据刷新时效与复核节点配置，需结合团队实际部署情况确认。
