01 / 09
工程方法 · Work Breakdown Structure
WBS · 把大事拆到不能再拆
「任务拆到不能再拆、每块不超过 2 天」——这条很多互联网公司（包括米哈游员工手册）都在讲的工作法，正式名字叫 WBS，工作分解结构（Work Breakdown Structure）。它把一个大目标拆成一棵「可执行清单树」。
它不是某家公司的私有发明，而是项目管理的通用地基。下面整套讲解，我们全程用自己的 Akke 抖音获客 近 3 天（6/23–6/25）的真实工作当例子，演示怎么把一堆活儿拆成一棵树。
先记住一句话：再大的项目，只要拆到「每一片都能被一个人在一天内干完、且能验收」，就不再可怕。
「分而治之：把复杂拆成简单，把简单拆到可执行——剩下的只是把它们一个个做掉。」
WBS · 工作分解结构的核心思想
02 / 09
定义 · 它到底是什么
什么是工作分解结构
WBS = 把一个目标，自顶向下层层拆解，直到最底层是「可以直接派给一个人独立完成」的工作包（work package）为止。
1目标 Goal唯一的顶层，一句话能说清——「让 Akke 在抖音上自动获客成交」。
2交付物 / 模块 Deliverables中间层，按「要产出的东西 / 子系统」切——图文发布、私信回复、数据看板……
3工作包 Work Package（树的叶子）最底层，一个人照着就能直接动手、能验收的最小活儿。
类比：把「做一顿年夜饭」拆成 买菜 / 备料 / 炒菜 / 摆盘，再把「炒菜」拆成一道道具体的菜——拆到「某个人照着就能直接下锅」那一层就停。
03 / 09
核心 · 拆到哪算「到底」
拆到哪一层算「不能再拆」？
「拆到不能再拆」不是凭感觉，而是有三条收口法则。一个叶子三条全满足，就停手；只要还差一条，就继续往下拆。
法则 1一人日一个叶子能被一个人在 ≈1 天（最多 2 天）内干完。再大 → 继续拆。
法则 2单一责任每个叶子只挂一个人名。挂不到具体人、要几个人合力 → 还能拆。
法则 3可独立验收「做完没做完」有明确、可验证的标志（合并 / 上线 / 跑通）。说不清算不算完 → 还没到位。
同层兄弟要 MECE（不重不漏）：同一层级几个节点加起来要正好等于父节点——既不重叠（别两个人干同一件事）、也不遗漏（别漏掉某块没人管）。
04 / 09
方法 · 自顶向下剥洋葱
怎么拆：一层层往下剥
2拆成 3–7 个交付物 / 模块第一层按「要产出的东西 / 子系统」切（名词），别按「步骤」切（动词）。
3每个模块继续往下拆直到每片满足上一页的三条收口法则为止。
4给每个叶子挂人 + 估时有了人和工时，排期、进度、风险就自动浮现。
经验：第一层按「东西」（可交付物）拆，比按「先做 A 再做 B」的步骤拆 更不容易漏项——动词清单容易漏掉"没人提但必须做"的事。
05 / 09
实战 ① · 把 3 天画成一棵树
用 Akke 这 3 天演示（宽度）
🎯Akke 抖音自动获客 · 6/23–6/25 迭代
A图文内容自动发布
题库 DB 化去重 #525封面按抖音号绑定 #527多 assignee 调度 #528
B私信自动回复
网页版 DM 0to1 #554报价越权硬闸 #550心跳卡死告警 #551
C真实关注数抓取
关注列表探针 #552抓取器 + 入口 #543入库→漏斗口径 #544
D团队旅程看板
入库时延环形图 #542卡点归因纠偏 #532高意向时延分布 #530
E话术 playbook 重构
按客户回复 7 类组织 §2/§3重点关键词高亮案例评分 + 删冗余结论
这 3 天不是「一堆零散提交」——而是 5 条并行支线，每条都能再往下拆成一个个可独立交付的工作包。下一页放大 A 支线看「深度」。
06 / 09
实战 ② · 叶子 = 一个 PR
「拆到不能再拆」= 每个叶子就是一个 PR
🎯 Akke 抖音自动获客
└─ A 图文内容自动发布（交付物）
├─ A1 题库 DB 化永久去重 + LLM 补题 #525
├─ A2 封面风格按抖音号绑定 #527
├─ A3 多 assignee cron 调度 #528
├─ A4 Lark 卡片真 @ 发送人 #522
└─ A5 生成稳定性：max_tokens / retry 调优 #513 #517 #520
拿 A2 套三条收口法则
「封面风格按抖音号绑定 #527」：一人日——一天能写完合并 ✓；单一责任——一个人负责这个 PR ✓；可独立验收——合并上线后封面按号生效，能直接看到 ✓。三条全中 → 这就是叶子，不用再拆。这也是「每块不超过 2 天」那条规矩的本质：一个 PR ≈ 一个工作包。
07 / 09
价值 · 拆完之后
拆到底之后，排期和分工自己就出来了
WBS 的真正回报，是在「拆完」那一刻——下面这些原本要靠拍脑袋的事，全都变成了「数叶子」。
估时工期 = 叶子相加每片估 1 天，加起来就是总工期，不再靠拍脑袋。
分工责任到人一个叶子一个负责人，没有「这块以为别人在做」。
进度勾掉就是进度条PR 合并 = 一片叶子变绿，进度一眼可见。
对应到我们的做法
Akke 里这套是天然落地的：每个工作包 = 一个 PR，合并即「叶子勾掉」；部署记录（deploy-ids）= 验收留痕；哪条支线卡住，看哪片叶子迟迟不绿就知道。WBS 不是额外的文档负担，而是 PR 列表本来就该长的样子。
08 / 09
避坑 · 四个常见错误
拆解最容易踩的四个坑
① 拆太粗一个「叶子」要干两周——根本没拆到位，估时和验收都模糊。判据：超过 2 天就接着拆。
② 拆太细拆到「打开编辑器」这种颗粒度，管理成本反噬、得不偿失。停在「一人日 + 可验收」就够。
③ 按动词拆，漏项用「先做 A 再做 B」的步骤清单拆，容易漏掉没人提但必须做的事。第一层按「东西」拆更全。
④ 叶子挂不到人挂到「某部门 / 客户说的」而不是具体人名——没人负责、追不到，等于没拆。
一句话自检：盯住任意一片叶子，问三遍——「一天干得完吗？一个人负责吗？怎么算做完了？」三个都答得干脆，才算拆到位。
09 / 09
总结 · 谁在用 + 一句话带走
不是私房秘籍，是行业通用地基
WBS 源自 1960 年代美国国防部 / NASA 的项目管理，后被写进 PMBOK 成为标准。今天几乎所有走正规项目管理的团队都在用，只是叫法和颗粒度不同：
米哈游 拆到 ≤2 天
华为 IPD 流程
微软 Project
字节 / 腾讯 / 阿里 研发拆解
Jira Epic→Story→Subtask
NASA / 国防部 WBS 起源
目标 → 交付物 → 工作包，拆到「一人、一天、可验收」为止。
别一上来就埋头干——先把大目标拆成一棵树，拆到每片叶子都满足「一人日 / 单一责任 / 可独立验收」，剩下的就是把叶子一个个勾绿。 —— WBS · 工作分解结构