--- layout: post.njk source: https://yage.ai/share/ai-code-bloat-structural-blindspot-20260712.html speaker: yage.ai title: 模型越强，代码越臃肿：AI 代码膨胀的结构性盲区 date: '2026-07-12' summary: 文章探讨了随着AI模型能力的增强，生成的代码反而可能变得更臃肿的结构性问题。研究指出存在‘体积与质量反向定律’，即模型越强，代码复杂度越高且缺陷越多。这导致了测试通过不等于满足人类意图（reward hacking）和理解成本增加（comprehension debt），使得清理AI生成代码的需求激增。文章分析了从人工服务到SaaS平台内置功能的市场演变趋势。 area: tech-engineering category: ai-application tags: - code-bloat - volume-quality-inverse-law - reward-hacking - comprehension-debt people: [] companies_orgs: - Slopfix - Claude Code - Tom’s Hardware - Faros AI - CodeRabbit - Sacra - Greptile - SonarQube - Cursor - Graphite - Microsoft - Anthropic products_models: - Claude Code - Claude Sonnet - Jasper - GPT-4 media_books: [] draft: true status: evergreen --- 2026 年 7 月，一篇 arXiv 论文报告了一个反直觉的发现：AI 模型越强，生成的代码不是越干净，而是越臃肿。代码体积与架构缺陷的相关度达到 0.94。能力更强的模型，为了覆盖更多边界情况，反而塞进更多冗余代码。 这个发现推翻了多数人的默认假设。大家以为模型进步会自动解决代码质量问题。实际恰好相反。原因不在工程实践，在当前生成方式本身的数学性质里。 同月，一家叫 Slopfix 的公司登上 Hacker News 首页。三位工程师一周收费一万美元，帮企业删除 AI 写的冗余代码。一个典型案例：10 万行砍到 3.5 万行。他们用 Claude Code 删 Claude Code 写的代码。（Tom’s Hardware 报道了这个故事。） Slopfix 证明需求真实。但盲区永久存在，不等于清理代码能成为长久生意。这个需求正在快速增长，但专门满足它的独立服务只是一个过渡形态。价值正在从人力服务向 SaaS 产品向平台内置功能迁移。 ## AI 代码为什么需要清理 代码膨胀得这么快，不是因为工程师不小心。这是 AI 写代码自带的特点。 数据证明了这一点。有人追踪了 6.23 亿次代码改动，发布在 GitClear 2026 report 上。数据显示，自 2023 年以来，全球代码库里的重复代码块增长了 81%。而开发者的重构行为减少了。2022 年，重构比例还有 21%。到了 2026 年，这个比例跌到了 4% 以下。现在开发人员复制粘贴代码的次数，是重构代码的 5 倍。 代码库的健康状况变差了。Faros AI 统计了团队开发数据。由于 AI 吐出大量代码，开发团队自己根本看不过来。结果，团队审查代码的时间增加了 441%。没经过审查就直接合并的代码，也增加了 31%。 AI 为什么会让代码库变得越来越臃肿？表面上看，AI 喜欢写新代码，不喜欢用旧代码。在更深处，有三个原因在起作用。这三个原因各自独立。解决其中一个，另外两个依然存在。 ### 测试通过了，但意图没满足 AI 写完代码，默认的目标是让测试用例全部通过。但测试通过了，不等于满足了人类的想法。这两者之间有一条鸿沟，因为我们的想法没法直接变成数学公式。 这在经济学里，就是经典的委托代理问题（principal-agent problem）。UC Davis 的 Lifu Huang 教授在一场关于 Goodhart’s Revenge 的演讲里指出，这是由于强化学习的训练机制造成的。我们越逼着模型去通过指标，它就越会去钻指标的空子。这种钻空子行为，技术上叫 reward hacking。例如，有开发人员发现 Claude Sonnet 会硬编码梯度值。它用这种方式去欺骗评测，假装自己通过了测试。这就是 reward hacking 的体现。 ### 写得太快，理解得太慢 AI 写完一段代码只需要几秒钟。但开发人员要读懂这段代码，可能需要十几分钟甚至更长。Addy Osmani 在 O’Reilly 的文章里，给这种现象起了一个名字，叫 Comprehension Debt（理解欠债）。 模型写得越快，人类欠下的理解账就越多。这真的能提高效率吗？一项 METR study 针对资深开发人员做了对照实验。结果发现，AI 辅助没有缩短开发时间，反而拉长了时间。因为资深开发人员不得不花更多时间去阅读和验证那些代码。根据 Sonar 2026 survey 的调查，59% 的开发人员承认，自己提交过还没完全看懂的 AI 代码。 ### 虚标的百万上下文 许多模型宣称自己能读 1M token 甚至更长的内容。但在多步推理任务中，它们的实际有效窗口往往连 1% 都不到。有些研究展示了这种遗忘现象，收录在 emergentmind 里。 LoCoBench 的测试数据表明，当上下文从 10K 扩大到 1M token 时，模型在多文件里推理的成功率直接减半。更奇怪的是，训练模型‘想’的时间越长，它反而越容易忘事。比如 HypeNet-9B 进行了 CoT 训练，它的检索准确率却从 67.2% 掉到了 9.4%。 这三个原因各自独立，解决任何一个都不影响另外两个。换更强的模型，第一个问题里的测试通过率会更高，但第二个问题只会更严重：模型生成更快，人类理解更跟不上。第三个问题也不见得好转：窗口更大，有效上下文反而衰减更多。盲区不在模型内部，在人把任务交给模型这件事本身。 ## 模型更聪明了，代码就会变干净吗 有人会想，AI 现在写代码臃肿，是因为它还不够聪明。只要大模型继续升级，写出的代码自然会越来越优雅。但最新的研究给出了相反的结论。 在 arXiv 2605.02741 的论文里，研究者审计了 AI 写的代码。他们发现，代码体积越大，架构缺陷就越多，两者的相关度高达 0.94。而且，能力越强的模型，生成的代码反而越臃肿。他们给这个现象起了一个名字，叫 Volume-Quality Inverse Law（体积与质量反向定律）。 为了在推理时多考虑各种边界情况，聪明的模型倾向于写更多的代码。这种追求完美的努力，客观上塞进了大量多余的代码。这种在推理能力和代码复杂度之间的纠缠，就是 Reasoning-Complexity Trade-off（推理与复杂度折中）。论文里写道：‘随着模型能力提升，它们生成的代码变得越来越臃肿且耦合。’ 图 2：模型能力与代码膨胀程度的关系。左图展示了人们的直觉：模型越强，代码越干净。右图展示了真实的规律：模型越强，生成的代码越多、越臃肿。 我们要诚实地说明，Volume-Quality Inverse Law 只是针对现在的自回归模型。如果以后有了全新的方式，比如用 diffusion LLM 来写代码，这个规律也许会失效。但目前来看，diffusion LLM 只是写得更快，并没有写得更好。所以在当前的技术路线下，模型变强，代码膨胀也会更严重。 ## 清理的需求增加了，不等于这门生意能做大 既然模型越好代码越臃肿，清理代码的需求肯定会增加。但需求变多，并不等于帮人删代码能成为一门长久的生意。 现在的代码治理市场，可以分成三个部分。它们互相吞噬，高处的部分正在吃掉低处的部分。 最下面的是人干活的清理服务。在 2025 年到 2026 年之间，市场上出现了十几家这类公司，比如 Slopfix 和 GetDevDone。他们收费很高，每周 10000 美元，其实是工程师自己用 Claude Code 等工具帮客户删代码。 中间这一层是专门做治理的 SaaS 软件，最近在飞速增长。比如 CodeRabbit (Sacra) 的年经常性收入（ARR），在一年内从约 500 万美元暴涨了 700%，达到估测的 4000 万美元。另一家工具 Greptile 也拿到了 Benchmark 领投的投资。SonarQube 这样的老牌软件，也成了 Gartner 技术债管理里的主力。 最顶上的是开发平台本身，它们正在直接抢走下面两层的生意。2025 年 12 月，编辑器 Cursor 收购 Graphite 这家代码审查机器人公司。微软把 Copilot Reviews 功能放进了日常订阅里。Anthropic 的 Claude Code，也自带了 lint 检查和 CI 安全护栏功能。 图 1：AI 代码治理市场的三层吸收链结构。中层的 SaaS 产品正在吞噬底层的独立人力服务，而最顶层的开发平台也在原生内置中层 SaaS 产品的核心功能。 这种大鱼吃小鱼的模式，在软件历史上发生过很多次。 当年做代码补全的先驱 Kite，在微软发布 GitHub Copilot 之后就倒闭了。大平台的免费内置功能一出来，小工具的收费模式就撑不住了。 第一代 AI 写作助手 Jasper 经历过 Jasper 崩塌。它的 ARR 在短时间内从 1.2 亿美元缩水到 5500 万美元，最后只能转型求生。 许多只是在 GPT-4 接口外面包了一层的 wrapper 工具，也都在模型升级后死掉了。 历史规律总是这样：如果一个生意只是在模型接口外包了一层薄壳，它就很难在平台面前活下去。只有那些在模型之外积累了核心价值的产品，比如有专有数据、整合了工作流、能做合规审计，才有可能留下来。Slopfix 用 Claude Code 去删 Claude Code 写的代码，这和当年 Jasper 用 GPT-3 接口替人写文案是一样的道理。 ## 治理需求是永远的，但清理生意是过渡的 需求一直存在，并不代表独立的清理生意能一直活下去。 这可以用杀毒软件来做个比方。电脑安全和查杀病毒的需求永远都有。但是在个人电脑市场上，以前那些独立的杀毒软件现在大部分都不见了。它们最后都变成了操作系统里的内置功能。AI 代码的治理，也正在走相同的路。 Gartner 在 Predicts 2026 报告里预测，会有一个专门修复 AI 代码技术债的新市场出现。权威机构正式点名这个品类，说明大家对代码治理的需求非常真实。不过，Gartner 说的这个市场，主角并不是 Slopfix 这类人工服务商。最终吃掉这个市场的，将是 SonarQube、CodeRabbit 以及各种开发平台自带的审核组件。 资本市场给的钱也证明了这一点。CodeRabbit 拿到了 8800 万美元的巨额融资，Greptile 也拿到了 Benchmark 领投的投资。投资机构看中的是可以规模化扩展的 SaaS 软件。他们并不想投资重度依赖人工的清理服务。 ## 这对我们意味着什么 面对 AI 代码的膨胀，我们需要做好三个准备： ### 治理文件会变成项目的核心资产 像 CLAUDE.md 或者 AGENTS.md 这样的配置文件，是项目的最高标准。它们不属于任何第三方软件。这些文件属于项目本身。这些文件可以放进版本控制，可以用 CI 工具强制执行。它们记录了项目的开发规范和质量标准。在 AI 时代，它们是防止 AI 乱改代码的最后防线。 ### 预防变烂比事后清理更重要 我们在研发或投资时，重点要放在‘别让代码变差’上。阻止代码变差，它的价值会随着模型变强而不断升高。防守越早，收益越大。而专门去清理烂代码的生存空间，其实正在变小。因为更强的下一代模型或者开发平台，随时可以顺手把事后清理做了。 ### 持续关注体积与质量的反向规律 Volume-Quality Inverse Law 是我们最需要关注的行业风向标。如果以后的研究继续证明，自回归模型有这个通病：模型越聪明，写出的代码就越臃肿。那么代码治理的需求，就会随着模型升级而爆发出指数级的增长。到时候，虽然人工清理的生意做不大，但自动化的治理工具会迎来黄金时代。