核验AI风险提示，核心是让每条提示都能追溯到具体工作项、时间节点、负责人和原始记录，再判断它是否成立。依据可分为数据、规则、责任、过程四类，缺任一类就只能作为待核实线索。若团队在ONES中管理项目，工作项状态、里程碑基线与处置记录可在同一处留存，便于核验时调取。
要点总览（TL;DR）
- 核验AI风险提示需要四类依据：数据依据（任务状态、计划与实际日期、依赖、阻塞与缺陷记录）、规则依据（里程碑基线、延期判定口径、风险分级标准）、责任依据（提出人、事实确认人、处置负责人）、过程依据（提示生成时间、核验结论、处置动作与关闭记录）。
- 核验按六步执行：登记提示、定位原始数据、对照规则判定、责任人确认、给出结论、触发处置与关闭；每步都要有输入、输出和完成标志。
- 提出、确认、决策、关闭四类职责应保持可区分，交付物依次为提示记录、确认说明、核验结论、处置记录，构成完整证据链。
- 四类依据缺任一类时，提示降级为待核实线索，先补证据再判断，避免线索被直接当作结论。
- 判断机制是否可用，重点看提示能否追溯到原始工作项、判定口径是否书面统一、确认与处置是否留痕、抽查与复查是否落实。
核验一条AI风险提示，先看哪四类依据
一条AI风险提示要被采信，需要同时具备四类依据。它们分别回答四个问题：事实是什么、按什么标准判断、由谁确认、核验过程是否留痕。四类依据齐备，提示才能进入风险决策；缺少任一类，应降级为待核实线索，先补证据再判断。
四类依据的对照说明
| 依据类别 | 回答的问题 | 具体内容 | 常见来源 |
|---|---|---|---|
| 数据依据 | 事实是什么 | 任务状态、计划与实际日期、依赖关系、阻塞记录、缺陷记录 | 任务详情、迭代记录、里程碑视图、缺陷库 |
| 规则依据 | 按什么标准判断 | 里程碑基线、延期判定口径、风险分级标准 | 项目计划文件、团队约定的管理规则 |
| 责任依据 | 由谁确认和处置 | 风险提出人、事实确认人、处置负责人 | 工作项负责人字段、风险登记记录 |
| 过程依据 | 核验是否留痕 | 提示生成时间、核验结论、处置动作、关闭记录 | 风险台账、评审记录、工作项变更历史 |
数据依据是核验的起点。AI提示通常指向某个任务延期、依赖阻塞或缺陷集中，核验时要回到原始工作项，核对状态、日期和关联记录，而不是只看提示文本。规则依据决定判断口径：同一个“延期三天”，在基线宽松和基线严格的项目中结论可能不同，因此延期判定口径和风险分级标准需要在核验前书面统一。责任依据解决“谁来认账”：提示涉及的工作项负责人确认事实，风险责任人决定处置。过程依据保证可复查：提示何时生成、谁核验、结论是什么、采取了什么动作、何时关闭，都要有记录。
缺项时的处理原则
四类依据并非总能一次齐备。缺数据依据时，提示只能作为线索，先补查工作项记录；缺规则依据时，先明确判定口径再下结论，避免同一提示在不同人手中得出不同结果；缺责任依据时，核验结论不具备约束力，需先指定确认人；缺过程依据时，即使结论正确也难以复查，应补记核验结论与处置动作。把缺项提示统一标记为“待核实”，并设定补证时限，可以防止线索被直接当作结论使用。
从提示到结论：核验的操作步骤
核验可以拆成六步。每一步都有明确输入、动作、输出和完成标志，便于不同角色按同一顺序执行，也便于事后复查。
第一步：接收提示并登记
输入是AI生成的风险提示。动作是登记提示来源、生成时间、涉及的工作项和初步风险描述，形成一条可追踪的核验记录。输出是提示登记条目。完成标志是每条提示都有唯一编号，并能关联到具体工作项。
第二步：定位原始数据
输入是登记条目中的工作项信息。动作是回到任务、迭代和里程碑记录，核对当前状态、计划完成日期、实际进展、依赖任务状态以及相关阻塞和缺陷记录。输出是一组原始数据摘录。完成标志是核验人能够说明提示所指事实在系统中的具体位置。
第三步：对照规则判定
输入是原始数据和团队书面规则。动作是按延期判定口径计算偏差，按风险分级标准判断影响程度，确认提示描述的风险是否达到需要处置的级别。输出是初步判定意见。完成标志是判定意见引用了具体规则条款或口径说明，而非凭经验估计。
第四步：责任人确认
输入是初步判定意见和原始数据。动作是由工作项负责人确认事实是否属实，说明延期或阻塞的原因、影响范围和已采取的措施；如有异议，补充说明并附证据。输出是负责人确认说明。完成标志是确认说明有明确结论，并记录确认人和确认时间。
第五步：给出核验结论
输入是原始数据、规则判定和负责人确认。动作是形成核验结论，明确写为成立、不成立或证据不足，并逐项写明所依据的数据、规则和责任确认。输出是核验结论记录。完成标志是结论可被第三方按记录复现。
第六步：触发处置与关闭
输入是成立的核验结论。动作是明确处置动作、处置负责人和复查时间，跟踪处置进展，到期复查后关闭提示。输出是处置记录和关闭记录。完成标志是处置动作有结果，复查已完成，关闭原因有记录。结论为不成立或证据不足的提示，同样记录原因后关闭或转入观察。
角色分工与各环节交付物
核验责任需要落到具体角色，避免提示生成后无人确认、结论无人负责。以下分工适用于一般项目跟踪场景，团队可根据规模合并角色，但提出、确认、决策、关闭四类职责应保持可区分。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 风险提示生成方（工具或分析角色） | 基于项目数据生成风险提示，标明涉及工作项和提示时间 | 提示记录 |
| 工作项负责人 | 核对事实，确认或说明异议，提供原因与影响范围 | 确认说明 |
| 项目经理或风险责任人 | 依据规则判定风险等级，决定处置动作和负责人 | 核验结论、处置决定 |
| 复核人/评审角色 | 抽查核验记录，确认处置完成情况，执行关闭 | 抽查记录、关闭确认 |
提示生成方的职责边界在于提供线索，不替责任人下结论。工作项负责人对事实负责，确认说明应包含原因和影响范围，便于后续判断处置优先级。项目经理或风险责任人承担判定与决策职责，其结论需引用规则依据。复核角色通过抽查发现核验走过场、结论无依据等问题，并在处置完成后确认关闭。四类交付物——提示记录、确认说明、核验结论、处置记录——构成一条完整的证据链，任一环节缺失都会削弱提示的可信度。
在ONES中，AI助手可基于项目、工作项、迭代和Wiki页面等真实工作上下文生成进展分析与风险判断，并将结果保存为工作项或Wiki页面等内容，核验所需的原始记录与后续处置可以在同一套工作项和页面中衔接。具体到风险提示的字段结构、规则配置和关闭流程，需结合团队实际配置确认。
示例：一条延期风险提示的完整核验
以下为演示情景，用于说明四类依据如何落到一条提示的核验过程，不代表真实项目数据。
示例背景
某迭代内一项接口开发任务临近里程碑仍未完成。AI提示该任务存在延期风险，可能影响后续联调。提示登记后进入核验。
数据依据核对
核验人回到任务记录，确认任务状态为“进行中”，计划完成日期为本周五，当前已过计划日期两天；依赖该任务的下游联调任务状态为“未开始”；任务下有一条阻塞记录，说明等待外部接口文档。数据依据指向延期事实成立，且影响下游任务。
规则依据对照
团队书面口径规定：任务超过计划完成日期一个工作日即判定为延期；影响里程碑关键路径的延期定为中风险以上。按此口径，该任务已构成延期，且位于关键路径，初步判定为中风险。
责任依据确认
工作项负责人确认延期属实，说明原因是外部接口文档延迟，影响范围为下游联调任务可能顺延两到三天，已采取的措施是每日跟进文档进度并准备替代方案。确认说明记录了确认人和时间。
过程依据与关闭
核验结论记录为“成立，中风险”，依据列明任务日期、阻塞记录和规则条款。处置决定为：由负责人跟进文档并在两天内更新进展，项目经理协调下游任务排期，复查时间定在两天后。复查时文档已到位，任务恢复推进，提示关闭并记录关闭原因。
证据不足时的降级处理
若该提示只有AI描述而任务记录中缺少计划日期或依赖关系，核验人应将提示标记为“证据不足、待核实”，先补查任务字段和依赖配置，暂不进入处置决策。补证后仍无法确认的，记录原因后关闭，并作为数据质量问题的线索留存。
完成检查：核验机制是否可用的判断项
核验机制是否真正运转，可以用以下清单逐项检查。检查对象是机制本身，而非单条提示的结论。
- 每条风险提示是否可追溯到原始工作项与记录：随机抽取若干提示，能否在系统中找到对应任务、日期和关联记录。
- 延期与风险分级口径是否书面统一：团队是否有成文口径，不同核验人对同一情形能否得出一致判断。
- 责任人确认环节是否留痕：确认说明是否记录确认人、时间和结论，异议是否有补充证据。
- 核验结论与处置动作是否可查：结论是否写明依据，处置是否有负责人和完成结果。
- 抽查机制与复查时间是否落实：是否有定期抽查记录，处置到期是否按复查时间执行。
- 误报与漏报是否有处理与复盘方式：误报是否记录原因并反馈给提示生成环节，漏报是否在事后复盘中被识别并补充规则或数据检查。
清单中任何一项长期无法满足，说明核验链条存在断点。优先补齐追溯和留痕两项，再逐步统一判定口径与抽查节奏，核验机制才能稳定支撑风险决策。
常见问题
AI风险提示的核验结论为“证据不足”时，应该关闭还是继续挂起？
建议先设定补证时限，在时限内保持“待核实”状态，由核验人补查工作项字段、依赖配置或相关记录。补证后能确认事实的，转入正常判定；补证后仍无法确认的，记录原因后关闭，并把缺失的数据项作为数据质量问题的线索留存，供后续完善任务记录时参考。关键是把关闭原因写清楚，避免同一问题反复生成提示又反复无果关闭。
团队规模较小、角色合并时，核验分工怎么保留？
角色可以合并，职责不宜合并到无法区分。至少保证“提出提示的人”和“确认事实的人”不是同一环节，处置决策与关闭确认有独立记录。例如项目经理可以同时承担判定与处置决策，但工作项负责人对事实的确认仍需单独留痕；复核可以由上一级管理者或定期交叉抽查承担。合并后要在团队规则中写明谁在什么情况下代行哪项职责，避免核验责任悬空。
延期判定口径应该由谁制定，多久复核一次？
延期判定口径和风险分级标准通常由项目管理负责人牵头制定，与各工作项负责人对齐后书面发布。口径应写明计算方式（例如超过计划完成日期几个工作日算延期）、关键路径的认定方式以及风险等级的划分条件。建议在项目阶段切换或连续出现判定争议时复核一次，把新出现的例外情形补进口径，保持不同核验人对同一情形能得出一致判断。
误报较多时，应该调整提示生成环节还是收紧核验标准？
先分类记录误报原因：是数据本身滞后或不完整，是判定口径过宽，还是提示把正常波动识别为风险。数据问题优先补任务字段与更新习惯；口径问题调整延期与分级标准；提示逻辑问题反馈给提示生成环节。核验标准不宜一味收紧，否则可能把真实风险也挡在门外。误报与漏报都应进入定期复盘，作为调整规则和检查数据质量的输入。
在ONES中落地这套核验流程，哪些环节可以直接衔接，哪些需要团队自行约定？
ONES Assistant 可基于项目、工作项、迭代和 Wiki 页面等真实工作上下文生成进展分析与风险判断，并将结果保存为工作项或 Wiki 页面等内容，核验所需的原始记录与后续处置可以在同一套工作项和页面中衔接。风险提示的具体字段结构、延期与分级规则如何配置、责任人确认与关闭流程如何设置，需要结合团队实际配置确认，建议在试点阶段先用少量提示跑通全流程再推广。
