AI 技术债务：Sprint 回顾中从未出现的四个类别

你的 Sprint 回顾涵盖了那些常见问题：不稳定的测试、某人一直推迟的数据库迁移、用胶带勉强粘合的 API 端点。但如果你正在交付 AI 功能，代码库中最昂贵的债务恰恰是那种没人会写在便利贴上的。

传统技术债务是线性积累的。你走了捷径，之后为此付出利息，等痛苦到了一定程度再重构。AI 技术债务是复合增长的。一个默默退化的提示词会产生污染评估的训练信号，这会误导你下一轮提示词修改，进而进一步侵蚀用户体验的质量。等有人注意到时，三层假设已经在底下腐烂了。

对 4,800 个工程团队的 810 万个 Pull Request 的研究分析发现，AI 采用后技术债务增加了 30% 到 41%，而开发者在端到端任务上实际上慢了 19%，尽管他们感觉更快了。这种债务是真实的、可衡量的，其中大部分属于传统工程实践无法捕获的四个类别。

提示词腐化：当昨天的指令破坏了明天的模型

提示词腐化是指随着底层模型的变化，提示词有效性缓慢衰退。你为 GPT-4 编写了一个精心调优的系统提示词。它运行得非常好。然后模型更新了，或者你迁移到了不同的提供商，同样的提示词现在产生了微妙不同的输出——不足以触发告警，但足以让用户感到困惑。

这是因为提示词是与特定模型行为的隐式契约。当你写"用恰好三个要点回答"时，你依赖的是该模型对"恰好"的理解。新版本的模型可能会以不同方式解释同样的指令——在要点前添加前言或将其重新格式化为编号列表。

复合问题在于：团队很少以与版本管理代码相同的严谨度来版本管理提示词。对 LLM 软件项目的研究发现，LLM 系统中技术债务的中位生命周期为 553 天，清除率仅为 49%。超过一半引入的债务永远不会被清理。提示词尤其脆弱，因为它们看起来像配置而非代码，因此逃过了捕获其他问题的审查流程。

提示词腐化的治理方法：

• 将提示词视为代码工件：对其进行版本管理、审查变更，并将其固定到特定模型版本。
• 构建自动化回归测试，在升级前针对新模型版本运行你的提示词套件。
• 维护提示词变更日志，不仅记录变更内容，还记录选择原始措辞的原因——推理比文本衰退得更快。
• 设置输出监控，检测模型响应中的分布偏移，而不仅仅是错误。

评估漂移：当你的测试不再反映现实

评估漂移发生在你的评估数据集和指标悄然偏离系统在生产中实际遇到的情况时。六个月前你从真实查询样本中构建了一个黄金测试集。那时它是有代表性的。此后，你的用户群增长了，使用模式发生了变化，产品增加了新功能——但评估集保持不变。

这比传统软件中的测试腐化更加隐蔽，因为评估仍然通过。一个在基准测试上得分 94% 的分类器，可能在用户今天实际发送的查询上只得 78%。你不会知道，直到有人手动审计一批生产输出并发现差距。

问题在于评估结果驱动决策。如果你的评估显示系统在改善，你就会自信地发布。如果评估测量的是错误的东西，你就是在自信地发布退化。通过对 1,200 个 LLM 部署的生产分析发现这一模式的团队认识到，成功的组织将评估视为基础设施，而非一次性设置任务。

评估已经漂移的信号：

• 你的评估分数在上升，但用户满意度持平或下降。
• 你的测试集超过 90 天没有刷新。
• 新的产品功能或用户细分没有在评估数据中体现。
• 你在衡量中间质量指标（BLEU 分数、余弦相似度），但没有衡量端到端任务完成率。

应对方法：

• 通过定期采样最近的生产流量、对其进行匿名化处理并纳入测试套件，实现持续的评估集刷新。
• 跟踪评估集与生产流量的分布，当它们显著偏离时发出告警。
• 使用 LLM 作为评判者的模式来扩展超出人工审查能力的评估范围，但至少每月将评判者与人工评分进行校准。
• 衡量结果，而非代理指标。如果你的 AI 功能帮助用户完成任务，就衡量任务完成率——而不是孤立地衡量嵌入相似度或响应流畅度。

嵌入锁定：你承担不起的迁移

嵌入锁定发生在你基于某个嵌入模型训练的向量索引变得成本高昂、难以迁移时。你选择了一个嵌入模型，为整个文档语料库生成了向量，构建了索引，调优了检索阈值，并围绕该模型的特性优化了分块策略。一切正常。然后一个明显更好的嵌入模型出现了，或者你的提供商改变了定价，或者你需要支持新语言。

迁移意味着重新嵌入你的整个语料库——可能需要数千美元的计算资源和数天的处理时间。但重新嵌入只是开始：

• 你的分块策略是针对旧模型的上下文窗口优化的。
• 你的相似度阈值是根据旧模型的距离分布校准的。
• 你的检索管道的精确率-召回率权衡是针对旧模型的行为调优的。

更换嵌入模型意味着重新校准所有下游环节。

这就是为什么在 2024 年初使用当时可用的嵌入模型构建 RAG 系统的团队现在陷入了困境。他们积累了数千份文档，在检索层之上构建了功能，并训练用户期望一定的质量水平。迁移的成本不仅是技术性的——还有每个依赖检索质量的功能出现退化的风险。

如何减少嵌入锁定：

• 将嵌入层抽象到一个干净的接口后面，使系统的其余部分不需要知道或关心哪个模型生成了向量。
• 将原始文档与其嵌入一起存储，这样你可以在不回到源系统的情况下重新嵌入。
• 在需要迁移之前先构建检索评估套件，这样你可以衡量新的嵌入模型是否真正改善了你的特定用例。
• 考虑将稠密嵌入与稀疏关键词搜索相结合的混合检索策略——关键词路径为你提供了与模型无关的后备方案。
• 为定期重新嵌入做预算。六个月后最好的嵌入模型将明显优于今天的。计划迁移，而不是假装它不会发生。

影子耦合：无人记录的依赖关系

影子耦合是最微妙也最危险的 AI 技术债务形式。它发生在功能隐式依赖于没有人明确记录或测试的特定模型行为时。你的产品之所以工作，不是因为你的代码正确，而是因为模型恰好以你的代码所依赖的方式运行。

例如，你的解析逻辑假设模型总是将 JSON 放在代码块中。你的 UI 截断逻辑假设响应保持在某个长度以下。你的下游管道假设模型从不在输出中使用某些字符。这些假设都不在你的提示词中。也不在你的测试中。它们是对模型行为的影子依赖，可能在任何模型更新时被打破。

影子耦合特别危险，因为它创建的故障模式看起来像应用程序 bug，而非模型问题。当模型开始偶尔返回没有代码块包装的 JSON 时，你的解析器抛出一个异常，被记录为代码缺陷。调查它的工程师看到解析错误，修复解析器，然后继续——从未意识到根本原因是对模型行为的未记录假设，明天可能以不同方式再次出问题。

对生产 LLM 系统的分析表明，引入文件的第一个技术债务几乎永远不会被移除——所有仓库类型的移除率都低于 5%。影子耦合尤其容易永久存在，因为它是不可见的：你无法清理你不知道存在的假设。

影子耦合如何积累：

• 开发者构建一个功能，手动测试它，看到它工作了，然后发布——从未意识到"它工作了"依赖于特定的模型行为。
• 另一个开发者在该功能之上构建，添加了第二层未记录的假设。
• 模型更新了。第一层的假设仍然成立，但第二层的打破了。由此产生的 bug 现在与其根本原因之间有两层间接关系。

如何应对：

• 明确记录你的代码对模型输出格式、长度、结构和内容所做的每一个假设。将这些假设作为断言或验证器放在代码中，而不仅仅是注释。
• 构建契约测试，独立于应用逻辑验证模型输出的一致性。如果模型不再将 JSON 放在代码块中，你应该从契约测试中得知——而非从生产异常中。
• 在调查 AI 功能的 bug 时，始终问："这是代码 bug 还是模型行为变化？"将这个问题纳入你的事件响应手册。
• 尽可能使用结构化输出模式（JSON 模式、函数调用）代替依赖你需要解析的自由格式文本。结构化输出将影子依赖转变为显式契约。

复合效应

AI 技术债务之所以特别危险，在于这四个类别如何相互作用。提示词腐化导致你的系统产生不同的输出，这使你的评估集不再具有代表性（评估漂移），这意味着你不会注意到检索质量何时退化（嵌入锁定），这导致微妙的行为变化，创造新的影子耦合。

一个在生产部署前以影子模式运行 Agent 的团队——将 Agent 预测与人工操作进行对比，只有在准确率达到特定阈值后才上线——发现这一单一实践捕获了跨越所有四个类别的问题。该模式之所以有效，是因为它创建了一个持续的、接近生产真实环境的评估循环，而不是依赖静态测试集。

善于管理 AI 技术债务的团队有三个共同实践：

• 他们单独跟踪涉及 AI 的组件。 AI 功能有自己的质量门禁、自己的监控面板和自己的审查清单。排名前 20% 的团队执行专门的质量门禁，在合并前捕获 AI 的可预见故障模式。
• 他们衡量结果，而非输出。 不是"我们生成了多少 token"，而是"用户是否完成了他们的目标"。编辑接受率、功能绕过率和修改覆盖时间等指标告诉你，你的 AI 功能是在提供真正的价值，还是在积累不可见的债务。
• 他们将维护预算作为一等成本。 背负 AI 技术债务的组织在维护上多花 40%，功能交付速度慢 50%。避免这种情况的团队定期分配时间用于提示词审计、评估刷新和依赖文档编写——不是作为技术债务冲刺，而是作为持续的运营成本。

将 AI 债务视为一门工程学科

一个令人不安的事实是，75% 的技术决策者预测，AI 驱动的复杂性将在今年年底前将其技术债务推至中等或严重水平。避免这一结果的组织是那些不再将 AI 功能视为"部署即忘记"，而是开始将其视为需要持续质量投入的活系统的组织。

2025 年是 AI 速度之年。2026 年正在成为 AI 质量之年。快速构建的团队现在将发现他们的根基是什么。那些投资于提示词版本管理、持续评估、嵌入迁移路径和显式依赖文档的团队将继续交付。其余的将在接下来的一年中进行昂贵的重写，困惑于为什么六个月前"运行良好"的 AI 功能现在产生令人尴尬的输出。

债务已经存在。唯一的问题是你是在逐步偿还，还是等着账单一次性到来。