我把WBS拆解交给了AI,现在拆一个项目只要20分钟

上周让 AI 拆一个项目的 WBS。二十分钟，出来一棵树：三个阶段、四十几个工作包，每个带工时、责任人角色、一句话验收标准。整齐得让我有点得意。

拿去评审，甲方技术负责人看了半分钟，问了一句：“联调在哪？”

我翻了一遍。没有。

一、它为什么必漏这三类

AI 的依据只有你给的材料。材料里写了什么，它就拆什么；没写的，它不会替你想到——它不知道还有别的。

而这三类活有个共同点：不在任何一份需求文档里。

① 验收配合。客户来验之前的资料准备、演示环境、验完之后的整改回复。这些没有一行代码，但要占人。

② 返工。一次通过是理想状态。现实里首轮评审被退回、首轮测试挂掉，重做的时间从来不在计划里。

③ 沟通协调。例会、跨部门对齐、等审批、催第三方。它们分散在每一天，加起来能顶一个人的全部工时。

我在自检表里把它们做成了固定清单项，每次拆完对着数一遍。这个动作花五分钟，能挡掉后面两周的意外。

还有一类更隐蔽：项目管理本身的工作。例会、评审、汇报、变更处理，这些是项目在跑，不是项目在做。AI 不会把它们拆成工作包，因为没有哪份需求写着“开 12 次周会”。但它们确实占着人的时间。

二、第二道闸是颗粒度

就算活没漏，颗粒度不对一样没法管。我自己卡的是 8/80：一个工作包，下限 8 小时，上限 80 小时。

小于 8 小时，是动作级。“发邮件”“建个群”“开个会”，这类东西进个人待办，不进 WBS。写进去只会让表变长，不会让项目变清楚。

大于 80 小时，是黑箱。两周以上的包，干到一半算百分之几，全凭一张嘴。等你发现它延期，往往已经到了收尾那一周。

8 到 80 小时，正好是“一个人一到十天，能交付一个可验收的东西”。估得准、分得出、查得动。

这条线不是为了好看，是为了让延期能被提前看见。一个 30 小时的包，干到 15 小时你能判断是不是要慢；一个 400 小时的包，干到 200 小时，你判断不了任何东西。

AI 拆完，常见的情况是一头一尾都超标：底下挂着一堆 0.5 小时的动作，上面顶着一个“完成系统开发”的 400 小时大包。这时候别急着用，先让它按 8/80 自检一遍，把超标的标出来。

三、我现在怎么用

三步，二十分钟。

① 喂料时先要清单。提示词里加一句“先列出这类项目容易漏的工作包，再开始拆”。顺序很重要：先让它想漏什么，再让它拆；反过来，它拆完就收工了。

② 拆完照表往回数。三张表：颗粒度、完整性、假设与责任。前两张挡漏项和黑箱，第三张挡“假设错了整个 WBS 要重拆”。

③ 假设逐条问人。它末尾会列三条关键假设，比如“老系统接口不用改”“关键人在本项目全职”。这三条拿去问核心成员，一条不成立，回去重拆。

我踩过的坑就在①：一开始我把“先列易漏清单”放在末尾问，AI 拆完就懒得再回头。挪到开头之后，漏项少了一半。

时间不是凭空省下来的，是挪到了这三步上。以前拆完直接发出去，现在拆完还要过一遍——但那半小时，比事后补两周便宜得多。

回到那棵树

AI 拆得整齐，每一层都对，末端那一排光点看着密密麻麻，像都拆到位了。

但底下有三颗它自己点不亮：验收、返工、沟通协调。它不知道有这三类活，所以不会主动告诉你它漏了。这是它的能力边界，不是它的错——它只是不知道，一份需求文档之外，项目还长什么样。那三颗得你自己点上去。

拆完不是结束，是照着清单往回数一遍。数出那三颗，这个 WBS 才算能用。

口径说明：

①8/80 规则、范围全覆盖原则为 WBS 分解的通用实践，不是本人独创；本文的阈值与自检表为本人自用版本，可按项目规模调整；

②“二十分钟”“四十几个工作包”为本人单个项目的实际耗时与规模，不同复杂度项目差异较大，不作为普遍承诺；

③文中评审对话为真实场景，已做脱敏处理，不涉及具体客户与项目名。

更新时间：2026-11-03

参与说明：本文由本人选题、实测与定稿，写作过程中使用 AI 辅助梳理结构与措辞，拆解过程与自检结论来自本人项目实践。