邓巴数与规模法则：规模改变一切
当你把任何系统的规模放大或缩小，它的性质就会改变。了解规模法则，你就不会用管理 10 人团队的方法去管理 1000 人的组织——也不会用做小产品的流程去做大平台。
**预计时间：**25 分钟读完 + 25 分钟做练习 = 50 分钟。
一、邓巴数：150 人的社交魔数
1.1 核心发现
人类学家 Robin Dunbar 发现：人类大脑新皮层的大小限制了我们可以维持的稳定社交关系的数量——大约 150 人。这不是”你认识多少人”（你可以认识几千人），而是”你真正了解、信任、能自然协作”的数量限制。
1.2 邓巴数的层级
| 层 | 人数 | 关系特征 |
|---|---|---|
| 核心圈 | ~5 | 最亲密的家人/朋友 |
| 支持圈 | ~15 | 可以信赖的伙伴 |
| 协作圈 | ~50 | 经常合作的人 |
| 邓巴数 | ~150 | 真正能维持稳定社会关系的极限 |
| 认识圈 | ~500 | 你记得名字但不太了解的人 |
| 识别圈 | ~1500 | 你见到能认出来的人 |
1.3 邓巴数在组织中的应用
- 公司：~150 人以下你可以靠”人与人之间的信任”来管理；超过这个数，必须靠正式流程
- 开源项目：核心贡献者 ~5-15 人；活跃贡献者 ~50-150 人；超过 150 人的项目会自然分化为子项目
- 部队：历史上最有效的军事单位——连队——大约 150 人
- 团队：Amazon 的”两个披萨团队”（~6-10 人）是邓巴数核心圈的体现
二、规模法则（Scaling Laws）
2.1 什么是规模法则
规模法则是系统在规模变化时属性如何变化的规律。核心原则：当你改变系统的规模时，某些属性不是线性变化的——你必须重新设计系统来适应新规模。
2.2 科技中的规模法则例子
| 领域 | 小规模（~10） | 中等规模（~100） | 大规模（~1000+） |
|---|---|---|---|
| 沟通 | 口头闲聊 | 定期的站会和群聊 | 正式的会议 + 文档 + 异步沟通 |
| 决策 | 创始人口头决定 | 产品/技术负责人分层决策 | 完整的需求/变更管理流程 |
| 代码管理 | 所有人都能改所有代码 | 代码审查 + 分模块 | 严格的权限、CI/CD、架构委员会 |
| 项目管理 | 口头任务分配 | 看板/sprint 规划 | OKR + 项目经理 + 多团队协调 |
| 测试 | 手动测试 | 自动化测试为主 | 分层测试（单元+集成+端到端+混沌） |
三、规模带来的三个核心挑战
3.1 沟通成本指数增长
团队的沟通路径是 O(n²) 的——10 人团队有 45 条沟通路径；100 人团队有 4950 条。这就是为什么超过一定规模后，必须有正式的沟通机制（文档、异步沟通、分层汇报），否则”信息在传递中失真”将成为主要问题。
3.2 协调开销 > 产出增益（超过某一点）
把一个功能从 2 个团队扩展到 4 个团队来做——交付时间不一定减半，因为协调开销增长了。这就是 Brooks 定律（后面会单独讲）的规模维度。
3.3 系统复杂度非线性增长
系统代码行数翻倍时——模块之间的接口数量可能是平方增长。这就是为什么大型系统必须有清晰的模块边界和接口规范。
四、实战案例
4.1 案例 1：创业公司突破邓巴数的阵痛
一家金融科技创业公司从 20 人发展到 200 人。
- 20 人时：CEO 认识每个人，知道每个人的能力、弱点和当前工作。决策很快——“老张，你来做这个”
- 80 人时：开始出现”CEO 不认识的人”——中层管理者出现。沟通开始需要文档和正式会议
- 150 人时：触及邓巴数——原来的”信任管理”失效了。CEO 不知道某些人是否高效
- 200 人时：必须有 OKR、绩效评估、正式的组织结构图——否则完全失控
这不是”变差了”——这是规模法则。很多创业公司在从 20 人到 150 人的过程中死于”用 20 人的方法管理 150 人的组织”。
4.2 案例 2：从单体到微服务的规模驱动
一个交易系统的演进：
- 2 个开发：单体应用完全够用——部署简单，调试方便，开发快
- 10 个开发：单体开始出现瓶颈——代码合并冲突增加、部署相互阻塞
- 50 个开发：单体完全撑不住了——拆成几个模块（不是微服务，是模块化单体）
- 200+ 开发：模块化单体也不够了，自然过渡到微服务
关键：不要在小规模的时候用大规模的方法——微服务在 5 个人的时候会严重拖慢节奏。
4.3 案例 3：API 设计的规模法则
5 个 API 端点 → 接口设计可以很随意，改起来也容易。
50 个 API 端点 → 必须有一套命名规范、版本策略、错误码规范。
500 个 API 端点 → 必须 API 网关 + 自动化文档 + 兼容性检查 + 废弃策略。
五、测验（11 题）
邓巴数（~150）表示什么？
当一家公司从 30 人扩张到 300 人——最可能发生的第一件事是？
"规模法则"的核心是？
为什么 10 人团队的沟通效率远高于 100 人团队？
创业公司应该什么时候引入正式的 OKR 系统？
5 个开发者的小团队应该用微服务吗？
邓巴数的"150"在组织中有实际应用吗？
"在大规模系统中适用小规模的做法"——这种错误叫什么？
芒格说"大公司很难翻倍"——这体现了什么？
在系统架构设计中，"规模法则"最重要的启示是？
场景题
R1. 场景：你加入了一个 15 人的 Fintech 创业公司。CTO 想引入一个完整的 Kubernetes 微服务架构 + 4 个独立的 CI/CD 流水线。你怎么看？
R2. 场景：你的公司从 100 人扩张到 300 人，原来"所有人直接找 CTO 解决问题"的方式开始失效——CTO 来不及回复。用杜巴数和规模法则怎么分析？
六、答题提示
展开提示
- Q1-3 邓巴数 = 社交认知极限；规模法则告诉我们”规模改变一切”。
- Q4-5 O(n²) 沟通路径是规模问题的主要原因。
- Q6-7 小团队不要用大方法；大组织要拆成小单元。
- Q8-10 “过度设计”和”设计不足”都是规模错配；架构要匹配当前规模。
- R1-R2 15 人用 K8s = 过度设计；100→300 人的组织必须更新管理模式。
七、本课行动清单
- 评估你的团队规模：你们的协作方式适合这个规模吗？有没有”用小规模的方法管理大规模团队”或”用大规模的方法做小规模项目”？
- 画一个”规模-复杂度”曲线：你的系统架构在什么规模下会扛不住？
- 如果你的组织 >150 人，确保有正式的分层管理；如果 <150 人，不要太早就建立僵化的流程。
- 下次做技术选型时问：“这个方案是为解决什么规模的问题设计的？我们的规模到了吗？“
八、参考来源
- ② 经典：Robin Dunbar，“Neocortex size as a constraint on group size in primates”（1992）——邓巴数的原始论文
- ③ 严肃著作：Geoffrey West，《Scale: The Universal Laws of Growth, Innovation, Sustainability, and the Pace of Life in Organisms, Cities, Economies, and Companies》——规模法则的综合性著作
- ③ 严肃著作：Frederick P. Brooks Jr.，《The Mythical Man-Month》——软件工程中的规模问题（Brooks 定律也是规模法则的一个特例）
- ④ 实用读物：J. Richard Hackman，《Leading Teams》——团队规模的心理学研究
**下一步：**看 Lesson 0016 · 古德哈特定律（进入 Part 4）。