AI延期预警要落地，核心是把项目里能反映进度的数据变成可计算的信号，再设定分级规则，由AI生成带依据的预警条目，最后落到固定的处置动作和复盘闭环。关键条件有三项：进度数据持续记录、规则可解释、每条预警有负责人和关闭条件。下文按信号选取、五步流程、角色分工、阈值示例、运行示例和上线检查展开，并说明ONES在承载工作项、迭代与风险标记上的衔接方式。
要点总览（TL;DR）
- AI延期预警的输入来自四类可采集信号：计划与里程碑、工作项状态与流转、依赖与阻塞、工作量与剩余工时；主观评价和口头承诺不适合作为预警输入。
- 落地流程分五步：确定预警口径与阈值分级、打通数据采集、设计规则型与模型型判断、由AI生成带依据的预警条目、分发并跟踪处置直到关闭。
- 阈值分级同时看偏差程度和剩余时间，分为提示、关注、严重三级；首版规则宜宽，运行两三个迭代后根据误报和漏报逐步收紧。
- 项目经理定义阈值并审核高等级预警，任务负责人确认预警真实性并给出处置计划，AI输出定位为辅助判断，最终确认由人完成。
- 机制上线后用信号覆盖率、预警准确率抽查、处置闭环率、误报漏报处理和规则复核五项检查判断是否真正跑起来。
先定预警对象：哪些延期信号值得被AI盯住
延期预警的输入质量决定输出质量。开始配置规则前，先把团队现有记录中能反映进度的字段列出来，再按可采集、可归因、变化频率合适三条标准筛选。没有记录的口头承诺、主观评价、临时讨论结论不适合作为预警输入，它们无法被稳定采集，也无法在预警发出后追溯到具体依据。
延期信号通常来自四类来源：
- 计划与里程碑：里程碑计划完成日期、当前完成度、剩余天数、阶段交付物状态。这类信号适合判断整体节奏是否偏离。
- 工作项状态与流转：工作项当前状态、状态停留时长、进入测试或评审的时间、返工次数。状态长期不流转往往比完成度更能提前暴露问题。
- 依赖与阻塞：前置任务是否完成、外部依赖是否到位、阻塞标记的持续时长、跨团队接口的等待时间。
- 工作量与剩余工时：已投入工时、剩余工时估算、剩余工时变化趋势、任务负责人负载。剩余工时在迭代中后期不降反升，是典型的延期前兆。
筛选时用一张清单把每个信号落到来源系统、字段名和更新频率上，例如：
| 信号类别 | 示例字段 | 来源 | 更新频率 | 是否纳入预警 |
|---|---|---|---|---|
| 计划与里程碑 | 里程碑计划完成日、完成度 | 项目计划表 | 每日 | 是 |
| 工作项状态 | 状态、状态停留时长 | 工作项管理 | 实时或每日 | 是 |
| 依赖与阻塞 | 阻塞标记、阻塞开始时间 | 工作项关联关系 | 实时 | 是 |
| 剩余工时 | 剩余工时、已投入工时 | 工时记录 | 每日 | 是 |
| 主观评价 | “感觉有点慢” | 聊天记录 | 不固定 | 否 |
这张清单的完成标志是：每个纳入预警的字段都能说清从哪个系统取、多久更新一次、由谁维护。字段缺失或更新不及时的信号，先补记录再纳入规则，否则预警会建立在过期数据上。
当这些字段持续记录在统一的项目管理工具中，预警才有稳定的数据底座。ONES 可承载项目、工作项、迭代和里程碑的状态与流转记录，ONES Assistant 能理解项目、工作项、迭代等真实工作上下文，并基于相关项目数据回答问题、执行后续操作，适合作为预警信号采集与预警条目生成的工作环境。
核心操作步骤：从数据到预警条目的五步流程
五步流程把“有数据”推进到“有处置”。每一步都明确输入、动作、输出和完成标志，避免流程停在规则配置阶段。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 第一步：确定预警口径与阈值分级 | 项目类型、迭代长度、历史偏差数据 | 定义提前多少天提示、偏差多少算风险，划分提示、关注、严重三级 | 预警口径说明与分级表 | 团队对“什么算延期风险”有一致理解，分级有书面定义 |
| 第二步：打通数据采集 | 信号清单中的字段与来源系统 | 确认字段映射、刷新频率、缺失处理方式 | 字段映射表与刷新计划 | 关键字段能按计划频率稳定更新，抽查数据与源系统一致 |
| 第三步：设计预警规则 | 分级表与可用字段 | 把明确可计算的判断写成规则，把需要综合判断的部分交给模型辅助 | 规则清单，标注规则型或模型型 | 每条规则能说清触发条件、依据字段和预期等级 |
| 第四步：AI生成预警条目 | 命中的规则与相关项目数据 | 生成风险描述、判断依据、影响范围和建议动作 | 结构化预警条目 | 条目包含依据字段，负责人能据此判断是否成立 |
| 第五步：预警分发与处置跟踪 | 预警条目与负责人名单 | 指派负责人、记录确认结果、跟踪处置动作直到关闭 | 处置记录与关闭结论 | 每条预警都有负责人、处置计划和关闭时间 |
第三步需要说明规则型与模型型的分工。规则型判断适合边界清晰的条件，例如“里程碑剩余5天且完成度低于70%”，结果稳定、可解释、便于复核。模型型判断适合需要综合多字段的场景，例如结合状态停留时长、剩余工时趋势和阻塞记录判断某个任务是否存在延期倾向。两类判断可以叠加：规则先筛出候选，模型再补充风险描述和影响范围，最终由负责人确认。
第四步的预警条目应包含四部分内容：风险描述说明哪个对象、出现什么偏差；判断依据列出命中的规则和关键字段值；影响范围说明涉及哪些下游任务、里程碑或团队；建议动作给出可执行的下一步，例如调整排期、补充资源或拆分任务。条目中的建议动作是参考，处置方案由负责人决定。
第五步的完成标志是关闭记录，而不只是“已通知”。关闭条件可以是偏差消除、计划调整后重新基线、或确认风险不成立并记录原因。没有关闭条件的预警会在系统中不断堆积，逐渐失去可信度。
角色与交付物：谁维护规则、谁处置预警
预警机制失效最常见的原因，是预警发出后没有明确的人对结果负责。角色分工要落到交付物上，每个角色知道自己产出什么、什么时候产出。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 项目经理 | 定义预警口径与阈值，审核高等级预警，主持复盘 | 分级表、高等级预警审核记录、复盘结论与规则调整建议 |
| 项目成员/任务负责人 | 确认预警真实性，更新工作项状态，给出处置计划 | 预警确认结论、处置动作与完成时间、状态更新记录 |
| 数据或工具维护角色 | 维护采集管道、字段映射和规则配置 | 字段映射表、规则配置记录、数据异常处理记录 |
| AI | 汇总信号、生成带依据的预警条目和建议动作 | 预警条目，供人工确认 |
AI输出的定位是辅助判断。预警是否成立、影响范围是否准确、采取什么处置动作，由任务负责人和项目经理确认。把AI条目直接当作结论分发，会让团队把精力花在解释误报上，反而削弱机制的可信度。
在ONES中，预警相关的工作可以落到可追踪的对象上：ONES Assistant 可汇总通知并标记交付风险，也可围绕项目进展、工时投入等生成进展分析和根因判断，帮助管理者在风险扩大前完成干预。这些输出基于ONES权限体系执行，过程可追踪、结果可审计，便于在角色之间交接时保留依据。
预警规则与阈值怎么设：一个可套用的分级示例
阈值分级建议同时看两个维度：偏差程度和剩余时间。偏差大但剩余时间充足，属于可观察的提示；偏差大且剩余时间少，才进入严重级别。只按偏差分级容易在早期制造大量噪音，只按时间分级又会漏掉已经明显偏离的任务。
| 等级 | 触发条件示例 | 默认动作 |
|---|---|---|
| 提示 | 里程碑剩余天数大于10天，完成度低于计划值10个百分点以内；或工作项状态停留超过平均时长1.5倍 | 进入观察列表，由任务负责人在下次站会说明 |
| 关注 | 里程碑剩余5至10天，完成度低于计划值10至25个百分点；或依赖阻塞持续超过3个工作日 | 生成预警条目，任务负责人确认并给出处置计划 |
| 严重 | 里程碑剩余少于5天，完成度低于计划值25个百分点以上；或关键路径任务阻塞超过5个工作日且无替代方案 | 项目经理审核，组织专项讨论，调整排期或补充资源 |
规则写法上，组合条件比单一条件更可靠。例如“里程碑剩余天数≤5 且 完成度偏差≥25%”比“完成度偏低”更可执行，也更容易在复盘时判断规则是否合理。依赖阻塞类规则要区分关键路径与非关键路径，非关键路径的阻塞可以降一级处理。
阈值需要按项目类型调整。迭代周期短、交付节奏快的项目，提前天数可以压缩；跨团队依赖多、外部接口多的项目，阻塞时长阈值应放宽。首版规则宜宽，先保证预警能被团队接受和处理，运行两三个迭代后，根据误报和漏报情况逐步收紧。每次调整阈值都记录调整原因和影响，便于后续复核。
完整示例：一个迭代内的延期预警运行过程
以下为演示情景，用于说明机制如何运行，数据为示例值。
场景设定：某团队进行为期两周的迭代，其中一个关键任务“支付接口联调”位于关键路径上，计划在第8个工作日完成，下游还有测试和上线准备两个任务依赖它。
信号采集与规则命中：第6个工作日，系统记录显示该任务状态停留在“开发中”已4天，剩余工时从12小时变为16小时，且关联的外部依赖“第三方沙箱环境”标记阻塞已持续3个工作日。规则命中“关注”级别：关键路径任务阻塞超过3个工作日，且剩余工时上升。
AI生成的预警条目示例：
- 风险描述：关键路径任务“支付接口联调”进度偏差扩大，剩余工时较上次估算增加4小时，外部依赖阻塞持续3个工作日。
- 判断依据：状态停留4天；剩余工时由12小时变为16小时；依赖阻塞记录起始于第3个工作日。
- 影响范围：下游“支付回归测试”和“上线准备”两个任务，里程碑“支付模块上线”剩余6天。
- 建议动作：确认第三方沙箱环境恢复时间；评估是否先用模拟环境推进部分联调；如阻塞持续，考虑调整里程碑或增加人手。
负责人确认与处置：任务负责人当天确认预警成立，更新阻塞原因，联系第三方获取环境恢复时间，并将任务拆分为“模拟环境联调”和“真实环境验证”两个子任务，前者先行推进。项目经理将预警等级维持为“关注”，约定两天后复核。
关闭记录：第9个工作日，第三方环境恢复，真实环境验证完成，剩余工时回落至计划范围，预警关闭，关闭原因记录为“依赖恢复，任务拆分后进度回归计划”。
复盘时的一次规则修正：迭代复盘发现，该预警在第6个工作日才触发，而剩余工时上升在第5个工作日已有记录。团队将“剩余工时连续两次估算上升”加入关注级触发条件，使同类风险提前一天暴露。这次修正记录了调整原因和生效迭代，作为后续阈值复核的参考。
完成检查：预警机制是否真的跑起来了
机制上线后，用一份检查清单判断它是否达到可用状态。检查项应有明确的通过标准，避免只凭感觉判断“运行良好”。
| 检查项 | 检查方法 | 通过标准 |
|---|---|---|
| 信号覆盖率 | 对照信号清单，核对关键工作项和里程碑是否都在采集范围内 | 关键路径任务和里程碑覆盖率达标，缺失项有补录计划 |
| 预警准确率抽查 | 随机抽取一定数量的预警条目，由负责人核对是否成立 | 抽查结果中成立比例达到团队约定水平，误报原因有记录 |
| 处置闭环率 | 统计预警条目中具备负责人、处置计划和关闭记录的比例 | 绝大多数预警有负责人和关闭记录，超期未关闭的有说明 |
| 误报与漏报处理 | 检查误报是否归因到规则或数据问题，漏报是否补充了触发条件 | 每类误报和漏报都有对应的规则或数据修正记录 |
| 规则与阈值复核 | 确认是否安排了定期复核，复核是否覆盖阈值调整和规则增删 | 有固定复核节奏，最近一次复核有结论和调整记录 |
误报和漏报要分开处理。误报多来自阈值过紧或字段口径不一致，处理方式是放宽阈值或统一字段定义；漏报多来自信号缺失或规则覆盖不足，处理方式是补充采集字段或增加组合条件。两类问题都应在复盘中记录，而不是临时口头调整。
规则与阈值的复核建议与迭代节奏绑定，每个迭代或每个阶段结束后检查一次。复核内容包括：哪些规则频繁触发但价值低、哪些风险反复漏报、数据刷新是否稳定。复核结论落到规则配置的变更记录中，让预警机制随着项目实际运行逐步校准。
常见问题
团队历史数据很少，第一版预警规则怎么起步？
数据积累不足时，先用规则型判断起步，选择字段稳定、口径清晰的少数条件，例如里程碑剩余天数与完成度偏差的组合、关键路径任务阻塞时长。首版阈值设宽一些，目标是让预警能被团队接受并产生处置动作，而不是追求准确率。运行两三个迭代后，用实际误报和漏报记录调整阈值和条件，再考虑引入需要多字段综合判断的模型型规则。
预警发出后负责人不认可，应该怎么处理？
把“不认可”本身作为有效记录处理。负责人需要写明不认可的原因：是数据不准、规则口径不符，还是风险确实不成立。数据问题转给维护采集的角色修正字段；规则口径问题进入下一次规则复核；风险不成立则记录关闭原因。这类记录是后续收紧阈值、减少误报的主要依据，比直接关闭预警更有价值。
跨团队依赖导致的延期，预警应该由谁负责？
预警负责人应指向本团队内对该任务结果负责的人，由其对外协调依赖方，而不是把预警直接派给外部团队。预警条目中的影响范围要写清涉及哪个外部团队、等待了多久、下游哪些任务受影响。若阻塞持续超过严重级阈值，升级到项目经理层面协调，并在关闭记录中写明依赖恢复时间或替代方案。
预警条目和普通工作项通知有什么区别，会不会造成重复打扰？
普通通知告知状态变化，预警条目要回答“哪里有延期风险、依据是什么、影响谁、建议做什么”。两者可以合并到同一渠道，但预警条目应带等级和关闭条件，进入独立的跟踪列表。若团队反馈打扰过多，优先检查提示级规则是否过紧，把提示级改为进入观察列表、只在站会说明，减少即时推送。
ONES 在延期预警中能承担哪些环节？
预警依赖工作项、迭代、里程碑和依赖关系的持续记录，ONES 可承载这些状态与流转数据。ONES Assistant 能理解项目、工作项、迭代等真实工作上下文，基于相关项目数据回答问题并执行后续操作，也可汇总通知并标记交付风险，围绕项目进展、工时投入生成进展分析和根因判断。这些输出基于 ONES 权限体系执行，过程可追踪、结果可审计。预警的触发方式、推送渠道和字段配置需结合团队实际环境确认。
阈值调整需要多频繁，调整后怎么验证效果？
建议与迭代节奏绑定，每个迭代或阶段结束后复核一次。调整前先统计上一周期各等级预警的数量、成立比例和关闭时长，调整后对比同类指标。每次调整记录原因、生效迭代和预期影响，避免多人反复修改导致口径漂移。若某条规则长期高频触发但处置价值低，考虑降级或删除；若某类风险反复漏报，补充采集字段或增加组合条件。
