大家好，我是 dtsola，一名IT解决方案架构师，也是一人公司的实践者。
在日常工作中，我经常需要在架构设计、技术选型和实际编码之间切换。最近这一年，AI编码工具的爆发式增长让我既兴奋又警惕。作为一个需要独立承担从需求到交付全流程的技术人，我深刻体会到：AI确实能让我们写代码更快，但也可能让我们陷入一个危险的陷阱——用速度替代思考。
今天分享的这篇文章来自 chrisloy 的《The AI coding trap》，它精准地指出了当前AI编程浪潮中最容易被忽视的问题。作为技术人员，我们需要警惕这个陷阱，因为它不仅关乎个人成长，更关乎我们交付软件的长期质量和可维护性。
以下是原文内容：
目录
一、AI编码陷阱
传统开发：思考大于编码
先思考，后编码
二、"先编码，后提问"
AI编码的速度与理解困境
先编码，然后试图理解
营销宣传vs实际效果
开发者角色的转变
三、技术负责人的困境
两种交付方式的冲突
高级工程师的高带宽优势
大包大揽的失败轨迹
第三种平衡之道
最佳实践框架
四、LLM是闪电般快速的初级工程师
工程师成长的两个维度
工程师和LLM的改进轨迹
LLM与初级工程师的两个根本区别
AI驱动的工程 vs Vibe coding
Vibe coding的失败状态
Vibe coding的适用场景
五、如何避免AI编码陷阱
工程师作为AI的技术负责人
AI在软件开发生命周期的应用
六大实践领域
六、写在最后：重新定义工程师的价值
一、AI编码陷阱
如果你曾经观察过某人"编码"，你可能会发现他们盯着屏幕发呆的时间远远超过敲击键盘的时间。不，他们（很可能）并不是在偷懒。软件开发从根本上说是一种解决问题的实践，因此，就像解决一个棘手的填字游戏一样，大部分工作都是在你的脑海中完成的。
在软件开发生命周期中，编码就像填字游戏中填入的字母，与所有的抓耳挠腮和草稿笔记相比，只占很小一部分工作量。真正的工作通常与编码同时发生，开发者需要学习业务领域、细化需求、规划相关抽象、考虑副作用、增量测试功能，最后消灭那些在这个严格过程中幸存下来的bug。
它看起来是这样的：
先思考，后编码。
但在AI驱动的编码中，事情的发展却截然不同。
二、"先编码，后提问"
像 Claude Code 这样的AI编码代理正在以惊人的速度独立编写代码。但大多数软件都存在于复杂的系统中，由于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：抛开谨慎，以速度实施，牺牲理解以换取交付速度，最终撞上无法挽救的混乱代码墙。
正如预期的那样，在这两种方法之间选择的长期轨迹遵循与在初级团队中选择并行委派和大包大揽之间相同的模式：
Vibe coding具有与大包大揽完全相同的失败状态。
这就是为什么vibe coding方法非常适合小型项目或一次性原型：足够简单的应用程序可以在完全不需要人类思考的情况下交付。通过限制项目的复杂性并依靠工具的能力，我们可以在短时间内交付端到端的可工作软件。
只要你不需要思考，Vibe coding就很棒。
但你会遇到AI单独无法扩展的复杂性壁垒。
现在构建原型比以往任何时候都容易。但如果我们想有效地使用LLM来加速交付真实、复杂、安全、可工作的软件，并实现超过边际效率提升的收益，我们需要编写一本新的工程实践手册，专门用于最大化包括人类和LLM在内的工程团队之间的协作。
五、如何避免AI编码陷阱
AI编码代理的生产力令人眼花缭乱，但缺乏对你的业务、代码库或路线图的深入了解。如果不加以控制，它们会愉快地产出数千行代码，而不考虑设计、一致性或可维护性。那么，工程师的工作就是充当这些能手的技术负责人：提供结构、标准和流程，将原始速度转化为可持续交付。
我们需要一本关于如何高效交付可工作软件的新手册，我们可以回顾过去来学习如何做到这一点。通过将LLM视为闪电般快速的初级工程师，我们可以依靠软件开发生命周期的最佳实践来构建可扩展的系统。
AI可以在软件开发生命周期的每个阶段使用。
正如技术负责人不仅仅是编写代码，而是为团队设定实践一样，工程师现在需要为AI代理设定实践。这意味着将AI引入生命周期的每个阶段：
规格说明：探索、分析和细化功能规格，以覆盖边缘情况并缩小焦点。
文档：预先生成和审查文档，以提供可重用的护栏和持久的证据。
模块化设计：搭建模块化架构以控制上下文范围并最大化理解。
测试驱动开发：在实施之前生成广泛的测试用例，以指导实施并防止回归。
编码标准：通过上下文工程，在生成代码时应用内部风格和最佳实践。
监控与内省：以比任何人类都更快的速度分析日志并提取见解。
通过理解交付软件远不止编写代码，我们可以避免AI编码陷阱，转而极大地增强我们交付可工作、可扩展软件的能力。
六、写在最后：重新定义工程师的价值
读完这篇文章，我想起了自己作为解决方案架构师的日常工作。在一人公司的实践中，我既是架构师，也是开发者，还是运维人员。AI工具确实帮我节省了大量编码时间，但我发现最有价值的，恰恰是那些AI无法替代的部分：
理解客户真正的业务痛点
设计符合长期演进的系统架构
在技术选型时权衡各种trade-off
预见系统在生产环境中可能遇到的问题
这篇文章给我最大的启发是：AI改变的不是工程师是否有价值，而是工程师的价值体现在哪里。
过去，我们的价值很大程度体现在"能写出代码"；现在和未来，我们的价值更多体现在"能思考清楚该写什么代码，以及为什么这样写"。
作为技术人员，我们需要：
把AI当作需要指导的初级工程师，而不是可以完全依赖的魔法工具
在速度和理解之间找到平衡，不要让AI的速度掩盖了思考的价值
建立新的工作流程，让AI在我们的框架和标准下工作
持续学习和成长，因为只有人类能够真正积累领域知识和架构智慧
AI编码工具是强大的放大器，它能放大优秀工程师的能力，也能放大糟糕实践的危害。关键在于，我们选择成为驾驭工具的人，还是被工具驾驭的人。
希望这篇文章能给同样在探索AI时代工程实践的你一些启发。
参考文献
https://chrisloy.dev/post/2025/09/28/the-ai-coding-trap
如果这篇文章对你有帮助，欢迎点赞、收藏、转发。也欢迎在评论区分享你的经验，我们一起交流学习！
我是 dtsola【IT解决方案架构师 | 一人公司实践者】 ；专注商业、技术、一人公司、个人成长分享。
提供服务：AI项目咨询 | 技术解决方案 | IT项目实施 | 企业技术顾问
博客：https://www.dtsola.com
公众号&VX：dtsola
需交流经验，加微信 dtsola，备注：交流经验。
需IT咨询，加微信 dtsola，备注：IT咨询。
#AI编码 #VibeCoding #Cursor #ClaudeCode #独立开发者 #AI创业 #一人公司 #程序员 #软件工程师 #软件工程
