AI Slop，能运行的代码成为维护的噩梦

一段 AI 生成的代码，命名规范、测试通过，连 Pull Request（PR）的描述也写得条理清晰。但三个月后，当需求发生变化，我们才发现：同一段逻辑散落在多个模块中，相似的功能采用了不同的实现方式，而那些一直通过的测试，恰恰没有覆盖真正需要保护的业务行为。

在 Vibe Coding 时代，AI Slop 已经成为另一种危害巨大的、更为隐蔽的技术债务。

还记得我们在 如何利用 Harness “一句话交付产品功能”？ 和 面向 Coding Agent 的多仓库 Git Worktree 中提到的 LLM Arena 平台吗？这个平台目前所有的代码都是 100% AI Coding 产生的。在经过仅半年的 AI Coding 之后，平台累积提交代码 200 余次，总代码行数近 30W，已经成为一个规模不小的产品了。

我用 4 个审计 Agent（后端架构一致性/后端复杂度与重复/前端重复与规模/前端一致性） 对这 30W 行的代码进行了审计，结果如下：

我一直以为平台运行的好好的，功能也都能正常，但是殊不知就在这个可以正常运行的平台之下，实现平台的代码却隐藏着这么多的风险。

什么是 AI Slop

AI Slop 代码是指今天能运行、明天就腐烂的 AI 生成代码，这些代码在结构上正确，但在架构上欠缺考虑。

AI Slop 代码能够成功编译、通过测试，但却在代码库内部悄然腐烂。他们表面看起来十分光鲜——命名规范、测试通过、PR 清爽——却在暗中蚕食着架构的一致性。AI Slop 的危害性比传统的技术债务更大，也比传统的技术债务更难捕捉。

AI Slop 代码不是那些会导致崩溃的代码，崩溃的代码反而很容易被发现。AI Slop 代码是周二还能正常工作、但三个月后就会演变成维护噩梦的代码。这些代码在结构上是正确的，但:

• 在架构上毫无章法——本该抽象的地方却充斥着大量的复制粘贴
• 本该由五个可组合的模块来实现的地方却堆砌着 500 行的长函数。
• ……

对于 AI Slop 而言，测试能通过仅仅是因为测试用例只是在重复具体的实现，测试在验证“代码是不是这么写的”，而不是验证“业务功能是不是满足需求”。

这就好比魏晋南北朝一直到隋唐，骈文（四六文）垄断文坛，而这些骈文重形式、轻内容，为了华丽的句式牺牲表意，一味堆砌典故辞藻而又空洞无物。也就是在这个时候，以韩愈、柳宗元为为首的唐宋八大家开始登上历史舞台，发起了古文运动，开始文学文体革新，整顿浮华文风。

如果我们还认为，Slop 仅仅还只是杞人忧天，那么数据会证明一切。GitClear 在报告 The Maintainability Gap: AI Code Quality in 2026 中对 2023–2026 年间的 6.23 亿处代码变更进行了分析：

• 跨文件函数调用（代表代码复用程度）下降 35%
• 重构带来的代码行迁移量下降 70%
• 长期遗留代码维护工作量相比 2022 年下降 74%
• 单次提交内复制粘贴代码 (+41%)
• 代码块重复冗余 (+81%)
• 掩盖错误的代码写法 (+47%)
• 两周周期内代码返工率 churn (+15%)

为什么 AI Slop 比传统技术债务更难发现

传统的劣质代码是有迹可循的。匆忙写就的代码一眼就能看出来——命名不一致、缺少测试、TODO 注释随处可见。资深工程师浏览一眼 Pull Request（PR），几秒钟内就能识别出来。

AI 垃圾代码完全没有这些破绽。它看起来无可挑剔：变量命名高度规范（模型从成千上万个优质代码库中学习过），配套测试一应俱全（模型随实现一同生成了测试），文档齐全，PR 描述也写得条理清晰。表面上的一切都显得极其专业。

更深层的问题在于：

缺乏架构思考的模式模仿。 AI 是通过在其训练数据中进行模式匹配来生成代码的。如果你的代码库中有三种不同的数据库访问模式，AI 会随意采用它在上下文中最近看到的那一种——或者干脆再自创第四种。几个月下来，代码库中各个模块虽能单独运行，却无法有机地结合在一起。原本能让系统保持可维护性的架构一致性，就这样在一个个 AI 生成的 PR 中被逐渐侵蚀。

测试与实现紧密耦合。 AI 生成的测试往往只是在镜像复刻实现的逻辑，而不是测试实际的行为。它们能通过测试，且会一直通过，却根本无法捕捉关键的回归问题，因为它们断言的是代码如何运行，而不是代码应该达成什么效果。你的代码覆盖率数据看起来极其漂亮，但实际的安全防护网却千疮百孔。

复杂度膨胀。 经验丰富的工程师在解决问题时，会思考能够满足需求的最简方案。而 AI 则倾向于从训练数据中提取最常见的方案，而这往往比实际所需的更复杂。面对一个只需 40 行就能搞定的问题，AI 给出的 200 行方案并没有错——它只是平白引入了 160 行没人需要的未来维护负担。

悄无声息的架构偏离。 这是代价最高昂的一点。每一个由 AI 生成的 PR 都会使代码库稍微偏离既定架构。单看任何一个 PR 都不是大问题，但在 AI 辅助开发持续六个月后，“系统最初是如何设计的”与“系统目前实际上是如何运转的”之间的差距已演变成一道鸿沟。事后通过重构弥合差距的难度，远大于前期防止架构偏离的难度。

以前纯手写代码很慢，而这种缓慢迫使人思考。你必须先理解问题，才能敲下解决方案。现在，你只需一句话描述问题，在还没来得及思考 200 行代码是否合适之前，这 200 行能跑通的代码就已经生成好了。

如何避免 AI Slop 代码

构建自动化的度量感知信号。 仅凭人工代码审查是无法拦截 AI 垃圾代码的。代码产出量过于庞大，且在表面上显得太过精致。你需要的是在代码仓库层级而非单个 PR 层级运行的自动化信号。我们可以通过 GitClear 报告中的类似指标作为信号来更快的感知 AI Slop 的存在，也可以采用 Larridin AI Slop Index 来评估 AI 生成代码的长期可维护性风险。

针对 AI 时代重塑代码审查机制。 前 AI 时代的代码审查聚焦于逻辑正确性和编码风格。AI 时代的代码审查则必须增加架构契合度的考量：这段代码属于这个代码库吗？它遵循了现有模式还是自作主张引入了新模式？这是最精简的方案还是最常见的通用方案？回答这些问题需要花费更多时间，这意味着随着 AI 产出量的增加，团队的审查投入应该扩大，而不是缩减。

开展针对性的重构冲刺（Refactoring Sprints）。 AI 只会生成新代码，不会主动去整合现存代码。团队应定期安排专门针对 AI 生成重复代码的重构周期——将重复模式收敛为共享抽象，对齐发散的实现逻辑，并剔除那些原本就不该合并的代码。可以将其视为等同于对初稿进行润色编辑的代码库维护工作。

鸟窝在 都不 code review 了， AI coding Agent 生成的垃圾代码怎么办？ 这篇文章中，也介绍了自己的方式：

对于生成的 Go项目来说，我会关注几个方面：程序的布局、使用/smell嗅探架构和设计中的坏味道、使用/refactor重构项目、使用不同的大模型交叉review、提供端到端的测试等……

在被 AI Slop 裹挟的当下，我们还是要保持一颗好奇心，不断探索，向阳而生。