\n\n开源维护者正被AI生成的低质量PR淹没。这种“生成快、评审慢”的生产力不对称即将波及企业团队。文章建议通过加强验证左移和明确人类问责制，来应对AI代码质量危机。
译自：Open source maintainers are drowning in AI-generated pull requests. Enterprise teams are next.
作者：Arjun Iyer
开源领域正发生一些变故，这应当引起每一位向组织推行编程智能体（coding agents）的工程领导者的警惕。
在过去的一年里，开源维护者被大量低质量、AI 生成的合并请求所淹没。这些请求包含冗长的变更和荒谬的描述。当被质疑时，提交者无法解释其贡献。代码在表面上看起来似乎可行，但在审查下却破绽百出。
Jazzband collective 是一个著名的 Python 项目生态系统，今年被迫彻底关闭。其首席维护者指出，难以承受的 AI 生成垃圾 PR 和 Issue 数量是主要诱因。
其他项目也感受到了同样的压力。维护 Godot 游戏引擎的 Remi Verschelde 将分拣 AI 垃圾内容描述为一种消耗精力且令人沮丧的过程。curl 的创建者 Daniel Stenberg 已经取消了漏洞赏金计划，因为它们变成了低质量 AI 提交内容的磁石。
这种模式是一致的：维护者花费了极不成比例的时间来评估那些本不该提交的代码，挤占了真正贡献的空间，并加速了职业倦怠。
这不仅仅是开源界的问题。它是企业工程团队即将面临的情况预演，而大多数团队尚未做好准备。
没人在计划中的不对称性
核心问题在于吞吐量的不对称。AI 编程智能体让代码生成变得极其廉价且快速。一名配合智能体工作的开发者一天可以产出五个、六个甚至更多的合并请求。
一个非技术团队成员在第一次使用编程智能体时，可以在几分钟内生成看起来可以运行的代码。但是，这些代码的评审、验证和集成速度并没有任何提升。60% 的无偿志愿维护者已经难以跟上进度。现在，工作量更是成倍增加。
“AI 编程智能体让代码生成变得极其廉价和快速……但代码的评审、验证和集成速度并没有任何提升。”
开源维护者体验到的是这种不对称性的极端形式，因为他们的代码库向全世界开放。任何人都可以将智能体指向一个开放的 GitHub Issue，并在几秒钟内生成一个看起来似是而非的合并请求。
正如一位贡献者所言，如果这真的是维护者想要的，他们完全可以自己动手。贡献的价值从来不仅仅在于代码本身，而在于背后的理解、验证它的测试，以及塑造它的决策判断。
企业团队在公司围墙内也面临同样的结构性问题。当组织强制采用编程智能体时，他们加速了流水线的一端，却让另一端保持不变。评审者继承了判断代码是否真正工作、是否正确集成、是否处理了边缘情况以及是否引入了回归问题的全部负担。来自 Agoda 的研究发现，资深开发者在使用 AI 工具时实际上慢了 19%，这在很大程度上归因于研究人员所说的“理解债（comprehension debt）”——随着 AI 生成代码的积累，开发者对自身代码库的理解程度会随时间推移而下降。CodeRabbit 对 470 个开源合并请求的分析发现，AI 共同创作的合并请求中的问题大约是纯人工编写的 1.7 倍。
这套数学逻辑对评审者不利。而且随着复杂性的增加，数字会变得更加糟糕。
为什么 AI 辅助评审还不够
面对 AI 生成代码的激增，自然的反应是部署 AI 智能体进行代码评审。总结合并请求、标记问题和评估质量的工具正在迅速扩散。对于简单的变更，它们可能已经足够。AI 评审员捕获样式违规、识别反模式以及发现明显 Bug 的速度比人类逐行扫描要快。
但对于拥有十几个或更多相互依赖服务的云原生分布式系统，AI 辅助评审遇到了与传统 CI 流水线相同的障碍：两者都无法告诉你变更在上下文中是否真正起作用。对一个服务的修改在孤立状态下可能看起来是正确的，但却会悄悄打破与下游依赖的契约。智能体生成的重构可能会引入仅在现实流量模式下才会显现的竞态条件。
解决这些问题需要在类似于生产的环境中运行代码，而任何静态分析（无论是人工还是 AI 驱动）都无法替代这一点。
“验证瓶颈出现的时间比大多数团队意识到的要早，就在代码编写完成与评审者能够信心十足地进行评估之间的间隙中。”
验证瓶颈出现的时间比大多数团队意识到的要早，就在代码编写完成与评审者能够信心十足地进行评估之间的间隙中。如果一名开发者一天生成六个合并请求，且每个请求都需要 30 分钟以上的手动验证，那么他们的大部分时间将花在管理部署队列上，而不是构建软件。智能体让编写变快了，AI 评审让分拣变快了，但下游的一切依然很慢。
开源危机究竟在告诉我们什么
开源代码库正在承受 AI 加速代码生成的完整、无过滤的冲击，因为他们无法控制谁来贡献。维护者采取了多种对策，包括更严格的贡献者政策、声誉系统、用于门控或过滤合并请求的平台工具，在某些情况下，甚至直接关闭项目。
企业团队对代码提交者有更多的控制权，但对提交者是否理解代码的洞察力较弱。在评审队列中，来自内部开发者或非技术团队成员的智能体生成 PR，与资深工程师精心构思的变更看起来是一样的。如果没有额外的上下文，评审者无法区分两者，也无法快速验证代码是否实现了其声称的功能。
开源界对这场危机的反应具有启发性。正在度过难关的项目不仅仅是增加了政策，他们还在投资一些机制，将“证明责任”转嫁回贡献者身上，要求其证明代码是工作的，而不是要求评审者去证明代码不工作。
企业应该如何应对
代码生成与代码验证之间的鸿沟需要被填平。每个合并请求在送达时都应该附带它能正常工作的证据，而不仅仅是一个声明。
首先，验证需要进入开发循环。开发者和智能体需要能够访问隔离的、类生产的环境，在开启 PR 之前就可以根据真实的业务依赖验证变更。评审应该从“证明代码可用”开始。
其次，评审流程需要演进。当智能体每小时产出数千行代码时，逐行评审是无法规模化的。转变的方向是从检查代码转向评估行为证据。变更在真实的业务交互中起作用了吗？行为是否符合规范？
第三，组织需要将 AI 生成的代码视为草稿。这意味着要标记 AI 编写的变更，单独跟踪缺陷率，并构建能够考虑到提交者可能并未完全理解代码的评审工作流。
最后，问责制不能外包给 AI。引导智能体的工程师仍然对发布的内容负责。这意味着要为他们提供在开发循环内验证智能体生成代码的工具，以便他们能充满信心地提交 PR，而不是指望评审者去发现问题。
警示已经显现
开源仓库就是那只“金丝雀”。它们的开放性意味着它们会最先且最明显地吸收廉价代码生成带来的每一种外部性。但这种潜在问题——即产出代码的速度与验证代码的速度之间的失衡——并非开源界所独有。它是结构性的。
如果企业组织在重金投入编程智能体的同时，不同样投入基础设施来验证这些智能体产出的内容，那么他们构建的流水线只会让创造工作的速度变快，而不会让完成工作的速度变快。PR 会堆积，评审时间会拉长，缺陷率会攀升。负责评审智能体产出内容的工程师会因为与当今开源维护者相同的原因而陷入崩溃。
填补这一鸿沟的工具已经零散存在。隔离的预览环境、自动化的端到端验证、更智能的评审工作流，以及对智能体生成变更的更好可观测性，这些都是可以解决的问题。像 Signadot 这样的解决方案已经在帮助团队在代码送达评审者之前，根据真实的业务依赖验证变更。
问题在于，组织是会吸取开源维护者实时传达的教训，还是等到自己感受到痛苦、面临失去优秀工程师和竞争优势的风险时才觉醒。在积压变得无法收拾之前投资这些能力，将是受益于编程智能体的团队与陷入危机的团队之间的关键区别。全 工智能
