AI生成的项目建议读起来往往条理清楚，真正容易出问题的地方在建议背后的事实和口径：数据截到哪一天、进度百分比怎么算、延期有没有核对关键路径、风险有没有落到责任人。这份检查清单面向项目经理、技术负责人和业务负责人，按输入事实、判断依据、风险登记、建议可执行性和结论边界逐项核对，并标出未通过就不能放行的阻断项。
要点总览（TL;DR）
- 复核AI项目建议，先查事实再谈结论：数据截止时间、统计口径、项目范围三项缺失，后续判断都不可靠。
- 按输入、判断、风险、建议、输出五个阶段逐项核对，重点看延期是否比对关键路径、风险是否落到责任人和时点。
- 每项检查写成可观察的通过标准并配证据，口头说明不能替代任务记录、里程碑状态或风险登记。
- 数据范围不明、进度结论无依据、重大风险无责任人、建议不可执行属于阻断项，未通过不能作为决策依据。
- 复核记录写明复核人、结论、未通过原因和补证期限，与当次AI建议版本一并留存，便于追溯。
谁在什么时点复核AI项目建议
复核对象是AI生成的项目状态总结、进度判断、延期识别、风险提示和管理建议，不包含报告成稿润色，也不涉及团队效能诊断与资源盘点。复核范围限定在项目状态与风险两类结论，超出这个范围的内容另行处理。
触发时点决定复核的严格程度。周会前的复核以更新事实为主，确认本周状态总结与任务记录一致；里程碑评审前要核对里程碑完成度、交付物状态和关键路径；风险升级前则重点检查风险的影响范围、责任人和应对动作是否齐全。三个时点都应在会议材料发出之前完成，避免会上才发现数据对不上。
| 复核角色 | 主要时点 | 复核重点 |
|---|---|---|
| 项目经理 | 周会前、里程碑评审前 | 数据范围、进度口径、延期识别、建议可执行性 |
| 技术负责人 | 里程碑评审前、风险升级前 | 技术任务完成依据、关键路径判断、技术风险影响 |
| 业务负责人 | 风险升级前、对外承诺前 | 业务影响判断、风险等级、建议是否符合业务优先级 |
角色分工不必每次全员到场。周会前可由项目经理完成全量核对，技术负责人和业务负责人只处理被标记为存疑或升级的条目；里程碑评审和风险升级则要求对应角色对相关条目签字确认。
分阶段检查项：从输入事实到建议输出
把复核拆成输入、判断、风险、建议、输出五个阶段，每个阶段回答一个具体问题，逐项打勾即可。这样做的目的是让复核有固定顺序，避免一上来就讨论建议好坏，却忽略了建议所依据的数据本身是否成立。
输入阶段：数据来源、时间范围、项目范围是否明确
- 状态总结引用的任务、缺陷、工时数据能否追溯到具体系统记录，而非口头同步。
- 数据截止时间是否写明，与本次会议或评审的时间差是否在可接受范围内。
- 项目范围是否与立项范围一致，是否混入了其他项目或已关闭工作项的数据。
- 统计口径是否统一，例如完成率按工作项数量还是按工时计算，延期按计划完成日还是按承诺日判断。
判断阶段：进度结论是否有依据，延期识别是否核对关键路径
- 每条进度结论能否对应到具体工作项状态或里程碑记录，而不是只有一句“整体进展顺利”。
- 延期识别是否核对了关键路径，非关键路径上的延迟是否被误判为整体延期，或关键路径延迟被漏掉。
- 进度百分比的计算方式是否前后一致，与上期数据相比是否出现无解释的跳变。
- 已完成事项是否有验收或关闭记录支撑，避免把“已提交”当成“已完成”。
风险阶段：风险是否标注影响、概率、责任人和应对动作
- 每条风险是否写明影响对象和影响程度，例如影响哪个里程碑、哪项交付或哪个外部依赖。
- 是否给出发生概率或风险等级，等级判断依据是否可说明。
- 是否指定风险责任人和应对动作，应对动作是否有完成时点。
- 已识别风险是否与风险登记记录一致，新增风险是否已登记而非只出现在总结文字里。
建议阶段：建议是否可执行、是否有负责人和完成时点
- 每条管理建议是否对应一个具体动作，例如调整排期、补充人力、拆分任务或增加评审。
- 建议是否指定执行负责人和完成时点，能否转化为可跟踪的工作项。
- 建议所依赖的前提是否写明，例如“若下周接口联调完成，则……”。
- 建议与风险是否对应，重大风险是否有对应的处置建议，而不是只提示不处置。
输出阶段：结论是否区分事实与推断、是否标注不确定项
- 事实性描述与推断性判断是否分开表述，推断是否有依据说明。
- 数据缺失、口径存疑或无法核实的内容是否明确标注为待确认。
- 结论边界是否清楚，是否把局部数据推广成了整体结论。
- 对外使用的材料是否经过对应业务负责人确认。
每项检查的通过标准与证据
检查项要能判断“过”还是“不过”，写法上应包含可观察的对象和明确的判定条件。“建议加强沟通”这类表述无法核验，应改成“每条重大风险均有责任人和应对完成时点”。下面按阶段给出通过标准与证据对照。
| 检查项 | 通过标准 | 所需证据 | 检查时点 |
|---|---|---|---|
| 数据来源可追溯 | 状态总结中每类数据均能指向具体系统记录或文档 | 任务记录、缺陷列表、工时记录 | 周会前 |
| 时间范围明确 | 写明数据截止时间，且与评审时点差距有说明 | 数据导出记录或系统查询截图 | 周会前 |
| 项目范围一致 | 统计范围与立项范围一致，排除项有说明 | 项目范围说明、工作项清单 | 周会前 |
| 进度结论有依据 | 每条进度结论可对应到工作项状态或里程碑记录 | 里程碑状态、任务完成记录 | 周会前、里程碑评审前 |
| 延期识别核对关键路径 | 延期清单与关键路径比对过，误判和漏判均有说明 | 计划排期、依赖关系、关键路径标注 | 里程碑评审前 |
| 风险要素齐全 | 每条风险有影响、等级、责任人、应对动作和时点 | 风险登记表、风险评审纪要 | 风险升级前 |
| 建议可执行 | 每条建议有动作、负责人和完成时点，可转为工作项 | 建议清单、工作项创建记录 | 周会前、里程碑评审前 |
| 事实与推断分开 | 推断性结论有依据说明，不确定项已标注 | 状态总结原文、批注记录 | 材料发出前 |
证据应留在团队共同可访问的位置，例如任务系统、风险登记表或评审纪要，并在复核时点当场核对，避免事后补录。确实无法取得证据的条目，处理方式只有两种：标注为待确认并指定补证人和期限，或直接判定不通过。用口头说明替代证据的条目，按未通过处理。
在ONES中，项目进展、工时投入、缺陷分布和资源配置可以作为AI生成进展分析与风险提示的数据上下文，ONES Assistant能够理解项目、工作项、迭代和Wiki页面等真实工作上下文来回答问题。复核时可以直接对照系统中的任务状态、里程碑记录和风险登记，核对AI结论是否与记录一致；基于ONES权限体系，输出过程可追踪、结果可审计，便于把复核意见和证据留在同一处。
证据与负责人如何分配
每项检查需要两类角色：提供证据的人和判定是否通过的人。两者分开，可以避免“自己证明自己”。证据提供人通常是离数据最近的角色，判定人则对结论负责。
| 检查项类别 | 证据提供人 | 判定人 |
|---|---|---|
| 任务与进度数据 | 任务负责人 | 项目经理 |
| 里程碑与交付物状态 | 项目经理 | 技术负责人 |
| 风险登记与应对 | 风险责任人 | 项目经理、业务负责人 |
| 业务影响与优先级 | 业务负责人 | 业务负责人 |
| 结论边界与对外口径 | 项目经理 | 业务负责人 |
争议项的处理路径要事先约定：判定人与证据提供人对结论不一致时，先由项目经理组织一次短会核对原始记录；仍无法达成一致的，升级到业务负责人裁定，并在复核记录中写明分歧点和裁定依据。涉及对外承诺的条目，未经业务负责人确认不得放行。
复核记录至少包含：复核日期、复核人、检查项结论、未通过原因、补证人和期限、升级情况。记录与当次AI建议版本一并留存，便于下次复核对照，也便于追溯某条结论当时依据了哪些数据。
阻断项与完成条件
并非所有检查项都同等重要。以下条目未通过时，AI建议不能作为会议或评审的决策依据，必须先处理：
- 数据范围不明：数据截止时间、统计口径或项目范围缺失，导致结论无法判断适用范围。
- 进度结论无依据：进度判断找不到对应的工作项状态或里程碑记录。
- 重大风险未标注责任人：影响里程碑或对外交付的风险没有责任人和应对动作。
- 建议不可执行：管理建议没有具体动作、负责人或完成时点，无法转为跟踪项。
阻断项的处理方式有两种：退回补充，由证据提供人在约定期限内补齐后重新复核；或标注为待确认，在材料中明确写出该结论暂不作为决策依据。两种方式都要记录处理人和处理时间，不能以“会上口头说明”代替。
整体复核完成的条件是：所有阻断项通过或有明确的待确认标注，非阻断项均有处理结论（通过、限期补证或不适用）。复核主持人据此给出放行、有条件放行或不放行三种结论之一，并写入复核记录。有条件放行时，需列明剩余待办和复查时点。
阻断项的范围可以按项目重要程度调整。对外承诺类和高风险项目宜从严执行全部阻断项；内部小迭代可以合并部分检查项，但数据范围和重大风险责任人两项建议始终保留。ONES的AI研发管理方案强调从汇报驱动转向风险驱动，帮助项目经理提前识别延期、资源不足和质量风险，这类风险提示同样需要经过上述复核才能进入决策。
常见问题
AI给出的进度百分比和上期相比跳变很大，复核时怎么处理？
先确认两期数据的统计口径是否一致，例如完成率按工作项数量还是按工时计算、延期按计划完成日还是承诺日判断。口径一致而数值仍出现无解释的跳变，应要求提供本期新增完成项的关闭或验收记录，逐条核对后再采信。口径发生变化时，在材料中注明变化原因和换算方式，避免把口径调整误读为进度变化。
关键路径判断依赖排期和依赖关系，团队没有维护这些数据怎么办？
复核时可以退一步处理：由技术负责人对本期延期事项逐条说明是否影响里程碑或对外交付，并在复核记录中写明判断依据。同时把“补齐依赖关系”作为限期补证项，指定负责人和期限。在依赖关系补齐之前，延期识别结论按待确认处理，不作为放行依据。
内部小迭代也要执行全部阻断项吗？
阻断项范围可以按项目重要程度调整。对外承诺类和高风险项目宜从严执行全部阻断项；内部小迭代可以合并部分检查项，但数据范围和重大风险责任人两项建议始终保留，因为这两项缺失会让结论无法判断适用范围，也无法落实处置。
复核发现AI建议与系统记录不一致，应该改建议还是改记录？
先判断哪一方反映真实情况。系统记录滞后于实际进展时，由任务负责人更新记录并说明更新时点；AI建议推断有误时，在复核记录中标注该条结论不采信及原因。两种情况都要留下处理记录，避免下次复核时再次出现同一分歧。
复核记录需要包含哪些内容，保存在哪里？
复核记录至少包含复核日期、复核人、各检查项结论、未通过原因、补证人和期限、升级情况，以及放行、有条件放行或不放行的最终结论。记录与当次AI建议版本一并保存在团队共同可访问的位置，例如任务系统、风险登记表或评审纪要，便于下次复核对照和事后追溯。
