19 篇博文 含有标签「technical-debt」

传统的技术债务往往会自我显现。构建缓慢、测试失败、或是被抑制了六个月的 lint 警告——这些都是你可以通过 grep 搜索、转化为工单并排入冲刺（sprint）的症状。AI 特有的债务则不同。它在部署的间隙中悄然累积，在任何人意识到数据波动之前，它就已经降低了系统的性能。

大多数生产环境中的 AI 系统现在都有三个正在滴答作响的“债务时钟”。第一个是当特定模型版本流行时才有意义的提示词（prompt）。第二个是在构建时能代表用户行为，但现在已经过时的评估集（evaluation set）。第三个是仍在支撑检索层的嵌入（embeddings）索引，它们是由早已被弃用的模型生成的。每个时钟独立运行。三者共同叠加。

进入生产环境六个月后，你面向客户的 LLM 功能的系统 Prompt 已从最初清爽的 11 行增长到超过 400 个 token，充斥着各种条件指令、对冲表述和异常处理。质量明显比发布时更差，但当时的每一次单独修改似乎都是合理的。没人知道哪些条款相互冲突，也没人知道其中一半是否仍然必要。没人敢动它。

这就是 Prompt 债务螺旋——大多数处于生产阶段的团队已经深陷其中。

这种规律在 2023 年和 2024 年采用编程智能体的团队中几乎普遍存在。第一个月，效率翻倍。第三个月，管理层把生产力指标拿出来，作为 AI 投资回报的证据。到了第十二个月，工程团队有一半的代码库已无法向新员工解释清楚，重构成本高得令人望而却步，工程师花在调试 AI 生成代码上的时间，比他们手写这些代码所需的时间还要多。

这不是一个关于 AI 代码暗中存在缺陷的故事。这是一个关于 AI 生成代码的质量特征如何系统性地瓦解团队已有的组织实践的故事——以及这些实践在技术债务复利失控之前需要如何改变。

你的 AI 功能准时上线了。用户正在使用它。一切看起来都很正常 —— 直到一季度后，一张支持工单揭露了系统已经“一本正经地胡说八道”了好几周，你的评估套件（evaluation suite）什么也没抓到，而向量索引正悄无声息地返回过期结果。没有任何环节崩溃。系统全程返回 200 OK。

这就是 AI 技术债务的样子。它不像失败的单元测试或堆栈溢出，而是以一种温和且概率性的方式退化。你不会遇到崩溃 —— 你面对的是微妙的质量侵蚀。主要由三种不同的负债驱动：提示词债务（prompt debt）、评估债务（eval debt）和嵌入债务（embedding debt）。每一项都独立积累，每一项又都在加剧其他的债务。而大多数工程团队正同时背负着这三者。

在你最优秀的提示词工程师转岗到新项目六个月后，一个面向客户的 AI 功能开始出现异常。响应质量下降了，输出格式偶尔损坏，还有一个说不清道不明但持续存在的语气问题。你打开提示词文件，里面是 800 字的自然语言。没有变更日志，没有注释，没有测试用例。写下它的人确切地知道每一段话存在的意义。但那份知识已经消失了。

这就是提示词考古问题，它已经让团队付出了真金白银的代价。一家全美抵押贷款机构最近发现，文档分类的准确率下降了 18%，原因可以追溯到三周前有人在所谓的“常规工作流优化”中向提示词添加的一句话。两周的调查，大约 340,000 美元的运营损失。而那次修改的作者早已离开了。

Andrej Karpathy 在 2025 年初创造了"氛围编程"（vibe coding）一词，描述一种编程风格："完全沉浸在氛围中，拥抱指数级增长，忘记代码的存在。"你用自然语言描述需求，AI 生成代码，然后直接发布。这感觉像是一种超能力。然而不到一年，数据开始讲述一个不同的故事。

METR 的一项随机对照试验发现，有经验的开源开发者在使用 AI 编码工具时效率降低了 19%——尽管他们预测自己会快 24%，事后仍然认为自己快了 20%。CodeRabbit 对 470 个 GitHub Pull Request 的分析发现，AI 协作编写的代码包含的重大问题是人工编写代码的 1.7 倍。Anthropic 对 52 名工程师的研究显示，AI 辅助的开发者在自己代码库的理解测试中得分低了 17%。

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

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