用AI拆解WBS：我把3天的活缩到了10分钟出框架+2小时调

预警：这不是教你偷懒，是教你用AI当实习生——它干活，你审核。

先说一个我踩过的坑。

大龙虾课程第二期启动的时候，我拿到了一份大概两万字的需求文档。

里面有课程目标、目标用户、内容大纲、运营方案、技术要求……各种信息混在一起。

我当时的第一个念头是：这玩意儿怎么拆成WBS？

WBS，就是工作分解结构。把一个大的项目拆成一层一层的小任务，直到每项任务都可以独立执行、有人负责、有明确的时间节点。

我以前做WBS的方式是这样的：

1. 1. 把需求文档从头到尾读一遍
2. 2. 拿着笔记本，把觉得应该做的任务一条一条列出来
3. 3. 列完之后，跟团队开会对一遍，看看有没有遗漏
4. 4. 然后再改，再对，再改……

这个过程，大概要三天。

而且每次开会，总有人会说："诶，这个你没列进去吧？"

然后我又得加。

WBS拆解这件事，本质上是一个"穷举+排序"的过程。人工做，累死还有遗漏。

我是怎么用AI做的

当时我试着把需求文档丢给AI Agent，跟它说了一段话：

帮我把这份需求文档拆解成WBS。

拆解的原则：

• • 按交付物分解，不是按动作分解
• • 每个任务时间颗粒度在2小时到2天之间
• • 每层分解逻辑清晰，不交叉

输出格式：

• • 第一层：阶段（启动/规划/执行/收尾）
• • 第二层：交付物
• • 第三层：任务（带工时和风险标注）

它给我返回了这样的结构：

第一阶段：启动（0-3天）

交付物1：项目立项报告

• • 任务1.1：需求文档评审（2小时）
• • 任务1.2：资源盘点（1小时）
• • 任务1.3：立项文档撰写（2小时）
• • 风险点：技术评估还没完成，工时预估可能有偏差

交付物2：项目沟通群

• • 任务2.1：确定核心成员名单（1小时）
• • 任务2.2：创建飞书群并邀请成员（0.5小时）

第二阶段：规划（4-10天）

交付物3：课程大纲

• • 任务3.1：内容框架设计（1天）
• • 任务3.2：每个章节的学习目标拆解（1天）
• • 任务3.3：大纲评审并定稿（0.5天）

……（后续省略）

我当时愣了好一会儿。

结果发现，它不光拆了任务，顺手把风险点和资源需求也标出来了。

我以前做WBS，要么忘了标风险点，要么忘了标资源。AI一次全给我标出来了。

但第一次不是完美的

我用了一次之后，发现一个问题。

它拆出来的WBS，颗粒度不太对。

有些任务拆得很细，比如"创建飞书群并邀请成员"这一步，它拆成三条；有些任务又拆得很粗，比如"课程大纲设计"，直接就是"1天"。

我跟AI Agent说了这个反馈：

"颗粒度不一致，有的太细，有的太粗。我需要的是：每个任务的时间颗粒度在2小时到2天之间，不超过2天。你能帮我再调整一下吗？"

它重新调整了一遍，把超过2天的任务继续拆细，把太细的任务合并。

调整完之后，颗粒度一致多了。

说白了，我定标准，它干活。我盯结果，它改细节。

还有一个我想不到的

我后来发现AI Agent做WBS，还有一个我没想到的价值：

它能帮我发现"隐性任务"。

有一次我让它拆一个大龙虾课程的WBS，它返回的结构里，有一条是我完全没想到的：

"交付物X：课程上线前的压力测试与备用方案"

我当时觉得很奇怪：课程又不是软件，为什么要做压力测试？

它跟我说：

"课程上线涉及直播平台并发，如果预估观看人数超过平台上限，需要提前跟平台申请扩容，或者准备录播备用方案。这是一个需要提前确认的风险项，建议在WBS里体现。"

我去跟运营确认了一下，他说："对，我们确实没想过这个问题，确实需要提前跟平台确认。"

这种"提醒我发现不了的风险"的价值，有时候比拆任务本身还大。

但它也给我整出过笑死人的活

有一次我让它帮我拆一个市场活动的WBS。

它给我返回的结果里，有一条任务叫"活动庆功聚餐准备"。

我盯着这条任务看了三秒钟，不知道该笑还是该哭。

最后我把这条删了。

得，删了完事。AI再强也不知道你们有没有聚餐文化，这种事儿还得你自己拍板。

我现在的WBS工作流

现在我做WBS的方式是这样的：

第一步：把需求文档或项目背景丢给AI Agent，让它先出一版WBS

我给它一个标准模板，告诉它拆解的原则和颗粒度要求。

第二步：检查AI出的WBS，跟团队同步，确认有没有遗漏

AI不是万能的，它不知道你们团队的特殊情况。所以我一般在AI出的WBS基础上，跟团队开一个快速的评审会，补充遗漏的部分。

第三步：把确认后的WBS录入飞书多维表格

录入之后，我自己每天花两分钟扫一眼，看看有没有延期的。暂时还没全自动化，但框架出来已经省了80%的力了。

整个过程，从拿到需求文档到WBS定稿录入表格，大概需要：

• • AI出框架：10分钟
• • 人工微调+团队评审：2小时

以前纯人工做要三天。现在同样的工作量，我花了两个半小时。

你要觉得有用，下面这个prompt直接拿去用

请帮我把以下项目需求拆解成WBS（工作分解结构）。

项目背景：
{简要描述项目是什么、目标是什么}

拆解原则：
1. 按交付物分解，不是按动作分解
2. 每个任务时间颗粒度：2小时到2天，不超过2天
3. 每层分解逻辑清晰，不交叉
4. 每个任务标注：预估工时、所需资源、风险点（如有）

输出格式：
- 第一层：项目阶段（启动/规划/执行/收尾）
- 第二层：交付物
- 第三层：具体任务（带工时和风险标注）

请先输出WBS结构，我检查后会告诉你需要怎么调整。

改改项目背景信息，直接能用。

三个让我少返工的核心感悟

感悟一：WBS不是一次性工作，是持续迭代的

很多人以为WBS是在项目启动的时候做一次就够了。但实际上，WBS应该随着项目的推进持续更新。有些任务是在项目过程中才发现的，不是一开始就能想到的。AI的价值，是帮你把每次更新的成本降到最低。

感悟二：好的WBS不是"没有遗漏"，是"遗漏了也知道"

没有任何WBS能做到完全没有遗漏。好的WBS是：即使有遗漏，你也能在项目推进的过程中快速发现、快速补充。我现在的做法是：把WBS录入飞书多维表格，然后自己每天扫一眼进度，一旦发现计划外的任务，就更新WBS。

感悟三：WBS的本质是沟通工具，不是控制工具

很多人把WBS当成控制团队的工具——我拆好了，你们按这个做就行了。但这种用法往往会遇到阻力：团队会觉得你在"管控"他们。WBS更好的用法是沟通工具：大家坐在一起，用WBS对齐"我们要做什么、怎么做、谁负责什么"。有了AI辅助，做WBS的成本降低了，你花在"对齐"上的时间反而能更多。

肯定有人要杠："每次项目都不一样，AI能通用？"

说实话，不能完全通用。

但以前我连框架都懒得搭，现在AI几秒钟给我一个骨架，我往上填肉就行了。这还不值？