02. 为什么 AI 时代，小团队会击败大团队？
那个关于“人月神话”的古老诅咒
在软件工程领域，有一本几十年前的圣经叫《人月神话》。作者布鲁克斯提出了著名的“布鲁克斯定律”：向一个已经延期的软件项目增加人力，只会让它更慢。 布鲁克斯当年讨论的是“人类工程师”，而今天，我们面对的是“被 AI 放大的工程师”。
这在过去是一个警告，而在 AI 时代，这变成了一个即死的诅咒。
过去，管理者还有借口：“虽然沟通成本增加了，但至少多了几双手在搬砖。” 但现在，AI 把每一双“搬砖的手”都变成了“挖掘机”。当团队里的 20 个人都开着 AI 挖掘机疯狂产出代码时，你面临的不再是人力不足的问题，而是工地拥堵的问题。
场景：周一早晨的代码评审灾难
让我们来看一个典型的管理瞬间：
周一早晨，一个 10 人的研发团队正在开站会。 在这个周末，3 位初级工程师利用 AI 辅助，每个人都生成了相当于过去一周工作量的代码。他们兴奋地提交了 Pull Request (PR)。 坐在角落里的 Tech Lead（技术负责人）看着屏幕上积压的几十个待评审文件，眼神里充满了绝望。他发现 AI 生成的代码逻辑看似完美，但在处理一个边缘鉴权逻辑时，几个人用了完全不同的写法，导致系统现在的状态像一团乱麻。
这就是 AI 带来的新问题：个体产出的“线性加速”，导致了协调成本的“指数级爆炸”。
为什么沟通成为了最大的成本？
在 “线性加速幻觉” 中，管理者认为：既然 AI 帮每个人节省了时间，大家应该更轻松才对。
现实恰恰相反。AI 加速了信息的生产，却没有加速信息的吸收。
- 代码密度的激增：以前一个工程师一天写 200 行代码，队友只要花 10 分钟就能读懂。现在他一天能生成 2000 行，队友需要花 2 小时去理解这堆逻辑到底有没有副作用。
- 上下文的稀释：团队人越多，每个人对系统整体（System）的理解就越碎片化。AI 能够快速填充细节，但它无法替人进行“上下文同步”。
我曾经历过一个项目，因为进度紧张，管理层决定临时调入另一个团队协助开发。
本意是“人多力量大”，结果却成了噩梦。新加入的成员虽然配备了最好的 AI 工具，但对业务上下文缺乏理解。在 AI 的加持下，他们迅速提交了大量代码。然而，核心团队发现，这些代码要么是重复造轮子，要么忽视了某些隐蔽的业务规则（比如历史遗留的脏数据处理）。
最终，核心团队不得不花费更多时间去开会同步、去解释为什么不能这么写，甚至重构那些“跑得通但不对”的代码。项目进度反而比原定计划更慢了。
AI 时代，组织的每一次沟通，都是对速度的征税。
重新定义：判断力密度 > 劳动力总和
在 AI 时代，小团队之所以能击败大团队，核心原因在于**“判断力密度”**。
- 大团队模式：依靠流程切分任务。产品经理 -> 交互设计 -> 前端 -> 后端 -> 测试。每个人只负责流水线的一环。AI 在这里只是加快了“拧螺丝”的速度，但并没有减少“传递螺丝”的等待。
- 小团队模式：依靠全上下文（Full Context）。一个 5 人的团队，每个人都对业务和系统有完整的理解。
当一个人利用 AI 就能完成全栈开发时，他不再需要去问后端“接口字段定义好了吗？”，也不用问运维“测试环境部署了吗？”。
他自己就能定义字段，自己就能部署环境。 他省下的不是写代码的时间，而是“等待别人回应”的时间。
5-8 人：新时代的黄金分割点
亚马逊的贝索斯曾提出“两个披萨原则”（团队人数不应多于两个披萨能喂饱的人数）。在 AI 时代，这个数字可能会进一步收缩，或者在这个数字下爆发惊人的能量。
未来的精英团队，很可能呈现这样的结构：
- 1 个架构师/Tech Lead（负责 System 的完整性与技术决策）
- 1 个产品工程师（负责 Product 价值与用户体验）
- 2-3 个全栈开发者（负责高密度的执行与落地）
他们不需要复杂的文档交接，甚至不需要每天开会。因为团队足够小，“常识”在团队内部是自动同步的。
结语：做减法的勇气
对于管理者来说，这可能是一个反直觉的建议： 如果你想利用 AI 提速，不要招更多的人，而是减少团队的依赖关系。
在这个时代，最奢侈的资源不是算力，也不是人力，而是无损的共识。
AI 无法解决“人多嘴杂”的问题，它只会让嘴杂的人吵得更快。
所以，请记住这句也许能改变你招聘策略的话： AI 时代，小团队的真正优势，是减少了“解释自己在做什么”的成本。