用 AI 做项目风险预演：在真正失败之前，先把最坏情况走一遍

项目启动会上，大家往往很乐观：时间排好了，负责人定了，方案也得到支持。两个月后延期发生，复盘时却发现那些原因并不陌生——关键接口一直没有确认、真正使用系统的人没参加评审、唯一懂旧流程的同事突然请假。风险不是完全看不见，而是开工时没人愿意把失败说得太具体。

AI 可以帮助团队做一种“项目风险预演”：先假设未来的项目已经失败，再从这个结果倒推可能发生了什么。它适合补充视角、整理因果链和扮演不同利益相关者，但不能替团队拍脑袋判断概率。

风险预演的目的不是证明项目危险，而是趁修正成本还低时，把最可能让项目失控的条件说清楚。

为什么直接问“有什么风险”效果很差

这个问题太宽，AI 通常会返回预算超支、沟通不畅、技术困难等通用答案。这些词没错，却无法行动。换成一个具体场景，答案会更有价值：

现在是项目原定上线日后的第 30 天。项目没有成功上线，团队正在复盘。请分别从业务负责人、一线使用者、技术团队、法务安全和外部供应商视角，列出最可能导致失败的具体事件。每项必须包含最早出现的预警信号，不要只写“沟通不足”这类抽象词。

“沟通不足”可以被改写成“接口字段连续两次评审仍未确认，业务和技术使用不同口径”；“需求变化”可以改成“试点用户没有参加原型测试，上线前两周才发现核心流程无法使用”。只有变成可观察事件，团队才能提前干预。

先给 AI 足够的项目背景

至少提供目标、时间、范围、依赖、参与角色和不可妥协的约束。内部资料涉及客户、合同、个人信息或未公开业务数据时，应做匿名化，并使用符合组织要求的工具。

把风险从清单变成可管理的卡片

一张风险卡至少要有六个字段：风险事件、触发原因、概率、影响、预警信号、应对动作与负责人。概率和影响不必追求假精确，可以先用高、中、低，但每个等级要有团队共同理解的标准。

例如，“供应商延期”仍然太笼统。更可执行的卡片是：供应商在接口冻结日前无法提供正式环境；预警信号是连续两个周会没有演示可运行版本；影响是集成测试至少晚两周；缓解措施是第一个月准备模拟接口并设置正式环境的最晚切换日；负责人是技术项目经理。

让 AI 做四轮不同的压力测试

1. 角色压力测试：分别扮演用户、管理者、技术、安全、财务和供应商。
2. 时间压力测试：假设关键任务晚一周、一个月，观察连锁影响。
3. 资源压力测试：假设核心人员离开、预算削减或外部服务不可用。
4. 假设压力测试：找出计划中哪些结论没有证据，只是团队默认成立。

AI 列出的风险不能直接照单全收。删除与项目无关的泛泛项，合并重复项，并让最接近现场的人校正概率。模型不知道组织政治、真实能力和未写进文档的历史，它的“高概率”不等于真实统计。

别只准备“出事后怎么办”

应对动作可以分成四类：避免、降低、转移和接受。最有价值的通常是提前降低发生概率，例如在正式开发前验证最不确定的接口；其次是降低影响，例如准备手工兜底流程。对于成本高但概率极低的风险，团队也可以明确接受，而不是假装所有风险都要清零。

把风险预演变成一次 45 分钟会议

• 前 5 分钟：主持人宣布“项目已经失败”的假设。
• 接下来 10 分钟：每个人独立写失败原因，避免被资深成员带节奏。
• 再用 10 分钟：AI 帮忙聚类，但团队决定是否合并。
• 接下来 15 分钟：选出最重要的五项，写预警信号和动作。
• 最后 5 分钟：为每项风险指定负责人和复查日期。

小结：AI 负责拓宽视角，人负责承担判断

• 不要空问风险，要先假设项目已经失败。
• 把抽象风险改写成可观察的具体事件。
• 每项重要风险必须有预警信号、动作和负责人。
• 用多角色、多时间点和资源中断做压力测试。
• AI 的概率只是建议，最终排序必须回到真实团队。

风险管理不是把坏消息写满一张表，而是在坏消息还没发生时，知道下一步该做什么。

本文为读懂 AI 原创内容。使用 AI 处理项目资料时，请遵守组织的数据安全、保密和合规要求。