AI 爱好者与时间赛跑，AI 怀疑者与熵增赛跑

本文最初发表于 Charity Majors 的 Substack，经作者许可转载。

最近我参加了一场演讲，其中一位演讲者声称通过纯粹的“氛围编码”（vibe coding）实现了惊人的成果：解决了棘手的工程问题，清除了积压任务，甚至将原本需要一年以上的重写工作压缩到短短几周内完成。会后，我听到许多兴奋的讨论：“我迫不及待想让团队看这场演讲，我的工程师们对不阅读代码就交付代码的想法非常抵触，这下终于有他们无法忽视的证据了！”

然而，问题在于，我认识该公司的许多其他员工，他们将这些项目描述为一场灾难。是的，他们承认取得了一些进展，其中部分成果令人印象深刻，但演讲者也留下了一条长长的混乱轨迹。数月后，一些团队仍在处理清理工作。

我不断回想这个片段：台上讲述的是一个高度选择性的故事，而台下满是对AI充满热情的听众，他们不加批判地全盘接受，因为这恰好验证了他们希望成真的所有假设。我思考着他们带回家的那种确定性，以及这种能量如何影响他们与团队的对话。

人们正在退回到各自的阵营，拉紧防线。爱好者与怀疑者之间的鸿沟日益加深。双方都感到紧张、沮丧，甚至有些恐惧，结果他们停止了相互对话，转而谈论对方——视为障碍、刻板印象或威胁。简而言之：一方说“那些人被AI洗脑了，根本不懂软件”，另一方则说“那些人讨厌AI，不想快速前进”。

这不是一方正确而另一方完全错误的情况。每一方都在应对一个真实、令人担忧且不断升级的威胁，而且随着他们深入观察，会发现更多真实的证据。

爱好者并没有错。我们开始看到那些积极拥抱AI的团队实现了真正的、非想象的能力飞跃。这不像正常的科技周期，你可以等待尘埃落定；在竞争者奋力前进时按兵不动的团队，可能在尘埃落定前就已被淘汰。这是真实的生存威胁。

怀疑者也没有错。当代码交付速度超过工程师的阅读能力，在无人掌握完整上下文的领域，你正在透支多年建立的信誉。可靠性下降，机构知识流失，最终导致系统无人理解，产品失去连贯性，值班轮换让团队精疲力竭。这也是真实的生存威胁。

本文面向的是那些正在努力工作的优秀团队。我谈的不是管理层脱离工程现实或聘请麦肯锡顾问的团队，也不是低工程纪律和低信任度的团队。我面向的是那些正在从AI前时代向AI原生时代转变的高绩效团队。这些团队拥有工程纪律和技能，他们努力挣扎，正是因为存在太多合理且相互竞争的威胁，却没有明确的答案。

问题在于，爱好者和怀疑者之间缺乏自然的反馈循环。胜利和成本分别发生在不同群体身上。演讲者可能并非故意误导，他们甚至可能没有意识到自己留下的混乱。在没有上下文或精通的情况下做事变得非常容易，而下游成本往往对产生成本的人不可见，他们只看到胜利。

怀疑者则面临相反的问题。他们无法避免听到爱好者的主张，但当这些主张变得越来越夸张、越来越脱离现实时，怀疑者会以越来越强的讽刺态度回应。他们听到了，但不再相信一个字。许多工程师无奈地告诉我：“我不想成为AI反对者，我在学校学过AI！我觉得它很酷！但我感觉自己被逼到角落，必须成为反对者，因为我是唯一关心现实的人！那些主张到底有多少是真实的？”

好吧，这很公平。我将展示我的工作成果，提供一个“好”的北极星示例。

以Fin（前身为Intercom）的工程组织为例。我一直很钦佩他们。去年，我和Christine制定AI任务时，从CTO Darragh Curran的文章“2x”中汲取了大量灵感，他挑战研发组织在12个月内将生产力翻倍。最近他公布的结果显示，他们超额完成了目标——在9个月内将产出提升了3倍（以合并PR总数除以研发总人数衡量）。当然，PR并非完美的现实表征，这一点我们大家都知道。

结果喜忧参半，但读来引人入胜。产品缺陷积压减少了一半以上；产品变更数量翻倍，从创意到交付的速度提高了39%；代码质量在经过18个月的可怕下滑后开始初步改善；停机时间减少了35%。

这是真实的、非想象的、不连续的能力飞跃。这并不是因为AI有魔力，而是因为Fin已经具备了极高的工程纪律、快速的反馈循环以及实验和测量的文化。如果你想知道AI前时代的工程团队通过拥抱AI能实现什么，这就是答案。

我们可以解决这个问题。首先，提醒大家：我们关心同样的事情，我们站在同一边。我们迫切需要彼此。为了在错失窗口的“斯库拉”和系统瓦解为“混沌”的“卡律布狄斯”之间安全航行，我们需要同时关注两种威胁，协调同步，共同努力。

为此，我们需要做两件事：将分裂的现实重新缝合，让大家都朝着同一个方向努力；并对问题应用工程严谨性。

第一步：讲述完整故事，谈论胜利，也谈论成本。修复共享现实的差距。你可以庆祝AI带来的巨大胜利和进步，但也要邀请对成本和下游后果的反思。要非常明确地表明，共同目标是找出如何以更少的不可预测成本交付更多、更大的胜利，而不是扼杀创新。

这听起来简单，实则不易。默认情况下，胜利在一个场合（博客、会议演讲、全员大会）被宣扬，而成本在另一个场合（SRE团队会议、值班、回顾、抱怨的私信、酒后的牢骚）浮现。结果是双方都可能觉得被不公平地噤声。你可能认为“我们甚至不允许批评AI”和“我们整天都在抱怨AI”这两种情绪不可能同时广泛存在，但事实确实如此。这种不对称并非恶意，而是结构性的，必须加以纠正。

如果你是爱好者，从这里开始。下次你完成一件真正令人兴奋的大事——“我在周末空闲时间完成了一项两个月前已经放弃的迁移！”——太棒了！告诉你的同事！但同时，也要询问其他团队是否有任何意外后果，并纳入你的分享。加上一句“如果有任何下游清理工作，我很想听听”。尤其是当存在权力动态、人们可能不敢发言时，要让反馈变得容易。

如果你是怀疑者，正在清理他人AI氛围编码胜利留下的下游混乱，不要只是苦涩地嘀咕。以负责任、友好的方式向造成问题的人提出，或者在同一论坛中提出。闭合反馈循环，这是我们学习的方式。

第二步：将其视为工程问题，而非修辞问题。一旦你在同一现实中运作，就可以进行真正的对话。目前，对话往往是这样：爱好者说“让我们不进行代码审查就交付！X公司正在这样做。这显然是世界的趋势。你为什么讨厌未来？”怀疑者回答“你是在开玩笑吗？我遇到从没听说过的人提交的代码像用蜡笔写的，你却想让我自动接受？”。

其实双方都可能是对的。是的，行业大方向是走向软件工厂和AI验证的差异。是的，考虑到你当前代码库和防护措施的现状，自动接受差异可能是完全不可想象的。但“你怎么了”和“这永远行不通”是伪装成立场的对话终结者。有效的对话应该是：“需要什么条件才能让你放心地在不阅读代码的情况下将代码交付到生产环境？”更好的评估？更好的测试？更好的功能开关、防护措施、可观测性？解耦依赖、减少爆炸半径？从关键路径之外的小事开始？我们需要做哪些准备工作？先后顺序是什么？能否将其纳入路线图？

将工程纪律应用于AI采纳从未像现在这样重要。正如2025年DORA报告所言：“AI是一个放大器。它放大了高绩效组织的优势，也放大了挣扎组织的功能障碍。”AI无法解决纪律缺失、工具差距或脱离现实的管理。要有效利用AI，你必须投资于工程纪律。