AI给出的项目进度判断与实际不符，先不必急着换工具或调模型。这类失真多数来自输入数据和判断规则：状态更新滞后、完成口径不一致、缺少可核对的完成证据，或者规则把“有更新”当成“有进展”。处置时先界定失真出现在哪些项目、哪类判断、偏向哪个方向，再逐项验证原因，修正输入与规则后重新判断，并用人工抽检确认恢复情况。
要点总览（TL;DR）
- 先把“判断不准”拆成可观察的偏差：区分项目整体、迭代、任务三层判断，记录偏差方向（偏乐观、漏报、误报）和影响范围，避免把个别误判当成系统性问题。
- 失真原因集中在三类输入问题：状态更新滞后或批量补录、完成口径不一致、缺少可核对的完成证据；判断规则把更新频率等间接信号当作进度依据也会推高偏差。每条原因先验证再下结论。
- 处置顺序是先修输入再调规则：统一状态定义与完成标准、清理滞后与异常数据（批量修改前备份并设停止点）、补齐完成证据、最后调整判断规则并记录依据。
- 恢复验证用人工抽检对照AI判断，按判断对象分别统计偏差率与偏差类型，观察周期覆盖至少一个完整迭代或里程碑，恢复标准在验证前约定。
- 防复发靠日常检查项：状态更新时效、完成证据完整性、状态口径一致性，并保留复发时回到症状清单重新排查的回退入口。
失真出现在哪些进度判断上
“AI判断不准”是一句笼统的感受，排查前要把它拆成可观察的偏差。建议从最近一个判断周期内AI输出的进度结论入手，逐条与项目实际交付情况对照，记录偏差的方向和幅度，而不是只记住印象最深的一次误判。
常见的失真表现有四类。第一类是整体进度偏乐观，任务大量标记为进行中或已完成，AI据此判断项目按期推进，实际关键交付物尚未产出。第二类是延期未识别，已经错过计划节点的任务没有被标出，风险提示里也没有出现。第三类是风险提示缺失，存在依赖阻塞、资源冲突的任务没有进入风险清单。第四类是误报，正常推进的任务被反复提示延期或高风险，导致团队对提示失去信任。
判断对象要分开看。项目整体进度、迭代进度、单个任务状态是三套不同的判断，失真可能只发生在其中一层。例如任务层状态准确，但迭代汇总时把未验收的任务计入完成，问题就出在汇总口径而非原始数据。确认影响范围时，记录涉及哪些项目、哪类判断、从什么时间窗口开始出现偏差，避免把个别误判当成系统性问题，也避免把系统性偏差当成偶发错误。
完成这一步后，应得到一份失真症状清单，至少包含：判断对象（项目/迭代/任务）、偏差方向（偏乐观/偏保守/漏报/误报）、涉及范围、首次观察到的时间。这份清单是后续验证原因的对照基准。
逐项验证：数据、口径与规则三类原因
原因排查按“提出假设—收集证据—给出结论”的方式推进。每条原因在拿到证据前只是假设，不能直接写进结论，也不能据此立刻修改数据或规则。下表列出常见假设及验证方法，实际排查时按证据逐条填写结论。
| 原因假设 | 验证方法 | 可观察的排除证据 | 结论 |
|---|---|---|---|
| 数据时效：状态更新滞后，判断基于旧数据 | 抽取被误判的任务，比对最后更新时间与AI判断时点，统计滞后任务占比 | 被误判任务在判断时点前均有及时更新，滞后任务占比很低 | 成立/排除/待验证 |
| 批量补录：集中补填状态导致判断跳变 | 查看判断周期内是否存在集中修改记录，核对补录时间与判断时间的关系 | 周期内无集中补录，或补录发生在判断之后 | 成立/排除/待验证 |
| 状态口径：完成定义不一致，开发完成与验收完成混用 | 抽查标记完成的任务，对照实际交付物与验收记录，确认“完成”指哪一层 | 所有完成状态均有统一验收依据，抽查未发现口径混用 | 成立/排除/待验证 |
| 证据缺失：任务标记完成但无产出物或评审记录 | 抽样核对完成任务的交付物、评审结论、合并记录等证据 | 抽查任务均能对应到可核对的完成证据 | 成立/排除/待验证 |
| 规则问题：判断逻辑把更新频率、工时填报等间接信号当作进度依据 | 查看判断规则说明，构造或找出“频繁更新但无实质进展”的任务，看是否被计为推进 | 规则明确以完成证据和里程碑为准，间接信号仅作辅助 | 成立/排除/待验证 |
验证时优先从被误判的具体任务入手，而不是先全面审计所有数据。抽取十到二十条偏差样本，逐条追溯其状态变更记录、交付物和判断时点，通常就能看出原因集中在哪一类。若样本中多数任务在判断时点前长时间未更新，数据时效假设成立的可能性较高；若任务更新频繁但完成证据缺失，则更可能是口径或证据问题。
需要提醒的是，多条原因可能同时存在。例如状态口径不统一会放大数据滞后的影响，规则把更新当作进展又会进一步推高乐观偏差。验证阶段不必急于确定唯一原因，先把每条假设的证据状态记录清楚，处置阶段再按影响大小排序。
按排查顺序处置失真
处置的基本顺序是先修输入、再调规则，最后才考虑调整判断阈值。反过来做，先放宽规则让结果“看起来对”，会把真实问题掩盖掉，下一次判断仍会失真。
第一步，统一状态定义与完成标准。明确哪些状态计入进度、每个状态对应什么条件，例如“开发完成”指代码合并并通过自测，“验收完成”指需求方确认交付物。这一步的产物是一份状态定义说明，由项目负责人或项目管理角色确认，作为后续数据清理和规则调整的共同依据。
第二步，清理滞后与异常数据。针对验证阶段确认的滞后任务和批量补录记录，逐项核实真实状态后更新。涉及批量修改历史数据时，先备份或导出原始记录，明确修改范围（哪些项目、哪些时间段的哪些字段），并约定回滚方式，例如保留修改前的导出文件、记录修改批次。修改过程中设置停止点：一旦发现某批数据无法确认真实状态，暂停修改并标记为待核实，不用推测值填充。
第三步，补齐完成证据要求。对标记完成但缺少证据的任务，补充交付物链接、评审结论或验收记录；无法补齐的，将状态回退到与实际相符的层级。这一步决定后续判断能否以证据为基础，而不是以状态标签为基础。
第四步，调整判断规则并说明依据。根据验证结论修改规则，例如将进度判断的主要依据从“最近更新时间”改为“里程碑完成与验收记录”，对间接信号只作辅助参考。每次规则调整记录调整内容、依据和生效时间，便于后续对照效果。调整的目的是让规则反映真实进展，而非让输出符合预期。
在ONES中，上述动作可以落到具体的管理对象上：任务状态对应工作项状态字段，完成标准可以通过状态流转规则和字段必填来约束，完成证据可以关联交付物、评审记录或验收结论。这样AI读取的进度数据来自有定义、有证据的工作项记录，而不是零散的更新动作。处置阶段建议由项目管理角色负责状态定义，各任务负责人负责数据核实，修改历史数据前统一留存导出记录。
如何验证恢复并防止再次失真
处置完成后，不能仅凭“这次结果看起来合理”就判定恢复。需要用人工判断作为对照，确认AI判断的偏差回到可接受水平。
验证方法是抽样对照：选取若干个项目和迭代，由熟悉情况的负责人独立给出进度判断，再与AI输出比对，记录偏差率和偏差类型。偏差率按判断对象分别统计，项目整体、迭代、任务三层分开看，避免一层准确掩盖另一层的问题。观察周期建议覆盖至少一个完整的迭代或里程碑节点，重点跟踪两类指标：延期识别是否命中实际延期，风险提示中误报与漏报的比例。
恢复的判定标准应在验证前约定，例如连续两个判断周期内，抽样对照的偏差率低于团队可接受阈值，且未出现方向一致的系统性偏差。若偏差仍集中在某一类判断上，回到原因假设表，针对该类判断重新排查，而不是整体推翻处置结果。
防复发依靠日常检查项，而不是一次性修复。建议把以下内容纳入固定检查：状态更新时效，即关键任务超过约定天数未更新时提醒负责人；完成证据完整性，即标记完成的任务是否附有交付物或评审记录；状态口径一致性，即新加入的项目是否沿用统一的状态定义。这些检查项可以按周或按迭代执行，结果记录在验证记录表中。
同时保留复发时的回退入口：当再次出现明显失真时，先冻结规则调整，回到症状清单重新界定范围，按“数据—口径—规则”的顺序复查，并对照上次的验证记录判断是旧原因复发还是新原因出现。这样每次失真都能留下可追溯的排查记录，判断的可信度也能随周期逐步积累。
常见问题
AI判断偏乐观，但任务状态看起来都填了，问题可能出在哪？
状态填了不等于进度真实。优先核对两件事：一是这些状态在判断时点前是否及时更新，批量补录或长期未更新的任务会让判断基于旧数据；二是“完成”指的是哪一层，开发完成与验收完成混用会把未验收的工作计入进度。抽查若干条被判断为完成的任务，看能否对应到交付物、评审结论或验收记录，通常就能定位是时效问题还是口径问题。
批量修正历史状态数据时要注意什么？
修改前先导出或备份原始记录，明确修改范围（哪些项目、哪些时间段、哪些字段），并约定回滚方式，例如保留修改前导出文件、记录修改批次。修改过程中设停止点：某批数据无法确认真实状态时暂停并标记待核实，不用推测值填充。修正的目的是让数据反映真实进展，修改记录本身也要留存，便于后续对照判断效果。
调整判断规则后，怎么确认失真已经修复？
用人工判断作对照：选取若干项目和迭代，由熟悉情况的负责人独立给出进度判断，再与AI输出比对，按项目整体、迭代、任务三层分别统计偏差率和偏差类型。观察周期覆盖至少一个完整迭代或里程碑，重点看延期识别是否命中实际延期、风险提示的误报与漏报比例。恢复标准应在验证前约定，例如连续两个判断周期偏差率低于团队可接受阈值且无方向一致的系统性偏差。
多条原因同时存在时，处置顺序怎么排？
按影响大小排序，但顺序上仍先修输入再调规则。状态口径不统一会放大数据滞后的影响，规则把更新当作进展又会进一步推高乐观偏差，因此先统一状态定义与完成标准，再清理滞后数据、补齐完成证据，最后调整规则。先放宽规则让结果“看起来对”，会掩盖真实问题，下一次判断仍会失真。
失真反复出现，如何判断是旧原因复发还是新原因？
先冻结规则调整，回到失真症状清单重新界定范围，按“数据—口径—规则”的顺序复查，并对照上次的验证记录逐项比对。若偏差类型、涉及判断对象与上次一致，多为旧原因复发，重点检查日常检查项是否执行到位；若偏差出现在新的判断层或新的项目范围，按原因假设表重新验证，补充新的证据再处置。
