AI demands more engineering discipline. Not less

AI 需要更多的工程纪律。而不是更少

如果你经历过从手工打造的服务器宠物向不可变基础设施转变的时期，你现在应该能感觉到某种奇怪的熟悉感。

Charity Majors

2026年6月15日

几天前，我写了一篇文章，标题是“AI爱好者正在与时间赛跑，AI怀疑者正在与熵对抗”。

我有关于许多AI相关主题的笔记，希望深入探讨：AI法规、沟通规范、代码审查、AI艺术等等。不幸的是，我收到了太多对我上一篇文章的有趣回应，现在我必须先处理这些回应，才能继续讨论其他话题。😉

这些有趣的回应有两种类型：一种是基于技术的，另一种是基于伦理的。我将分别回应这两种类型。先从技术方面开始，因为这更容易。

不知何故，一些读者误以为我在告诉所有人要放弃代码审查，直接将最糟糕的代码推送到生产环境，现在立刻就做。1

这并不是我所做的事情。这也不是我认为你应该做的事情。但我选择这个例子并不是随机的，我会告诉你原因。

在2025年，问题是AI是否能够生成“好”的代码

很容易忘记，但2025年的大部分时间里，AI生成的代码是垃圾，而且可能永远都是垃圾，这种观点不仅是一个合理的立场，而且是默认的主流立场。2

这个问题在去年11月得到了明确的答案。自Opus 4.5发布以来，AI已经能够生成的代码质量大致与普通软件工程师相当，至少在常见模式上是如此，而且速度更快、成本更低。我在2026年1月从书堆中出来后意识到这一点，而在2026年的头几个月，我周围的人似乎也都有类似的领悟。

但许多人早就预见到了这一点。

主流的叙述认为，是Opus 4.5改变了这一切。但Opus 4.5更像是一个转折点。代理式框架（将大语言模型包裹在带有工具的循环中的代码）在2025年中期成为现实，其前身可以追溯到2024年底。工具使用、函数调用、MCPs……所有这些趋势在2025年逐步形成，并在年底达到了真正的通用用途可用性。

这就是去年爱好者们试图告诉我们的话。不仅仅是“这即将到来”，而且“这比你想象的要来得更快”。

事实证明，他们是对的。

第一次持怀疑态度是合理的

正如你可能知道的，我来自可靠性这一边。我会对自己和我的团队给予的赞美是，我们并不难适应新的现实。只要一个问题真实地出现在我们面前，我们就会顺利、甚至热切地进行调整，这得益于对吸收令人作呕的技术混乱的不健康热情（以及之后我们可以讲述的篝火故事）。

我会对自己和我的团队给予的不赞美是，我们有时难以接受进步是真实的，难以接受即使存在bug和边缘情况，随着时间的推移，问题空间的大部分区域确实得到了或多或少的解决，以至于大多数人可以将其视为理所当然。3

代码从一团糟变成“哇，这还真不赖”的速度，一直萦绕在我的脑海里。因为热衷者告诉我们，驾驭工程和人工智能验证是真实存在的，它已经来了，而且正以惊人的速度变得越来越好。

第一次抱着“除非亲眼所见，否则我不信”的态度是可以理解的，但第二次再这么想就不太对了。事实证明，这正是身处指数级变化曲线内侧的感觉。

2025年到底发生了什么？

我想在这里暂停一下，并非常明确地说明我认为正在发生的事情。然后我会告诉你我具体对什么感到兴奋，以及原因。

你完全没有义务和我一起认同这一点。但目前市面上有很多泛泛而谈的说法，比如“它从来都不是X”，“它一直都是Y”，“未来属于xyzzy”——我想要非常明确地说明我的观点是有条件、具体且基于上下文的。

2025年发生的事情是这样的：代码生产的经济性被彻底颠覆了。过去生成代码非常困难、耗时且昂贵，现在却几乎变得免费且即时。代码行数从被珍视、重用、精心呵护和仔细整理，一夜之间变成了可以随意丢弃并重新生成的东西。

在计算机历史的大部分时间里，人们主要通过编写代码来学习和理解软件。一旦你掌握了一定的技能，阅读和讨论代码就足以让你达到目标。（我可能会争论，软件工程师一直过于依赖代码本身，而不是通过可观测性来理解系统。）

“软件团队的真正产品是共享的理解”

许多优秀的软件工程师认为，每个（优秀）软件工程团队的真正产品始终是对我们所拥有软件的共享理解。这种理解被存储在我们脆弱的、小小的大脑中，经常被刷新到磁盘、部署到生产环境、提交到GitHub，但我们的大脑始终是意义的所在。

软件始终是一个如此强调集体主义的领域，对人际关系动态、礼仪、公平性和情感价值极度敏感，这难道令人感到惊讶吗？这正是当你的一部分大脑生活在别人的脑中，而你们的集体相互依赖性极高时的预期结果。

我喜欢这个行业的这一点。但不可否认的是，大脑对于软件开发模型的某些方面来说，是一个非常糟糕的容器。我们健忘、容易分心、不耐烦。我们不擅长发现小细节，我们很容易对重复变得习惯。最糟糕的是，我们脑海中的模型与用户所交互的世界之间存在巨大且持续的差异。

不管怎样，SRE（站点可靠性工程师）们从未真正接受过这种解释。对我们来说，每个（优秀）软件工程团队的真正产品是生产环境。

只有生产环境才是真正的生产环境。在生产环境中进行测试，否则你就是在撒谎。

（这些都是背景故事。我保证，我正在接近重点。）

然后我发现了 Chad Fowler 关于 Phoenix 架构的写作。

如果你不知道我在说什么，你现在应该诚实地停止阅读我的内容，去读他的。Chad 是在 2013 年首次提出“不可变基础设施”这一术语的人。他最著名的文章是“将严谨重新定位”，因为 Martin Fowler 在回顾 Thoughtworks 聚会关于软件未来时提到了它。我回应了他，写了一篇名为“严谨去向生产环境”的文章，抱怨他们没有充分讨论生产环境。

当我写那篇文章时，我认为“将严谨重新定位”是我读过的唯一一篇他的文章。但很快，我发现了他的其他文章，读了两三篇后，一切都突然明白了。我知道他到底在说什么。我能预测他接下来要说什么。然后，读者……我感到非常兴奋。

这一切以前都发生过，未来还会再次发生

我将给你一些 Chad 的引语样本，足够让你理解他的观点。这是来自“编程的死亡与重生”的一段话：

不可变基础设施。无状态服务。容器。蓝绿部署。基础设施即代码。这些理念都有一个共同的前提：永远不要修复正在运行的东西。替换它。AI 将这一前提从基础设施扩展到了应用代码本身。当重写成本较低时，原地编辑变得风险重重。变异会积累熵，而替换可以重置它。

另一个我最喜欢的一段：“删除测试”。

这是一个你可以应用在你所工作的任何软件系统上的简单测试：想象一下删除整个实现。大多数工程师对删除感到存在主义上的恐惧。代码感觉就像是那个东西。这是我们编写、审查、版本控制、部署和调试的内容。失去它感觉就像失去了系统本身。当人们说“我们不能就这样扔掉代码”，他们通常想表达的是更具体的意思：我们并不确切知道需要什么行为。我们不知道哪些失败是不可接受的。我们不知道哪些不变量必须始终成立。我们不知道如何判断一个新版本是否正确。我们不知道哪些错误是故意修复遗忘的边缘情况。这些问题不是代码问题，而是评估问题。当代码是唯一存储知识的地方时，代码才变得珍贵。

还有：

在软件历史的大部分时间里，将代码视为持久是合理的。我们之所以将代码视为永久，是因为生产代码的劳动是瓶颈。重写成本高昂，重新验证风险很大。随着时间的推移，实现逐渐积累了意义。结构、测试、注释、错误修复和部落知识融合成了一种你不再轻易去打扰的东西。这在生产环境是限制因素时是有道理的。当再生变得容易时，代码不再是一种资产，而是开始像一个缓存：一个在当前有用、过时时可以丢弃的理解的具象视图。

“一个在当前有用、过时时可以丢弃的理解的具象视图。”我想这可能就是让我突然明白的那一句话。

你还记得系统管理员吗？

我刚刚年长到足以让我的第一份工作头衔是“系统管理员”。我那时还是个青少年，在大学工作，那时每台机器都有 root 权限，而他们还没意识到他们绝对不应该这么做。

我亲历了从手工打造的服务器宠物到不可变基础设施的牛群的转变。当时我并没有真正理解发生了什么，但近年来我对此思考了很多。我在《可观测性工程》第二版的最后章节中写道（自6月17日星期三起即可下载！）：

从手工打造的服务器转向不可变基础设施教会了我们：可变性是理解的头号敌人。任何在原地被修改的工件都会导致漂移。漂移使得系统难以维护。我们能够杀死并重新生成基础设施组件的能力，正是我们信任它的原因。在 Honeycomb，我们每周二通过 cron 杀掉最老的 Kafka 节点。这就是我们对启动和平衡过程充满信心的原因：一切都可以重复，数据可以重新生成，承诺存储在别处。我们无法以同样的方式重新生成代码，这表明我们并不理解它。我们不知道自己做了哪些承诺，不知道哪些依赖关系会出问题。我们只能通过让它们出问题来发现它们，大多数时候都是这样。

想想你在职业生涯中浪费在痛苦迁移和重写上的那些年。想想替换承载着负载的遗留代码。想想那些“绞杀榕”式的重构。

代码行数已经做了太多。代码是开发者意图、用户期望、显式和隐式行为的捆绑存储库，是我们唯一能够记录过去错误的化石化复合记录。这已经太多了！

代码行数并不是理想的审查对象

再想想由于维护和修改代码行数所耗费的巨大代价，有多少领域被忽视了。我可以在哪里审查和讨论这些工件，以了解我们的架构是如何演进的？我们的架构工件又在哪里？如果我们能够讨论并达成一致的架构图，然后从架构的变化中重新生成代码，而不是从代码中大致推断出架构，那会怎样？

我并不是在断言所有代码最终都会由 AI 根据规格自动生成，从而绕过人类的理解。这个整个计划的可行性取决于“规格”到底是什么，或者“规格”可以是什么。任何曾经经历过痛苦数据库迁移的人都应该对我们在以可重放、可自动化的形式提取和形式化用户期望方面的能力，有了些许应有的谦卑。

但我认为，我们每向前迈出一步，都会对我们有利。

实现这一点的工具还不存在，但其中许多想法已经存在。大多数想法都来自运维和 QA，这两个领域，软件工程历史上一直对其持有些许偏见。

这些测试和方法并不是为了测试正确性或应该发生的事情，而是为了观察和编码正在发生的事情。行为测试、特征测试、捕获/重放、流量分割器。可观测性（好的那种）。

我们的头脑并不是为验证而构建的

在生产环境中存在不可确定的代码，终于迫使我们去做那些我们本应一直做的事情。使用追踪进行仪器化。在生产环境中进行测试和评估。生产环境并不是开发结束后发生的事情，生产环境是开发的一个阶段。

人类的大脑并不擅长验证。那种吹毛求疵、重复检查的特性，是我们最不该执着的地方。在软件的开发和维护过程中，我们有太多更好的东西值得去坚持和捍卫。在验证方面，我们永远无法战胜机器——我们本身就是最薄弱的环节！

在创造力、灵感、逻辑跳跃以及许多其他方面，我始终看好人类的潜力，但请千万不要把人类在软件领域中的核心优势建立在我们是“最佳质量守门人”这一点上。天啊，真的不要这样。🙈

好了，我差不多要结束了。还有一点需要说。

非确定性系统将需要更多的工程纪律，而不是更少

我认为，许多工程师在过去两年中对人工智能领域讨论感到疏离和恐惧的原因之一，是许多知名的人工智能声音似乎兴高采烈地宣称软件问题不再是工程问题。“SaaS已经死了！”“让AI在编码方面变得优秀是解锁一切的关键策略”，等等。甚至我的好友亚当·雅各布（Adam Jacob）——他几乎从不犯技术判断上的错误——也似乎预见到软件行业将面临一场血洗。9

如果2025年是“氛围编程”的一年，AI在生成代码行数方面达到了普通软件工程师的平均水平，而未来可能的范围常常让人感到不安和难以想象地广阔，那么我觉得2026年可能会回归到工程纪律。

毕竟，我们大脑中的知识在被编码进系统之前是无法被AI使用的。这些投资的回报将是巨大且非线性的。我们也许可以争论，从长远来看，这些投资本来就会自我回报。但现在，每一位CEO都迫不及待地想要分得一些AI的“蛋糕”，所以让我们把蛋糕给他们吧。纪律第一，蛋糕第二。

这是我们将工程价值观带入主流的机会

在我看来，以短而快速的反馈循环（工程纪律的标志）开展工作的软件工程团队所占的比例，一直都很小，而且一直都很小。也许只有5%？肯定少于10%。AI工具比以往任何时候都更有可能让这种情况变得更容易实现。或者，它可能实现这一点。工程纪律的投资回报是不连续的，而且足够真实，因此这种情况也许真的会发生。

至少在短期内，我不担心在缺乏工程纪律的情况下，AI会创造巨大的、不连续的投资回报。（许多人会尝试，而观察这一过程将很有趣。）

但价值是建立在持久性上的，而不是一次性使用性上，而且我认为这一点不会改变。比特是便宜、快速的，并且受逻辑和语言规则的支配，但任何有价值的东西最终都必须与物理系统达成一致：一边是持久性，另一边是用户体验。

人们并不希望每天早上登录Slack时，发现按钮和菜单都被微妙地移动了位置。人们也不希望财务交易大部分时间都能完成。确定性不会消失，我的朋友们。

AI并不是魔法。这仍然是工程。正如亚当所说，“这仍然是技术，而技术需要技术人员。”我个人很期待学习新的、有趣的工程问题，审查不同类型的工件。

而且，永远、永远不再进行那种耗时两年、令人痛苦的API重写或“ strangler fig（绞杀榕）”迁移。

P.S. 感谢所有阅读初稿并给予反馈的人：Dave Williams、Chad Fowler、Adam Jacob、Mark Ferlatte、Austin Parker、Erwin van der Koogh、Ankur Bhatt。

我上一篇文章并不是试图保持中立或公平对待所有人，只是想对每个人表示基本的礼貌。但我觉得这揭示了我被指责的次数：被怀疑者指责“对怀疑者过于苛刻”，被热情者指责“对狂热者过于苛刻”，有时甚至只是简单地说“有些人无法接受现实，真让人难过”，却不说他们指的是哪一方。天哪。

2025年3月，Fred Hebert和我在SRECon上做了闭幕主题演讲，我们告诉SRE们，他们应该了解AI，甚至尝试一下“氛围编程”（停顿一下，让听众发笑），否则他们的批评就很难引起共鸣。

认真地说，这就是我们的主要观点。学习AI，这样你才能更有效地抱怨。

比如基础设施。顺便说一句，我认为这在很多工程师身上都适用。我只是觉得，对于那些报名成为SRE的工程师来说，这一点尤其真实。技术悲观主义和注意力缺陷多动障碍，是我们最显著的两个特征。

有一部分AI爱好者认为，我们正在进入一个永恒的指数增长时代，在这个时代里，机器开始制造越来越好的机器，而我们却无法理解其方式。

我认为这些人对数学的理解不够。我们唯一可以确定的是，指数增长最终会结束。它总是如此，要么是S型曲线，要么是崩溃。（如果你感兴趣，可以搜索Heinz van Foerster和“我们的曾曾孙将被挤压致死”）

我当然认为我们会用机器来制造机器——当然，我们已经在做了——但这涉及递归和专业化。我认为我们现在所处的指数曲线，是由于大量自由资金追逐高回报，加上软件作为语言和逻辑的函数的特性，再加上技术繁荣早期阶段总是会出现最大的发现，因为最容易摘取的果实总是最先被摘走。

我个人的感觉——请记住，我对AI并不是什么专家——是AI模型的指数级进步早已趋于平稳，现在的进展变得越来越难取得，而且是渐进式的。当然，我可能完全错了。但即使未来不再有新的AI创新，过去一年所释放的累积力量也足以彻底改变我们所熟知的软件行业。就像一只猪被蟒蛇缠住一样，我们将会在很长一段时间内面对其后果。

关于这一点，我会在EXTREMELY不久之后详细说明。请关注Honeycomb博客！

技术很酷，但作为一个有思想、有感情、有呼吸的人，关心他人，很难对那些让这么多人感到如此沮丧的事情感到兴奋。当那么多最响亮的声音在高兴地谈论让所有人永久失业时，也很难对某件事感到兴奋，而那么多艺术家、作家和来自发展中国家的人则公开谈论这件事对他们造成的影响。

请克制住想要在这里指责我的冲动，我恳求你们。正如我所说，我将在下一篇文章中讨论使用AI的伦理和道德问题。诚实地说，你的注意力持续时间并不比我的更长，足以阅读一篇一万字的文章。（我们能把这归咎于AI吗？）

“另一个Fowler。”我听说他们已经开这个玩笑大约……五十年了。

我在《Observability Engineering》第二版第32章中分享了这个故事的更长版本，本周晚些时候就可以下载！！

Adam 在技术问题上很少犯错，我百分之百确定他正在一个软件工程的未来中生活和工作。我不确定这个未来是否是我们所有人都将要生活其中的未来。如果软件中最困难的部分从来就不是编写代码——这是我的信念——那么即使代码生产的经济成本降至零，困难的部分仍然会是困难的。