软件团队对「技术债务」这个概念已经习以为常。多数人也理解设计债务——积累的不一致、过时的模式、走捷径的 UI，它们拖慢未来的工作。
但我没怎么听到有人讨论的是：AI 债务。而在 2026 年，它正在变成比前两者都更昂贵的一类债务。
以下是三者的比较，以及为何 AI 债务值得单独被命名。
三种债务
技术债务：代码里的捷径、过时的库、被绕过的抽象。偿付成本：范围清晰、可度量，通常几个工程冲刺内偿还。
设计债务：不一致的间距、过时的模式、47 种按钮变体、组件漂移。偿付成本：一次设计系统冲刺，几周的重构。可见、可处置。
AI 债务：生产环境中糟糕的 prompt、未经评估的模型输出被复合进新的系统、把工作流锁死在某个供应商上的选择、过早做出的训练数据决策。偿付成本：有时巨大，有时无法恢复。
为何 AI 债务更难偿付
设计债务是可见的。你打开一个 Figma 文件，能看到不一致。你能数它，能排优先级。
AI 债务藏在概率性系统里。一个在生产环境中「够用」的 prompt，可能在你从未度量过的边缘情况里悄悄产出糟糕输出。团队以为没事，因为抱怨还没抵达领导层。
等债务开始变得可见时，你通常已经在它之上又搭建了三套系统。此时的修复就不再是调一下 prompt——而是要重建若干下游工作流。
AI 债务最常见的形态
基于我在这件事上做了一年咨询的观察：
Prompt 意大利面：代码库里散落几十条 prompt，不同的人在不同时间编辑过，没有一份中央日志记录谁在何时为何改了什么。最终无法审计。
未经评估的输出：AI 产出一样东西，系统直接用，没有人检查它是不是正确的。直到客户投诉，你才发现错误率。
无出口的供应商锁定：产品完全按某一家供应商的特定脾气来构建。当对方改定价、下架模型、发生故障时，你没有任何备选。
训练数据决策：关于 AI 看什么数据（不看什么）的早期决策，在生产环境中形成难以回卷的行为。
质量漂移：AI 逐渐产出更低质量的输出（因为上游数据变了、或模型被升级了），而没有人有度量能捕捉这种漂移。
我们在自己的工作中如何管理它
我们交付的每一套 AI 系统，都会在上线前先把四件事配齐：
1. Prompt 版本管理。每一条 prompt 都活在一份类型化配置里，有版本历史，和其他代码一样可测试。
2. 输出评估。我们为输出必须满足的条件写自动化检查。不是「看起来对不对」——是具体的断言，每次部署都跑。
3. 供应商抽象。业务逻辑从不直接调用某家供应商的 API。中间永远有一层 shim。切换供应商是改配置，不是重写。
4. 质量监测。样本输出被记录、每周人工审阅一次。漂移在第一周被捕捉，而非第二季度。
这些听起来像是负担。确实是。但第一次出问题时——而 AI 系统迟早会出问题——这份负担会把自己还清。
2026 年我会采取的立场
像 2010 年好的团队对待数据库那样对待 AI：关键基础设施、值得拥有 schema、迁移、监测与明确的所有权。不要让「这不就一条 prompt 吗」把团队花了十年才学会在其他地方避免的那些草率习惯重新正常化。
启动便宜，修复昂贵。这就是 AI 债务。