Gergely Orosz 最近去了趟 Anthropic。
他采访了四名内部人员，想看一件事：当一家造 AI 的公司开始大规模用 AI 写软件，它自己的研发组织会先变成什么样？
答案里有一组很奇怪的组合。
代码审查和测试越来越多交给 AI；团队同时推进更多项目；单个项目最多只有两名工程师。可另一边，两个披萨团队仍然活跃，复杂项目照样写 PRD，规划和上下文切换也一个没少。
所谓两个披萨团队，就是一个团队小到两张披萨大致够吃。外卖预算只是个形象说法，重点是控制团队规模，让沟通保持直接、责任保持清楚。
既然一个项目只需要一两名工程师，为什么还要保留一个更大的稳定团队？
这组看似矛盾的变化，可能比任何代码生成演示都更接近软件开发的未来：
AI 缩小的是项目执行单元，不是责任单元。
项目变薄了，团队没有
过去做一个项目，最直接的提速方式是加人。
前端、后端、测试、基础设施各来一个，复杂一点再加项目经理和安全同学。人越多，理论吞吐越高；同时，会议、等待和信息损耗也一起增加。
Agent 改变的是这笔账。
一名工程师可以同时让几个 Agent 查代码、写实现、补测试、跑迁移，再让另一个 Agent 做审查。过去必须分给不同人的执行动作，现在可以在一个人的终端里并行完成。
我自己用 tmux 调度 Codex 和 Kimi 时，也感受到过这种变化。一个窗口负责决定目标，几个窗口分别执行、回读和验收。从屏幕上看，像突然多了一个小组；但真正决定优先级、处理冲突、判断结果能不能合并的，仍然只有一个人。
这也是“项目”和“团队”第一次需要被认真分开。
项目是为了交付一个结果临时形成的执行单元。团队则是稳定的上下文容器：谁理解这套系统，哪些边界不能碰，事故由谁接住，新人从谁那里学会判断。
有了 Agent，项目可以缩到一两名工程师；但这些人仍然需要属于一个稳定团队。否则每个项目都像临时拼出的剧组，拍摄速度很快，拍完以后没人记得布景为什么不能拆。
写代码变快，验证没有
Anthropic 内部变化里，对普通团队更有用的问题在于：原来分给更多工程师的工作量，究竟去了哪里？
在 Bun 从 Zig 重写到 Rust 的个案中，真正把代码翻译出来只占大约 15% 的时间；剩下约 85%，花在修编译、补问题、跑测试和验证行为是否一致。
15/85 看上去不像一张提效海报，更像一张工程账单。
代码生成突然便宜以后，验证立刻成为最大支出。
Jarred Sumner 为这次重写安排了多轮 AI 代码审查、11 次安全扫描、模糊测试，以及和实现会话隔离的测试。Bun 团队的自动化更往前走了一步：新 Issue 会先让 Agent 尝试复现；能复现才继续修；提交 PR 前必须证明测试在旧版本失败、在修复版本通过；没有测试的 PR 直接拒绝。
这套流程里，AI 不只写代码，也在审 AI、测 AI。但模型之间达成一致并不构成信任，可检查的证据链才构成。
这也是为什么不能把“一两名工程师一个项目”简单翻译成裁员公式。
如果公司只是把项目人数砍到两人，再给他们开十个 Agent，却没有独立测试、审查隔离、失败回流和明确的合并责任人，最后只会得到一台高速生产返工的机器。
项目人数可以减少，验证系统不能缩水。
规划没有消失，只是换了位置
另一个容易被误读的变化，是“边做边设计”正在增加。
AI 让原型太容易了。过去需要先讨论几天的交互和接口，现在一名工程师半天就能做出可运行版本。设计因此更像持续动作，而不是开工前一次性完成的仪式。
但这不代表规划已经过时。
Gergely 报道的另一个项目是 Claude Managed Agents。这是一套让客户在云端或自有基础设施上运行生产级 Agent 的底层能力，远比一个 CLI 复杂。项目从想法到发布用了大约六个月，最大的工作仍然是规划；中途也照样因为认识变化而重构架构。
简单原型可以先跑起来，复杂基础设施仍要先想清楚。AI 只是让错误方向也跑得更快。
我也踩过相似的坑。让多个 Agent 并行以后，写代码的人手突然不缺了，“哪件事值得先做”却成了新瓶颈。如果目标和验收条件没写清楚，四个窗口不会带来四倍进度，只会同时制造四份需要重新理解的上下文。
所以我后来把 Issue 当作 checkpoint：目标、当前状态、证据、下一步和风险都写进去。Agent 会换，会话会结束，但项目不能跟着失忆。
稳定团队的价值也在这里。它不再主要提供更多双手，而是提供一套不会随会话关闭而消失的共同记忆。
普通团队真正该改什么
Anthropic 是一个极端样本。它有最新模型、充足算力，也有最愿意试验 Agent 的工程师。普通公司不能看到“两个人做项目”，就直接把它抄成人力预算。
更值得抄的是三层分工。
第一层是稳定团队。它负责系统边界、技术方向、共享知识、人员成长和事故责任。团队不必围着一个项目转，而是可以支持多个更薄的项目单元。
第二层是一两名工程师组成的项目单元。他们定义目标、拆任务、协调 Agent，并对结果做最后判断。这个角色远超“提示词操作员”：他必须最了解问题，还要能看见下一层系统。
第三层才是 Agent。它们负责搜索、实现、测试、审查和重复执行，但每项工作都必须留下可回读的结果：测试、日志、差异、截图或运行状态。
Anthropic 对约 40 万次 Claude Code 会话的研究也给出相似结论：典型会话里，人主要决定“做什么”，Claude 主要决定“怎么做”；领域经验越深的人，越能让 Claude 完成更多工作。
新型工程师并不是最会背提示词的人。他要能同时做两件看起来相反的事：把执行尽量交出去，把判断牢牢留在手里。
这也解释了为什么造 AI 的人最先被 AI 改造，却没有因此取消团队。
当代码越来越便宜，真正稀缺的会变成三样东西：值得做的目标、证明结果正确的证据，以及出了问题愿意负责的人。
未来最小的项目也许只需要一个人和一群 Agent，但再小的项目，都不能没有一个真正的负责人。
如果一个项目只剩你和一群 Agent，最后那个“合并”按钮，你敢交给谁？
参考资料：
The Pragmatic Engineer：《How building software is changing at Anthropic》
https://newsletter.pragmaticengineer.com/p/inside-anthropic
Anthropic：《How Anthropic teams use Claude Code》
https://claude.com/blog/how-anthropic-teams-use-claude-code
Anthropic：《Agentic coding and persistent returns to expertise》
https://www.anthropic.com/research/claude-code-expertise
