别被 AI 生成代码的速度骗了，用 PERT 估算法对冲集成风险
这种现象的本质是：AI 把不确定性从“实现难度”转移到了“集成成本”上。以前我们担心的是“这个功能怎么实现”，现在我们担心的是“AI 写的这几百行代码里到底藏了多少逻辑地雷”。
在这种环境下，我建议大家重新捡起最传统的 PERT（三点估算法）。因为在 AI 时代，单一的预估数字几乎没有参考价值，你必须强迫自己量化那种“说不准”的焦虑。
具体操作时，针对每一个任务模块，你不能只给一个数字，而要拆解出三个维度：
首先是乐观值（O）。这是指 AI 生成的代码一次性命中，无需大幅修改，直接跑通的情况。在 Copilot 或 Cursor 的辅助下，这个数值确实大幅下降了，很多样板代码几乎是秒出。
其次是最可能值（M）。这是基于以往经验的预估，即 AI 帮你搭建框架，但你依然需要花时间修 Bug、对齐业务逻辑并调整细节。
最后是悲观值（P）。这是最关键的，指 AI 产生了极其隐蔽的幻觉，代码在隔离环境下看起来完美，但在集成测试时彻底崩盘，导致你不得不推倒重写。
当你拿到这三个值后，使用这个加权平均公式来计算期望值：Expected Duration = (O + 4M + P) / 6
这里有一个非常危险的心理陷阱：因为 O（乐观值）现在变得极低，很多开发者在潜意识里把 O 当成了 M，甚至直接把 O 作为最终交付日期报给了客户。但事实是，AI 并没有消除工作量，它只是重新分配了工作量。你节省了敲键盘的时间，却增加了审阅代码（Code Review）的时间。
最可怕的失败模式已经发生了变化。以前的失败是“功能太难，实现不出来”；现在的失败是“AI 信心满满地写错了，且在集成前没人发现”。这种隐蔽的错误会导致一个项目在 90% 的进度看起来都非常顺利，但最后 10% 的集成阶段却卡死了 90% 的时间。
因此，在 AI 驱动的开发流中，你的 P 值（悲观值）应该比以前设得更高。你必须意识到，AI 生成的代码行数越多，潜在的逻辑漏洞就越多。如果一个模块由 AI 快速生成了 500 行代码，而你只花了 5 分钟扫了一眼，那么这个模块的 P 值应该被显著拉高，用来对冲那些隐藏在代码行之间的风险。
回归 PERT 估算法，本质上是在承认 AI 的不确定性。不要被瞬间生成的代码量蒙蔽，把重点放在对 P 值的审视上，才能在 AI 时代拿回对项目进度的掌控权。
