AI 编码陷阱：为什么过度依赖 AI 会损害你的编程能力

原文来源：Chris Loy — 过度依赖 AI 编码工具正在让许多开发者陷入"先写代码、后想问题"的陷阱，看似效率提升，实则损害了深度思考与长期技术成长。

如果你观察过真正的程序员工作，会发现他们盯着屏幕发呆的时间远比敲键盘的时间长。别误会，他们大概率没有在摸鱼。软件开发本质上是一门解决问题的技艺，就像解一道复杂的填字游戏，大部分功夫其实花在脑子里。

在整个软件开发生命周期中，写代码只是填入填字游戏的字母，真正的脑力消耗在于挠头苦思和涂涂画画。开发者需要理解业务领域、厘清需求边界、设计合理的抽象、考虑副作用、逐步测试功能、最后消灭那些侥幸逃过层层审查的 bug。这个过程大致是这样的：先深度思考，再动手编码。

但 AI 驱动的编码方式，让这一切发生了根本性的逆转。

"先写代码，后问问题"

像 Claude Code 这样的 AI 编码助手，让孤立地写代码变得快得惊人。但大多数软件都活在复杂的系统之中，而 LLM 目前还无法一次性承载整个应用的完整上下文。人类的审查、测试和集成需求依然存在。问题在于，当代码是在人类没有深入思考的情况下被写出来的，后续的审查和集成会变得异常困难。结果就是，在复杂软件项目中，大量时间被花在了事后理解 AI 到底写了什么上面。

这正是营销文案鼓吹的"用 AI 写代码速度提升 10 倍"与现实世界中"交付可用软件"的实际生产力增益（通常只有 10% 左右）之间的巨大鸿沟的根源。写代码和交付能跑起来的软件，完全是两回事。

更令人沮丧的是，作为开发者，我们越来越多的时间被花在收拾这些"会说话的神奇机器"的烂摊子上。LLM 以闪电般的速度搞定了所有有趣、轻松的活儿，而我们却被留下去做那些吃力不讨好的脏活：测试以确保现有功能没有被破坏、清理重复的代码、写文档、处理部署和基础设施……真正留给开发者热爱的事情——编码本身——的时间反而所剩无几。

技术负责人的两难困境

好消息是，这个问题本身并不新鲜。LLM 确实在颠覆软件开发的方式，但核心矛盾其实是一个老生常谈的问题，我称之为"技术负责人的两难困境"。

当工程师的职业生涯逐步进阶，他们终将踏入技术负责人（tech lead）的角色。他们可能是在带团队，也可能是作为首席工程师（principal engineer）驱动技术交付而不直接管理人。无论哪种情况，他们都对团队的技术交付负责，而且通常也是团队里经验最丰富的开发者。

软件交付是团队协作的成果，但经验对个体产出的速度有着极大的不平衡效应。因此，当技术负责人的首要任务是最大化交付速度时，他们往往会面临一个内在冲突：

• 公平分配：把任务合理分派给团队每个人，最大化 junior 成员的学习和成长机会，但交付速度会被最慢的成员拖后腿。
• 过度包办：只把简单或非核心的工作交给 junior，最难的活儿自己扛，因为你是团队里最能快速交付的人。

不幸的是，虽然过度包办对团队的长期健康极其有害，但它往往能在短期内显著加速交付。技术负责人的高带宽，最高效的用法似乎就是把所有硬骨头都啃掉。这种模式在我职业生涯中反复出现，代价也显而易见：经验被锁死在技术负责人一个人身上，团队变得脆弱，支持成本变高，技术负责人成为单点故障，压力越来越大。接下来发生的事情完全可以预料：身心俱疲、离职，然后团队陷入危机——因为那个唯一真正了解一切的人不在了。

解决方案通常在于第三条路，平衡交付与团队成长：

建立团队实践，让工程师在最小化返工、最大化有效协作、促进个人成长和学习的前提下，交付可用的代码。

当我还在 Datasine 担任 CTO 时，我们把这种态度凝练成了一句简单的团队格言：

学习。交付。玩得开心。

好的技术负责人会让工程师接触能力边界上的工作，用流程和实践控制交付风险，同时帮助每个成员提升技能、知识和领域专长。这才是优秀技术领导的本质。

实现这一目标的方法有很多，从严格的 极限编程规则 到更松散的"最佳实践"集合：

• 代码审查
• 增量交付
• 模块化设计
• 测试驱动开发
• 结对编程
• 高质量文档
• 持续集成

那么，对于今天的资深工程师来说，一个紧迫的问题是：如何在 AI 驱动的编码世界里，把这些实践翻译过来？

LLM 是闪电般的初级工程师

2025 年，许多工程师第一次体会到了每个技术负责人都熟悉的处境：管理一个聪明但不可预测的初级工程师。驾驭和控制这种人才，使其有利于团队协作，是工程领导力的核心挑战之一。但 AI 编码助手需要与初级工程师不同的管理方式，因为它们的生产力和成长机制完全不同。

软件工程师随着经验增长，通常会在多个维度同步提升：写出更健壮的代码、使用更好的抽象、减少写 bug 和修 bug 的时间、理解更复杂的架构、更有效地覆盖边界情况、更早发现重复模式等等。工程是一门丰富而复杂的学科，有许多专精方向，但简单起见，我们可以把这些维度归纳为两大主题：

• 质量：交付更复杂、更高性能、更易维护的代码的能力
• 速度：在更短时间内开发出可用、无 bug 代码的能力

优秀的工程师会在这两个轴上同时进步。

早期的 LLM 写代码很快，但花在修 bug 和清除幻觉上的时间意味着它们交付无 bug 代码的速度很慢。随着时间推移，更聪明的 LLM 和更好的上下文工程与工具使用，让现代 AI 编码助手在"一次性"写代码方面强了很多。当前这一代商用代理，对于一些能难住中级工程师的问题，已经能以惊人的速度产出可用代码——尽管还无法匹敌资深工程师的专业水准。

因此，我们可以把当前这一代 AI 编码助手看作初级工程师，但有两个根本差异：

1. LLM 交付代码的速度比初级工程师快得多得多，既不受思考时间也不受打字速度的限制；
2. LLM 没有真正的学习能力，它们的进步只能依赖更有效的上下文工程或新基础模型的发布。

和对待初级工程人才一样，部署 LLM 也有两种大致不同的方式，取决于你的关注点是长期还是短期：

• AI 驱动工程：采用最佳实践，强调人类对代码的理解，慢下来以实现可持续的开发。
• Vibe Coding：把谨慎抛到脑后，以速度优先实现功能，牺牲理解换取交付速度，最终撞上无法挽救的烂代码墙。

不出所料，这两种选择的长期轨迹，与在"公平分配"和"过度包办"之间做选择时呈现的模式几乎一模一样。

这就是为什么 Vibe Coding 对于微型项目或一次性原型来说很棒：复杂度足够低的应用，可以完全不需要人类思考就能交付。通过限制项目复杂度并充分利用工具的能力，我们可以在极短时间内交付端到端的可用软件。

但你终将撞上一堵 AI 独自无法逾越的复杂度之墙。

构建原型从未如此简单。但如果我们想有效利用 LLM 来加速交付真正复杂、安全、可用的软件，并实现远超边际效率提升的价值，我们就需要编写一本全新的工程实践手册，专门用来最大化人类与 LLM 混合团队之间的协作效率。

如何避免 AI 编码陷阱

AI 编码助手令人目眩的生产力背后，是它们对你的业务、代码库或路线图缺乏深度了解。放任不管的话，它们会肆无忌惮地产出数千行代码，完全不顾设计、一致性或可维护性。工程师的职责，就是充当这些"天才新秀"的技术负责人：提供结构、标准和流程，把原始速度转化为可持续的交付。

我们需要一套新的工程实践指南来高效交付可用软件，而答案可以从过去的经验中寻找。把 LLM 当作闪电般的初级工程师，我们就可以借鉴软件开发生命周期中的最佳实践来构建可扩展的系统。

就像技术负责人不只是写代码，更要为团队制定实践规范一样，工程师现在也需要为 AI 代理制定实践规范。这意味着把 AI 引入生命周期的每个阶段：

需求分析：探索、分析和细化功能规格，覆盖边界情况，缩小范围。

文档：提前生成和审查文档，提供可复用的护栏和持久的知识沉淀。

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

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

编码规范：通过上下文工程，在生成代码时应用团队风格和最佳实践。

监控与洞察：分析日志、提取洞见，速度远超任何人类。

认识到交付软件远不止"写代码"这件事，我们才能避免 AI 编码陷阱，转而大幅放大我们交付可用、可扩展软件的能力。

写在最后

AI 工具不会取代思考，它们只是改变了思考发生的时机和方式。真正的危险不在于使用 AI，而在于用 AI 替代了本该由人类完成的深度思考。当你习惯了让 AI 替你填字，你自己的填字能力就会退化。

最聪明的开发者会把 AI 当作一个超级加速的 pair programmer，而不是一个可以外包思考的替身。保持对代码的深刻理解，建立让 AI 输出可控的工程实践，才能在 AI 时代持续成长，而不是沦为 AI 产出的修理工。