感觉 AI 会写很多各种可能情况的无用代码？它不会调试，不知道外部模块调用返回的具体格式，就用一堆if else去处理，最后还没有处理对。

GZ 大佬也说到：

ai 写代码感觉太差了，不知道在写什么
会不会制造更难维护的屎山

大家现在都已经在 AI 编程的世界中畅游了，整个软件开发似乎正以一种前所未有的方式悄然发生。 Cursor、Windsutf、Trae、lovable 等等已经完全进入了当前软件开发的世界中。

AI 能够根据自然语言注释或上下文，瞬间生成代码片段、函数甚至整个模块，极大地提升了编码的「表面」效率。我们正迈入一个「人机结对编程」的新时代。

但是大佬们也开始担心其产生的一些可能产生的后遗症。

今天我们从架构师的角度来看 AI 编程可能会给我们带来哪些技术债务。

作为架构师，我们的职责是超越眼前的速度与激情，洞察长期影响和潜在风险。

当团队的开发者们沉浸在「Tab」键带来的快感中时，一种新型的技术债务正在无声无息地累积。这种债务不再仅仅是糟糕的设计或潦草的实现，它更加隐蔽、更具迷惑性，并且直接与我们赖以信任的开发范式相冲突。

1992 年 Ward Cunningham 首次提出了传统的技术债务，指的是为了短期速度而采取了非最优的、有瑕疵的技术方案，从而在未来需要付出额外成本（利息）去修复。

它通常体现在糟糕的代码、过时的架构或缺失的文档上。

然而，AI 技术债务的范畴远超于此。它深深根植于数据、模型、基础设施乃至组织文化之中，其「利息」不仅是未来的重构成本，更可能是业务决策的失误、用户信任的丧失、合规风险的爆发，甚至是整个 AI 战略的崩塌。

从大模型的本质上来看，「 AI 编程是一个基于海量代码数据训练的、概率性的“代码建议引擎”」。它的工作方式决定了其产生的技术债务具有全新的特点。我们可以将其归纳为三个相互关联的维度：微观的代码级债务、宏观的架构级债务，以及深层的组织级债务。

微观的代码级债务 ——「似是而非」的陷阱

这是最直接、也最容易被感知的债务层面，它潜藏在 AI 生成的每一行代码之中。

在传统编程逻辑下，代码是要写的，而在 AI 编程时，代码是生成的，程序员的作用不再是写代码，而更多的是读代码，审核代码。

AI 生成的代码通常语法正确，甚至能够通过单元测试，但其内部逻辑可能存在微妙的、难以察觉的缺陷。例如，它可能选择了一个在特定边界条件下有问题的算法，或者「幻觉」出一个不存在的 API 调用，甚至在一个复杂的业务流程中，遗漏了一个关键的状态检查。这些 Bug 不再是明显的语法错误，而是「看似正确」的逻辑陷阱。

AI 编程减少了写代码的需要的认知成本，但是极大提升了读代码的心智负担。我们不仅仅要检查代码是否符合规范，还需要检查是否满足需求，以及是否在业务逻辑上完备。如果我们没有管这些问题，将来就可能是一个定时炸弹，隐藏在线上，不知道哪天会爆。

我们知道，AI 的知识来源于其训练数据——通常是海量的开源代码。因为 AI 倾向于生成「最常见」或「最流行」的解决方案，而不是针对当前上下文「最合适」的方案。它可能会引入一个庞大的库来解决一个小问题，或者使用一个过时但常见的编程范式，而不是团队正在推广的、更现代的模式。

这是 「设计熵增」的债务。它会持续不断地将外部的、非标准的、可能是平庸的设计模式注入我们的系统。长此以往，系统的技术选型会变得混乱，代码风格会变得不一致，精心设计的架构原则（如轻量级、高内聚）会被一点点侵蚀。我们必须警惕这种「随波逐流」的设计倾向。

每一行 AI 生成的代码，都应被视为一个来源不明的「外部依赖」。因为 AI 生成的代码片段可能悄无声息地引入了新的第三方依赖。更危险的是，它可能复现了其训练数据中包含的、有安全漏洞的代码模式（例如，不正确的加密实现、SQL 注入漏洞等）。此外，它生成的代码可能源自某种具有严格传染性的开源许可证（如 GPL），而团队并未意识到，从而引发法律合规风险。

为此，我们需要建立机制，自动扫描这些代码中的安全漏洞（SAST）和许可证合规问题。我们需要推动一种「零信任」的代码审查文化：开发者对任何由 AI 生成并最终提交的代码，负有 100% 的理解和责任。

宏观的架构级债务 ——「无声」的侵蚀

如果说代码级债务是「树木」的问题，那么架构级债务则是「森林」的水土流失。这种债务更加隐蔽，破坏性也更大。

如过往我们已经有一套优雅的微服务架构，定义了清晰的通信协议（如 gRPC）、统一的错误处理机制和标准的日志格式。然而，在使用 AI 编程时，为了快速实现一个功能，可能会接受一个使用 RESTful API、采用不同错误码、日志格式也千差万别的代码建议。单次来看，这只是一个局部的不一致，但当团队中数十个开发者每天都在这样做时，整个架构的一致性就会被破坏掉。

这是由于 AI 编程缺乏对我们「项目级」或「组织级」架构约定的认知而导致的，AI 编程是一个无状态的建议者，不理解我们系统的顶层设计。偿还这笔债务的成本极高，可能需要大规模的重构。架构师的核心挑战，从「设计」架构，扩展到了如何「捍卫」架构，防止其在日常开发中被无声地侵蚀。

AI 编程非常擅长生成「胶水代码」——那些用于连接不同系统、转换数据格式的脚本。这使得开发者可以轻易地在两个本应解耦的模块或服务之间建立直接的、临时的连接，绕过了设计的网关或事件总线。系统的模块化边界因此变得模糊，耦合度在不知不觉中急剧升高。

这是一种「捷径」。AI 让走「捷径」的成本变得极低，从而放大了人性中寻求最省力路径的倾向。架构师需要提供同样便捷、但符合架构原则的「正道」。例如，提供设计良好、文档清晰的 SDK、脚手架和标准化的 API 客户端，让「走正道」比「走捷径」更轻松。

从领域知识的角度来看，AI 可以从文档和代码中了解到一些，但是可能做不到完整的理解。

软件的核心价值在于其对复杂业务领域的精确建模。我们需要给 AI 以某种方式注入领域知识，如通过维护高质量的、富含领域术语的内部代码库和文档，来「引导」或「微调」AI 模型，使其建议更具上下文感知能力。

深层的组织级债务 ——「温水煮青蛙」的危机

这是最深层、也最关乎未来的债务，它影响的是人与团队。

当我们严重依赖 AI 编程时，会慢慢失去思考力和对代码的掌控力。

如果初级开发者过度依赖 AI，习惯于「提问-接受」的工作模式，而跳过了学习、思考和调试的艰苦过程。他们能够快速「产出」代码，但对底层原理、算法选择、设计权衡的理解却越来越肤浅。知其然不知其所以然，长此以往，团队成员的平均技能水平可能会停滞甚至下降。

这是团队的「未来」债务。我们在用未来的能力，来换取今天的速度。一个团队如果失去了独立解决复杂问题的能力，其创造力和韧性将不复存在。架构师需要倡导一种新的学习文化，将 AI 视为一个「助教」或「陪练」，而不是「枪手」。例如，鼓励开发者不仅要采纳 AI 的建议，更要尝试用自己的方法实现一遍，或者让 AI 解释它为什么这么写，并对解释进行批判性思考。

我们过往会用代码行数或者功能交付速度等指标来衡量团队的生产力，当有 AI 编程后，这些传统指标会得到巨大的提升，一天生产几千行代码是常事了。管理者可能会为此感到满意，但实际上，系统内部的技术债务正在快速累积，维护成本和风险也在同步攀升。

这是「技术管理」债务。我们需要建立新的、更能反映真实工程质量的度量体系。例如，关注代码的「可变性」（修改一个功能需要触碰多少文件）、「圈复杂度」、单元测试覆盖率的「质量」（而不仅仅是数量），以及 Code Review 中发现的深度问题的数量。架构师需要向管理层清晰地阐释 AI 编程的「债务风险」，推动建立更成熟的工程效能度量。

AI 编程助手是这个时代给予软件工程师最强大的杠杆之一，它有潜力将我们从繁琐的样板代码中解放出来，去专注于更具创造性的设计和思考。然而，任何强大的工具都伴随着巨大的责任和风险。

作为架构师，我们不能成为新技术的「勒德分子」，也不能成为盲目的「技术乐观派」。我们的角色，是确保这个强大的杠杆，成为放大我们架构意图和工程卓越的「放大器」，而不是制造技术债务的「复印机」。

这要求我们重新思考架构师的职责：我们不仅是蓝图的绘制者，更是蓝图的守护者；我们不仅要设计优雅的系统，更要设计能让优雅得以延续的「开发体系」；我们不仅要关注技术，更要塑造文化。通过建立清晰的规则、打造坚实的工程护栏、培育健康的开发者文化，我们才能确保，在 AI 赋能的未来，我们构建的软件系统，不仅跑得更快，而且走得更远、更稳。

以上。