AI给出的进度判断失真，通常来自两处：输入数据本身不可信，或判断逻辑与团队实际口径不一致。前者要靠数据质量治理解决，后者要靠人工校准纠偏，两者需要按“先治理输入、再校准判断、最后回流规则”的顺序连成闭环。下文给出字段规则、校准触发点、归因回流、角色分工与检查清单，并说明ONES可承载字段维护、校准记录与规则沉淀的协作环节。
要点总览（TL;DR）
- AI进度判断失真分两类：输入数据不可信与判断口径不一致。数据质量治理负责前者，人工校准负责后者，两者按“先治理输入、再校准判断、最后回流规则”的顺序连成闭环。
- 字段规则应覆盖任务状态、完成比例、里程碑日期、阻塞与依赖，并写明更新人、更新时点和允许值范围；通过比对最后修改时间、状态与比例一致性、跨团队字段定义来识别缺失、滞后和口径不一致。
- 人工校准设在里程碑到期前、状态跳变和偏差超阈值三类触发点，校准记录必须包含AI原始判断、人工结论、修正理由和后续动作，修正理由是回流环节的关键输入。
- 校准差异按数据错误、口径差异、判断逻辑偏差三类归因，分别对应补充字段校验、统一字段定义、调整触发条件与依赖表达；按迭代小结、按季度复盘，规则变更需留痕。
- 检查机制是否生效看三类指标：核心字段完整率与更新及时率、校准覆盖率与记录完整性、回流动作落地情况与同类失真复发次数。
核心答案：治理与校准如何分工配合
数据质量治理解决的是“AI看到的输入是否可信”，人工校准解决的是“AI基于输入得出的判断是否可信”。两者各自只能覆盖一类失真：字段缺失、更新滞后、口径混乱会让再合理的判断逻辑也输出错误结论；而数据齐全时，AI仍可能因里程碑粒度过粗、依赖关系未表达清楚而误判进度。因此配合的基本顺序是固定的：先把输入治理到可追溯，再在关键节点由人确认或修正判断，最后把修正结果转成规则和校验的更新。
闭环可以拆成三个环节，每个环节都有明确的交接物：
| 环节 | 主要动作 | 责任方 | 交接物 |
|---|---|---|---|
| 输入治理 | 定义进度判断依赖的字段、更新责任与校验规则，清理缺失和滞后数据 | 数据维护人、研发负责人 | 字段与校验规则清单、数据质量状态 |
| 判断校准 | 在触发点核对AI给出的进度与偏差判断，确认或修正并记录理由 | 项目经理、研发负责人 | 校准记录（含修正前后结论与原因） |
| 规则回流 | 对校准差异归因，更新字段校验、判断口径与校准清单 | 项目经理、AI工具管理方 | 归因表、规则变更记录 |
三个环节的衔接点在于校准记录：它既是判断侧的产出，也是回流环节的输入。如果校准只停留在“这次改一下结论”，差异原因没有沉淀，下一轮同类失真会重复出现。反过来，如果只做数据治理而不设校准点，AI的判断逻辑偏差无法被发现，治理投入也难以验证效果。
第一步：确定进度判断依赖的数据与字段规则
治理的起点是把AI进度判断实际依赖的输入列清，并为每个字段写明更新人、更新时点和允许值范围。字段清单不必求全，应覆盖能直接影响进度结论的核心项：任务状态、完成比例、里程碑日期、阻塞与依赖关系。字段越多，维护成本越高，优先保证这几类字段的准确和及时。
| 输入字段 | 更新人 | 更新时点 | 允许值与校验规则 |
|---|---|---|---|
| 任务状态 | 任务负责人 | 状态发生变化当日 | 限定在团队约定的状态集合内；进入“完成”须有对应交付物或评审记录 |
| 完成比例 | 任务负责人 | 每日或每个工作日结束前 | 0–100的整数；与状态保持一致性，例如状态为“未开始”时比例应为0 |
| 里程碑日期 | 项目经理 | 计划变更时即时更新，并注明变更原因 | 日期格式统一；变更须留痕，避免静默改期 |
| 阻塞项 | 任务负责人或项目经理 | 发现阻塞时登记，解除时关闭 | 须写明阻塞对象、影响范围和预计解除时间；关闭时填写解除说明 |
| 依赖关系 | 任务负责人 | 建立或调整依赖时 | 指向具体工作项；禁止循环依赖；跨团队依赖须标注对接人 |
字段规则确定后，需要能识别三类常见数据问题。缺失表现为必填字段为空或关键工作项没有负责人；滞后表现为状态长时间未更新、里程碑已过但完成比例未变；口径不一致表现为同一概念在不同团队含义不同，例如“完成”在一处指代码提交、在另一处指通过验收。识别方式可以做成例行检查：按更新时点比对最后修改时间，按状态与比例的对应关系筛查矛盾记录，按跨团队字段定义对照表发现口径分歧。
这一步的完成标志是：字段清单经项目经理和研发负责人确认，每个字段都有明确更新人，且能通过一次抽样检查说出当前数据的缺失率与滞后情况。
第二步：按里程碑粒度设置人工校准触发点
里程碑粒度直接决定AI判断的失真空间。粒度过粗，例如整个迭代只设一个交付里程碑，AI在中期只能依据完成比例推断，而比例本身主观性强，偏差会被放大到结论上；粒度过细，例如把每个小任务都设为里程碑，校准点过多，人工核对变成负担，反而容易流于形式。较稳妥的做法是把里程碑设在可验收的交付单元上，使每个里程碑都有可核对的完成标志，同时控制单个迭代内的里程碑数量在团队能逐条校准的范围内。
人工校准不宜按固定频率平均分布，而应设在判断最容易失真的时点：
- 里程碑到期前：在到期前的固定窗口内核对AI给出的达成概率与剩余工作量，提前暴露偏差。
- 状态跳变：工作项从进行中直接跳到完成、或完成比例大幅跃升时，核对是否有对应交付物支撑。
- 偏差超阈值：AI判断的进度与项目经理掌握的情况差距超过团队设定阈值时触发校准，阈值按项目周期和风险容忍度确定。
校准人按对象分工：任务级偏差由研发负责人核对，里程碑级和跨团队偏差由项目经理核对，涉及判断口径本身的争议提交给AI工具管理方。校准记录应包含校准时间、校准对象、AI原始判断、人工结论、修正理由和后续动作，其中修正理由是回流环节最有价值的信息，不能省略。
第三步：把校准结果回流为治理规则
校准记录积累后，需要按差异原因分类，不同原因对应不同的治理动作。把“AI判断错了”笼统处理，会导致每次都在改结论而规则不变。
| 差异归因 | 典型表现 | 治理动作 |
|---|---|---|
| 数据错误 | 状态未及时更新、完成比例与实际不符、阻塞项未登记 | 补充字段校验规则，增加例行检查频率，明确该字段的更新责任 |
| 口径差异 | 团队对“完成”“延期”的定义不同，AI按一种口径判断而团队按另一种执行 | 统一字段定义并写入规则清单，必要时调整状态集合或增加说明字段 |
| 判断逻辑偏差 | 数据准确但AI对依赖关系、风险传导的推断不符合实际 | 调整校准触发条件与阈值，补充依赖关系表达，把典型误判写入校准清单供后续核对 |
回流需要固定节奏。可以按迭代做一次小结，按季度做一次规则复盘：迭代小结处理当期的数据错误和个别口径问题，季度复盘审视阈值是否合理、校准清单是否需要增删、字段规则是否仍然适用。责任人上，项目经理负责组织复盘并确认规则变更，数据维护人负责落实字段校验调整，AI工具管理方负责把口径和触发条件同步到判断配置中。每次复盘应产出规则变更记录，写明改了什么、为什么改、从哪个迭代开始生效。
在承载方式上，字段规则、校准记录和归因结论需要有统一的存放位置，避免散落在个人表格里。ONES Assistant 能理解项目、工作项、迭代和 Wiki 页面等真实工作上下文，并可把结果保存为工作项、Wiki 页面等内容，团队可以把校准记录与规则变更沉淀在项目空间中，使回流动作有据可查；其基于权限体系执行任务，输出过程可追踪，便于复盘时回溯判断依据。
角色分工与各环节交付物
治理与校准要持续运行，前提是每个环节都有明确的责任人和可交接的产出。角色不必新增，通常由现有项目角色兼任，但要写清边界，避免校准和治理互相等待。
| 角色 | 职责边界 | 输入 | 动作 | 输出 |
|---|---|---|---|---|
| 项目经理 | 对里程碑级判断和整体闭环负责，不替代研发负责人做任务级核对 | AI进度判断结果、校准记录 | 组织校准、主持复盘、确认规则变更 | 校准结论、规则变更记录 |
| 研发负责人 | 对任务级状态与完成比例的真实性负责 | 任务清单、阻塞与依赖信息 | 维护任务字段、参与任务级校准 | 准确的任务数据、校准意见 |
| 数据维护人 | 对字段完整率和及时率负责，不判断业务结论 | 字段与校验规则清单 | 执行例行检查、清理缺失与滞后数据 | 数据质量状态报告 |
| AI工具管理方 | 对判断配置与口径同步负责 | 归因表、规则变更记录 | 调整触发条件与阈值、同步口径 | 更新后的判断配置 |
交接时点与评审时点需要固定下来：迭代开始时确认字段规则与里程碑设置，迭代中按触发点完成校准并记录，迭代结束时提交归因表，复盘会上确认规则变更。交接物以校准记录和归因表为核心，二者齐全，闭环才算走完一轮。
示例：一个迭代周期内的治理与校准运行
以下为一个两周迭代的示范情景，用于说明各环节如何按节奏衔接，具体阈值和角色名称需按团队实际调整。
迭代开始时，项目经理与研发负责人确认本期字段规则：任务状态限定为五个约定状态，完成比例每日更新，里程碑设在两个可验收的交付单元上，阻塞项须在发现当日登记。数据维护人对上一迭代遗留的缺失字段做一次清理，形成初始数据质量状态。
迭代进行到第一周，AI判断某交付单元进度正常，但该单元下两个任务的状态连续多日未更新，触发滞后检查；同时一个跨团队依赖被登记为阻塞，AI据此下调了达成概率。研发负责人核对后确认状态确实滞后，补充更新并说明原因，项目经理在里程碑到期前的校准窗口内确认了修正后的判断。这次校准记录中，修正理由归为“数据错误”。
第二周出现一次状态跳变：某任务从进行中直接标记完成，但没有对应交付物。校准发现团队对该状态的“完成”口径理解不一致，属于口径差异。迭代结束后的复盘中，项目经理据此统一了状态定义并写入规则清单，AI工具管理方同步调整了判断口径；数据维护人则在例行检查中增加了状态与交付物对应关系的校验项。下一迭代的校准清单中，这类问题被列为重点核对项，同类失真随之减少。
完成检查：判断配合机制是否生效
机制是否生效，可以用三类可核对的检查项判断。检查按迭代或按月执行，结果用于调整下一轮的治理重点和校准触发条件。
| 检查类别 | 检查项 | 判断标准 |
|---|---|---|
| 数据字段 | 核心字段完整率 | 必填字段为空的工作项占比在团队可接受范围内，且较上一周期未恶化 |
| 数据字段 | 更新及时率 | 状态与完成比例在约定时点内更新的比例达到团队设定目标 |
| 人工校准 | 校准覆盖率 | 触发点出现时均完成校准，无遗漏的里程碑级偏差 |
| 人工校准 | 记录完整性 | 校准记录包含AI原始判断、人工结论、修正理由和后续动作 |
| 规则回流 | 回流动作落地 | 归因表中每类差异都有对应治理动作，且已落实到字段校验或判断配置 |
| 规则回流 | 失真复发情况 | 同类归因的校准次数逐周期下降，或稳定在低水平 |
如果完整率和及时率达标但校准仍频繁出现判断逻辑偏差，说明问题在判断口径而非数据，应优先调整触发条件和依赖关系表达；如果校准记录齐全但回流动作长期未落地，说明复盘缺少责任人跟进，需要把规则变更纳入项目经理的例行工作。检查结果本身也应进入下一轮字段规则和校准清单的更新，使闭环持续运转。
常见问题
团队刚开始做AI进度判断，应该先治理数据还是先设人工校准？
建议先做一轮最小化的数据治理，再设校准点。具体做法是：先列出AI进度判断直接依赖的3–5个核心字段（任务状态、完成比例、里程碑日期、阻塞项），为每个字段指定更新人和更新时点，并做一次抽样检查，确认当前缺失率和滞后情况。有了这个基线，人工校准才有可核对的输入；否则校准人面对的是残缺数据，只能凭经验推翻AI结论，修正理由也难以归因到具体字段。
如果团队数据基础很弱，可以先在单个迭代内并行运行：一边按字段清单维护数据，一边在里程碑到期前做校准，用校准记录反过来暴露哪些字段最需要优先治理。
里程碑粒度调整到什么程度，人工校准才不会变成负担？
判断标准是“每个里程碑都有可核对的完成标志，且单个迭代内的里程碑数量在团队能逐条校准的范围内”。粒度过粗时，AI在中期只能依赖完成比例推断，主观偏差会被放大；粒度过细时，校准点过多，核对容易流于形式。实际操作中，可以把里程碑设在可验收的交付单元上，例如一个功能模块通过评审或一个接口完成联调，而不是设在“开发中”这类过程状态上。里程碑数量没有统一数值，需要结合迭代长度和团队校准人力来定，并在季度复盘时根据校准覆盖率调整。
校准记录里最重要的字段是什么？只记“AI错了、人工改了”够不够？
不够。校准记录至少应包含校准时间、校准对象、AI原始判断、人工结论、修正理由和后续动作。其中修正理由是回流环节最有价值的信息：它决定了这次差异归入数据错误、口径差异还是判断逻辑偏差，进而决定治理动作是补字段校验、统一字段定义，还是调整触发条件。只记结论不记理由，下一轮同类失真会重复出现，校准就退化成每次改结论。记录可以放在项目空间或Wiki页面中，便于复盘时按归因分类统计。
校准发现AI判断错了，但数据看起来没问题，这种情况怎么处理？
这类情况通常归为判断逻辑偏差，处理重点不在补数据，而在调整AI判断所依赖的规则和表达。可以分三步：第一，确认AI是否掌握了完整的依赖关系和阻塞信息，如果依赖关系未在工作项中表达清楚，先补充依赖字段；第二，检查校准触发条件是否覆盖了这类误判场景，必要时把该场景加入校准清单作为重点核对项；第三，由AI工具管理方评估是否需要调整判断阈值或口径配置。如果同类误判反复出现，应在季度复盘时审视判断逻辑本身是否适合当前项目类型，而不是继续逐条人工修正。
ONES在这套治理与校准闭环里能承载哪些环节？
ONES可以作为字段维护、校准记录和规则沉淀的协作载体。ONES Assistant能理解项目、工作项、迭代和Wiki页面等真实工作上下文，并可把结果保存为工作项、Wiki页面等内容，团队可以把校准记录与规则变更沉淀在项目空间中，使回流动作有据可查；其基于权限体系执行任务，输出过程可追踪，便于复盘时回溯判断依据。需要说明的是，具体的字段校验规则、校准触发条件和归因分类仍需团队按自身项目管理实践定义，ONES承载的是这些规则的记录与协作过程。
