AI需要更严格的工程纪律，而非更少

# AI 需要更多的工程纪律，而不是更少 来源：https://charitydotwtf.substack.com/p/ai-demands-more-engineering-discipline 几天前，我写了一篇题为“AI 热衷者在与时间赛跑，AI 怀疑者在与熵增赛跑”的文章。 我有一堆 AI 相关主题的笔记想深入探讨：AI 强制要求、沟通规范、代码审查、AI 艺术等。不幸的是，我上一篇文章收到了太多有趣的回应，现在我得先处理这些，才能继续讨论其他话题。😉 这些有趣的回应分为两类：一类是关于技术优点的，另一类是基于伦理的。我将分别回应这两类问题。先聊技术方面，因为它更简单。 不知怎么的，一部分读者看完后觉得，我是在告诉所有人马上扔掉代码审查，把最烂的代码直接推送到生产环境，连看都不看一眼。¹ 这不是我在做的事情。也不是我认为你应该做的事情。但我选这个例子并非随意为之，我会告诉你为什么。 [](https://substackcdn.com/image/fetch/$s_!3g6N!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F87a779c4-2e63-495a-aa1b-b44f1558a24f_903x241.png) 很容易忘记，但在 2025 年的大部分时间里，认为 AI 生成的代码是垃圾，并且可能永远是垃圾，不仅是一个合理的立场，而且是默认的主流立场。² 去年 11 月，这个问题有了决定性的答案。自从 Opus 4.5 发布以来，AI 已经能够生成质量大约相当于普通软件工程师水平的代码——至少在常见模式上是如此——而且速度更快，成本更低。我结束了一段“书呆子闭关”状态，并在 1 月份意识到了这一点。在 2026 年的头几个月里，我身边的每个人似乎都有了类似的领悟。 但很多人更早就预见到了这一点。 流行的说法是 Opus 4.5 改变了一切。但 Opus 4.5 更像是那个引爆点。智能体框架（将 LLM 与工具封装成循环的代码）在 2025 年中成为现实，其前身可追溯到 2024 年底。工具使用、函数调用、MCP……所有这些浪潮在 2025 年逐渐蓄积，并在年底达到了真正通用的可用性。 这就是那些热衷者去年试图告诉我们的。不仅是“这即将到来”，而且是“这比你想像的要快得多”。 事实证明，他们是对的。 你可能知道，我是从可靠性这边出来的。我给自己和同行们的一个褒奖是：我们并不难以适应新现实。一旦问题真实地摆在我们面前，我们会平稳甚至热切地调整——这得归功于我们对处理恶心技术烂摊子的不健康热情（以及我们之后能讲的篝火故事）。 [](https://substackcdn.com/image/fetch/$s_!jEKP!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F60b0224a-8572-43fa-85d5-0579487ed15f_787x301.png) 我给自己和同行们的一个非褒奖是：我们有时难以接受“进步是真实的”——bug 和边缘情况的持续存在，并不能否定大量问题域会随着时间的推移或多或少被解决，以至于大多数人都可以不假思索。³ 代码从彻底的垃圾变成“哦，靠，还不错”，这个速度一直萦绕在我脑海中，同时热衷者告诉我们：智能体工程和 AI 验证是真实的，已经在这里了，而且改善速度快得惊人。 坚持“眼见为实，我才相信”，第一次是可以原谅的，但第二次就没那么容易了。原来，这就是身处指数级变化曲线内部的感觉。⁴ 我想在这里暂停一下，非常明确地说清楚我认为正在发生的事情。然后我要告诉你，具体来说，我兴奋的是什么，以及为什么。 你完全没有义务跟我一起兴奋。但现在关于“从来就不是 X”——“一直是 Y”——“未来属于 xyzzy”🤮 的笼统断言太多了，我想把我论点的条件性、具体性和语境性说清楚。 2025 年发生的事情是这样的：**代码生产的经济学被彻底颠覆了。** 生成代码不再是非常困难、耗时和昂贵，而是变得几乎免费且即时。一夜之间，代码行从被珍藏、重用、精心关照和整理，变成了可丢弃、可再生的。 在计算机历史的大部分时间里，人们学习理解软件的主要方式就是写代码。一旦你掌握了一定水平，阅读和讨论代码就能让你解决大部分问题。（我可能会说，软件工程师长期以来一直过于依赖*代码*，而不是通过可观测性来理解*系统*。） [](https://substackcdn.com/image/fetch/$s_!3-TF!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fb45ec2a6-8f65-4ece-af9f-27720fbbaeb2_779x318.png) 许多优秀的软件工程师认为，每个（优秀）软件工程团队真正的产物，一直是对我们拥有的软件的共享理解。这种理解作为缓存状态存储在我们脆弱的小肉脑中，经常被刷新到磁盘，部署到生产环境，提交到 GitHub——但意义一直存在于我们的头脑中。 难怪软件一直是一项如此强烈集体主义的事业，对关系动态、礼仪、公平问题和情感价值如此敏感吗？这正符合你的预期：当你大脑的一部分活在别人的大脑里，而你的集体相互依赖性极高时。 这是我热爱这个行业的原因之一。但不可否认，对于软件开发模型某些方面来说，头脑一直是一个糟糕的容器。我们健忘、易分心、没耐心。我们不擅长发现小细节，我们对重复习以为常。最糟糕的是，我们头脑中的模型与用户交互的世界之间存在着巨大且持续的偏差。 无论如何，SRE 们从未完全接受过这种解释。对我们来说，很明显，每个（优秀）软件工程团队真正的产物是生产环境。 只有生产环境才是生产环境。要么在生产环境中测试，要么活在谎言里。 （这些都是背景故事。我保证，我马上要说到重点了。） 我们在去年八月发布了我们的 AI 强制要求。⁵ 我看到了足够多的迹象，知道这一切正在发生，是时候做负责任的事情了。Honeycomb 是一家开发者工具公司，人们来找我们是为了解决技术前沿的难题。我对 AI 是全力支持的，但在内心深处，我不能说我对此超级兴奋。⁶ [](https://substackcdn.com/image/fetch/$s_!lHkQ!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Faf09736c-8384-4a8b-8055-0e629d3c70f6_786x296.png) 然后我找到了 Chad Fowler 关于“凤凰架构”的文章。 如果你不知道我在说什么，老实说，你应该现在就停止读我这些破玩意儿，**去读他的文章**。Chad 就是在 2013 年创造了“不可变基础设施”这个术语的人。他最著名的文章是“迁移严谨性”，因为 Martin Fowler⁷ 在总结 Thoughtworks 关于软件未来的一次聚会时提到了它。我回复了一篇“生产环境才是严谨的去处”，抱怨他们没有充分讨论生产环境。 当我写那篇文章时，我想我只读过“迁移严谨性”这一篇文章。但很快我找到了剩下的内容，在读完两三篇之后，我**一下就懂了**。我完全知道他在说什么。我甚至可以预测他接下来会说什么。然后，读者啊……然后我就**兴奋了**。 我将给你提供一小段 Chad 的引文，足够让你领会大意。这是来自“编程之死与重生”的一段： > 不可变基础设施。无状态服务。容器。蓝绿部署。基础设施即代码。这些想法都有一个共同的前提：永远不要修复一个运行中的东西。替换它。AI 将这个前提推向了更远的范畴，从基础设施延伸到应用代码本身。当重写成本很低时，原地编辑就变得危险。变更积累熵。替换重置熵。 另一段我很喜欢的话：“删除测试”。 [](https://substackcdn.com/image/fetch/$s_!WxpU!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F98d0d940-6230-4da3-8f73-38d275b056bc_779x295.png) > 这里有一个简单的测试，你可以用在任何你工作的软件系统上：想象删除整个实现。大多数工程师会觉得删除是毁灭性的。代码感觉就像是**那个东西**。那是我们编写、审查、版本控制、部署和调试的东西。失去它就像失去了系统本身。当人们说，“我们不能扔掉代码”，他们通常意味着更精确的东西： - 我们不知道确切需要什么行为。 - 我们不知道哪些失败是不可接受的。 - 我们不知道哪些不变量必须始终保持。 - 我们不知道如何判断新版本是否正确。 - 我们不知道哪些 bug 是针对已被遗忘的边缘情况的故意修复。那些都不是代码问题。它们是评估问题。当代码是知识唯一存在的地方时，它才变得珍贵。 以及， [](https://substackcdn.com/image/fetch/$s_!TaBS!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F8910be06-8ab1-4348-a6c2-63c426bc93b6_782x333.png) > 在软件历史的大部分时间里，将代码视为持久的是合理的。我们视代码为永久，因为生产它的劳动力是瓶颈。重写很昂贵。重新验证有风险。实现随着时间的推移积累意义。结构、测试、注释、bug 修复和部落知识融合成一种你学会不去打扰的东西。当生产环境是约束时，那是有道理的。当再生变得容易时，代码就不再是一项资产，而开始像一个缓存：一个对理解的具体化视图，当它新鲜时有用，当它过时可以丢弃。 “**一个对理解的具体化视图，当它新鲜时有用，当它过时可以丢弃。**” 我想，可能就是这一行让它在我的脑海里豁然开朗。 我年纪刚好够大，我的第一个职位头衔是“系统管理员”。我当时是个青少年，在大学工作，拥有每台机器的 root 权限——在他们学会“绝对不能这么做”之前的那些日子。⁸ 我经历了从手工打造的服务器宠物到不可变基础设施的转变。我当时并不真正理解发生了什么，但近年来我对此思考了很多。我在《可观测性工程》第二版（将于 6 月 17 日星期三开放下载！）的最后一章中这样写道： > 从手工打造的服务器到不可变基础设施的转变告诉我们，可变性是理解的宿敌。任何在原位编辑的工件都会产生漂移。漂移使系统无法维护。我们杀死和再生基础设施组件的能力是我们信任它的原因。在 Honeycomb，我们每周二通过 cron 杀死最旧的 Kafka 节点。这就是为什么我们对我们的引导和平衡过程充满信心：一切都是可重复的，数据可以再生，承诺存在于别处。我们无法以相同的方式再生代码这一事实，表明我们并不理解它。我们不知道我们做出了哪些承诺，我们不知道哪些依赖会被破坏。我们主要是通过破坏它们来发现它们的。 [](https://substackcdn.com/image/fetch/$s_!_xw8!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F3181579b-618e-4ef5-b7da-33756cc15ff8_888x281.png) 想想你职业生涯中浪费在痛苦迁移和重写上的所有岁月。想想替换承载重担的遗留代码。想想那些绞杀藤模式。 代码行一直承担着**太多**的任务。代码一直是开发者意图、用户期望、隐式和显式行为、以及过往 bug 唯一石化复合记录的捆绑仓库。这太多了！ 再看看那些因为维护和修改代码行那高昂、吞噬一切的代价而被忽视的领域。我在哪里能找到那些用于审查和讨论、以理解我们架构如何演进的工件？干脆说，我们的架构工件在哪里？如果我们能讨论并达成一个架构图，然后代码可以从架构的变更中再生，而不是从代码中大致推断架构，会怎么样？ 我**并不是**在断言所有代码最终都将由 AI 按规格生成，绕过人类的理解。这整个事业的可行性取决于“规格”是什么、“规格”可能是什么的问题。任何做过痛苦数据库迁移的人，都应该学到一些该死的谦逊——关于我们以一种可重放、可自动化的方式提取和形式化用户期望的能力。 但我认为，我们朝着那个方向迈出的每一步，都**对我们有益**。 做到这一点的工具还不存在，但许多想法已经存在。大部分来自运维和 QA 领域——软件工程历史上对这两个领域一直相当傲慢。 那些测试和技术不是关于测试正确性或*应该*发生什么，而是关于观察和编码*正在*发生什么。行为测试、特征化测试、捕获/重放、流量分割器。可观测性（好的那种）。 [](https://substackcdn.com/image/fetch/$s_!2r_p!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F0156e490-2a09-4246-af73-6d6264cf5324_792x274.png) 生产线中出现的非确定性代码，终于迫使我们去做那些从一开始就应该做的事情。用链路进行探测。在生产环境中进行测试和评估。生产环境不是开发结束后发生的事情，**生产环境是开发的一个阶段**。 人类的大脑**不擅长**验证。那种吹毛求疵、反复重复。这是最不该紧抓不放的东西啊，各位。还有那么多更好的事情等着我们去