项目风险雷达：用 AI 把进度、会议和阻塞变成预警清单

开场困境

项目出事前，通常已经提醒过你很多次

很多跨部门项目不是突然失败的。活动延期前，设计稿已经晚了两天；客户投诉前，交付群里已经有人说“这个口径还没确认”；上线翻车前，测试同事已经在会议里提过“这个场景没覆盖”；老板追问前，项目负责人其实已经看到多个部门都在等别人回复。

问题是，这些信号分散在太多地方。计划表里有里程碑，任务系统里有延期，会议纪要里有待确认，群聊里有催办，邮件里有客户承诺，数据看板里有异常。每个信号单独看都不一定吓人，但合在一起，可能就是项目风险正在变大。

这篇教程要训练的能力很明确：用 AI 把项目进度、会议记录、任务状态、群聊邮件和阻塞信息整理成一张“项目风险雷达”。读完以后，你应该能做出一张可复用的风险清单，包含事实来源、风险信号、影响范围、责任人、下一步动作、升级口径和复盘记录。

趋势判断

工作代理正在从写材料，走向主动发现卡点

近几年，企业对 AI 办公的期待正在变化。早期大家最关心的是让 AI 写邮件、写周报、总结会议。现在更多产品开始强调 AI 工作代理、AI teammate、AI chief of staff：它们不只是回答问题，而是读取目标、项目、任务和沟通上下文，主动提示哪些事情需要关注。

例如 Asana 把 Dash 定位成 AI Chief of Staff，强调它能理解目标、优先级并提示需要注意的事项。类似趋势说明，企业不是只想要一个更会写字的聊天框，而是希望 AI 能进入工作流，帮团队从复杂项目里发现遗漏、冲突和阻塞。

但这篇文章不讲个人每日信息处理。个人指挥台关注的是“我今天回什么、做什么、跟什么”。项目风险雷达关注的是跨部门项目里的“哪条线可能出事、影响谁、谁要处理、什么时候必须升级”。它更适合老板、项目负责人、运营经理、产品/市场/交付主管和 PMO 使用。

• 个人日常管理：重点是收拢个人邮件、日程、会议和待办。
• 项目风险管理：重点是识别跨部门依赖、交付阻塞、责任空缺和升级时机。
• AI 工作代理的价值：不是替人当负责人，而是把负责人需要判断的信号提前摆出来。

旧做法

只问“进度怎么样”，很难提前看到风险

很多项目会每周开一次例会，项目经理逐个问：“你这边进度怎么样？”大多数人会回答“推进中”“这周可以”“还差一点”“等对方确认”。这些话听起来都不算坏消息，但它们也没有给出足够的管理信息。

真正的问题是，进度汇报经常只报状态，不报风险。一个任务写着进行中，但它可能已经缺资源三天；一个会议纪要写着“会后确认”，但没有负责人；一个客户承诺写在销售邮件里，交付团队却没看到；一个需求范围变更在群里讨论过，却没有进入计划。

如果项目负责人只靠例会口头追问，就会陷入被动。大家不是故意隐瞒风险，而是每个人只看自己那一段。AI 风险雷达的作用，是把不同渠道的碎片拼起来，提醒项目负责人：这里可能不是普通进度慢，而是责任、依赖、范围、质量或承诺正在失控。

本质解释

项目风险雷达，本质是一张提前预警清单

用一句大白话说，项目风险雷达就是把项目里可能导致延期、返工、客户不满、成本增加或责任不清的信号，提前整理成一张清单。它不是项目复盘，不是周报，也不是为了证明谁没做好。

它解决的工作问题，是跨部门项目的信息不对称。产品知道需求变了，市场知道活动时间不能动，交付知道人手不够，客服知道客户已经不满，老板知道收入节点很关键。每个人都掌握一部分事实，但项目负责人需要看到全图。

你应该怎么用？每周固定一次，关键项目每天一次，把项目计划、任务状态、会议纪要、群聊邮件和反馈材料交给 AI 初步整理，再由项目负责人确认事实、调整严重程度、指定动作和决定是否升级。AI 负责照亮风险，人负责决定怎么处理。

• 事实来源：风险从哪里来，能不能追溯到具体材料。
• 风险信号：到底是延期、阻塞、责任空缺、范围变化还是质量异常。
• 影响范围：会影响客户、收入、上线、交付、成本、合规还是团队节奏。
• 管理动作：找谁确认、谁负责处理、什么时候升级、后面怎么复盘。

AI 分工

AI 负责整理和提示，人负责判断、承诺和升级

项目风险雷达非常适合 AI 辅助，因为项目材料里有大量重复而容易漏看的信息：任务是否延期，会议行动项是否有负责人，群聊里是否出现反复催办，客户邮件里是否出现新的承诺，数据反馈是否和计划不一致。这些信息靠人逐条翻，很容易漏。

AI 最适合做四件事。第一，合并材料，把多个渠道里的同一问题放在一起。第二，提取信号，标出延期、阻塞、无人负责、范围变化、质量异常。第三，生成初步风险清单，把事实来源、影响范围、建议动作写清楚。第四，起草升级口径，让项目负责人可以更快同步老板或跨部门负责人。

但 AI 不能做项目负责人。它不能替人判断某个风险是否真的高优先级，不能承诺某部门什么时候交付，不能决定延期，不能替老板接受风险，也不能把推断写成事实。最稳的分工是：AI 做雷达，人做指挥。

工作产物

一张合格的风险雷达，至少要有七列

风险雷达不要写成一段长文字。项目负责人每天已经很忙，老板和部门负责人也没有时间从长篇叙述里找重点。最实用的形态是一张表，一眼能看到风险来自哪里、影响什么、谁要处理、什么时候必须处理。

最少要有七列：事实来源、风险信号、影响范围、责任人、下一步动作、升级口径、复盘记录。如果只写风险名称，没有事实来源，就容易变成主观感受；如果只写影响范围，没有责任人，就没人动；如果只写动作，没有复盘记录，下次还会踩同样的坑。

你可以把这张表放在项目文档、飞书表格、Notion、Asana、Jira、Trello 或普通电子表格里。工具不是重点，重点是结构稳定。结构稳定后，AI 才能持续帮你把新材料整理进同一个框架。

1. 事实来源：具体来自哪份计划、任务、会议、邮件、群聊或数据。
2. 风险信号：延期、阻塞、责任空缺、依赖未确认、范围变化、质量异常、资源冲突。
3. 影响范围：客户、收入、上线、交付、体验、合规、成本、团队节奏。
4. 责任人：当前谁最适合推进确认，不等于最终背锅人。
5. 下一步动作：今天或本周必须做什么，找谁确认，交付什么结果。
6. 升级口径：需要向谁说明什么，请求什么支持，最晚什么时候决定。
7. 复盘记录：风险关闭后记录真实结果、有效动作和机制改进。

资料准备

开始前，先把项目材料分成五类

不要直接把一整个项目群聊天记录丢给 AI。材料太乱时，AI 会输出看似完整但无法追溯的结论。更好的做法，是先把材料按来源分成五类：项目计划、任务状态、会议记录、群聊邮件、数据或现场反馈。

项目计划告诉你原定目标和节点；任务状态告诉你执行是否偏离；会议记录告诉你决定和行动项；群聊邮件告诉你最新变化和催办；数据或现场反馈告诉你结果是否异常。五类材料放在一起，项目风险才会从碎片变成图像。

如果资料涉及客户姓名、报价、合同编号、员工隐私、供应商价格或内部敏感策略，要先做脱敏。AI 不需要知道全部隐私才能识别风险，它需要的是事实结构：谁提出了什么要求，哪个节点延期，哪个决定没落地，哪个影响正在扩大。

请帮我整理一个跨部门项目的风险雷达原始材料。注意：你只负责整理、归类和提醒，不替团队判断最终责任，不替任何人承诺时间，也不替负责人升级。

项目背景：
[项目名称、业务目标、当前阶段、计划上线/交付时间、项目负责人、关键部门]

资料来源：
1. 项目计划：[粘贴里程碑、关键交付物、原定截止时间]
2. 任务状态：[粘贴任务系统里的进行中、延期、阻塞、待验收事项]
3. 会议记录：[粘贴最近 3-5 场项目会议的决定、行动项、待确认问题]
4. 群聊/邮件摘要：[粘贴重要变更、催办、争议、资源请求、客户或老板关注点]
5. 数据或现场反馈：[粘贴进度数据、质量问题、用户反馈、客户反馈、交付风险]

请先输出材料诊断：
1. 已经能确认的事实。
2. 只能作为线索、不能直接当结论的内容。
3. 缺少负责人、截止时间、交付物或验收标准的事项。
4. 可能影响上线、交付、收入、客户、合规或团队资源的风险信号。
5. 需要补充或人工确认的资料。

要求：
明确区分“事实”“推断”“待确认”。没有材料支持的地方写“材料未提供”。不要把群聊里的倾向写成正式决定。

第一步

先让 AI 做材料诊断，不要急着要结论

新手最容易犯的错，是一上来就问 AI：“这个项目有什么风险？”如果材料不完整，AI 仍然会努力回答，结果就是把模糊线索包装成确定结论。项目管理里，确定性比文采重要得多。

第一步应该让 AI 做材料诊断。它要先告诉你哪些事实已经明确，哪些只是线索，哪些缺负责人、缺截止时间、缺交付物，哪些内容不能直接下结论。这个动作看起来慢，其实是在避免后面误判。

项目负责人看到材料诊断后，要先补资料。比如 AI 发现“法务确认”没有截止时间，就去问法务；发现“客户要求周五上线”只有销售转述，就去确认客户原话；发现“开发阻塞”没有说明阻塞原因，就让开发补充依赖条件。材料补齐后，再生成风险雷达。

• 先问材料是否足够，再问风险是什么。
• 先找缺字段，再排严重程度。
• 先确认事实来源，再决定是否升级。
• 先把“待确认”保留下来，不要为了好看把它改成结论。

第二步

把进度问题翻译成风险信号

项目进度里的很多问题，一开始都不会写成“风险”。任务系统只会显示延期，会议纪要只会写待确认，群聊里只会有人说“这个还没收到”，邮件里只会出现“客户又催了一次”。项目负责人要训练自己把这些状态翻译成风险信号。

例如，延期不一定只是速度慢，可能代表资源不足；等待确认不一定只是流程没走完，可能代表决策人缺席；反复催办不一定只是对方着急，可能代表承诺口径已经不一致；需求范围变化不一定是正常优化，可能代表上线范围正在失控。

AI 的作用，是帮你从材料里提取这些信号，但信号的严重程度要由人判断。对一个内部小工具来说，延期一天可能只是低风险；对一个客户上线项目来说，延期一天可能影响回款、合同和续约。

1. 延期信号：任务超过截止时间，或关键节点连续两次推迟。
2. 阻塞信号：任务状态停留在等待、卡住、需确认，但没有明确推动人。
3. 责任信号：会议有行动项，但没有唯一负责人、交付物或截止时间。
4. 依赖信号：多个部门都在等待同一个输入，且没人拥有这个输入。
5. 范围信号：新增需求、临时改口径、客户新增要求，但计划没有更新。
6. 质量信号：测试、客服、试点用户或现场反馈出现重复问题。
7. 承诺信号：外部已经有时间或结果承诺，内部交付状态不匹配。

第三步

给每个风险补上影响范围和最晚处理时间

风险清单最怕写得像抱怨：“设计太慢”“产品没定”“客户太急”“资源不够”。这些话都可能是真的，但它们不能直接推动管理动作。你要把它们翻译成影响范围和时间压力。

影响范围回答的是：如果不处理，会影响什么。是影响上线日期，还是影响客户体验？是影响收入确认，还是影响团队加班？是影响合规，还是只是内部排期需要调整？影响范围越清楚，项目负责人越容易判断要不要升级。

最晚处理时间回答的是：什么时候之前必须有动作。很多风险不是今天就爆炸，但有一个处理窗口。比如下周三要上线，本周五还没完成测试环境，就必须预警；客户周一要评审，周五还没确认演示口径，就必须升级。没有时间线的风险，很难被认真对待。

第四步

责任人不是背锅人，而是下一步推动人

很多团队不愿意写责任人，是因为大家把责任人理解成背锅人。风险雷达里的责任人不是最终责任裁判，而是当前最适合推动下一步的人。这个区分很重要。

比如“客户验收口径未确认”这条风险，事实来源可能是客户邮件和交付会议。当前推动人可能是客户成功负责人，因为他最适合约客户确认；协作者可能是产品和交付；最终拍板人可能是项目 Sponsor。一个风险可以有多个相关方，但下一步推动人最好只有一个。

AI 可以根据材料建议责任人，但不能替团队指定责任。项目负责人要检查建议是否符合真实组织关系和权限。如果 AI 写“产品负责人确认”，但实际需要销售负责人先和客户对齐，就要人工改掉。

• 当前责任人：负责推动下一步确认或动作的人。
• 协作者：提供资料、判断、资源或执行支持的人。
• 拍板人：能决定范围、延期、资源、客户口径或预算的人。
• 知会对象：需要知道风险，但不一定要立即行动的人。

第五步

升级不是告状，而是请求管理动作

项目升级经常被误解成告状，所以很多项目负责人拖到最后才说。真正健康的升级不是说“某部门不配合”，而是说“基于这些事实，如果不在某个时间前做决定，会影响某个结果；我需要谁给出什么支持”。

好的升级口径必须短、准、可行动。它包含四个要素：事实、影响、请求、截止时间。事实说明风险从哪里来；影响说明不处理会怎样；请求说明需要对方做什么；截止时间说明为什么现在就要处理。

AI 很适合帮你把情绪化、零散的风险描述改成管理语言。但项目负责人必须检查事实是否准确，语气是否合适，请求是否合理。不要让 AI 把风险写得像危机公关，也不要为了客气把真正需要拍板的事写成“有空看下”。

请把下面项目风险改写成适合向上升级或跨部门同步的口径。注意：语气要基于事实，不甩锅，不夸大，不替对方承诺。

风险条目：
[粘贴风险名称、事实来源、风险信号、影响范围、责任人、下一步动作、最晚处理时间]

升级对象：
[老板 / 项目 Sponsor / 部门负责人 / 客户成功负责人 / 产品负责人 / 交付负责人 / PMO]

希望对方做什么：
[拍板选项 / 协调资源 / 确认优先级 / 接受延期 / 同意预案 / 指定负责人]

请输出 3 个版本：
1. 群里同步版：80-120 字，适合项目群。
2. 上级汇报版：150-220 字，写清事实、影响、选项和请求。
3. 会议开场版：3 个要点，适合风险会开头说明。

每个版本都必须包含：事实证据、影响范围、需要谁在什么时候做什么。
每个版本都不能包含：没有证据的指责、绝对化判断、未经确认的承诺、情绪化表达。

第六步

给高风险准备预案，不要只写“继续跟进”

很多风险雷达最后一列都写着“继续跟进”。这句话几乎没有管理价值。继续跟进不等于问题会解决，也不说明如果解决不了怎么办。高风险事项至少要有一个预案草案。

预案不是让 AI 替你做决定，而是先把可选方案摆出来。比如范围收缩、延期上线、增加资源、先内测后公测、先交付核心模块、调整客户沟通口径、暂停低优先级任务。每个方案都有代价，项目负责人要把代价讲清楚，交给有权限的人拍板。

预案还可以避免团队在最后一刻乱做决定。风险刚出现时，大家还有时间选择；风险爆发后，选择会越来越少。AI 可以帮你整理保守、折中、激进三类方案，人负责判断哪一个符合公司目标和承诺边界。

请帮我为下面项目风险生成预案草案。你只负责提供选项和影响，不替负责人选择最终方案。

风险背景：
[粘贴风险条目、事实来源、影响范围、最晚处理时间]

当前限制：
[预算、人员、时间、客户承诺、合规要求、质量底线、不可改变的里程碑]

请输出：
1. 保守方案：最稳妥但可能牺牲速度或范围。
2. 折中方案：兼顾交付和风险控制。
3. 激进方案：争取按原计划推进，但需要哪些前提。
4. 每个方案的适用条件、代价、需要谁拍板。
5. 不建议采用的做法及原因。
6. 建议项目负责人今天先确认的 5 个问题。

要求：
不要假设资源一定可用。不要把“建议”写成“已经决定”。

核心模板

直接复制：项目风险雷达提示词

下面这段模板适合项目负责人、运营经理、产品主管、市场活动负责人、交付负责人和 PMO 直接使用。你可以每周固定使用，也可以在重要节点前使用，例如上线前、客户评审前、活动发布前、版本冻结前。

使用时要注意两点。第一，输入材料越具体，输出越可靠。不要只写“项目进度如下”，要给出计划、任务、会议和反馈。第二，输出之后必须人工检查，尤其是事实来源、责任人、严重程度和升级口径。

如果你所在团队已经有项目管理工具，可以把输出字段映射到工具字段里。比如风险编号对应任务编号，责任人对应 assignee，最晚处理时间对应 due date，复盘记录对应评论或文档记录。

请根据下面材料生成一张“项目风险雷达”。它不是项目总结，而是帮助项目负责人提前发现卡点、安排动作和准备升级。

项目背景：
[项目名称、目标、当前阶段、计划交付时间、项目负责人、关键部门]

原始材料：
[粘贴已脱敏的项目计划、任务状态、会议记录、群聊/邮件摘要、数据反馈]

请按以下表格结构输出：
1. 风险编号：R1、R2、R3。
2. 风险名称：20 字以内，写成具体问题。
3. 事实来源：来自哪份计划、哪条任务、哪场会议、哪封邮件、哪条反馈。
4. 风险信号：延期、无人负责、依赖未确认、范围变化、质量异常、资源冲突、外部承诺不清等。
5. 影响范围：客户、收入、上线、交付、体验、合规、成本、团队节奏。
6. 严重程度：高 / 中 / 低，并说明依据。
7. 最晚处理时间：什么时候之前不处理就会扩大影响。
8. 当前责任人：如果材料没有明确负责人，写“待确认”。
9. 下一步动作：找谁确认、补什么资料、开哪个会、做什么预案。
10. 是否需要升级：不需要 / 观察 / 建议升级 / 立即升级。
11. 建议升级口径：一句话说明事实、影响、请求和截止时间。
12. 复盘记录：暂留空，等处理后填写结果。

限制：
不要制造恐慌，不要替负责人背锅，不要把推断写成事实；如果材料不足，请直接标注。

案例一

市场活动上线前，AI 提前发现了三个隐性风险

一家 B2B 公司准备下周三发布一场线上活动。市场负责报名页和推广，产品负责演示环境，销售负责邀约重点客户，客服负责活动当天答疑。项目负责人每周开会时，大家都说“基本按计划”。

他把项目计划、任务状态、最近两次会议纪要和项目群摘要交给 AI 生成风险雷达。AI 没有直接写“活动会失败”，而是列出三个风险信号：演示环境还没有完成内部验收；销售邀约邮件里承诺了一个产品功能，但产品演示范围没有包含；客服 FAQ 仍停留在旧版本，没有活动当天的异常处理口径。

项目负责人逐条核实后发现，三个风险都是真的。最后他安排产品第二天中午前确认演示范围，销售修改邀约口径，客服主管补活动 FAQ，并把“演示环境未验收”列为观察风险。活动没有因此变成危机，反而因为提前暴露问题，减少了上线当天的混乱。

案例二

客户交付项目里，风险雷达把“互相等待”变成了明确动作

一家软件服务公司正在给大客户做实施交付。合同里约定月底完成第一阶段验收。交付团队说还在等客户提供数据，客户成功说客户在等产品确认字段，产品说字段需求来自销售承诺，销售说客户只是初步提过。每个人都有理由，但项目已经停了四天。

PMO 把合同节点、任务系统、客户邮件摘要、实施会议纪要和内部群聊整理给 AI。AI 生成的风险雷达里，最关键的一条是：“验收数据字段责任边界不清，影响月底验收和回款节点。”事实来源包括客户邮件、实施会议待确认项和任务系统阻塞状态。

PMO 没有让 AI 判断谁对谁错，而是用升级模板生成了上级汇报：目前不是单一部门进度慢，而是客户数据字段的定义、确认人和验收口径都不清。最后项目 Sponsor 组织 30 分钟风险会，指定客户成功负责客户确认，产品负责字段可行性判断，交付负责验收样例，销售负责澄清原承诺。四天互相等待变成了三条有截止时间的动作。

老板验收

老板看风险雷达，不是看字多，而是看能不能管

老板或业务负责人验收风险雷达时，不需要纠结每一句话是否漂亮。重点是看它能不能支持管理动作：风险是否可追溯，影响是否清楚，责任是否明确，升级是否及时，预案是否有选择。

一张不可用的风险雷达，常见问题是风险很多但都很虚。比如“进度存在不确定性”“资源可能不足”“需要加强协同”。这些话看起来稳妥，却不能告诉任何人该做什么。一张可用的风险雷达，应该让老板看完就能问出具体问题：这条风险谁今天确认？这件事是否需要我拍板？如果明天还没解决，方案 B 是什么？

老板还要检查 AI 边界是否清楚。凡是涉及延期、客户承诺、预算、人员增补、范围缩减和合规风险的地方，都不能只靠 AI 建议。AI 可以把选项和影响列出来，最终接受哪个风险、投入多少资源、对外怎么说，必须由人负责。

常见错误

新手做风险雷达，最容易踩这八个坑

风险雷达做不好，通常不是因为 AI 不够强，而是人给的材料、边界和验收标准不清。AI 会顺着输入工作，如果你只给它模糊材料，它就容易输出模糊判断；如果你没有要求事实来源，它就可能把推断写得像事实。

另一个常见问题，是把风险雷达做成追责表。这样团队很快就会抵触，大家只报好消息，不报真实卡点。风险雷达的目的不是让某个部门难堪，而是让项目负责人更早看见影响，给团队争取处理窗口。

还要避免过度预警。不是所有小延迟都要升级给老板。风险雷达要分层：低风险记录观察，中风险安排动作，高风险准备升级和预案。否则老板每天收到一堆小问题，很快会忽略真正重要的风险。

检查清单

开始前、输出后、升级前，各查一遍

项目风险雷达要稳定使用，最好配三类检查清单。第一类是开始前检查，确保输入材料足够。第二类是输出质量检查，确保 AI 没有把不确定内容写成结论。第三类是升级前检查，确保同步出去的信息准确、克制、可行动。

这三类检查清单可以让团队降低试错成本。尤其是刚开始用 AI 做项目管理时，不要追求一次生成完美结果。先让 AI 出初稿，再用清单逐项检查，这比让 AI 自己“保证准确”可靠得多。

如果你是 PMO 或运营负责人，可以把这些检查项固化到项目周会前。每次周会前 30 分钟更新风险雷达，会议上只讨论高风险和需要拍板的事项。这样会议会更短，决策会更集中。

复盘机制

风险关闭后，别急着删掉，要留下复盘记录

风险雷达最容易被忽略的一列，是复盘记录。很多团队一旦风险解除，就把它从看板里删掉。短期看很清爽，长期看很可惜，因为团队失去了改进机制的证据。

复盘记录不需要写成长报告。它只要回答几个问题：最早的风险信号是什么，发现是否及时，实际影响和预估是否一致，哪个动作有效，哪个动作无效，下次应该提前监控什么。几次项目做下来，团队就会知道自己的风险高发点在哪里。

AI 可以帮忙把处理过程整理成复盘记录，但不要让它替团队下责任结论。复盘的目标是改进项目机制，不是事后追责表演。比如发现每次都卡在客户验收口径，就要更新合同模板、启动会清单或客户确认流程，而不是每次都怪交付同事。

请根据下面项目风险处理记录，生成一份复盘记录，用于更新项目风险雷达和团队机制。

风险条目：
[粘贴风险编号、风险名称、事实来源、影响范围、严重程度、责任人、升级记录]

处理过程：
[粘贴确认动作、会议结论、负责人回复、预案选择、实际结果]

请输出：
1. 最初风险信号是什么。
2. 哪些信号被及时发现，哪些发现晚了。
3. 实际影响是什么，和预估是否一致。
4. 哪个动作有效，哪个动作无效。
5. 责任边界：谁负责判断，谁负责执行，谁负责拍板。
6. 下次应该提前监控什么。
7. 需要更新的模板、会议机制、任务字段或升级规则。

限制：
复盘用于改进机制，不用于追责表演。没有证据的结论写“待确认”。

团队落地

把风险雷达嵌进项目节奏，而不是额外增加负担

风险雷达如果变成一份额外文档，很快就会没人维护。最好的落地方式，是把它嵌进已有项目节奏。项目周会前更新一次，关键里程碑前更新一次，客户评审前更新一次，重大变更后更新一次。

对小项目来说，可以每周维护一次。对活动上线、客户交付、产品发布这类时间压力大的项目，可以每天维护一次。维护频率不是越高越好，而是要匹配风险变化速度。风险变化快，就多看；项目稳定，就少看。

角色也要提前分清。项目负责人负责确认风险和动作；PMO 或项目协调人负责收集材料和维护表格；各部门负责人负责确认自己领域的事实和承诺；老板或 Sponsor 只处理高风险和需要拍板的事项。这样风险雷达才不会变成一个人单独表演。

1. 项目启动会：确定风险雷达字段、更新频率和责任分工。
2. 每周例会前：收集材料，让 AI 生成初稿。
3. 例会中：只讨论中高风险、责任空缺和需拍板事项。
4. 例会后：把动作写回任务系统，明确负责人和截止时间。
5. 风险关闭后：补复盘记录，更新模板和流程。

一周计划

用一周时间，把风险雷达跑起来

不要一开始就要求全公司所有项目都使用。最稳的做法，是选一个正在推进、跨部门依赖明显、但还没有彻底失控的项目试点。一周足够让团队体验到风险雷达的价值。

第一天选项目和材料，第二天生成第一版风险雷达，第三天在项目会上使用，第四天跟踪动作，第五天做一次小复盘。这个过程不追求完美，重点是让团队看到：AI 可以把散乱信息整理成预警清单，但最后仍然由人负责判断和推进。

试点结束后，再决定是否推广到更多项目。推广前要先统一字段、模板、升级规则和复盘方式。否则每个项目都做一套表，AI 输出也无法沉淀成团队习惯。

1. 第 1 天：选择一个跨部门项目，收集计划、任务、会议和沟通材料。
2. 第 2 天：用材料整理模板做诊断，补齐缺失负责人、截止时间和事实来源。
3. 第 3 天：生成风险雷达，在项目会上只讨论中高风险。
4. 第 4 天：跟踪下一步动作，更新责任人、处理状态和升级口径。
5. 第 5 天：关闭已处理风险，补复盘记录，调整团队模板。

练习任务

今天就练：拿一个项目做 30 分钟风险扫描

练习不需要等系统上线。你可以选一个正在进行的项目，拿最近一周的项目计划、任务状态、两场会议纪要和关键群聊摘要，做一次 30 分钟风险扫描。不要追求覆盖所有材料，先让自己跑通方法。

第一轮输出后，重点检查三件事：风险是否有事实来源，责任人是否合理，下一步动作是否能在本周完成。只要这三件事清楚，这张风险雷达就已经比普通进度汇报更有管理价值。

练习结束后，把结果发给项目负责人或主管时，可以明确说明：这不是最终结论，而是基于现有材料整理的风险提示，请相关负责人确认事实、责任和动作。这样既能使用 AI 的整理能力，又不会越过人的判断边界。

最后提醒

风险雷达的目标，是让团队更早做正确动作

项目风险雷达不是为了让项目看起来更复杂，也不是为了制造焦虑。它的目标很简单：把散在进度、会议和阻塞里的信号提前整理出来，让团队在还有选择的时候做动作。

AI 在这里的边界必须一直清楚。它可以读材料、找模式、标信号、写初稿、起草升级口径、整理复盘；但它不能替人确认事实，不能替人承诺交付，不能替人判断责任，不能替老板接受风险。项目管理最终仍然是人的责任。

当团队习惯用这种方式工作后，项目会少一些突然爆雷，多一些提前沟通；少一些互相等待，多一些明确动作；少一些事后解释，多一些事前预案。这就是项目风险雷达真正的价值。