AI项目风险识别要建立在可追溯的项目事实之上，主要依据四类输入：计划与基线、过程执行数据、质量与验证证据、外部与组织约束。把这些依据按统一字段结构化，明确采集频率、责任人和判定阈值，AI才能给出可复核的风险信号。本文给出依据框架、字段清单、操作步骤与完成检查，并说明如何借助ONES承载工作项状态与风险记录。
要点总览（TL;DR）
- AI项目风险识别的依据分为四类：计划与基线、过程执行数据、质量与验证证据、外部与组织约束，每类依据对应不同的风险问题。
- 依据要落到可填写的字段，每个字段明确数据来源、采集频率和唯一责任人，才能支撑阈值判断。
- 从依据到风险结论分五步：核对依据完整性与时效、设定阈值、AI生成候选信号、责任人复核登记、持续跟踪状态变化。
- AI输出定位为候选风险信号，正式风险由项目经理、技术负责人和质量角色分别复核确认，复核人与采集人尽量分离。
- 依据体系是否可用，以信号能否追溯到原始记录、风险是否有复核记录、阈值是否落地作为检查标准。
风险识别依据分几类，各自回答什么问题
风险识别的依据可以按“计划怎么定、执行怎么样、质量过不过、外部变没变”四个方向划分。四类依据各自回答不同的风险问题，合在一起才能覆盖项目的主要不确定性。分类的作用是让采集有边界：每类依据对应一组可查证的数据源，避免凭印象讨论风险。
| 依据类别 | 回答的典型风险问题 | 常见数据源 |
|---|---|---|
| 计划与基线 | 范围是否清晰、里程碑是否可行、依赖是否落实、资源是否匹配 | 项目计划、范围说明、里程碑表、依赖清单、资源与预算表 |
| 过程执行数据 | 进度是否偏离、任务是否长期阻塞、变更是否频繁、返工是否增多 | 任务状态记录、进度报表、阻塞记录、变更单 |
| 质量与验证证据 | 缺陷是否集中、测试是否通过、评审是否闭环、验收是否达标 | 缺陷库、测试报告、评审记录、验收结论 |
| 外部与组织约束 | 合规节点是否临近、供应商是否按期交付、关键人员是否稳定 | 合规日历、供应商交付记录、人员变动通知 |
四类依据要满足两个基本要求。一是可追溯：每条风险信号都能指回具体的任务、缺陷、文档或记录，而不是一段概括性描述。二是可复核：依据的采集时间、采集人和原始数值保留完整，复核人能够独立判断信号是否成立。缺少这两点，AI输出的内容只能作为讨论素材，无法进入正式风险台账。
四类依据之间存在关联。例如计划基线中的里程碑是判断进度偏差的参照，执行数据中的偏差只有对照基线才有意义；质量证据中的缺陷密度也需要结合范围与测试覆盖来解读。建立分类框架时，应同时标注依据之间的引用关系，避免各类数据各自孤立。
每类依据要采集哪些字段
分类框架落到执行层，需要变成可填写的字段清单。字段设计的原则是：每个字段有明确含义、固定来源、采集频率和责任人，能直接支撑阈值判断。以下字段清单可作为起步模板，团队可按项目规模裁剪。
计划与基线字段
- 范围条目及版本：记录需求或交付物清单的当前版本，来源为需求文档或范围说明，范围变更时更新，责任人为项目经理。
- 里程碑名称、计划日期、完成标准：来源为项目计划，立项时建立、每周核对，责任人为项目经理。
- 依赖关系：前置任务、外部依赖方、约定交付时间，来源为依赖清单，每周更新，责任人为项目经理与相关接口人。
- 资源与预算：计划人力投入、关键角色到位情况、预算额度与已用比例，来源为资源计划与财务记录，每月更新，责任人为项目经理。
过程执行数据字段
- 任务状态与完成比例：来源为任务管理工具中的工作项状态，每日或每周采集，责任人为各任务负责人。
- 进度偏差：实际完成量与基线计划的差值，按里程碑或迭代计算，每周采集，责任人为项目经理。
- 阻塞时长：任务处于阻塞状态的持续天数及阻塞原因，来源为阻塞记录，每日更新，责任人为任务负责人。
- 变更次数：范围、计划、需求的变更单数量及影响范围，来源为变更记录，每次变更时登记，责任人为项目经理。
质量与验证证据字段
- 缺陷密度：单位模块或单位工作量内的缺陷数量，来源为缺陷库，每周统计，责任人为质量角色。
- 返工情况：返工任务数、返工工时占比，来源为任务记录与工时记录，每周统计，责任人为技术负责人。
- 测试与评审结论：用例通过率、遗留缺陷等级、评审意见闭环情况，来源为测试报告与评审记录，每个测试或评审节点更新，责任人为质量角色。
外部与组织约束字段
- 合规节点：适用的合规要求、对应检查时间、当前准备状态，来源为合规日历，每月核对，责任人为项目经理或合规接口人。
- 供应商交付：约定交付物、交付日期、实际交付状态，来源为采购或合作记录，按交付节点更新，责任人为采购或项目接口人。
- 人员变动：关键角色在岗情况、计划离岗或交接安排，来源为人员安排记录，变动发生时登记，责任人为项目经理。
字段清单建议以一张总表维护，列出字段名、所属类别、数据来源、采集频率、责任人和判定用途。字段一旦确定，采集动作就变成例行工作，AI的输入也保持稳定口径。字段口径调整时保留历史版本，便于回溯此前的风险判断依据。
从依据到风险信号的操作步骤
有了字段和采集机制，下一步是把依据转化为可复核的风险结论。这个过程分五步，每步都有明确的输入、动作、输出和完成标志，AI在其中承担汇总与候选信号生成，人工承担确认责任。
步骤一：确认依据完整性与时效
输入是本期应采集的字段清单和实际采集记录。动作是逐项核对字段是否齐全、采集时间是否在有效期内、关键字段是否有缺失或异常空值。输出是一份依据完整性说明，标注缺失项和过期项。完成标志是缺失与过期项已列明，并明确补采责任人和补采时间。依据不完整时，后续信号需要标注置信度限制。
步骤二：设定偏差与异常判定阈值
输入是历史项目数据、基线计划和团队可接受的风险偏好。动作是为关键字段设定阈值，例如进度偏差超过计划工期的某个比例、任务阻塞超过约定天数、缺陷密度超过历史均值的一定幅度、变更次数在迭代内超过约定上限。输出是一份阈值表，写明字段、阈值、比较方式和触发后的处理动作。完成标志是每个用于风险判断的字段都有对应阈值，且阈值经过项目负责人确认。
步骤三：由AI汇总生成候选风险信号
输入是结构化后的依据数据和阈值表。动作是让AI按阈值比对字段值，识别超出阈值的组合情况，并生成候选风险信号，每条信号包含涉及字段、当前值、阈值、可能影响的里程碑或交付物，以及指向原始记录的引用。输出是候选风险信号清单。完成标志是每条信号都能追溯到具体依据记录，且信号描述包含事实数据而非笼统判断。
步骤四：责任人复核并登记为正式风险
输入是候选风险信号清单。动作是由对应责任人核对原始依据，判断信号是否成立、影响程度如何、是否需要采取应对措施，确认后登记为正式风险，记录风险描述、触发依据、影响评估、应对措施和责任人。输出是更新后的风险台账。完成标志是每条候选信号都有复核结论，正式风险均关联原始依据链接。
步骤五：跟踪信号变化并更新风险状态
输入是风险台账和后续采集的依据数据。动作是定期重新比对相关字段，判断风险是缓解、持续还是升级，并同步更新风险状态和应对措施进展。输出是风险状态更新记录。完成标志是每条开放风险都有最近一次复核时间和状态说明。这一步让风险识别从一次性动作变成持续机制。
角色分工与各环节交付物
依据体系能否运转，取决于每个环节是否有人认领。AI输出定位为候选信号，正式风险结论由人确认，这一边界需要在分工中写清楚。
| 角色 | 主要职责 | 在采集、复核、登记环节的交付物 |
|---|---|---|
| 项目经理 | 维护计划基线，组织阈值设定，对风险台账整体负责 | 基线版本、阈值表、风险台账、风险状态更新记录 |
| 技术负责人 | 提供执行与返工数据，复核技术类风险信号 | 任务与阻塞记录、返工统计、技术风险复核意见 |
| 质量角色 | 提供缺陷、测试与评审证据，复核质量类信号 | 缺陷统计、测试报告、评审结论、质量风险复核意见 |
| 数据提供方（各任务负责人、接口人） | 按频率更新所负责字段，保证数据真实及时 | 任务状态更新、阻塞说明、变更登记、外部交付状态 |
| AI工具 | 汇总结构化依据，按阈值生成候选风险信号 | 候选风险信号清单，含字段值、阈值和原始记录引用 |
分工落地时有两个要点。一是每个字段只有一个采集责任人，避免多头填报导致口径不一。二是复核人应与采集人分离，至少对高影响风险如此，防止同一人既提供数据又确认结论。风险台账的最终确认权归项目经理，技术类和质量类结论分别由技术负责人和质量角色签署意见。
在工具承载上，ONES可以把任务状态、缺陷、变更和文档记录作为依据来源，工作项的状态变化与阻塞记录形成执行数据，风险条目可作为独立工作项登记并关联原始记录。这样候选信号与正式风险在同一处留痕，复核时能直接打开来源工作项核对，减少依据与结论脱节的情况。
示例：一个迭代内的风险识别依据流转
以下为演示情景，用于说明依据如何流转为一条可复核的风险记录，不代表真实项目数据。
某迭代计划为期两周，包含接口开发、联调测试和一次交付评审三个里程碑。迭代第一周结束时，采集到的依据包括：接口开发任务完成比例为计划的一半，其中两个任务处于阻塞状态已持续四天；缺陷库中该模块新增缺陷数量高于前两个迭代同期水平；变更记录显示本迭代内范围变更两次，均涉及接口字段调整。计划基线显示联调测试的开始时间依赖接口开发完成。
按阈值表比对：进度偏差超过约定比例，阻塞时长超过三天上限，缺陷密度高于历史均值，变更次数达到迭代上限。AI汇总这些字段后生成一条候选风险信号：接口开发进度滞后且阻塞未解除，可能影响联调测试开始时间；缺陷与变更集中出现，可能增加联调阶段返工。信号中附带了具体任务编号、缺陷统计区间和变更单号。
技术负责人复核后确认阻塞原因是外部依赖方接口文档未到位，缺陷集中在变更涉及的字段上。项目经理据此登记正式风险：联调测试延期风险，触发依据为进度偏差、阻塞记录和变更单，影响评估为可能推迟交付评审，应对措施为协调外部依赖方并调整联调范围，责任人为项目经理，复核时间为下一采集周期。后续采集时重新比对相关字段，风险状态从“开放”更新为“缓解中”。
这个示例体现的规律是：单看某一项数据往往不足以支撑风险结论，进度、阻塞、缺陷和变更的组合才能说明问题；每条信号都要能指回原始记录，复核才有依据；风险登记后仍需持续比对字段，状态更新与依据变化保持同步。
完成检查：依据体系是否可用
依据体系建成后，可用以下清单逐项检查。检查以“能否支撑一次完整的风险识别”为标准，不以文档数量为标准。
- 四类依据均有明确的数据来源，且来源为项目日常产生的记录，而非临时补填。
- 每个字段都有采集频率和唯一责任人，抽查最近一个周期，字段更新及时率符合约定。
- 关键字段均有阈值，阈值经过项目负责人确认，并有对应的处理动作说明。
- 候选风险信号能追溯到具体任务、缺陷、变更或文档记录，抽查若干条信号可打开原始依据。
- 正式风险台账中每条风险都记录了触发依据、复核人和复核时间。
- 复核人与采集人分离的规则已执行，高影响风险的复核意见有记录。
- 风险状态有定期更新记录，开放风险均有最近一次复核时间。
- 字段口径调整时保留了历史版本，能够回溯调整前的判断依据。
检查中若出现以下情况，应作为阻断项优先处理：关键字段长期缺失或靠人工估算补填；候选信号无法指向原始记录；正式风险没有复核记录；阈值缺失导致AI只能输出泛泛描述。这些情况会使风险结论失去可复核性，应先补齐采集与阈值机制，再扩大识别范围。改进方向可按“先保证四类依据齐全、再细化字段、最后优化阈值”的顺序推进，每轮迭代复盘一次误报与漏报，逐步调整字段和阈值设置。
常见问题
项目刚开始、执行数据还很少时，AI风险识别能依据什么？
项目早期可以先用计划与基线类依据支撑识别，包括范围条目是否清晰、里程碑完成标准是否明确、外部依赖是否已约定交付时间、关键角色是否到位。这些字段在立项阶段就能采集，不依赖执行数据积累。
此时AI生成的信号更多是“计划层面的不确定性提示”，例如依赖方未确认交付日期、里程碑缺少完成标准。复核时应把这类信号当作待澄清事项处理，等执行数据积累后再补充进度偏差、阻塞时长等字段，逐步提高判断精度。
阈值定多少合适，定得太松或太紧会有什么影响？
阈值没有通用数值，应结合历史项目数据和团队风险偏好确定。起步阶段可参考过往同类项目的实际分布，把阈值设在明显偏离常态的位置，例如阻塞时长超过团队通常处理周期的天数、缺陷密度高于前几个迭代同期水平。
阈值过松会让候选信号过多，复核负担加重，团队容易逐渐忽略信号；阈值过紧则可能漏掉早期风险。可行做法是每轮迭代复盘一次误报与漏报，按实际情况微调，并保留阈值调整记录，便于解释此前判断的依据。
AI生成的候选风险信号被复核人否定后，这条记录还要保留吗？
建议保留。被否定的信号同样是判断过程的记录，说明当时哪些字段超出了阈值、复核人基于什么事实认定风险不成立。保留这些记录有两个用处：一是后续同类信号再次出现时，复核人可以参考此前结论；二是复盘阈值设置时，能看出哪些阈值产生了较多无效信号，作为调整依据。
保留方式可以是在风险台账之外单独维护一份候选信号处理记录，标注复核结论和否定理由，不必进入正式风险清单。
跨团队或跨供应商的项目，外部依据采集不到怎么办？
外部依据采集受限时，先把可获取的部分结构化，并在依据完整性说明中标注缺失项及其对判断的影响。例如供应商交付状态无法实时获取，可以按约定节点要求对方提供书面进度确认，作为阶段性依据。
对于长期缺失的关键字段，应在风险台账中登记为“依据缺口”类风险，明确补采责任人和时间要求。AI生成信号时，涉及缺失字段的判断应标注置信度限制，避免把推测当作事实结论。
风险识别机制运行一段时间后，如何判断是否需要调整字段清单？
可以从三个迹象判断：一是某些字段长期采集但从未触发过任何信号，可能说明该字段与当前项目风险关联弱，或阈值设置不合理；二是复核中频繁出现“信号成立但影响很小”的情况，说明阈值偏松；三是反复出现事后才发现的风险，说明字段清单遗漏了相关依据来源。
调整时保留字段的历史版本和口径说明，确保此前基于旧字段做出的风险判断仍可回溯。调整频率不宜过高，可按迭代或季度集中评估一次。
