引子：10 倍代码不等于 10 倍工程

Google 首席软件工程师 Adam Bender 在 Google I/O 2026 的一场演讲里抛出大多数人还没来得及思考的问题：当 AI 把代码产出速度推到现有工程流程无法承载的地步，开发者生态系统里什么会最先垮掉？

他的回答直白：今天构建软件的方式，在 10 倍速度下根本行不通。AI 时代的真正赢家不是产出最高的团队，而是基本功最扎实的那些人。AI 只负责放大，不负责方向。

这场演讲串起一个大多数人没听过的概念：软件生态学，对生产软件的社会技术生态系统进行整体性研究的学科。它要求不只看技术，还要看人、看文化、看组织里那些不成文的规则。

flowchart TB
    subgraph Eco["社会技术生态系统（软件生态学的研究对象）"]
        direction LR
        Culture["工程文化<br/>组织结构 · 激励机制"]
        Practice["工程实践<br/>审查 · 测试 · 发布"]
        Tool["工具链<br/>构建 · 版本控制 · CI"]
    end

    AI["AI 放大器<br/>10x 代码产出速度"]

    Eco --> AI
    AI --> Outcome{"放大方向<br/>取决于基本功"}
    Outcome -->|"基本功扎实"| Super["放大成超能力"]
    Outcome -->|"基本功不扎实"| Mess["放大成麻烦<br/>10 倍承压点全爆"]

软件生态学：被忽视的整体视角

系统、生态系统与社会技术系统

要理解软件生态学，得先回到三个基础概念。

系统是一组相互关联的元素，按照一套规则运作，形成统一的整体。空调就是系统：恒温器知道目标温度，暖通空调负责升温或降温，房间温度合适了信号就停。

生态系统是特殊的系统，由相互依赖的行动者组成的动态网络，这些行动者与其环境共同演化，具有涌现行为和去中心化的自主性。关键点是，环境是系统的一部分，不能把两者分开。生态系统还有个特性叫"涌现"，即无法通过观察任何单独部件看到的东西，只有整体组装起来，行为才会从中涌现。

内部开发者环境就是一种生态系统：工具、服务、人、业务约束都在里面。它是一种社会技术系统，由人和技术共同构成的系统。技术加上人，复杂度激增。

康威定律：组织塑造技术

康威定律是社会技术系统领域最被反复引用的观察：组织所构建的技术，会镜像其内部的沟通结构。通俗版是，如果四个团队做同一个编译器，就会得到一个四遍编译器。

康威定律的核心不是"组织结构会影响技术"，而是"组织结构不可分割地塑造了被构建出来的东西"。价值观和文化同样影响深远：生态系统构建的是组织所激励的东西，工程文化创造了围绕开发者生态的环境。

[PATTERN] 名称：社会技术镜像
症状：技术问题反复在同一个地方出毛病，根因不在技术。
本质：组织结构、激励机制、文化价值观镜像到了技术产物里。
迁移：看到反复发作的技术顽疾，先问"组织结构和文化是不是就长成这样"，再问技术方案。

软件生态学的定义

软件生态学是对生产软件的社会技术生态系统进行整体性研究的学科。它要求把技术、人、文化、组织规则放在一个框架里看，而不是切片式地只看技术栈或只看流程。

Google 的开发者生态：文化与技术纠缠

Adam Bender 强调，讲 Google 不是为了让别人照搬，而是因为它最熟。Google 做的很多选择都是针对当时构建生态的具体需求，照搬到不同阶段、不同规模的公司没好处。

文化特质与技术栈

Google 的文化特质包括：深度工程导向、极高透明度、鼓励乐于助人、代码审查当指导机会而非批改试卷、重视标准化、持续改进、免于追责的事故复盘、可持续性优于英雄主义、自动化优于手工劳作。

技术栈则是：单体代码仓库、基于主干的开发、几乎每一行代码都从源码构建、统一的构建工具链、全球化测试自动化平台（每天数十亿测试用例）、全局"最后绿色"信号、统一的计算环境、高度规范化的开发者框架和一小组核心编程语言。

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

共享命运：超能力与权衡

"共享命运"描述的是一个生态系统及其组件之间紧密关联的程度，在高共享命运的生态里，一个组件可以影响所有其他组件。它既是技术选择，也是社会选择：不能只靠让所有人用同样技术，还要建立如何管理这些技术的社会契约。

Google 的共享命运始于单体代码仓库。所有代码提交到主干，没有分支，没有版本号。这种共享命运让一个安全补丁能在一周内修复公司里每一个应用程序，十行代码修补一百亿行应用和系统软件，像超能力。

共享命运也是一种权衡。生产环境里绝不希望一个服务拖垮所有其他服务，所以 Google 在避免"会导致级联故障的共享命运"上下了很大功夫。共享命运要找到正确的放置位置，确保它为你工作。

[PATTERN] 名称：共享命运的放置位置
症状：改一处影响全局，要么超能力要么级联故障。
本质：共享命运是技术+社会的复合选择，不是非黑即白。
迁移：问"这个共享命运放在哪里是超能力，放在哪里是地雷"，而不是"要不要共享命运"。

大规模变更：涌现属性的典型

Google 共享命运环境里最有趣的涌现属性，是大规模变更。远在 AI 出现之前，Google 内部工具就已经让一个开发者有可能修改数百万行代码，数百万行他们根本不会去读、再也不会去看、可能对其一无所知的代码。这种能力让公司能持续演化单体代码仓库，更新语言和框架，防止内部环境僵化。

大规模变更是"自动化优于手工劳作"理念的终极体现，它只有在整个生态系统协作时才可能：普及的测试文化、统一的测试平台、共同的构建工具、标准化的库、标准化的代码审查、代码仓库本身的透明度。没法指着开发者环境中某一个部分说"这就是它产生的原因"，所有部分连接在一起才是原因。

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

Adam Bender 抛出问题：如果生态突然必须在未来十八个月内吞吐 10 到 15 倍的代码量，什么会最先崩溃？

地球上每一个开发者生态系统都在经历彻底变革。过去二十五年有意演化出来的所有权衡取舍，都将被重新平衡。生成代码快 10 倍和工程开发快 10 倍是两件不同的事，工程是随时间积分的编程，加速编程环节不等于加速工程交付。

代码入库的承压点

写源代码：每个人写代码都快了，代码量就会多很多。Jeff Atwood 说过，软件是一种负债。10 倍代码，10 倍负债。

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

代码设计：如果 agent 写出了容易写但难以维护的代码，别太惊讶，这是当前的基准水平。Agent 擅长写代码，不总是从长远角度思考。

代码审查：这是一个非常人性化的流程，正在变成瓶颈。10 倍代码量，要么得到 10 倍大的变更，要么 10 倍多的变更。大多数技术负责人连五个 10 倍开发者一天的代码量都审查不过来。如果用 AI 部分替代审查，团队成员不写代码了，他们唯一遇到代码的时刻就是在审查时，而审查时的注意力又不够，谁在关注代码库的演化？没有人。

Token 经济学：Token 很贵。在大规模下，token 是必须纳入考量的实际成本。如果公司里每个人都开始用 10 倍或 100 倍的 token 会发生什么？甚至有没有看到 token 正在流向何处的可见性？

测试与版本控制

测试基础设施消耗的计算资源在 Google 从来没让 Adam Bender 满意过。每一个进入版本控制的变更都必须被测试。agent 也很喜欢运行测试，因为测试能告诉它们自己做得好不好，agent 产生了额外工作量。

更糟的是，随着代码库增长，依赖图是二次方增长，不是线性。代码库大了 10 倍，要跑的可能不是 10 倍的测试，而是 100 倍乃至 1000 倍的测试。

版本控制系统不是为性能优化的，它们为一致性和排序优化。一分钟能吃多少次提交？比想象的要少。它无法扩展到 10 倍速度。沦落到要讨论版本控制性能，说明有些事已经严重跑偏，系统性变化就是会找到每一个角落。

[PATTERN] 名称：容量型节点的二次方陷阱
症状：线性扩容预算后突然爆掉。
本质：依赖图、调用图这些图结构规模是 O(n²) 级，不是 O(n)。
迁移：线性乘 10 算预算，二次方乘 100 算容量；测试计算资源、依赖解析、跨服务调用都要按这个量级估。

意外清单：二阶效应

除了容量型节点，还有一串意料之外的挑战。

验证策略：今天的验证大概就是单元测试加一些集成测试。在 10 倍代码和 10 倍服务的世界里，集成测试会变成质量策略中最重要的部分。

布尔值合取问题：今天要发布软件，要求每一个测试都通过。当有了一百万个测试，而底层测试基础设施运行一百万测试的可靠性本身就成问题的时候，所有布尔值都必须为真才能发布软件这件事就做不到了。需要一种基于统计的方法，来判断哪些是正确的测试去运行。

超大变更：能处处重构、更换语言和框架令人兴奋。但有支撑的工作流和社会契约，能让人们管理数以百万计行的合并冲突吗？

Agent 编辑战争：一个 agent 做了一个修改，另一个 agent 跑过来说不，要做一个不同的修改。看着挺好笑，直到意识到在为两边支付 token 费用。

发布节奏：不是每天发布的团队会得到 10 倍多的软件，每次变更会变得大很多，SRE 朋友会告诉你非常大的变更非常可怕。每秒发布一次大概不会带来太多价值，收益会递减。

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

杰文斯悖论：一种资源越便宜、越高效，就用得越多。Token 的爆发就是活生生的例子。

回滚：今天回滚基本可行，是因为发布软件的速度略慢于在生产环境中检测到问题所需的时间。如果能非常快地发布，快到还没法检测到任何问题，回滚姿态会怎样？如果回滚流程依赖某个 agent 有足够的容量，而之前有人把那个 agent 的 token 预算耗尽了，导致现在无法回滚，那大概不是好事。

人人都是构建者：人人都是构建者很酷，直到必须维护所有人构建的所有东西。

技术领导力速成班：成为技术负责人之所以花那么长时间，是因为必须积累直觉、判断力和专业能力。当一个应届生踏入一个可以调用五十个 agent 的环境，却没有任何直觉和判断力时，怎么在六个月内教出十年的经验？

人类注意力：人类注意力是最宝贵的资源。以前受益于一个事实，制造麻烦的能力不会超过投入注意力的能力，现在情况已经不是这样。

[PATTERN] 名称：注意力-麻烦反转
症状：自动化的产出能力超过了人类复核能力。
本质：以前人类注意力是上限，AI 让"制造麻烦的能力"先突破了上限。
迁移：任何"自动化+人类把关"的流程都要问"如果产出速度超过人类复核速度，会发生什么"，提前设计注意力预算。

AI 是放大器，不是方向

DORA 去年的 AI 开发报告发现了一个关键关系：真正搞清楚了事情的团队，能够把 AI 的放大效应引导到有用的方向。

AI 可以给你更多，更多测试、更多文档、更多代码，也更多混乱。放大是幅度，不是方向。AI 不关心那些东西去了哪里，它就是给你更多。DORA 真正发现的是，那些基本功扎实的团队，能够把放大效应引导到有用的方向。

这就引出了问题：你对自己的基本功感觉怎么样？决策文化怎么样？技术战略呢？组织里的人今天协作得怎么样？安全态势呢？代码健康度、发布卫生、可靠性呢？AI 默认不帮你解决任何问题。如果实践是好的，它能放大它们；如果不够好，它只会制造更多麻烦。

[PATTERN] 名称：放大器先于方向
症状：AI 上线后麻烦也等比例增长。
本质：AI 只放大存量实践，不分辨方向。
迁移：上 AI 之前先评估基本功，基本功好的被放大成超能力，基本功差的被放大成灾难。

四件可思考的事与智识掌控问题

演讲给出四件可以沿途思考的事。

基础设施容量：如果不知道有多少资源可以花，就不能部署 AI，不能部署计算资源，需要好方法跟踪这些。

验证策略：不能也不应该发布没有验证过的软件。验证策略会变，集成测试会成为最重要的武器，而可能还没有趁手的工具。

隔离：会得到很多用于不同目的的代码，有些目的以前根本不用代码。不希望一个很酷的原型代码真的跑进生产环境，让好玩的东西不要影响赚钱的东西。

抽象：构建抽象是为了防止开发者做出糟糕的选择，这就是为什么有库和框架。让 agent 做大量决策会导致同样的后果，需要好的抽象让 agent 遵循，不要给它们糟糕的选择。

演讲中还有一个被反复提及的问题：随着代码库的增长，如何保持对它的智识掌控？智识掌控是指人类能否对面前的东西进行推理。这场战争至少已经输了十五年了，最大的系统早就超出了任何一个人能思考的规模。让团队里每个人画一张系统架构图，看看能得到多少种不同的版本，就是验证。

AI 这里有一个让人兴奋的想法：一个持续更新的、几乎可交互的架构空间，可以向它提问。如果把这些容量移到东海岸会怎样？如果用户增长突然跃升 40% 呢？AI 可以理解非常庞大的数据集，这里可挖掘的方向是用 AI 加深对已构建系统的理解，而不仅是让代码机器转得更快。

工程实践会变，原则才重要

工程实践不是神圣不可侵犯的。实践会变，原则才是重要的。说起来容易做起来难，如果从来没真正思考过为什么团队以这样的方式测试软件，或者为什么发布流程是这样运作的，就没法演化它。理解原则，才会给力量和信心去穿越这个 10 倍时刻。

对软件工程师来说，这是一个令人着迷的时代：工作的每一个维度都在被重新定义，比以往任何时候都更需要发挥创造力。需要技能来应对上下文管理、token 经济学、模型漂移；不能太沉迷于优化一切的诱惑，需要鼓励探索。

资深工程师们，去当导师。找到那些卡住的人，帮助他们。如果已经搞清楚了 AI 开发工作流，去分享给别人，这不是什么珍贵的秘密。技术负责人必须参与进来，帮助引导软件工程在公司的发展方向。如果关心软件质量或软件设计，必须用声音去为它发声。

现在的做法是紧紧盯着每一个树枝上的每片叶子，像照顾某种特殊生命形态一样照料每一棵树。不用多久，要管的就不是一棵树了，是整片森林。不能通过盯着单棵树来管一片森林，得把森林看作一个生态系统来管理。

系统性变化有一种特质：它在一切地方、一切事物上同时发生，大到让人觉得什么都抓不住。在一个系统里，一切皆关联，小的行动可以产生大的后果。AI 转型不是只属于公司领导者的领域。作为一线软件工程师，在这个临界点时刻，你处于决定软件工程将走向何方的核心位置。从工具到工作流，从工程实践到工程文化，如果能看清正在运转的系统，就能找到杠杆。

模式速查表

模式 一句话
社会技术镜像 反复发作的技术顽疾，根因往往在组织结构和文化
共享命运的放置位置 共享命运不是要不要，是放在哪里是超能力、哪里是地雷
容量型节点的二次方陷阱 线性乘 10 算预算，二次方乘 100 算容量
注意力-麻烦反转 产出速度超过人类复核速度时，自动化会反噬
放大器先于方向 AI 只放大存量实践，上 AI 之前先评估基本功

参考资料