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

一个功能发布时通过率为 92%。发布演示稿（Launch deck）为此庆祝。12 个月后，同样的功能通过率降到了 78% —— 没有事件报告，没有部署失败，没有任何单一的变更可以追责，仅仅是无人负责监控的缓慢侵蚀。团队将其归咎于“幻觉”或“用户行为转变”，选了一名初级工程师去调查，并设定了一个“提高质量”的季度 OKR。OKR 没能达成。该功能上线了一个道歉对话框，告诉用户 AI 有时会犯错。六个月后，它被弃用，取而代之的是一个发布时通过率为 91% 的新版本，循环再次开始。

这并非运气不好。这是 AI 功能运行的“第二时钟”，一个在发布时没有人会在日程表上标注的时钟。传统软件也有功能衰减 —— 依赖漂移、代码库腐化、缓慢积累的半成品重构 —— 但这些衰减是发生在工程团队已经理解并预留预算的时钟上。AI 功能具备上述所有问题，此外还有一系列传统摊销假设无法建模的并行衰减源：模型弃用、厂商权重轮换、用户输入的分布偏移、不断叠加的 Prompt 补丁、评估器（Judge）校准偏移，以及不再能代表生产流量现状的评估集的悄然老化。

在下一个 AI 功能发布之前，而不是之后，必须落地的架构认知是：AI 功能具有非零的基础维护成本。功能在发布时并没有“完成”。它已经进入了一个无法逃避的维护周期，而那些没有为这个周期预留预算的团队，终将通过惨痛的方式发现这一点。

工程主管们对“代码腐烂”这一概念已经习以为常。依赖项需要更新，基础设施有生命周期管理，证书会在无人质疑的日期过期。然而，提示词仓库（prompt repository）却往往被视为一种“一次编写，多次读取”的产物——尽管它定义了你的产品如何与一个每六周就发布一次行为变更的概率引擎进行对话。

六个月前针对当时主流模型调优的系统提示词，现在依然在生产环境中使用。针对早已变更的分词器（tokenizer）挑选的 Few-shot 示例，仍在每次调用时被注入。重排序提示词是针对供应商上季度已废弃的嵌入端点调优的。没有人安排审查。也没有人打算去安排。

这并非假设性的失效模式。当一个团队将其精心针对 GPT-4-32k 稳定化的提示词套件迁移到 GPT-4.1 和 GPT-4.5-preview 时，其回归测试的通过率分别仅为 95.1% 和 97.3%。在生产环境中，3-5% 的隐性质量退化绝非可以忽略的误差；在任何具有一定规模的场景下，这都是一种用户可见的退化，而团队中没人是有意发布这种退化的。而且，这些还是拥有回归测试套件的团队。中等水平团队的“回归测试”，不过是值班工程师在处理上一次事故时凭感觉形成的印象。

我们缺失的范畴是提示词资产折旧（prompt asset depreciation）：这是一种维护纪律，它将每个生产环境中的提示词视为具有已知寿命的折旧资产，而非一成不变的常数。

当智能体（agent）在同一个 diff 中编写函数和注释时，该注释并不是文档。它是代码在编写时的转述，由同一个模型从同一个上下文中生成。当代码第一次发生变动时，它就会悄然出错。函数被重构，参数类型改变，或者添加了提前返回（early-return），但注释却保持不变。到下个季度，注释所编码的规范已不再与代码匹配，而下一位读者会因为注释更易读而选择相信它。

这是一个古老的失效模式 —— 人类修改代码，注释保持陈旧 —— 但智能体从三个维度同时加速了这一进程。注释量增加了，因为智能体无论是否需要，都会给每个函数添加文档块（doc block）。注释的语法非常完美，所以审阅者不会将其标记为低质量。而且，注释用与代码实际执行不同的术语来转述代码，因此它们看起来像文档，但实际上编码了第二套规范，这套规范独立于第一套规范而漂移。

每个在没有评估（evals）的情况下发布 AI 功能的团队都会对自己讲同样的故事：我们会以后再添加衡量标准，等到找到产品与市场契合点（PMF）之后，等到提示词（prompt）稳定之后，等到下一次发布之后。六个月后，提示词已经被四位工程师和两名产品经理修改过，其行为支撑着三个客户集成，团队发现“以后添加评估”意味着要从从未为此目的结构化过的生产日志中重建意图。本应开发新功能的季度变成了考古季度。

这不是规划错误。而是一个复利错误。为了更快发布而跳过评估的团队，正是那个将花费十二周时间从不完整的追踪（traces）中重建评估基础设施、为二月份所谓的“正确”含义争论不休、并悄悄移除没人能证明依然有效的功能的团队。追赶的成本超过了内置的成本——不是一点点，而是随着每一次未经回归检查就发布的提示词修改而倍增。

这个说法非常诱人：用英语描述行为，模型生成代码，然后交付。提示词（Prompts）变成了源码，产物变成了目标，而 LLM 就像是一个前端界面更友好的 gcc 坐镇其中。如果这个框架成立，那么软件工程的其余部分——评审、重构、架构——都将成为提示词质量的下游产物。但事实并非如此。那些基于这种假设构建的代码库，正以一种现在看来极其乏味的模式走向失败：在大约第六个月，没人能解释为什么某个特定函数长成那样，而且每一次增量变更都会引发一波重复代码。

编译器隐喻才是根本原因，而不是“氛围感编程”（vibe coding）、模型质量或提示词技巧。这是一个范畴错误，它悄无声息地让团队逃避了那些能保持代码库长年连贯性的工作。当你认为模型是编译器时，生成的代码就变成了实现细节，就像汇编语言是 C 程序的实现细节一样。而当你实际在带领一个由非确定性、上下文受限的协作成员组成的团队时，生成的代码才是资产——而提示词比起源码，更像是 Slack 消息。

2026 年 3 月，一家大型电商平台在一天之内损失了 630 万个订单——美国订单量的 99% 化为乌有。原因不是某次鲁莽的部署，也不是数据库故障。一个 AI 编程工具基于过时的内部文档自主生成并部署了代码，导致每个市场的配送时间估算全部出错。该公司要求 80% 的工程师每周使用该工具，采用率指标一片绿灯，工程纪律却不然。

这才是规模化 Vibe 编程的真实面貌——不是四天就能上线的快速演示，而是第 365 天消失的 630 万个订单。

在一项受控随机对照试验中，使用 AI 编程助手的开发者预测他们的速度会提高 24%。而实际上，他们慢了 19%**。关键在于：他们仍然认为自己变快了。这种认知鸿沟——即生产力的“感觉”与实际交付能力背道而驰——是一种失效模式的早期预警信号，这种模式通常在数月而非数小时内显现。

行业已实现近乎普及的 AI 采用。93% 的开发者使用 AI 编程工具。生产力增长却停滞在 10% 左右。这些数字之间的差距并非工具问题，而是一个不断累积的债务问题，大多数团队在扭转成本变得极其昂贵之前，往往察觉不到它的存在。

传统的技术债务往往会自我显现。构建缓慢、测试失败、或是被抑制了六个月的 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 美元的运营损失。而那次修改的作者早已离开了。