核验AI风险提示，需要把提示本身、原始项目数据、判断口径和人工复核记录放在一起对照，缺任何一类，结论都难以回溯。本文聚焦项目状态与风险识别场景，给出四类依据的取数清单、五步核验流程、角色分工、一个延期提示的取证示例，以及判定核验是否到位的检查项。
要点总览（TL;DR）
- 核验AI风险提示需要四类依据：提示自身信息、原始项目数据、判断口径、人工复核记录，四类齐备才能形成可回溯的结论。
- 核验按五步执行：取提示并登记、对照原始数据核实、套用判断口径、人工复核记录结论、回写处置状态，每步留下字段与责任人。
- 判断口径应在核验前书面约定风险分级规则、阈值、责任人与处置时限，核验中临时变更需单独记录原因与生效时间。
- 复核人宜独立于提示生成方，结论写明采纳或驳回的具体理由，避免只看提示摘要就签署。
- 核验完成的判定标准是依据可回溯、口径一致适用、复核独立、结论与处置已回写、理由具体，任一项不通过即视为未完成。
核验一份AI风险提示，先备齐哪几类依据
核验的目标是回答一个问题：这条提示所说的情况，在项目原始记录中是否成立，按事先约定的口径是否构成需要处置的风险。围绕这个目标，依据可以归为四类，收集时按类别逐项确认，避免只拿到提示文本就开始判断。
第一类是提示自身信息。需要记录提示来源（哪个工具、哪个分析场景）、触发条件（基于什么规则或数据变化产生）、生成时间、涉及的项目、工作项、迭代或里程碑。这类信息决定后续去哪些地方取数，也决定这条提示是否在有效期内。第二类是原始项目数据，包括任务状态与完成情况、进度与里程碑偏差、工作项之间的依赖关系、缺陷与阻塞记录、近期变更历史。原始数据是核验的事实基础，提示中的每个判断都应能在其中找到对应记录。
第三类是判断口径，即团队事先约定的风险分级规则、阈值设定、责任人与处置时限。例如进度偏差达到多少天算高风险、哪类缺陷密度需要升级处理、由谁在多久内响应。口径需要在核验前书面确定，核验时直接套用，避免边看数据边改标准。第四类是人工复核记录，包括复核人、复核时间、结论、采纳或驳回的理由，以及后续处置状态。这类记录让核验从个人判断变成可查证的管理动作。
| 依据类别 | 具体字段 | 取数位置 | 责任人 |
|---|---|---|---|
| 提示自身信息 | 提示来源、触发条件、生成时间、涉及项目/工作项/里程碑 | AI工具提示记录或通知 | 项目跟踪负责人 |
| 原始项目数据 | 任务状态、进度偏差、依赖关系、缺陷与阻塞记录、变更历史 | 项目管理工具中的工作项、迭代、里程碑记录 | 项目经理、技术负责人 |
| 判断口径 | 风险分级规则、阈值、责任人、处置时限 | 团队风险管理规范或项目计划附件 | 项目经理 |
| 复核记录 | 复核人、复核时间、结论、采纳/驳回理由、处置状态 | 复核记录表或工作项评论与状态字段 | 风险复核人 |
四类依据中，提示信息和原始数据解决“事实是什么”，判断口径解决“算不算风险”，复核记录解决“谁做了判断、依据什么、后续怎么处理”。收集阶段可以并行取数，但核验结论必须等四类都齐备后再形成。
五步核验流程：从收到提示到回写结论
核验按固定顺序执行，每一步都有明确的输入、动作、输出和完成标志。顺序的价值在于：先固定提示原文，再核对事实，再套口径，最后记录结论并回写，避免结论先行或证据后补。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 | 负责人 |
|---|---|---|---|---|---|
| 1. 取提示并登记 | AI风险提示原文 | 登记来源、触发条件、生成时间、涉及对象，保留原文快照 | 提示登记记录 | 关键字段填写完整，原文可查 | 项目跟踪负责人 |
| 2. 对照原始数据核实 | 提示登记记录、项目数据 | 逐项核对任务状态、进度、依赖、缺陷与变更记录，标注一致与不一致之处 | 事实核对表 | 提示中每个判断都有对应原始记录或明确标注无记录 | 项目经理、技术负责人 |
| 3. 套用判断口径 | 事实核对表、风险分级规则与阈值 | 按约定阈值判定风险等级，确认责任人与处置时限 | 风险等级判定结果 | 等级判定可引用具体规则条款和数值 | 项目经理 |
| 4. 人工复核并记录 | 事实核对表、等级判定结果 | 复核人独立判断，写明采纳或驳回及理由 | 复核结论记录 | 复核人签署，理由具体到证据或口径 | 风险复核人 |
| 5. 回写处置状态 | 复核结论 | 在工作项或风险台账中更新状态、责任人和计划完成时间，关联证据 | 处置状态与留痕记录 | 状态已更新，证据与结论可关联查询 | 风险责任人 |
第二步是核验中最耗时的环节，建议按提示涉及的对象逐条核对，而不是整体浏览。核对时同时记录“提示说的情况”和“原始记录显示的情况”，两者不一致的地方要单独标注，这类差异往往比提示本身更值得关注。第三步套用口径时，如果发现现有规则没有覆盖当前情形，应记录口径缺口并另行修订，本次核验仍按现行规则给出结论。
第五步的回写决定核验是否真正闭环。处置状态需要和证据关联，例如在工作项中更新状态并附上复核结论，或把提示登记记录、事实核对表、复核结论放在同一处可查的位置。ONES 的 AI 能力基于其权限体系执行知识问答和任务执行，输出过程可追踪、结果可审计；ONES Assistant 能够理解项目、工作项、迭代和 Wiki 页面等真实工作上下文，基于相关项目数据和团队知识回答问题。对于需要把核验结论落回工作项状态的团队，这类上下文关联可以减少在多个系统间搬运证据的动作。
角色分工与各环节交付物
核验悬空通常不是流程缺失，而是每个环节都有人“看过”，但没有人对具体交付物负责。把角色和交付物对应起来，交接时点明确，核验才有落点。
| 角色 | 主要职责 | 交付物 | 交接时点 |
|---|---|---|---|
| 项目经理 | 提供项目状态与进度依据，套用风险分级口径 | 事实核对表中的进度与里程碑部分、风险等级判定结果 | 收到提示登记记录后一个工作日内 |
| 技术负责人 | 确认技术类风险的原始记录，如缺陷、阻塞、依赖问题 | 缺陷与阻塞记录核对结果、技术判断说明 | 事实核对阶段结束前 |
| 风险复核人 | 独立判断提示是否成立，签署采纳或驳回结论 | 复核结论记录，含理由与引用证据 | 等级判定完成后 |
| AI工具维护方 | 说明提示触发条件与数据来源，解释提示生成逻辑 | 触发条件说明、数据来源说明 | 提示登记阶段或复核人提出疑问时 |
| 风险责任人 | 执行处置并回写状态 | 处置状态更新记录、后续跟踪计划 | 复核结论签署后按处置时限执行 |
复核人独立于提示生成方是分工中的关键约束。如果由维护AI工具的人同时签署复核结论，核验就变成用AI输出自证AI输出，证据链失去独立性。规模较小的团队可以由项目经理之外的人担任复核人，但需要保证复核人能接触到原始记录，而不是只看提示摘要。
一个核验示例：进度延期提示如何取证
以下为演示情景，用于说明取证与判断过程，不代表任何真实项目数据或实测结果。
某迭代进行到第二周，AI工具生成一条风险提示：“迭代X存在延期风险，当前完成率低于计划，涉及工作项A、B、C，建议关注依赖阻塞。”触发条件为迭代剩余时间与未完成工作项数量的比例超过设定值。第一步登记提示原文、生成时间、涉及迭代与工作项，保留快照。
第二步调取原始数据：工作项A状态为进行中，实际开始时间晚于计划三天；工作项B处于阻塞状态，阻塞原因是等待外部接口联调，阻塞记录已挂在工作项下；工作项C已完成，但完成时间晚于里程碑节点两天。迭代里程碑偏差记录显示当前进度落后计划约15%。依赖关系显示B被外部团队的工作项阻塞，该依赖在迭代计划中已登记。
第三步套用口径：团队规则规定迭代进度偏差超过10%且存在未解除阻塞时，判定为中级风险，责任人為项目经理，处置时限为两个工作日内给出调整方案。按此规则，该提示成立，等级为中级。
第四步复核：复核人核对事实核对表后采纳提示，理由写明“进度偏差15%超过10%阈值，工作项B阻塞记录完整且未解除”，同时补充一条意见：工作项A的启动延迟原因未在记录中说明，建议项目经理补充。第五步回写：项目经理在两个工作日内提交迭代调整方案，更新工作项B的阻塞跟进状态，风险台账中记录处置状态为“处理中”，并关联提示登记记录与复核结论。
这个示例体现的可迁移规律有三点：提示中的每个判断都要落到具体工作项和记录上；等级判定引用规则条款和数值，而不是凭印象；复核结论既包含采纳决定，也包含对证据缺口的补充要求。
核验完成的检查项与常见失效点
判断一次核验是否做到位，可以逐项检查以下内容。任何一项不通过，核验结论都应视为未完成，需要补充证据或重新复核。
| 检查项 | 通过标准 | 证据 | 阻断条件 |
|---|---|---|---|
| 依据可回溯 | 提示中每个判断都能对应到原始记录或明确标注无记录 | 事实核对表、原始工作项记录 | 存在无法对应原始数据的判断且未标注 |
| 口径事先约定且一致适用 | 等级判定引用核验前已生效的规则与阈值 | 风险分级规则版本、判定记录 | 核验过程中临时变更阈值且无变更记录 |
| 复核人独立 | 复核人独立于提示生成方，能接触原始记录 | 复核签署记录、角色说明 | 由提示生成方单独签署结论 |
| 结论与处置回写 | 复核结论、处置状态、责任人、时限均已更新并可关联查询 | 工作项状态记录、风险台账 | 只有结论记录，处置状态未更新 |
| 理由具体 | 采纳或驳回理由指向具体证据或口径条款 | 复核结论记录 | 理由仅为“同意”或“不成立”等无依据表述 |
常见失效点集中在三处。一是只记录结论不留证据，复核记录写着“已确认”，但找不到对应的原始数据，事后无法解释判断依据。二是口径临时变更，核验中发现按现行阈值不构成风险，于是调整阈值使提示成立，这类变更如果没有单独的变更原因和生效时间记录，会破坏口径的一致性。三是复核流于形式，复核人只看提示摘要就签署结论，没有打开原始工作项记录，导致提示中的错误判断被原样采纳。
把检查项固化为核验记录的固定字段，可以让每次核验都留下相同结构的证据。对于使用 ONES 的团队，ONES Assistant 可基于项目、缺陷与资源数据提前识别风险，围绕项目进展、工时投入、缺陷分布和资源配置生成进展分析、根因判断和资源合理性建议；核验时可以将提示涉及的工作项、迭代和变更记录作为原始数据来源，把复核结论和处置状态回写到对应工作项，使证据与结论在同一处可查。
常见问题
团队还没有书面的风险分级规则，能先做核验吗？
可以先核验事实，但等级判定会缺少稳定依据。建议先补一份最小口径：列出进度偏差、阻塞未解除、缺陷集中等常见情形对应的等级和处置时限，由项目经理确认后生效。口径生效前收到的提示，可以先完成提示登记和事实核对，等口径确定后再判定等级，并在复核记录中注明口径生效时间，避免事后追溯时说不清依据。
AI提示与原始记录不一致时，核验结论应该怎么写？
以原始记录为准，同时把差异写进复核结论。事实核对表中分别记录“提示所述情况”和“原始记录显示情况”，不一致处单独标注，例如提示称某工作项延期，但记录显示计划变更已审批。复核结论应说明差异原因，并判断提示是否仍然成立。若差异源于数据同步延迟或字段口径不同，可请AI工具维护方说明触发条件与数据来源，把解释一并留档。
小团队人手有限，复核人能否由项目经理兼任？
可以由项目经理之外的人担任复核人，重点是复核人能够接触原始记录并独立判断。若团队规模确实很小，至少保证签署结论的人不是配置提示规则或维护AI工具的人，并在记录中写明角色关系。复核时打开原始工作项、迭代和阻塞记录逐项核对，避免只依据提示摘要签署。角色重叠时，在复核记录中注明，便于后续审计时理解判断链路。
核验记录需要保存多久，保存在哪里比较合适？
保存期限由团队的风险管理规范和项目周期决定，通常至少覆盖项目结项后的复盘与审计窗口。保存位置建议与项目数据同处可查，例如把提示登记记录、事实核对表、复核结论关联到对应工作项或风险台账，而不是散落在个人文档中。这样处置状态更新后，证据与结论仍能一起查询。使用 ONES 的团队可将复核结论和处置状态回写到对应工作项，ONES 的 AI 能力基于其权限体系执行，输出过程可追踪、结果可审计。
提示被驳回后，还需要继续跟踪吗？
需要留下驳回理由和后续观察安排。驳回意味着按当前证据和口径不构成需处置的风险，但触发提示的条件可能仍然存在，例如进度偏差未达阈值但趋势在扩大。复核结论中写明驳回依据，并在风险台账中标注观察期限或复查时点，到期后重新取数核对。这样既避免对已驳回提示反复处置，也防止真实风险因一次驳回而被忽略。
