用AI写了两个月代码，项目反而延期了。不是AI写得慢，恰恰相反，写得太快了。快到每周产出的代码，下一周要推翻一半重写。
这不是个例。我带团队转型AI下来，观察到一个很反直觉的现象：AI把代码生产成本打到了地板，项目管理成本反而涨了。涨得不是一点半点，是量级上的差异。
原因说起来也简单：传统项目管理管的是"能不能按时做完"，AI项目管理管的是"做的东西到底对不对"。这两件事需要完全不同的管理工具，但大部分团队还在用老办法管新问题。
变更管理，永恒的难题
在展开之前，得先说一个事实：AI时代项目管理面临的核心难题，并不新鲜。变更管理一直是项目管理的最大难点之一，变更是导致项目失败的主要原因。这句话不是我说的，是项目管理教材里写的，是几十年的行业经验总结。
传统项目是怎么对付变更的？靠摩擦力。
传统方式的变更管理九步骤：提出变更要书面记录、找客户签字确认、分析对范围进度成本的影响、沟通变更影响看能不能取消、审批人签字批准、开变更控制会议、执行后跟踪状态。每一步都在人为增加变更的摩擦系数。
这个设计的本质很聪明：让变更变得困难，客观上就降低了变更的频率。以前改一个功能，要跟开发沟通、评估工作量、排期、等开发有空，一两周过去了。沟通成本、等待成本、协调成本，这些就是摩擦力。大部分变更在摩擦力面前就自然消亡了，因为不值得。
AI把这个摩擦力打没了。
跟AI说一声，下午就能改出来。没有沟通成本，没有等待成本，没有协调成本。代价越低，改动越频繁，方向漂移就越严重。
这个判断是反直觉的：AI降低了改代码的成本，但提高了改对的成本。每次改动都可能偏离原始意图，偏离的积累速度远超想象。极简项目管理里有一句话放到现在依然成立：如果你允许变更随意发生，那么它变化的速度将超过你的想象。
我们团队经历过一个极端案例：一个后台管理模块，两周内被改了15次。不是因为需求不清楚，恰恰因为太清楚了，每天都能想到新的优化点。AI让"改一下试试"的成本几乎为零，团队就陷入了一种改动惯性，看到能改就改，没人停下来想"到底该不该改"。
问题回到了原点：摩擦力没了，怎么管变更？答案不是恢复摩擦力（那是开倒车），而是换一种方式锚定方向。
但这里有个容易被忽略的另一面。摩擦力消失不只是风险，也是机会。
需求变更不再是需要抵抗的事，而是竞争优势的来源。前提是你的需求文档是结构化的。业务说"审批规则改了，超过2天就要总监审批"，你打开判定矩阵，改一个数字，相关的流程图、状态机、测试用例全都更新一遍，半天搞定。竞争对手改一个需求要20天，你2天。客户下次找谁？找你。
所以AI时代的变更管理不是"怎么挡变更"，而是"怎么在快速响应变更的同时不丢方向"。这两个目标看起来矛盾，其实可以兼顾：靠结构化文档解决响应速度，靠场景剧本解决方向锚定。
从PRD到场景剧本
我试过很多办法控制方向漂移，目前最有效的一个是把PRD改成场景剧本。
区别在哪？PRD描述"系统应该做什么"，场景剧本描述"用户怎么用"。
举个具体例子。传统PRD会写"支持微信一键登录"，场景剧本会写"小明在地铁上打开APP想查昨晚的订单，从微信登录一键授权后直接进订单列表页，3秒内完成"。差别在于：PRD给的是功能点，场景剧本给的是一段有上下文的完整故事。
上下文才是关键。AI生成代码的能力很强，理解意图的能力并不强。你给"支持微信登录"和"地铁上3秒内完成登录"两个描述，AI产出的代码质量天差地别。前者给你一个标准OAuth流程，后者会考虑网络不稳定下的降级策略、加载状态、超时重试。
场景剧本还有另一个价值：它天然就是变更管理的锚点。传统变更管理靠流程摩擦来卡变更，场景驱动靠场景本身来判断变更。当有人提出一个新需求时，不需要走九步流程审批，只需要问一个问题：这个变更偏离了已有场景吗？偏离了就走变更流程，没偏离就是场景内的自然迭代。
但这里有个实操层面的心得。项目管理里有一条原则到AI时代依然好用：决不让步，除非交换。客户提变更，你同意了，那就得让他也在别的地方让步。不是为了为难客户，是为了让客户意识到变更是有成本的，哪怕技术成本几乎为零，它也有时间成本、测试成本、方向成本。客户越清楚这一点，提变更时就越谨慎。另外一条也值得记住：忠告不如警告。跟客户说"这个变更可能影响进度"，客户会觉得你在推诿。说"这个变更上线后如果出了问题，影响面是XX"，客户就会认真想了。
但这里有个trade-off必须说清楚。场景驱动开发能管住方向，代价是前期投入显著增加。写一个场景剧本比写功能列表费时得多，它要求PO不只想着"做什么"，还要想清楚"用户在什么情况下用、期望什么结果、异常时怎么办"。这对PO的能力要求高了一个量级。
选场景驱动意味着放弃快速试错的可能，选敏捷迭代意味着接受方向漂移的风险。我的判断是，在AI开发模式下方向漂移的代价比前期投入大得多，所以这个trade-off值得做。具体多少我没仔细统计，但体感上，场景驱动的前期准备时间大约是传统PRD的2到3倍，后期返工量大概少了六七成。
五个人跑一个项目
参考AI时代新范式：1+3Ownership模式和项目管理的思路，我们落地的是5人FDE小组：PM统筹管理、对外沟通、控版本节奏，前端和后端各一人带着AI写代码，PO专职做需求分析和场景剧本，QO全程护航质量。5个人不是接力跑，是同时跑。
PO上午产出场景，前端下午出原型，QO同步在写测试用例。不是等PO完全定义好了前端才开始，场景定义的同时前端做技术预研，后端确认接口方案，QO设计测试策略。PM全程把控节奏，不插手具体执行，但所有报价和交付承诺由PM定。
但并行有一个硬性前提：沟通成本必须足够低。不过实际上5个人坐到一起，问题就不大了。5个人坐一起都沟通不清楚，就是人有问题了。
这个模式的trade-off也很明显：5个人要高度默契，任何一个人掉链子整个链条就断了。而且初期前端和后端还是按岗位分工，后期才逐步融合成全栈的TO角色，中间的过渡期需要靠AI降低跨领域开发门槛，前端用AI写后端接口，后端用AI写前端页面，但人对架构和业务逻辑的理解不能缺。
Review什么
AI时代，Review的重心从审查产出转向审查输入。
产出是什么？是代码。代码Review这事，AI时代基本不需要人做了。变量命名规范？AI比人规范。代码结构清晰？AI比人清晰。注释完整？AI比人完整。异常处理、并发竞态这些AI容易翻车的地方，多跑几轮自动化测试也能覆盖大部分。
真正值得人花时间Review的，是你喂给AI的东西：场景剧本、上下文描述、技术约束。
为什么？因为AI生成代码的质量，几乎完全取决于输入文档的质量。你给的场景剧本有歧义，AI就生成歧义的代码。你漏写了"网络不稳定时怎么处理"，AI就不会考虑降级策略。你描述的需求上下文不完整，AI就会自作主张填补空白，而且填补的方向大概率不是你要的。
换句话说，AI时代Review的本质变了。以前Review的是"代码写得对不对"，现在Review的是"文档写清楚没有"。一个是检查产出，一个是校准输入。投入产出比完全不同：你花30分钟Review一份场景剧本，可能省掉3天因为理解偏差导致的返工。你花30分钟Review一段AI代码，可能只发现一个命名风格问题。
我们实际落地的做法是，把Review拆成两层。
第一层：场景剧本Review。 PO产出的场景剧本，前端、后端、QO各看一遍。前端看交互流程有没有遗漏的页面跳转，后端看数据流有没有缺失的接口，QO看异常路径有没有被覆盖。三个人从不同视角看同一份文档，比一个人看三遍有效得多。发现的问题当场改，改完再交给AI生成代码。
第二层：AI上下文Review。 每次把任务交给AI之前，花两分钟检查你要给AI的上下文描述。场景描述清楚了吗？技术约束写了吗？已有接口引用了吗？输出要求明确了吗？这两分钟看似多余，但省掉这两分钟，AI给你返工的代码可能要花你20分钟去修。
核心原则就一条：把Review前置到AI动手之前。Review代码是事后诸葛亮，Review文档是事前校准。前者治标，后者治本。
原型是最大的坑
AI让原型生成速度快到离谱。上午一个需求，下午就能出一个可交互的原型。但这恰恰是最大的陷阱。
客户看到原型，第一反应是"差不多了吧"。实际上可能只完成了两成。
我们踩过这个坑。有次给客户演示AI生成的原型，客户非常满意，当场要求两周内交付。团队心里清楚，原型到产品中间还有大量工作：异常处理、性能优化、数据校验、兼容性测试。但客户不理解这个差距。
后来定了一条硬规则：原型和产品代码分开管理，原型放独立分支。演示时必须说清楚"这是原型，验证场景用，距离产品化还需要XX时间"。这个"XX时间"必须给具体数字，不能说"还需要一些时间"。
规则看着简单，执行起来要很大的定力。当你花一下午就出一个看起来很完善的原型时，心里会有个冲动：直接在上面改改就能交付了。但这个冲动是致命的。原型代码和产品代码的质量标准完全不同，原型追求"看起来能用"，产品追求"各种异常情况下都能正确运行"。直接在原型上改，改出来的东西两头不靠。
从哪开始
如果你的团队正在或准备全面用AI开发，我建议从四件事开始。
第一，把手头最重要的那个项目的PRD改写成3到5个核心场景剧本。不要全改，先改最重要的几个。看看场景剧本和PRD落地时有什么区别，你自己会有体感。
第二，建立每日场景对齐会。每天早上15分钟，固定时间固定形式。关键是"只跑场景不聊技术"。这15分钟的价值不在于解决问题，在于暴露问题。
第三，统一团队的AI工具。这事儿看着小，影响很大。不同AI工具生成的代码风格差异极大，5个人用5种工具，Review成本会暴涨到不可接受的程度。选一个主力工具全团队统一用，代码风格才能统一。
第四，重新设计变更管理流程。传统九步骤的摩擦力已经被AI瓦解了，你需要一套新的锚定机制。场景剧本是锚点，但光有锚点不够，还要有一套轻量的变更评估方法：每个变更先问三个问题，偏离场景吗，影响已有代码吗，影响测试吗。用这三个问题替代九步流程，快但不失控。同时，建立确定性测试作为安全网。每次变更执行后，自动运行核心场景测试套件。测试通过说明没破坏已有功能，测试失败说明变更有问题需要回退。没有这套机制，改得再快也是在盲飞。
AI项目管理不是"用AI管理项目"，是在AI时代重新想清楚项目管理到底在管什么。管的核心从"能不能做完"变成了"做的东西对不对"，管的方法从"控流程"变成了"控方向"。
但有一件事没变：变更管理依然是最难的事。AI只是改变了它的博弈格局，从"变更有摩擦所以可控"变成了"变更没摩擦所以必须主动锚定"。搞明白这个，剩下的都是术的问题。
但还有个好消息：搞明白这个之后，你就拥有了传统团队没有的武器。快速响应变更本身就是竞争力。以前改一个需求要两周，现在两天。这个差距不是靠流程优化能追上的，是AI时代的结构性优势。前提是你得有结构化的需求文档、有场景剧本做锚点、有确定性测试做安全网。缺任何一环，快速响应就变成了快速翻车。
最后
记住一件事：AI让代码变便宜了，但判断力变得比以前更贵了。