AI 编码普及后,项目管理流程要不要重构?

上周参加了一个技术沙龙，话题是：AI 编码助手普及后，项目管理流程要不要重构。

两种声音。

一拨人说 AI 让开发效率提升了 10 倍，站会、Sprint、回顾会统统该砍。另一拨人说 AI 只是工具，项目管理管的是人的协作，流程不能省。

两种观点都对了一半。也都漏了一半。

漏的那一半是：**没算过这些流程的浪费指数。**

先算账

一个项目经理年薪 30 万。他每天花多少时间真正在做"决策"和"管人"？30%？剩下 70% 在干什么——同步进度、更新 Jira、写周报、拉会。

浪费指数 3，也就是说，你付了 3 倍的钱买信息同步。

每日站会：15 个人，每人 15 分钟。3.75 小时/天。其中真正解决阻塞的时间占比多少？不超过 20%。剩下的时间在听别人讲跟自己无关的事。

Sprint 计划会：两天。产出是什么？一个 AI 能从 Git 提交记录、Issue 状态、CI/CD 日志里自动生成的进度表。

这些东西不该存在。它们存在是因为 Scrum 指南说有。

先回头看看，项目管理到底在管什么

在讨论过没过时之前，有个前置问题值得想清楚：不管瀑布还是敏捷，传统项目管理方法论底下其实压着三个假设。

第一个假设：信息不对称。

开发者不知道产品需求的全貌，产品经理不知道技术实现有多难，老板不知道项目到底走到哪一步了。项目经理、Scrum Master、PMO 这些角色为什么存在？本质上就是为了降低信息不对称带来的协调成本。项目经理就是信息枢纽。

AI 正在干掉这个假设。用过 Copilot、Cursor 的人都有体感，AI 能理解整个代码库的上下文。Linear、Notion AI 这类工具，能自动从会议纪要里提取待办事项，直接生成进度报告。

信息不再只装在项目经理脑子里了。任何人问 AI"这个项目卡在哪"，它能根据 Git 提交记录、Issue 状态、测试覆盖率给你一个客观回答。

第二个假设：人力是瓶颈。

需求分析、设计、编码、测试、部署，每个环节都得有人盯着。项目管理的活儿，就是在人力有限的前提下，靠任务分解、优先级排序、风险管控来最大化产出。

AI 能写代码、写测试、写文档、做 Code Review。一个开发者配合 AI，产出可能超过三个不用 AI 的开发者。

项目的瓶颈悄悄转移了，从"人手够不够"变成了"决策对不对"和"上下文清不清楚"。AI 能很快实现一个功能，但"这个功能该不该做"、"做到什么程度算完"，还是得人拍板。

第三个假设：变更很贵。

瀑布模型的想法是前期把需求定义清楚，后期改起来代价最小。敏捷接受了"需求一定会变"这个现实，但用两周一个 Sprint 来控制变更的影响范围。两家打法不同，底层逻辑一样：变更需要人来处理，人力是贵的。

AI 几分钟就能重构一个模块、调整一套架构、适配一次需求变更。变更的人力成本几乎归零。

剩下的成本是认知层面的：团队理解不理解变更的背景？变更跟产品方向是不是一致的？有没有引入新的技术债？这些问题 AI 答不了。

三个假设，两个半已经被 AI 干掉了。

哪些流程确实可以砍

五步算法的第一步：质疑需求。谁提出的？为什么？

每日站会可以变成异步同步。站会为什么存在？因为 Scrum 指南说有。不是因为物理定律要求它存在。**删掉它。** 既然 AI 能从 Git、Issue Tracker、CI/CD 日志里自动抓取进度摘要，何必每天把人拉进会议室？让 AI 每天早上推一份"昨日进展 + 今日计划 + 当前阻塞"到 Slack 或钉钉就行了，只有阻塞项需要人讨论。15 分钟站会变成 3 分钟异步阅读。

需求文档可以让 AI 先起草。以前一份 PRD 产品经理得写几天，再开会评审。现在 AI 基于会议纪要、竞品分析、用户反馈，几分钟就能拉出初稿。产品经理审核修改，团队异步评论，AI 再更新。删掉从零写 PRD这个步骤。整个流程快了一大截。

Sprint 周期可以缩短。两周一个 Sprint，在 AI 加速下确实有点长了。为什么是两周？因为 Scrum 指南建议一到四周。如果 AI 几小时就能完成一个 User Story 的开发、测试、部署，两周太长了。缩短它。Backlog 按优先级排好，AI 自动分配任务，开发者配合 AI 完成，自动部署到 Staging，产品验收。团队完全可以转向更短的迭代甚至持续交付。

回顾会议可以改成数据驱动。以前回顾会全靠主观感受——这个 Sprint 感觉有点乱、测试覆盖率好像不够。用数据替代感觉。AI 能给你拉出代码变更频率、Bug 引入率、Review 响应时间、部署失败率。数据摆在那，讨论才有靶子。

哪些流程不能省

但有些流程看着低效，解决的其实是人的问题，不是效率问题。

需求澄清会议得保留。AI 能生成 PRD，但替代不了需求澄清这个环节。团队对需求的理解是不是一致？边界条件明不明确？异常场景怎么处理？这些必须坐下来聊。时间可以压缩，从两小时缩到半小时，但不能砍。

架构设计评审得保留。AI 能生成架构方案，但"这个方案符不符合公司技术战略"、"有没有考虑未来几年的扩展性"，这些需要资深工程师的经验和判断。可以让 AI 提前生成 A/B/C 方案的对比，但评审会本身不能省。

一对一沟通不仅不能省，反而该加强。项目经理跟团队成员的 1-on-1，聊的是人的状态：有没有职业困惑？跟同事有没有摩擦？对技术方向有没有疑虑？这些东西 AI 碰都碰不到。当 AI 接管了事务性工作之后，管理者的价值就落在"人"身上了。

跨团队协调也得保留。一个项目涉及前端、后端、数据、运维好几个团队的时候，协调成本不会因为 AI 就消失。每个团队有自己的优先级、资源约束、技术栈，依赖关系、接口协议、上线时间这些东西还是得人盯。可以让 AI 提前画好依赖关系图和风险评估，但会还是得开。

一句话总结新范式

想明白这些之后，新范式其实很清晰了：

AI 管"事"，人管"人"和"决策"。

任务分配、进度跟踪、代码生成、测试执行、文档编写、数据报告，这些是 AI 的活。需求澄清、架构决策、团队协调、人员成长、风险判断，这些是人的活。

项目经理和 Scrum Master 这个角色不会消失，但定位得变：从"流程执行者"变成"决策支持者"和"团队赋能者"。

落地三步走

第一步，先把 AI 工具引进来，减少事务性工作。部署 Copilot 或 Cursor，接入 Linear AI 或 Notion AI，让 AI 自动生成每日进度摘要。一两周能搞定。

第二步，简化流程。每日站会改异步，需求文档让 AI 先起草，回顾会议用数据说话。两到四周见效。

第三步，也是最难的一步，把人的精力聚焦到决策和协作上。加强 1-on-1，保留需求澄清和架构评审，有意识地培养团队的决策能力而不只是执行能力。这一步没有终点。

最后

传统项目管理没有过时，但确实需要进化。

AI 不是来替代项目经理的，是把项目经理从事务性工作中解放出来。跟踪进度、分配任务、生成报告这些事交给 AI 之后，项目经理才有精力真正聚焦在"人"和"决策"上。

一个能驾驭 AI 的项目经理，比十个只会开会的项目经理值钱得多。

这不是对未来的预测。这事正在发生。