谷歌首席工程师：二十年自然生长出来的软件工程生态，快被大模型 10 倍提速撑爆

核心观点

Google 首席软件工程师 Adam Bender 的警告很直接：今天你构建软件的方式，在 10 倍速度下根本行不通。AI 时代的真正赢家，不是产出最高的团队，而是基本功最扎实的那些人。因为 AI 只负责放大，不负责方向。

在 Google I/O 2026 的一场主题演讲中，Adam 抛出了"软件生态学"（Software Ecology）这个概念——对生产软件的社会技术生态系统进行整体性研究的学科。核心观点：

AI 默认不帮你解决任何问题。如果你的实践是好的，它能放大它们。但如不够好，它只会制造更多麻烦
人人都是构建者是很酷，直到你必须维护所有人构建的所有东西
工程实践不是神圣不可侵犯的。实践会变，原则才是重要的
作为一线软件工程师，在这个临界点时刻，你处于决定软件工程将走向何方的核心位置

什么是"系统"与"生态系统"

系统

一个系统是一组相互关联的元素，按照一套规则运作，形成一个统一的整体。系统很复杂，组件之间深度连接，每个组件有自己的自主性，可以做决策、采取行动。环境是系统的一部分，不能把两者分开。

生态系统还是一种复杂适应系统，能够随着时间增长、变化和演化。它们还有一种特性叫涌现（Emergent Property）：你没法通过观察任何一个单独部件来看清整体行为，只有当系统整体组装起来，行为才会从中涌现。

开发者生态是社会技术系统

内部开发者环境也是一种生态系统：有各种工具和服务、有带着各自想法和诉求的人、有业务约束。康威定律（Conway's Law）说得很对：你构建技术的方式，与构建它的组织结构不可分割，组织塑造了最终被构建出来的东西。

Google 的开发者生态

Google 写了内部称为"火烈鸟书"的一本书。书里有一半讲版本控制和测试，但整个前半部分都在讲工程文化。Google 有几个比较独特的文化特质：

深度工程导向
极其重视透明度，尽可能让所有文档和代码对所有人开放
鼓励乐于助人
把代码审查当作指导的机会，而不是批改试卷
极其重视标准化
相信持续改进
推崇免于追责的事故复盘
坚信可持续性优于英雄主义
自动化优于手工劳作

技术方面的几个关键实践：

单体代码仓库：几乎所有代码都在一个仓库里
基于主干的开发：每一次变更直接合入主线
构建二进制文件时几乎每一行代码都从源码构建
统一的构建工具链，每个人用一样的
全球化测试自动化平台，每天数十亿个测试用例
一个全局的"最后绿色"信号：靠一个简单的内部网站就可以告诉你任何构建的状态
统一的计算环境："在我机器上能跑"基本不可能发生

这种文化与技术的混合，造就了 Google 今天的模样——你没办法只理解其中一半而忽略另一半。

共享命运（Shared Fate）

如果要选一个一直在隐隐指导 Google 的原则，Adam 会选"共享命运（Shared Fate）"。它描述的是一个生态系统及其组件之间紧密关联的程度。

单体代码仓库

Google 公司的每一行代码，除了少数例外比如 Android 和 Chrome，都在一个共享仓库里。所有代码提交到主干，没有分支，没有版本号，一切都在一个地方。这种共享命运让 Google 能够在一个文件里应用一个安全补丁，然后知道在一周之内公司里每一个应用程序都会被修复。十行代码修补一百亿行应用和系统软件。

但共享命运并不总是好事，它是一种选择。在生产环境中，绝不希望一个服务拖垮所有其他服务，或者一个集群感染整个区域。所以在避免危险的共享命运方面下了很大功夫。

大规模变更

Google 共享命运环境中最有趣的涌现属性之一，就是大规模变更。在 AI 出现之前，Google 的内部工具就已经让一个开发者有可能修改数百万行代码。

这种能力让 Google 能够持续演化单体代码仓库，更新语言和框架，防止内部环境变得僵化。毫不夸张地说，没有大规模变更，Google 就不会是今天的 Google。做这些工具的同事干的是一种幕后英雄式的工作。

但关键在于，你如果不了解使大规模变更成为可能的那些文化组件和技术组件，你就没法真正理解它。你需要：

普及的测试文化，每个人都得写测试
统一的测试平台，你知道去哪里拿结果
共同的构建工具，你构建跟我构建结果一样
标准化的库，替换组件时不会跳来跳去找哪个版本对你有用对我没用
标准化的代码审查
代码仓库本身的透明度

大规模变更是 Google"自动化优于手工劳作"这个理念的终极体现，而且它只有在整个生态系统协作的情况下才有可能。

10 倍时刻：每一个节点都在承压

写源代码

如果每个人写代码都快了很多，代码量就会多很多，这可不是好事。Jeff Atwood 说过，软件是一种负债。所以，10 倍代码，10 倍负债。

构建系统

更多的代码、更大的系统意味着更长的编译时间。而且如果 agent 在驱动大量工作，编译次数也在暴涨。编译不是免费的，不管在时间还是计算资源上。

代码设计

你有合适的 agent 化技能来鼓励解耦吗？有合适的服务端框架来确保快速安全地组合各种能力吗？你知道你们公司里 Web 应用有多少种部署方式吗？有多少种不同的服务端框架在跑？

Agent 擅长写代码，但不总是从长远角度思考。那些代码，Adam 确定不会很好地被重构。没关系，这部分我们将来会解决。但事实是，agent 正在为我们做大量工作，我们必须每天想办法最高效地应用这些能力。

二进制大小

到了某个时候，这些 agent 化工作可能让你的二进制文件大到无法编译，或者大到没法推送到手机上。

微服务

也许你是微服务技术栈：10 倍网络流量、10 倍服务数量、10 倍通信量，准备好了吗？没有人能全身而退，规模的影响无处不在。

代码审查

当给他人施加压力时，他们的行为会变得古怪。10 倍代码量，要么得到 10 倍大的变更，要么 10 倍多的变更。你的技术负责人能维持必要的审查速度吗？大多数技术负责人连五个 10 倍开发者一天的代码量都审查不过来。

所以他们为了不当瓶颈，会开始重新安排流程，开始走捷径，确保不阻塞任何人。

测试和版本控制

测试基础设施

在 Google，Adam 从来没有对自己的测试速度满意过。代码库大了 10 倍，你要跑的可能不是 10 倍的测试，而是 100 倍乃至 1000 倍的测试。这将是一个非常有趣的挑战，而且它会在某个时刻变成你预算表上的一行。

Agent 自己也在跑测试

每一个进入版本控制的变更都必须被测试。除此之外，agent 也很喜欢运行测试，因为测试能告诉它们自己做得好不好。所以 agent 产生了额外的工作量。

部署和运营

内部 API

所有 API 突然之间都变成公开的了。Agent 不会跟你商量，它会找到 API 然后直接调用。如果你从来没有像对待公网 API 那样加固内部接口和内部数据集，agent 会找到那些你并不希望它们找到的东西。

杰文斯悖论

一种资源越便宜、越高效，我们就用得越多。Token 的爆发就是活生生的例子。我们正在把它们放到所有地方，这改变了我们怎么工作，以及怎么思考工作。

回滚

你知道为什么回滚今天基本可行吗？因为你发布软件的速度略慢于你在生产环境中检测到问题所需的时间。如果你能非常非常快地发布，快到你还没法检测到任何问题，你的回滚姿态会怎样？

人人都是构建者

当每个人都在用完全不同的工具时，公司的社会肌理会发生什么？

技术领导力速成班

当一个应届生踏入一个可以调用五十个 agent 的环境，却没有任何直觉和判断力时，什么会出错？Adam 不知道怎么在六个月内教出十年的经验。

AI 是放大器

DORA 去年 AI 开发报告的核心发现是：那些真正搞清楚了事情的团队之间存在一种关系——他们弄明白了如何让 AI 成为放大器。

AI 可以给你更多测试、更多文档、更多代码，但也更多混乱
放大是幅度，不是方向
那些基本功扎实的团队，能够把放大效应引导到有用的方向

四件可以沿途思考的事

基础设施容量：如果你不知道你有多少资源可以花，你不能部署 AI
验证策略：验证策略会变，现在是时候想清楚了。集成测试会成为你最重要的武器
隔离：让好玩的东西不要影响赚钱的东西
抽象：不要给 agent 糟糕的选择

关于"智识掌控"的难题

随着代码库的增长，我们要如何保持对它的智识掌控？智识掌控就是指，人类能否对面前的东西进行推理。我们输掉这场战争至少已经十五年了——让你团队里每个人画一张系统架构图，看看你能得到多少种不同的版本。

关于 AI 一个非常兴奋的想法：一个持续更新的、几乎可交互的架构空间，可以向它提问"如果把这里的容量移到东海岸会怎样？"

给一线工程师的呼吁

变化发生得非常快，比你们大多数人经历的都快。你们现在能做的最重要的事情之一，就是去帮助那些正在挣扎的人。资深工程师们，去当导师；技术负责人，你必须参与进来。

作为一线软件工程师，在这个临界点时刻，你处于决定软件工程将走向何方的核心位置。从工具到工作流，从工程实践到工程文化，如果你能看清正在运转的系统，你就能找到杠杆。你拥有的自主性比你以为的要多，用好这份自主性。

我的评价

这篇是 2026 年我看过的对"AI 时代软件工程"最清醒的总结。Adam 给的不是鸡汤，是一份"前线工程师的作战手册"。

1. 对前端/PC 团队最直接的几个痛点

"代码量 10 倍"在我们这里已经发生：CSS-in-JS、AI 生成组件、auto-import、copilot 自动补全……我们仓库的变更频率比三年前至少高了一个数量级。Adam 说的"10 倍代码，10 倍负债"不是危言耸听
构建/打包是真痛点：Vite/Webpack/Turbopack 都在抢构建时间，但 monorepo + 微前端场景下，单个 PR 触发下游十几个包重编是日常。建议团队层面把"哪些包需要完整构建 vs 增量构建"做成可观察的指标
Code Review 是隐形瓶颈：我们自己写代码可能只要 1 小时，但 PR 排了 2 天 review。这才是"AI 提速"没兑现的真实原因——AI 不会帮我们审 PR。Rainsho 我个人体感：把"超过 N 行的 PR 必须拆"作为硬规则，比"让大家自觉"有效 10 倍
Token 经济学是新的预算科目：Adam 说的"Token 经济学"在国内企业里还很少有人正式管。建议每个 TL 在 OKR 里加一项"AI 工具 ROI 监控"

2. 我所在团队可以马上试点的几件事

强制"测试文化"基线：Adam 说"普及的测试文化"是大规模变更的前提。建议团队层面把"PR 缺测试 = 不予合并"作为硬规则
二进制/包大小可观察性：前端场景下就是"主 bundle 大小 + 首次加载体积"做 dashboard，超过阈值就报警
Code Review 时长分布：在 GitHub/GitLab 里统计每个 PR 从"提交"到"合并"的等待时长，按团队/模块分桶
内部 API 最小权限原则：agent 化时代，每个内部 API 默认公开就是出事现场。让安全团队做一次"如果 agent 来了，哪些接口会出事"的红队演练

3. 与 Rainsho 之前关注"bottom-up 提效"的关联

我之前一直琢磨的"个人贡献者能做哪些团队效率提升"，和 Adam 这篇的逻辑完全对齐：

工具/流程/文化是耦合系统，单点优化没用（康威定律）
真正能撬动系统的，是看清"涌现行为"——比如"团队里每个人画的架构图都不一样"这种真实信号
不用等老板，资深工程师要主动做导师——这正是 Rainsho 能发挥的作用：把 AI 工作流经验教给团队里还在摸索的人

4. 最重要的引用

你拥有的自主性比你以为的要多，用好这份自主性，为你的组织、你的团队和你自己去创造未来。

这一句值得打印贴在显示器上。