AI 生成代码引入的新型技术债

六个月前，我的团队在庆祝。

我们在第三季度发布的功能比整个前一年都多。我们的速度快到飞快。AI 工具改变了我们的工作方式 —— 过去需要一周的工作变成了一天。过去需要一天的工作变成了一个小时。

我们的 CTO 发了一条全公司 Slack 消息："这就是工程的未来。"

上个月，我们不得不停止所有功能开发整整三周。

不是因为安全漏洞。不是因为服务器故障。而是因为我们的代码库与 AI 生成的代码缠绕在一起，以至于没有人 —— 甚至包括那些"编写"它的人 —— 能够有信心地修改它。

我们庆祝着走进了一场危机。

最糟糕的是？我看到了这一点。我只是不知道我在看什么。🧵

至今无人命名的新技术债

技术债早就不是新闻了。每个开发者都知道那种感觉 —— 急着上线，抄近路，承诺自己以后会重构。代码今天能用。明天就成别人的问题了。

AI 技术债不同。它不是关于抄近路。它是关于你移动得太快，以至于完全失去了线索。

现在代码库中正在积累三种不同的 AI 技术债 —— 大多数团队同时经历所有三种：

1. 认知债 —— 比你能理解代码的速度更快地上线代码

2. 验证债 —— 批准你没有完全阅读的代码差异

3. 架构债 —— AI 生成的可用方案违反了系统的设计

大多数关于 AI 和技术债的文章都关注代码质量。这是错误的层级。真正的危机发生在更上一个层级 —— 在应该理解他们所构建系统的开发者的脑子里。

我理解发生了什么的时刻

让我告诉你那个一切都明白了的一周。

一个新开发者加入我们的团队 —— 我们叫他 Rahul。聪慧、快速、显然很有才华。从第一天起，他就在积极使用 Cursor 和 Claude Code。

三周后，我让他给我讲解一下他构建的身份验证流程。

他打开了文件。开始解释。到了令牌刷新逻辑的地方停了下来。

"实际上，"他说，"我不太确定为什么要这样组织。我测试时它能用。"

我没有生气。我认出了那种感觉。那和我试图调试自己的 AI 生成代码、感觉像在读别人的工作时的感觉一样。

那次对话让我进入了一个兔子洞，彻底改变了我对 AI 工具的看法。

解释危机的数据

下面这些数据应该是每个开发者社区的头条新闻 —— 但不知何故不是：

开发者对 AI 编码工具的信任在十八个月内从 43% 下降到 29%。然而使用率却升至 84%。

再读一遍。开发者信任 AI 工具的程度比以往任何时候都少。他们使用它们比以往任何时候都多。这个差距 —— 使用你日益不信任的工具 —— 现在有个名字了：认知债。

75% 的技术领导者预计到 2026 年会因为 AI 加速的编码实践而面临中度或严重的债务问题。

还有这个最触动我的：

一家 API 安全公司发现，2024 年 12 月至 2025 年 6 月间，财富 50 强企业中每月的安全发现数增加了 10 倍。从 1,000 增加到超过 10,000 个月度漏洞。在六个月内。

十倍的安全漏洞。在六个月内。在世界上最大的公司中。

这就是当速度成为唯一衡量标准时会发生的事情。

"我曾经是个工匠"

一个开发者用一种方式抓住了一些重要的东西，我一直在思考：

"我曾经是个工匠……现在我感觉像是宜家的工厂经理。"

那个形象刻在了我的脑子里。不是因为它悲观 —— 而是因为它很准确。

宜家的工厂经理并不理解每件家具是如何制造的。他们管理吞吐量。他们留意明显的缺陷。他们相信这个系统。

这对家具很管用。对处理用户数据、处理支付或运行人们依赖的基础设施的软件系统就不行了。

软件需要有人深入理解它，足以在事情出错时推理会发生什么。工厂经理模式 —— 高吞吐量、浅层评审 —— 产生的系统是没有人真正理解的。

而没有人理解的系统会以没有人能预测或快速修复的方式崩溃。

三种债务类型 —— 用简洁的语言

让我准确解释现在在代码库中积累的是什么。

1. 认知债 —— 无形的危机

Margaret-Anne Storey 完美地描述了这一点：程序不是它的源代码。程序是一个理论 —— 一个存在于开发者脑子里的心理模型，它捕捉了软件做什么、意图如何变成实现、改变事物时会发生什么。

AI 工具默认将开发者从创建模式推入审查模式。你停止解决问题，开始评估别人产生的解决方案。

问题在于审查 AI 输出感觉很有成效。你在阅读代码，发现问题，进行编辑。但你没有建立让你能够独立地推理这个系统的心理模型。

一个学生团队完美地演示了这一点 —— 他们一直在用 AI 快速构建，有可用的软件。当他们在第七周需要做一个简单的改变时，项目陷入了困境。没有人能解释设计原理。没有人理解组件如何相互作用。程序的共享理论已经蒸发了。

// This code works. Can you explain why in 30 seconds?
// If you generated it with AI and didn't stop to understand it — 
// you've accumulated cognitive debt.

const processPayment = async (userId, amount, currency) => {
  const [user, rateLimit, fraud] = await Promise.all([
    db.users.findById(userId),
    redis.get(`rate:${userId}`),
    fraudService.check(userId, amount)
  ]);

  if (!user || rateLimit > 10 || fraud.score > 0.7) {
    throw new PaymentError(user ? 'RATE_LIMITED' : 'USER_NOT_FOUND');
  }

  // Can you spot the bug? What happens if fraud.score is exactly 0.7?
  // What if rateLimit is null?
  // AI generated this. Did you understand it before you shipped it?
};

2. 验证债 —— 虚假信心的陷阱

每次你点击批准一个你没有完全理解的差异，你就是在借用未来。

与技术债不同 —— 技术债通过日益增长的摩擦、缓慢的构建、纠缠的依赖宣布自己 —— 验证债滋生虚假信心。代码库看起来很干净。测试是绿色的。

六个月后，你发现你已经准确构建了规范所说的 —— 以及客户实际想要的东西。

# The verification debt accumulates here:
# ✅ All tests passing
# ✅ No linting errors  
# ✅ Code review approved
# ✅ Deployed to production

# But nobody asked:
# ❌ Does this actually solve the user's problem?
# ❌ What happens in edge cases the AI didn't consider?
# ❌ Does this match our architecture patterns?
# ❌ Will the next developer understand this?

3. 架构债 —— 当模式崩溃时

AI agent 生成可用代码很快，但它们倾向于重复模式而不是抽象它们。你最终在五个文件中得到相同逻辑的五个略有不同的实现。每一个都能用。它们都不共享公共工具。

AI 生成的代码倾向于走快乐路径。它处理训练数据覆盖很好的情况 —— 标准输入、预期状态、常见的错误代码。边界情况、竞态条件和基础设施特定的失败得到浅层处理或完全没有。

当一个 AI agent 需要功能时，它会寻找一个包。它不考虑现有的代码库是否已经处理了这个需求、依赖是否被维护，或者包的大小是否合理只是为了一个单一的功能。

结果是我所说的"一致的混乱" —— 代码在单独看很合理，但整体上不一致。

生产力悖论 —— 为什么更快实际上不是更快

这里有一个矛盾，没有领导层想听到：

AI 编码工具在 2026 年编写 41% 的所有新商业代码。速度从未如此之高。

然而，根据 Stack Overflow 的分析，经验丰富的开发者报告在使用 AI 工具时生产力下降 19%。大多数开发者报告花更多时间调试 AI 生成的代码和更多时间解决安全漏洞。

生成代码更快的工具怎么会让开发者更慢？

因为写代码从来都不是瓶颈。

理解代码是瓶颈。调试代码是瓶颈。修改你没有写的代码 —— 或你写但不理解的代码 —— 是瓶颈。

AI 让快的部分更快了。它让慢的部分更慢了。

衡量 AI 采用率和功能速度的团队优化的是错误的指标。他们忽视了技术债的积累。仓促进入 AI 辅助开发而没有治理的公司是那些在 2026-2027 年面临危机级别累积债务的公司。

当没有人理解代码时实际会发生什么

我想具体说明这在实践中是什么样的。

场景 1：三周的冻结

那是我们。六个月的 AI 辅助速度，随后是三周的完全停止，因为我们需要理解我们构建的是什么，然后才能安全地改变它。

考虑到冻结后的净速度：与传统开发相比，获益约为零。

场景 2：初级开发者陷阱

54% 的工程领导人计划因为 AI 而雇用更少的初级开发者。但是 AI 生成的技术债需要人类判断来修复 —— 正是初级开发者通过多年的出错和学习而发展的判断力。

通过消除初级职位，组织正在创造一个未来，他们将缺乏人力资源来修复今天生成的债务。

2027 年需要的工程师 —— 那些有 2-4 年调试经验的 —— 不会存在，因为他们没有被雇用。

场景 3：安全定时炸弹

一家安全公司发现，与人类编写的代码相比，AI 辅助开发导致的代码安全问题率高 2.74 倍。这种债不会宣布自己。它坐在生产环境中，等待。

实际上如何修复这个 —— 实际上

三周的痛苦调试和重构之后，这是我的团队改变的方式：

1. 引入"你能在凌晨两点调试吗？"规则

在任何 AI 生成的代码合并之前，作者必须能够回答：

"如果这在凌晨两点在生产环境中崩溃并呼叫你，你能在不再看一遍的情况下调试它吗？"

如果答案是否 —— 代码在作者理解它之前不能合并。

这一条规则在我们的第一周捕捉到的问题比我们之前所有的代码审查流程加起来都多。

2. 将"生成会话"与"理解会话"分开

Monday: Use AI to generate the feature (fast)
Tuesday: Read every line without AI assistance (slow)
Wednesday: Refactor what you don't understand (medium)
Thursday: Test edge cases AI didn't consider (medium)
Friday: Merge

短期更慢。在六个月的时间线上快得多。

3. 跟踪认知债 —— 而不仅仅是代码质量

将这些问题添加到你的冲刺回顾中：

我们团队的每个成员能解释我们这个冲刺中上线的核心系统吗？

有没有只有一个人理解的模块？

我们上线了什么我们下周不能有信心地修改的东西吗？

这些不是感伤的问题。它们是风险评估。

4. 像对待聪慧的初级开发者一样对待 AI

强大。快速。对不应该自信的事情很自信。在任何复杂的东西上都需要监督。

Junior developer rule:
✅ Use for boilerplate and scaffolding
✅ Use for well-understood patterns
✅ Use for test generation
⚠️ Review everything carefully
❌ Don't let them architect alone
❌ Don't merge code you can't explain
❌ Don't skip review because tests pass

对 AI 应用相同的规则。因为风险是相同的。

令人不适的真相

以下是 AI 编码工具营销不想你听到的：

2026 年赢得的团队不是生成最多代码的那些。他们是那些生成正确代码并维持纪律来审查、重构和围绕 AI 输出进行架构的那些。

清洁、模块化、文档良好的系统让 AI 成为增压器。纠缠、拼凑的系统会令 AI 的价值窒息 —— 并最终令试图运行它们的业务窒息。

AI 技术债的讽刺在于：你的代码库越好，你从 AI 中获得的价值就越大。你的代码库越差，AI 对它造成的伤害就越大。

AI 放大已经存在的东西。强大的基础被放大成更快的上线。薄弱的基础被放大成更快的债务积累。

与传统技术债不同 —— 它通过摩擦逐渐宣布自己 —— AI 技术债可以在绿色测试套件和高速度指标背后无形地积累，直到它不再累积的那一刻。

改变了我如何领导我的团队的问题

三周冻结后，我的 CTO 在我们的回顾中问了一个我一直在思考的问题：

"我们在什么时候停止构建软件而只是生成它的？"

有区别。构建意味着理解。生成意味着吞吐量。

未来属于开发者，他们两者都做 —— 他们使用 AI 的生成速度而不失去自己的理解。

这不是反对 AI 工具的警告。这是关于有意图地使用它们的论证。

快速生成。理解一切。

你的团队是否已经撞上了 AI 技术债墙 —— 或者你看到了警告信号？我真的很想知道其他团队是如何处理这个的。在评论中分享你的经验 —— 特别是如果你已经找到了真正有效的系统。👇

提示：AI 帮助我写了这篇文章。考虑到话题，这颇为恰当 —— 但三周冻结的故事、Rahul 的对话和教训都是我的。我相信对我的过程保持透明！😊

有些评论可能只对登录的访客可见。登录以查看所有评论。

对于进一步的操作，你可以考虑屏蔽此人和/或报告滥用行为。