如果你真的不想被"AI垃圾代码"淹没，你需要经验丰富的工程师来监督所有AI生成代码的可观测性、测试和审查。

反弹是不可避免的。过去一年里，硅谷一直在告诉我们，软件开发即将变成一项"输入提示、一键交付"的工作——你知道的，就是描述你想要什么，然后让AI编码智能体来构建它。当然，也许可以留几个资深工程师来做最终把关……也许连这个都不需要。毕竟，谷歌的Sundar Pichai说，谷歌75%的新代码现在是AI生成并由工程师审查的，比之前大幅上升。

太棒了！对吧？？？嗯……

《华尔街日报》最近重点报道了Mario Zechner和Armin Ronacher的警告。这两位工程师是热门AI智能体OpenClaw核心组件的构建者，他们指出AI编码工具正在用所谓的"随性垃圾代码"（vibe slop）淹没软件。他们的不满在于：太多人正在用AI跳过软件开发中真正重要的环节——设计、判断、测试、归属感，以及对被修改系统的深度理解。

这值得认真对待。当那些帮助构建了数百万人使用的工具的人开始警告说，这些工具可能以工业规模产出有缺陷、甚至危险的软件时，也许是时候重新思考那些推动AI浪潮的假设了。

重新思考，而非全盘否定。

正确的答案不是"AI编码不好"，这很愚蠢。AI编码的强大，大致相当于电动工具的强大——它们帮助熟练的人做得更多、更快，也帮助不熟练或粗心的人以更大的信心犯更大的错误。这就是企业AI故事的浓缩版。

接近正确，等于大错特错

我曾就"接近正确"的AI代码的真实成本提出过类似论点。问题从来不是大语言模型会产出明显破烂的代码——如果是那样，我们会发现然后跳过。问题在于，它们非常迅速地生成看起来合理的输出。"快速且看似合理"，正是那种能滑入生产环境的错误类型。

重要的是要认识到，生成代码从来不是软件开发中最难的部分。正如Honeycomb创始人兼CTO Charity Majors所说，成为一名伟大的软件工程师，"更多地取决于你理解、维护、解释和管理一个长期运行的大规模生产软件系统的能力，以及将业务需求转化为技术实现的能力"，而不是简单地大量产出代码。正如我之前写过的，开发速度很少是正确的衡量指标。开发者大部分时间花在理解现有系统上，而不是简单地向其中添加代码行。

AI并没有消除这些硬功夫的必要性。它做的，是让愚蠢地跳过这些硬功夫变得更容易。

这在软件之外也同样成立。我在工作中不断使用AI。比如，我会用AI草拟用于培训销售团队的幻灯片，或者综合客户的反馈。AI给我一个起点，就像一份可能80%正确的备忘录初稿。这是真正的馈赠。但一份只能做到80%正确的终稿是一种负债，所以我必须指导和监督这些智能体。这是真实的工作，尽管与以前的工作方式不同。

问题在于推卸责任

关于AI编码的争论中，最愚蠢的版本是问"AI会不会取代开发者"。更好的问题是：AI奖励什么样的开发者？ 它不奖励那些盲目接受输出的人。相反，它奖励那些能够快速、准确地判断输出是否适配系统、安全模型、性能边界、用户需求和组织标准的人。换句话说，AI奖励经验；它奖励那些知道什么是"好"的人。

这就是为什么成群的自主编码智能体让我感到不安。不是因为智能体没用，而是因为责任感不会像提示词那样规模化扩展。一个开发者可以审查一个AI生成的改动。也许五个。如果改动很小且测试很扎实，也许二十个。但当一个公司开始庆祝几十个或几百个智能体在不停地产出拉取请求、工单、测试、迁移和修复时，一个显而易见的问题是：谁真正理解正在发生什么？

如果答案是"另一个智能体"，抱歉，我们又回到了原点。开源维护者已经在承受这种负面后果。GitHub一直在考虑加强拉取请求控制，因为维护者们警告说，大量低质量、往往是AI生成的贡献正在压垮项目。GitHub已考虑采用更强的过滤器和维护者控制来遏制这股洪流。

这就是AI垃圾代码的丑陋经济学：生成很便宜，审查却很昂贵。

摩擦才是重点

Ronacher一直以令人钦佩的清晰度阐述着类似的观点。在他与Cristina Poncela的演讲《摩擦即是判断力》中，他们指出智能体生成的代码有一种倾向，总是滑向"当下方便"的答案——捕获异常、加个回退、敷衍过去那个奇怪的边界情况、让演示继续跑下去。每一个改动单看可能都显得合理，但问题是当上百个这样的改动在代码库中层层堆积，它们会悄悄让整个系统变得越来越难以理解。

这对我来说很有道理。摩擦不是敌人，它恰恰是你的判断力所在之处。

这就是为什么"人机协同"这个说法虽然已显陈旧，但仍然重要。但这句话只有在人既保持关注、又有能力评判工作时才有意义。一个初级开发者因为生成的代码通过了第一次测试就接受它，这解决不了问题。一个资深开发者在速度上"审查"大量智能体生成的拉取请求，使得真正的审查成为不可能，这也解决不了问题。

保障不在于"大致在流程附近有个人"。不是的，保障在于审慎运用的专业能力，以及强制问责而非假定的制度设计。对开发者来说，AI在用于有边界任务时最强——比如生成测试或解释陌生代码；而在被要求做出广泛的架构决策或推断只存在于人脑而非仓库中的业务规则时，则较弱。

对管理者来说，最糟糕的指标就是"AI生成代码的百分比"。这就像用自动补全生成的句子占比来衡量一家新闻编辑室。谁在乎？真正的问题是：缺陷是否减少了，交付是否加快了，事故是否变少了，客户是否更满意了。

2025年DORA关于AI辅助软件开发状态的报告更有效地指出了这一点：AI倾向于放大一个组织已有的优势和劣势。如果你有扎实的测试、清晰的归属权、严谨的审查、良好的可观测性和快速的回滚能力，AI能让你变得更好。如果你的工程卫生习惯很差，AI能让你更快地变得更糟。

换句话说，AI并没有消除工程纪律的必要性——它提高了不具备工程纪律的代价。

护栏不能只是一纸备忘录

纪律是必要的，但对一家企业来说还不够。你无法通过良好意愿和一纸备忘录，让成千上万的工程师、分析师、市场人员、律师和销售人员可靠地"慢下来并检查工作"。在规模化场景中，保持人机协同必须由架构来强制执行，而非善意。

实际上，这意味着将护栏嵌入智能体所触及的系统中——身份认证、数据治理和可观测性。说到这里，我可能会冒昧地听起来像在为我的雇主说话（Oracle）。我在整个行业中看到的真正有趣的变化——也是Oracle正在押注的方向——是将更多的这些控制下沉到数据层本身，使智能体在有治理的企业数据之上运行，而不是像拿着生产环境钥匙的聪明脚本。

这不如说"智能体将为你编写所有代码"那么令人兴奋，但你猜怎么着？这是好事。在企业AI领域，"无聊"就是好。

那么，谷歌说他们75%的新代码来自AI，这对企业来说到底应该有多大意义？这很可能属实，但谷歌也拥有世界上最好的工程师在审查那些输出。这是AI鼓吹者跳过的故事另一半，但它不该被跳过。人类是让AI发挥作用的最佳方式。