AI项目风险分析的依据，主要来自四类可核查输入：计划基线、过程事实、判断材料和外部与约束条件。每项依据都要能说明来源、责任人、更新时间和适用范围，AI负责归纳与提示，人负责确认与定级。这样得出的风险结论才能追溯、复核和更新。
要点总览（TL;DR）
- AI项目风险分析的依据分为四类：计划基线、过程事实、判断材料、外部与约束条件，每类都要标注来源、责任人、更新时间和可信度。
- 操作上按“定范围—取数校验—AI归纳提示—人工复核定级”四步推进，每条风险都要能指回具体依据编号。
- 分工上由项目经理维护基线与风险登记，技术负责人提供技术判断，职能负责人确认资源与外部约束，AI输出一律标注为待核实。
- 完成标准是依据齐全、时效在窗口内、风险写明触发条件与责任人；没有依据支撑的结论不得进入正式风险登记。
- 依据更新后按原编号回溯关联风险并复评，保留变更记录，让结论可复核、可追溯。
风险分析前先定依据清单：四类输入与字段
风险分析的质量首先取决于输入是否齐全、口径是否一致。开始分析前，先把依据分成四类，并为每类规定最小字段，后续取数和复核才有统一标准。
计划基线回答“原本应该怎样”。包括项目范围说明、里程碑计划、任务依赖关系、验收标准、资源投入计划。它是对比偏差的参照物，缺少基线时，进度落后、范围蔓延都难以判断严重程度。
过程事实回答“实际发生了什么”。包括任务状态与完成比例、工时与投入记录、阻塞与等待记录、变更单、缺陷与返工数据、接口联调结果。这类依据应优先来自系统记录，避免凭印象补填。
判断材料回答“专业上怎么看”。包括评审结论、技术验证或原型测试结果、架构评估意见、专家与一线人员判断。这类依据允许来自人工，但要写明判断人、判断时间和依据的事实基础。
外部与约束条件回答“哪些边界在变化”。包括合规与安全要求、供应商交付承诺、外部接口方进度、关键人员可用性、预算与采购限制。这类信息常由项目外部提供，需要标注有效期。
每类依据的最小字段建议统一为五项：来源（系统、文档或人员）、责任人、更新时间、适用范围（哪个项目、迭代或工作项）、可信度（已核实、待核实、估计值）。字段统一后，AI归纳时才能区分事实与推测。
| 依据分类 | 典型内容 | 建议来源 | 责任人 | 更新频率 |
|---|---|---|---|---|
| 计划基线 | 范围、里程碑、依赖、验收标准 | 项目计划与需求文档 | 项目经理 | 基线变更时 |
| 过程事实 | 任务状态、工时、阻塞、变更、缺陷 | 工作项系统记录 | 项目经理、技术负责人 | 每日或每周 |
| 判断材料 | 评审结论、验证结果、专家意见 | 评审记录、测试报告、会议纪要 | 技术负责人 | 每次评审后 |
| 外部与约束条件 | 合规要求、供应商承诺、资源可用性 | 合同、合规文件、资源台账 | 职能负责人 | 条件变化时 |
哪些依据必须来自系统记录，哪些可以来自人工判断，需要在清单里事先写明。任务状态、变更、缺陷这类高频事实应以系统记录为准；技术可行性、方案取舍这类判断可以由人工提供，但要附上支撑事实。两者混在一起而不标注来源，后续复核时很难分清哪部分是数据、哪部分是观点。
按步骤完成一次风险分析：从取数到定级
有了清单，一次风险分析可以按固定步骤推进。每一步都应有明确输入、动作、输出和完成标志，避免分析停留在泛泛讨论。
第一步：确定分析范围与时间窗口。输入是项目阶段和关注重点，动作是明确本次分析覆盖哪个项目、哪些迭代、哪个时间段，输出是一页范围说明。完成标志是范围、时间窗口和排除项都已写明，参与人对边界没有歧义。
第二步：按清单取数与校验完整性。输入是依据清单，动作是逐项收集四类依据，检查字段是否齐全、更新时间是否在窗口内、来源是否可追溯，输出是带字段的依据汇总。完成标志是每类依据都有对应记录，缺失项已标注“缺失”及原因，而不是留空。
第三步：用AI做归纳、异常提示与候选风险生成。输入是校验后的依据汇总，动作是让AI按统一口径归纳偏差、提示异常组合（例如关键路径任务阻塞叠加人员可用性下降）、生成候选风险清单，输出是候选风险及每条风险引用的依据编号。完成标志是每条候选风险都能指回具体依据，AI的推断与原始事实分开呈现。
第四步：人工复核、定级并写入风险登记。输入是候选风险清单，动作是由项目经理和技术负责人逐条复核依据是否成立、判断影响范围与发生可能性、确定风险等级和应对责任人，输出是正式风险登记条目。完成标志是每条风险都有依据引用、等级、责任人和复评时间。
在取数和登记环节，如果工作项状态、阻塞记录、变更与评审结论分散在不同工具里，可以先在ONES中按项目归集工作项与文档记录，让任务状态、阻塞说明和评审结论保持同一来源，再把整理后的依据交给AI分析，减少口径不一致带来的返工。
角色分工与交付物：谁提供依据、谁确认风险
依据体系能否持续运转，取决于每个角色是否清楚自己提供什么、多久更新一次、对哪些结论负责。分工不必复杂，但要覆盖依据提供、AI输出复核和风险确认三个环节。
| 角色 | 主要职责 | 负责的依据 | 更新频率 | 交付物 |
|---|---|---|---|---|
| 项目经理 | 维护计划基线，组织风险分析，确认风险等级 | 范围、里程碑、依赖、变更记录 | 每周及基线变更时 | 依据清单、风险登记条目 |
| 技术负责人 | 提供技术判断，复核技术类候选风险 | 评审结论、验证结果、缺陷与返工数据 | 每次评审或验证后 | 判断材料、技术风险复核意见 |
| 职能负责人 | 确认资源可用性与外部约束 | 人员可用性、供应商承诺、合规要求 | 条件变化时 | 约束条件说明 |
| AI工具使用者 | 整理输入、运行分析、标注AI输出 | 依据汇总与分析记录 | 每次分析时 | 候选风险清单、分析记录 |
AI输出与人工确认的边界要写清楚：AI可以归纳事实、提示异常、生成候选风险和影响假设；风险是否成立、等级如何、由谁负责应对，必须由人确认。AI给出的推断要标注为“待核实”，不能直接进入正式风险登记。
各环节交付物形成一条链：依据清单说明输入从哪来，分析记录保留AI输出与人工复核过程，风险登记条目承载最终结论。三者对应同一批依据编号，后续复评时可以顺着编号回溯。
示例：一个迭代延期风险的依据链
以下为演示情景，用于说明依据如何支撑一条风险判断。
背景：某迭代进入后半程，一个关键任务出现阻塞，涉及外部接口联调。
引用的计划基线：该任务位于迭代关键路径，计划完成时间为迭代结束前三天，验收标准包含接口联调通过。基线显示后续两个任务依赖它的产出。
引用的过程事实：工作项状态连续五天停留在“阻塞”，阻塞说明记录等待外部接口方提供测试环境；同期该任务工时投入低于计划；变更记录显示接口协议在迭代中期调整过一次。
引用的判断材料：技术负责人在评审中判断，协议调整后联调至少需要额外三个工作日；一线人员反馈外部接口方响应不稳定。
AI提示的候选风险：结合关键路径位置、阻塞时长和协议变更，AI提示“迭代交付延期”为候选风险，并列出引用的依据编号，同时标注外部接口方响应情况属于人工判断、可信度为“待核实”。
人工确认后的结论：项目经理与技术负责人复核后确认风险成立，等级定为高，触发条件为“外部测试环境在两天内仍未提供”，影响范围为迭代验收和后续两个依赖任务，责任人为项目经理，复评时间定在两天后。
依据缺失时的处理：如果外部接口方的承诺没有书面记录，就在条目中标注“供应商承诺依据缺失”，把该风险的影响评估标为不确定，并安排职能负责人补充确认，而不是用推测填补。
完成检查：依据是否充分、可追溯、可更新
一次风险分析结束前，用下面的清单逐项核对，确认结果达到可用状态。
- 四类依据是否都有覆盖，缺失项是否写明缺失原因和补充计划。
- 每条依据是否具备来源、责任人、更新时间、适用范围、可信度五项字段。
- 依据的更新时间是否落在本次分析的时间窗口内，过期数据是否已标注。
- 每条风险是否写明触发条件、影响范围、发生可能性判断和责任人。
- 每条风险是否引用具体依据编号，AI推断与已核实事实是否分开标注。
- 风险等级是否有复核人确认，而不是由AI直接给定。
- 是否设定复评时间，以及依据更新后由谁触发复评。
其中有一条阻断项：没有依据支撑的风险结论不得进入正式风险登记。可以先把这类结论放在观察区，待补充依据后再定级。依据更新后，例如阻塞解除、供应商承诺变化或评审结论调整，应按原依据编号找到关联风险，重新评估等级和应对措施，并在登记条目中保留变更记录。做到这一步，风险分析才既能支撑当前决策，也能在下一轮复评时说清结论是怎么来的。
常见问题
项目刚启动、过程数据很少，风险分析还能做吗？
可以做，但要调整依据的重心。启动阶段过程事实有限，分析应更多依赖计划基线和判断材料：范围说明、里程碑、依赖关系、验收标准，加上技术评审和专家对方案难点的判断。此时在依据清单中把过程事实一栏标注为“数据积累中”，并写明预计开始产生有效记录的节点。这样得出的风险结论可信度偏低，适合作为观察项跟踪，等过程数据积累后再复评升级。
AI提示的风险和人工判断不一致时，以哪个为准？
以人工复核结论为准，但要把分歧记录下来。AI的归纳基于输入的依据，可能漏掉未写入系统的背景信息；人工判断也可能受经验偏差影响。处理方式是回到依据本身：核对AI引用的依据是否准确、是否过期，再请判断人说明其结论所依据的事实。若分歧源于依据缺失，就先补依据；若依据齐全而结论不同，在分析记录中保留两种判断及理由，由项目经理和技术负责人共同定级。
依据分散在多个工具里，取数环节怎么保证口径一致？
关键是先统一字段再汇总，而不是把各工具的原始导出直接拼在一起。做法是依据清单里先规定五项最小字段（来源、责任人、更新时间、适用范围、可信度），取数时按字段逐项填写，同一类事实只认一个权威来源，例如任务状态以工作项系统记录为准，评审结论以评审记录为准。若工作项、阻塞说明和评审结论分散在不同位置，可以先在ONES中按项目归集工作项与文档记录，让状态与结论保持同一来源，再交给AI分析。
风险登记之后，什么情况下需要重新分析？
三类情况会触发复评：一是依据本身更新，例如阻塞解除、供应商承诺变化、评审结论调整；二是到达登记时设定的复评时间；三是风险触发条件被满足或明显偏离。复评时按原依据编号找到关联风险，重新核对依据的时效与可信度，再调整等级和应对措施，并在条目中保留变更记录。依据长期未更新的风险应标注为“依据待刷新”，避免用过期信息支撑当前判断。
小团队没有专职职能负责人，角色分工怎么落地？
可以合并角色，但不能合并职责。小团队中项目经理可同时承担资源可用性与外部约束的确认，技术负责人可兼做AI输出的初步复核，但每类依据仍要写明具体提供人，风险定级仍要有一名复核人。合并后建议在依据清单和风险登记中直接写人名而非岗位名，并保持更新频率不变。角色越少，越需要把“谁提供、谁确认”写清楚，否则依据缺失时容易无人补位。
