如何避免AI代码质量下降

# 如何避免AI代码垃圾（Code Slop） 来源：https://newsletter.eng-leadership.com/p/how-to-avoid-ai-code-slop [](https://substackcdn.com/image/fetch/$s_!-moc!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fcf9c3791-15cb-4c85-9b50-c90eefeb0cfd_1600x578.jpeg) 本周的新闻简报由**Larridin (https://larridin.com/developer-productivity?1)** 赞助，这是一款AI原生的开发者智能平台。 **衡量AI对工程的影响。** Claude写代码的速度比人类快10倍。那为什么工程效率只提升了20%，而不是200%？ [](https://larridin.com/developer-productivity?2) 工程师实际上只有30%-40%的时间在写代码。剩下的时间被部署、冲刺计划、行政事务、支持问答、设计评审、事件响应以及各种杂事占据。 直到现在，我们还没有办法去映射和衡量那些隐形工作到底花在了哪里。Larridin改变了这一点。它能够映射工程工作在你的组织中如何流动，揭示阻碍效率的瓶颈和摩擦点，并精确展示你需要修复什么。 Larridin (https://larridin.com/developer-productivity?3)为AI原生工程团队提供完整的360度开发者智能。从传统的开发者生产力指标，到AI时代的度量标准，比如代理效能评分。 释放AI原生工程潜力 (https://larridin.com/developer-productivity) 感谢Larridin赞助本期新闻简报，让我们回到本周的思考吧！ 在之前的一篇文章中，我提到**代码审查已经成为工程团队的新瓶颈 (https://newsletter.eng-leadership.com/p/code-review-is-the-new-bottleneck)**。原因在于，如今我们借助AI生成代码的速度比以往任何时候都快。 但问题是，我们审查代码的速度跟不上，因此审查过程成了新瓶颈。正因如此，许多团队正在努力寻找以下两种方案之间的平衡： 1. 通过优秀的人工代码审查来阻止进度，确保质量保持在高水平 2. 仅依赖AI代码审查和/或进行浅层的人工代码审查 > 问题在于，行业内尚未达成共识：如何在不产生糟糕代码（即“AI代码垃圾”）的前提下，规模化代码审查以支持新代码的生成速度。 幸运的是，今天我们有请到Aviator公司CEO Ankit Jain作为本期文章的客座作者。他将分享他的推荐解决方案。 下面有请我们的客座作者，开始吧。 Ankit (https://www.linkedin.com/in/ankitjaindce/)是Aviator (https://www.aviator.co/)的联合创始人兼CEO。此前，他曾在Sunshine、Homejoy和Shippo领导工程团队，也曾在Google和Adobe担任工程师。 [](https://www.linkedin.com/in/ankitjaindce/https://www.linkedin.com/in/ankitjaindce/) 他还领导着The Hangar (https://dx.community/)，这是一个由资深DevOps和资深软件工程师组成的社区，专注于开发者体验。今天，他将与我们分享他对如何避免糟糕AI生成代码（即“AI代码垃圾”）的看法。 有请Ankit！ 本文是《如何终结代码审查 (https://www.latent.space/p/reviews-dead)》的后续文章，那篇文章认为，在AI加速的软件开发生命周期中，传统的代码审查已不再是可行的质量关口。 *那么自然的下一个问题是，如果不是代码审查，那会是什么？替代方案应该是什么？* 本文就是实践中的答案。 速度图表看起来很棒。PR合并得更快了。如果你只看代码编写量，数据讲述的是一个AI加速输出的故事。但在这些指标背后，工程团队正在积累一种新型的技术债务。 > 这些PR要么数日无人审查，要么被**橡皮图章式批准**，因为没有工程师有时间仔细审查500行的差异。 [](https://substackcdn.com/image/fetch/$s_!IAdp!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fc0ea6097-41b9-4063-927b-13e6718dfa95_1600x656.jpeg) 我并不是说工程团队应该从审查每一行代码变成什么都不做。我主张将批准关口上移，以防止我所说的“AI垃圾”代码。这种代码能编译通过、通过基本检查、看起来很合理，但实际上却是错的。 现在，让我更详细地分享AI生成代码在哪些地方会出错，即使它“看起来没错”。 1. **看似合理但逻辑错误** 最危险的一种。代码读起来正确，语法也正确，但逻辑是错误的。这些bug在审查中很难发现，因为它们需要理解代码本应做什么，而不是代码实际上做了什么。 1. **过度工程化** AI模型在大量代码语料上训练，这些代码包括企业级模式、框架抽象和生产级加固架构。 [](https://substackcdn.com/image/fetch/$s_!ebph!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fe8dddbca-487f-4ccb-a399-e1ac50e8792e_1000x410.jpeg) 要求解决一个本来只需要15行代码的问题，模型可能生成一个200行的抽象层，预判了一个没人要求的通用性。 1. **约定盲区** 模型生成的是优秀的通用代码，而不是适合你系统的代码。你的仓库有关于命名、错误处理、日志模式和模块边界的约定。 AI经常忽略它们，不是因为它学不会，而是因为提示中没有告诉它。 1. **幻影API和已弃用用法** 模型自信地调用不存在的方法、引用两个版本前已移除的配置选项、或者调用在当前服务上下文中不可用的内部API。 这些错误有时会立即被发现，有时则只有在生产环境中才会暴露。 1. **防御性过度** 过多的try-catch块、静默吸收错误、冗余日志。代码在某种意义上优雅地处理了失败，因为它默默地吞掉了错误，这使得调试变得异常困难。 1. **盲目模仿模式** 复制模式却不理解原因，比如在重试毫无意义的上下文中使用重试逻辑。为总是同步的调用使用断路器。错误处理看起来全面，但实际上与真实的故障模式不匹配。模式是存在的，但其背后的推理却不存在。 > 共同点在于：垃圾代码能通过视觉检查。它看起来像真正的代码。这正是它在规模上危险的原因。 代码审查是为一个不同的世界设计的。 AI生成的PR在性质上不同，而不仅仅是规模上不同。当人类编写代码时，意图会随着作者一起贯穿审查过程。 他们可以解释他们考虑过的权衡、他们拒绝的替代方案以及他们所受的约束。即使没有写出来，这些上下文也是可获取的。 当AI编写代码时，意图可能存在于一个从未被保存的提示中、一个没有捕捉到决策过程的工单中、或者仅仅存在于工程师的脑海中。实现被保留了，但其背后的推理却没有。 **测试发现的比我们假设的少。** 自动化测试是必要的，但并不充分。测试在测试作者想到要测试的范围内验证行为。 AI生成的代码引入了本质上未曾预料到的失败模式，因为如果工程师预料到了，他们就会在提示中说明。 > 你无法针对你都不知道要表达的需求编写测试。 [](https://substackcdn.com/image/fetch/$s_!qVa7!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fc4d77f89-0777-4ebb-97c2-a88fa9b868a6_1600x663.jpeg) 在实现之前形式化意图的概念并不新鲜。行为驱动开发（BDD）、测试驱动开发（TDD）和契约式设计（Design by Contract）都试图在编写任何代码之前，以结构化、人类可读的形式定义行为。 这些方法通常被视为开销。在交付压力下，它们被跳过了。AI使它们变得前所未有地实用。 AI可以从简短描述中协助生成结构化的验收标准、规格说明和契约式描述。它还可以根据这些描述验证输出。当规格本身也由AI辅助生成时，开销异议就消失了。 在Aviator，我们最近进行了一项实验来测试**意图驱动验证方法 (https://www.aviator.co/blog/what-if-code-review-happened-before-the-code-was-written/)**。我们想回答的主要问题是： > 如果审查发生在代码编写之前会怎样？ 团队实现了一个中等范围的、全栈的功能：一个分层、基于仓库的配置系统，且没有手动编写一行应用程序代码。 一切都是由一份经过团队审查和同意的规格说明引导，在生成一行代码之前就完成了。 它涵盖了整个技术栈，包括：用于配置历史的数据库模型和迁移、模式/验证层、合并仓库和全局配置的解析引擎、用于读取和更新配置的GraphQL API（类型+变更）、将解析后的配置集成到所有运行时子系统（沙箱预置、CI处理、代码生成、聊天处理、角色选择）以及一个前端设置页面，包含配置编辑器、变更历史视图和显示每个设置来源的源指示器。 这种功能，如果按传统方式做，会在多个PR中产生几十条审查评论。 该规格是协作生成的：一个脚手架PRD被输入到Claude Code，指示它提出澄清性问题，由团队同步回答。 生成的规格在两个层面进行了审查。 1. **第一个是实现细节** 具体的UI组件选择、输入验证要求、性能策略（如用于配置查找的Redis缓存）。 这些是通常在代码审查（而非规格审查）中浮现出来的问题。 1. **第二个是范围与完整性** 团队发现了一个缺失的UX需求，质疑是否某个角色的功能定义得足够清晰以包含进来，并标记了规格文本与实际设计不同步的地方（例如，引用了一个不存在的表）。 这些决策如果推迟到实现后的审查，就需要返工。这个规格审查花费了多位工程师大约10个小时的工程工作量。 它产生了14条验收标准，包含65个可检查项。它还产生了一份文档，可以作为验证代码的依据。 我们使用Claude Code来实现该规格。代理决定将实现分为四个阶段： 1. 基础， 2. 后端核心， 3. 集成，以及 4. 前端。 整个实现包含大约6000行代码，其中40%是应用代码，40%是测试，20%是GraphQL自动生成文件。 值得注意的是，规格中没有给出编写测试的明确指令，这表明代理满足验收标准的策略是编写测试。 然后，第二个代理针对生成的PR验证了65条验收标准。 这花了六分钟，并生成了一份结构化报告，包含每个项的文件引用和解释： - 60项通过， - 4项失败，以及 - 1项部分通过。 人类进行同样的彻底验证需要数小时。 人工审阅者平均每个PR留下了10条评论。发现的bug很少，主要的一个是状态编辑器过时。代码审查发现了约定级别的问题，例如导入位置、枚举重复和命名模式。 这是预期的结果。规格审查发现的是设计层面的问题，例如缺失的需求、未充分说明的特征和范围问题。 代码审查发现的是约定层面的问题，那些需要熟悉你特定代码库的事情。这两个层面都是必要的，因为它们发现的是不同的问题。 我们仍在学习如何编写足够精确的规格，以便代理能够可靠地实现，但又足够灵活，使团队不会在规格上花费比编码更多的时间。 > 工程师往往过分担心规格应该是什么样子以及编写它的开销。 如果我们把编写规格简单地看作编写一个JIRA工单，这种压力就可以消失。对于一个简单的问题，一行意图或你会在工单中写的内容可能就足够详细了，而验收标准可以由AI生成。 我们的实验效果很好，足以改变我们验证AI代码和防止代码垃圾的思考方式。 以下实践并非完整的方法论。它们是一组具体的干预措施，团队可以逐步采用，从他们最痛苦的地方开始。 1. **严格限定AI任务的范围** 大型、开放式的提示会产生最多的垃圾代码。“构建这个功能”给了AI太大的自由度。 范围明确、边界清晰的任务——一个特定的函数、一个定义的API表面、一个受约束的重构——会产生好得多的输出，并且更容易验证。 这对于那些认为AI的价值在于处理大型任务的团队来说可能违反直觉。价值确实存在，但更好的方式是将大型任务分解为更小、更明确指定的子任务，并在它们之间设置明确的检查点。 这和人类如何更好地工作没什么不同。 1. **将意图作为一等制品** 在生成任何代码之前，意图应该以可审查和批准的形式写下来。这不需要正式的方法论。它需要养成在生成“如何做”之前记录“做什么”的习惯。 验收标准也可以由AI编写。意图实际上隐藏在用户与AI对话的提示交互中（决策树），或者用户可能在工单中添加的细节中。 在更严格的一端，这意味着BDD风格的规格或可用于验证输出的契约式描述。 精确的格式不如明确捕捉意图的纪律重要。再次强调，我不是要增加开销或发明新的文档来编写。我们在提示LLM时已经很擅长表达意图了。 在实践中，对于AI辅助工作，这很可能看起来像一个轻量级的规格模板。 两到三句关于范围的描述，一个验收标准列表，以及一个明确不在范围内的说明。将其设为PR的要求。同样，这可以由AI生成。 1. **在实现之前审查意图** 对于超过某个复杂度阈值的任何AI辅助任务，要求在代码生成之前获得规格批准。 > 最昂贵的审查是代码已经存在之后进行的审查。 当在规格审查中发现一个设计决策时，修复它只是一个句子修改。当在代码审查中发现时，可能需要大量的返工。 将审查提前的团队——在生成代码之前批准规格——将高价值决策前置，而让代码审查去做它真正擅长的事情：捕获实现层面的问题。 1. **尽可能自动化** 测试、linting和类型检查可以捕获表面级别的垃圾代码，你绝对不应该跳过它们。正如我在我的文章中所述，对于AI代码，信任是分层的。我们堆叠不完美的过滤器，直到没有漏洞穿过。 1. **建立并维护团队垃圾代码登记表** 每个代码库都有AI持续出错的模式。可能是特定的错误处理约定、命名模式、被违反的模块边界，或者是AI偏好的但你已弃用的库。这些都是可知且可预防的。 垃圾代码登记表有两个目的：将这些模式反馈到提示中