AI 编码陷阱:当速度超越理解时的困境

我爱免费

作者：微信文章
AI 编码陷阱：当速度超越理解时的困境

核心要点：探讨 AI 驱动编程带来的生产力悖论及应对策略

引言：编码的本质是什么？


如果你曾经观察过别人"编码"的过程，你可能会发现他们盯着空白处的时间远比敲击键盘的时间要长。不，他们（可能）并不是在偷懒。软件开发本质上是一种解决问题的实践，就像解复杂的填字游戏一样，大部分工作都在头脑中完成。

在软件开发生命周期中，编码只是填入填字游戏中的字母，相比大量的思考和草稿笔记，这只是很小一部分努力。真正的工作通常发生在编码过程中，开发者学习领域知识、细化需求、规划抽象模型、考虑副作用、逐步测试功能，最后修复那些逃过严格审查的 bug。看起来像这样：

思考，然后编码。

但在 AI 驱动的编码中，情况却截然不同。
AI 编码陷阱的核心问题

"先编码，后提问"


AI 编码代理（如 Claude Code）使得孤立地编写代码变得惊人地快。但大多数软件都存在于复杂系统中，由于大型语言模型（LLM）还不能一次性记住整个应用的完整上下文，人工审查、测试和集成的需求依然存在。而当代码是在没有人类深入思考的情况下编写的，这些工作就变得更加困难。因此，在复杂软件开发中，大量时间会花在事后理解 AI 所写代码的含义上。

编码，然后试图理解。

这就是营销宣传中声称的 AI 编码范式转变速度（通常被描述为"10 倍更快"）与实际交付可用软件时看到的边际生产率增益（通常接近 10%）之间差异的根本原因。
开发者的新角色


更令人沮丧的是，作为开发者，我们花费越来越多的时间仅仅是在修复这些神奇的胡言乱语机器的输出。当 LLM 以闪电般的速度完成所有有趣且简单的任务时，我们却被留下处理所有吃力不讨好的工作：测试以确保现有功能不被破坏、清理重复代码、编写文档、处理部署和基础设施等。很少有时间真正用于开发者喜欢做的事情：编码。
技术领导者的两难境地


虽然 LLM 正在改变软件开发的执行方式，但这个问题本身并不是新现象。实际上，这只是古老问题的一个极端例子，我称之为：
技术领导者的两难选择


随着工程师职业生涯的发展，他们最终会承担技术领导的角色。可能是团队管理者，也可能是首席工程师，推动技术交付而不涉及人员管理。无论哪种情况，他们都负责团队的技术交付。同时，他们通常是团队中经验最丰富的开发者：要么在职业经验上，要么在专门领域知识上，或者两者兼备。

软件交付是一个团队协作的过程，但经验会对个人贡献速度产生极大的不平衡影响。因此，当技术领导者的主要职责是最大化交付时，他们常常面临两种软件交付方式之间的内在冲突：

公平分配任务给团队成员，最大化初级工程师的学习和所有权机会，但允许交付被最不高效团队成员的速度所瓶颈。 过度保护团队，只把简单或非关键工作分配给初级工程师，而把最难的工作留给自己——因为自己是团队中最能快速交付的人。 不幸的是，尽管我们会看到过度保护对团队长期健康极其有害，但它通常也是加速交付的有效方法。技术领导者的高带宽往往通过承担所有最难的工作得到最有效的利用：

资深工程师具有更高的带宽。

在我的职业生涯中，我多次看到这种模式重复出现。当然，它也有代价。技术领导者经验的孤岛化使团队变得脆弱，使支持工作更加困难，并给技术领导者带来越来越大的压力，使其成为单一故障点。接下来的结果是可以预见的：倦怠、离职，以及随之而来的危机，团队在失去唯一真正了解一切运作原理的人之后艰难求生。

过度保护带来短期收益但最终失败。

通常情况下，解决方案在于第三种方式，避免这两种极端做法，平衡交付与团队成长。我们可以将其表述为：

实施团队实践，让工程师在一个最小化返工、最大化有效协作并促进个人成长和学习的框架内交付可用代码。

当我担任 Datasine 的 CTO 时，我们将这种态度铭刻在一个简单的技术团队座右铭中：

学习。交付。享受乐趣。

优秀的技术领导者会让工程师接触处于其能力极限的工作，使用能够最小化交付风险的过程和实践，同时让每个团队成员都能发展自己的技能、知识和领域专长。这实际上是良好技术领导力的精髓。

实现这一目标有很多方法，从严格的编码框架（如极限编程规则）到较为宽松的原则（我们通常称之为"最佳实践"）：

代码审查 增量交付 模块化设计 测试驱动开发 结对编程 高质量文档 持续集成 因此，对于今天的资深工程师来说，一个紧迫的问题是：我们如何将这些实践转化为 AI 驱动的编码世界？
LLM 是闪电般快速的初级工程师


2025 年，许多工程师首次发现自己处于每个技术领导者都熟悉的境地：监督一位才华横溢但难以预测的初级工程师。以一种有利于有效团队协作的方式来驾驭和控制这种人才，是工程领导力的主要挑战之一。但 AI 编码代理需要不同于初级工程师的管理方式，因为它们的生产力和成长本质完全不同。

随着软件工程师获得经验，我们的生产力会在多个方面同时提高：编写更健壮的代码、使用更好的抽象、减少编写和修复 bug 的时间、理解更复杂的架构、更有效地覆盖边缘案例、更早地识别重复模式等。工程是一门丰富而复杂的学科，有许多专业化的途径，但为了简化起见，我们可以将这些维度归为两个广泛的主题：

质量：交付更复杂、更高性能、更易维护代码的能力 速度：在更短时间内开发可用、无 bug 代码的能力 随着时间推移，优秀的工程师在这两个轴上都会有所改进。

工程师和 LLM 在速度和质量上都有所提升。

早期的 LLM 编写代码很快，但由于修复 bug 和消除幻觉所需的时间，它们完成无 bug 代码的速度很慢。随着时间推移，更智能的 LLM 以及更有效的上下文工程和工具使用意味着现代 AI 编码代理在"一次性"编写代码方面做得更好。目前一代商业可用的代理能够以惊人的速度生成一些中等级别工程师都会感到挑战的可用代码，尽管它们还无法匹配资深工程师的专业知识：

所以我们可以将当前一代 AI 编码代理视为初级工程师，尽管有两个根本区别：

LLM 交付代码的速度比初级工程师快得多，不受思考时间和写作时间的限制； LLM 没有真正的学习能力，而是只能通过更有效的上下文工程或新基础模型的到来来改进。 就像初级工程人才一样，根据你的关注点是长期还是短期，有两种大致的部署方式：

AI 驱动工程：采用最佳实践，强调人类对代码的理解，缓慢推进以使开发可持续。 氛围编码（Vibe coding）：抛弃谨慎，快速实施，牺牲理解换取交付速度，最终撞上一堆无法挽救的混乱代码的墙。 正如预期的那样，选择这两种方法的长期轨迹与在平行委派和过度保护初级团队之间做选择的模式非常相似：

氛围编码与过度保护有着完全相同的失败状态。

这就是为什么氛围编码方法非常适合小型项目或一次性原型：足够简单的应用可以在不需要任何人类思考的情况下交付。通过限制项目的复杂性并充分利用工具的能力，我们可以迅速交付端到端的可用软件。

氛围编码很棒，只要你不需要思考。

但你会遇到 AI 无法独自扩展的复杂性壁垒。

构建原型从未如此容易。但如果我们要有效地使用 LLM 来加速交付真实、复杂、安全、可用的软件，并实现超出边际效率的收益，我们需要编写一套新的工程实践手册，专门针对最大化包含人类和 LLM 的工程团队之间的协作。
如何避免 AI 编码陷阱


AI 编码代理具有令人眼花缭乱的生产力，但缺乏对你业务、代码库或路线图的深入了解。如果不加以控制，它们会愉快地生成数千行代码，而完全不考虑设计、一致性和可维护性。因此，工程师的工作就是充当这些高手的技术领导者：提供将原始速度转化为可持续交付的结构、标准和流程。

我们需要一个新的手册来指导如何高效交付可用软件，我们可以回顾过去来学习如何做到这一点。通过将 LLM 视为闪电般快速的初级工程师，我们可以依靠软件开发生命周期的最佳实践来构建可扩展的系统。

AI 可以在软件开发生命周期的每个阶段使用。

正如技术领导者不仅编写代码还要为团队设定实践一样，工程师现在也需要为 AI 代理设定实践。这意味着将 AI 引入生命周期的每个阶段：

规格说明：探索、分析和完善功能规格，以涵盖边缘案例并缩小焦点。

文档：提前生成和审查文档，以提供可重用的防护措施和持久证据。

模块化设计：搭建模块化架构，以控制上下文范围并最大化理解。

测试驱动开发：在实现之前生成广泛的测试用例，以指导实现并防止回归。

编码标准：通过上下文工程，在生成代码时应用内部风格和最佳实践。

监控与自省：比任何人都更快地分析日志和提取洞察。

通过理解软件交付不仅仅是编写代码，我们可以避免 AI 编码陷阱，而是极大地放大我们交付可用、可扩展软件的能力。

---

文档来源：The AI coding trap
原始作者：[作者名，如有]
原始发布日期：[发布日期，如有]

---

本文由 AI 助手整理优化，欢迎关注、分享转载，请注明出处