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

每个成熟的 AI 产品最终都会演变成一个当前团队中没人能完全理解的系统提示词（system prompt）。起初它只是 40 个 token 的纯英文，20 个月后，它变成了一堵 4,000 token 的“高墙”，堆满了条件句、拒绝模板、格式规则、角色强化、边缘情况警告，以及一句没人能解释的关于周二的奇特句子。每一行都是为了应对特定的失败：客户投诉、法务发来的 Slack 消息、评估（eval）中发现的回归，或者在投资者演示期间出现的偶发 bug。写下第 37 行的工程师已经转岗到其他团队。写下第 112 行的工程师是一名外包人员，他的 Notion 文档已被归档。评估套件覆盖了提示词所主张行为的大约三分之一，但没人确定是哪三分之一。

于是，这个提示词以一种最糟糕的方式成为了系统的“承重墙”：它能用，团队也知道它能用，但团队已经不再碰它了。本该对提示词进行迭代的工程师，反而绕过它来处理变更——这里加一个后处理过滤器，那里加一个 few-shot 封装，或者做一个并行的“v2 提示词”并用特性标志（feature flag）关闭，以防有人哪天有勇气进行 A/B 测试来替换它。提示词不再是软件，而成了遗迹。一旦发生这种情况，提示词就不再是你用来改进产品的杠杆，而是塑造产品的约束条件。

一个中型公司的团队在发布文档摘要功能三个月后，对提示词进行了优化。新提示词在他们手动测试的 5 个示例上表现更好。他们在周五下午部署了它。周一上午，Slack 里堆满了用户反馈：摘要现在会截断一半文档，却将截断后的内容呈现为完整版本。功能看起来没问题，变更通过了代码审查，没有人发现，因为根本没有评估机制——没有黄金测试集，没有回归基线，没有自动检查。棘轮已经悄悄转动了数月。

这就是评估债务最典型的表现形式。团队跳过评估并非因为粗心大意，而是因为为 AI 功能编写评估比听起来难得多，功能发布快且看起来运行良好，没有人想拖慢一个高速运转的团队。现在，他们正在偿还复利。

在 2022 年，一支团队花了三个月时间微调一个基于 BERT 的分类器，用于对客户支持工单进行分类。这是一次实实在在的胜利——准确率达到了 94%，而他们旧的基于规则的系统最高只有 70%。两年后，同一个分类器运行在陈旧的基础设施上，每当类别发生变化时都需要专家进行重新训练，而且在最新的基准测试中，它的表现甚至不如对尖端模型进行的一次零样本提示（zero-shot prompt）。没人敢碰它。开发它的工程师已经离职了。现在的团队担心弃用它会破坏某些功能。该功能就此被冻结了。

这就是“冻结功能陷阱”（frozen feature trap）。它是 AI 技术债中一种较为隐蔽的形式，且正在整个行业中蔓延。各支团队逐渐发现，曾经看起来像是护城河的东西，实际上是一个他们一直在往里砸钱的无底洞。

你的 AI 功能顺利发布了。文档看起来很棒：输入 schema、预期输出，以及一个经过验证的示例。三个月后，模型静默更新。输出发生了偏移。你的文档错了，但还没人发现——因为它们看起来仍然是“正确”的。

这是 AI 文档债（AI documentation debt）的核心，而且它比任何其他类型的技术债积累得都要快，因为在用户发现之前，这种失败是隐形的。

你的代码库中有三种不同方式实现的身份验证逻辑，而且团队中没人在写过其中任何一种。通过 git blame 快速查看，发现这三个文件都出自同一位工程师之手，但去问那位工程师，他们会告诉你他们只是接受了 AI 的建议，而且看起来“没问题”。这种反模式的蔓延并不是因为有人偷懒，而是因为一个对你现有认证模块毫无记忆的 AI 模型，在每次有人打开新文件寻求帮助时，都生成了看起来合理的实现。

这就是“复制粘贴传染病” (copy-paste contagion)，它在结构上与你已知如何应对的经典复制粘贴问题完全不同。

一个功能发布时通过率为 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% 左右。这些数字之间的差距并非工具问题，而是一个不断累积的债务问题，大多数团队在扭转成本变得极其昂贵之前，往往察觉不到它的存在。