评估债务棘轮：靠感觉发布 AI 功能的团队如何被技术欠账所困

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

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

评估债务不只是技术债

技术债的说法很宽泛——你快速写出的代码，打算之后再清理。评估债务在性质上有所不同，不只是程度上的差异。在传统软件工程中，你通常可以直接观察正确性：函数要么返回正确值，要么不返回；API 要么响应正确的状态码，要么不响应。这些是确定性的、可验证的事实。

AI 功能产生概率性输出。摘要的好坏不是非此即彼的——它在忠实度、完整性和有用性上各有高低。定义"正确"需要人类判断、领域知识或精心构建的评分标准。这种困难是真实存在的，也正是团队拖延的原因。当你无法写出简单的断言语句时，评估就会感觉像是一个研究问题，而非工程任务。

但陷阱在于：推迟评估并不能消除行为问题，只是意味着你无法对其进行测量、检测或推理。针对 ML 软件项目的实证研究发现，它们积累自我承认技术债的速度大约是非 ML 项目的两倍——而这一差距恰好集中在团队在时间压力下最容易忽视的验证和测试领域。

当你在没有评估的情况下发布 AI 功能时，你不只是在跳过测试。你正在签署一份自己看不到的隐性合同：功能以某种分布方式运行，而你同意通过用户投诉来发现这个分布是什么样的。

为什么团队持续跳过评估

四股力量推动团队走向"凭感觉发布"，理解它们很重要，因为每种情况的解决方案各不相同。

指标模糊性。 对于分类模型，准确率是显而易见的。但对于客服机器人，质量是什么样的？如果用户没有追问，是说明简短的回复更好，还是他们只是放弃了？高任务完成率是良好体验的标志，还是说明你没有发现需要升级处理的用户？无法就衡量什么达成共识的团队，往往会决定什么都不衡量，因为局部测量可能比不测量更具误导性。

演示充分性偏见。 在你测试的 10 个示例上能运行的功能，感觉就像是能正常运行的功能。这对生成式 AI 来说尤为严重，因为即使输出有误，看起来也很精美。一个幻觉引用、一个缺失从句、一个自信却错误的实体——如果审查者没有核对原始材料，这些都不像是出了问题。功能在向利益相关者展示的所有演示中似乎都运行良好。它不起作用的情况在用户发现之前是不可见的。

评估基础设施成本。 编写有用的评估不仅仅是收集测试用例。它需要决定测量什么、标注基准真值（这通常需要领域专家）、构建可重复运行测试的框架，以及将该框架集成到部署流水线中。对于一个试图在两周内发布的三人团队来说，这是一个需要数周的项目。成本是真实的，当你的功能进度已经落后时，预先支付这笔费用显得不合理。

速度文化。 AI 产品格局奖励快速迭代。快速行动的团队能进入市场、获得反馈、持续改进。隐含的假设是，生产环境中的用户反馈是一种评估形式——市场就是评判者。这对某些类型的信息是正确的。但对于用户无法清楚表达的质量退化（"感觉就是变差了"）、用户没有发现的细微事实错误，或者影响用户很少触发但一旦触发就高度依赖的边缘案例的回归，这种方式是行不通的。

棘轮是如何转动的

评估债务危险的特性不在于任何单次糟糕的部署，而在于随时间推移的复利效应。

当你在没有评估的情况下发布第一个功能时，代价是抽象的。还没有出什么问题。功能在主要路径上能正常运行。工程师转向下一个任务。

当你发布第二个功能时，你现在有两个行为未被测量的系统。它们之间的任何交互都是未知领域。但仍然没有明显的问题。

这种模式持续下去。功能层层叠加。提示词不断更新。模型被升级。工具 Schema 发生变化。每次修改都触及未被测量的系统。任何变更的影响范围都是未知的，因此工程师开始保守地行动——做更小的改动，更多地手动测试，在本该快速完成的事情上花更长时间。

然后棘轮咔嗒一声卡住了。

这声"咔嗒"通常是用户注意到的一次回归。不是灾难性的故障——那种很容易被发现。而是一种悄然积累的细微退化：成功率下降 15%、响应相关性下降、智能体任务在更多重试后才完成。用户开始说系统"感觉变差了"。团队开始调查，却发现没有基线。他们不知道问题从何时开始，是哪次变更造成的，甚至不知道"好"是什么样的。他们唯一拥有的就是当前的行为和愤怒的用户。

没有评估的调试在设计上是被动反应式的：等待投诉、手动复现、形成假设、做出变更、等待投诉减少。每次回归调查可能需要数周时间。而每一个调查周期都消耗了本可用于功能开发的产能。

提前构建了评估基础设施的团队也会遇到同样的回归。但对他们来说，问题在部署前的 CI 中就会出现。告警是具体的：测试用例 #47（六个月前在 QA 中遭遇的多部分实体提取场景）发生了回归。他们知道该从哪里着手。修复在数小时内上线，而不是数周。

信任崩塌

评估债务会悄悄积累很长时间，然后突然崩塌。这种崩塌既是技术问题，也是信任问题。

体验过 AI 行为不一致的用户会形成一种可以称之为"防御性使用模式"的习惯。他们不再将该功能用于重要工作。他们增加手动验证步骤，从而消除了生产力收益。他们在反馈调查中将该功能标记为不可靠，这会影响团队的路线图和高管的信心。即使底层技术质量从未下降，所有这些也会发生——对不可靠性的感知是根深蒂固的，很难逆转。

在工程侧，信任以另一种方式崩塌。当工程师无法测量其变更的影响时，他们就无法为自己的信心辩护。审查变得更漫长、更有争议，因为没有人有数据支撑。部署节奏放缓，因为隐性的审批门槛提高了——"在发布之前，我需要非常确定"取代了"CI 是绿色的，上线吧"。高级工程师开始手动审查更多变更。那个靠感觉快速行动的团队，现在因为恐惧而变得缓慢。

重建信任需要评估覆盖，而在已建立的系统上补充评估覆盖比一开始就建立评估要困难得多。你必须逆向推导系统应该做什么，构建可能根本不存在的基准真值，为从未设计过检测的流水线添加检测，同时还要继续发布功能。推迟时间够长的团队往往会发现，评估补建项目比当初的功能开发工期还要长。

在不停止功能开发的前提下偿还评估债务

应对评估债务的正确方式，不是在发布任何其他功能之前暂停下来构建一个全面的评估系统。那只是用一种功能失调换另一种。目标是以增量方式引入测量，从风险最高的领域开始。

从 20 个测试用例开始，而不是 200 个。 团队通常会高估需要多少示例才能获得信号。一组精心挑选的 20 个用例——来自生产环境的真实故障、已知的边缘案例、QA 中出现的场景——就能为你提供回归检测和部署门控。你可以随着遇到新的故障模式持续扩展覆盖范围。阻碍性错误是在运行任何内容之前等待完美覆盖。

将生产故障直接转化为测试用例。 每一个经过调查的用户投诉都应该以评估数据集中的新条目作为结尾。这是获得覆盖最廉价的路径——用例已经被发现，已经被理解，已经足够痛苦以至于团队不会忘记。六个月后，坚持这样做的团队就拥有了一个反映其系统实际故障面的测试套件。

使用分层评估策略。 不同的测量方法有不同的成本/可靠性权衡。Schema 验证和格式检查快速且廉价，但覆盖范围狭窄。LLM 作为评判者（LLM-as-judge）的评估方式灵活但昂贵，并引入了自身的测量不确定性。人工审查准确但无法扩展。正确的设置同时使用这三种方式：用快速自动化检查发现明显故障，用基于模型的评分大规模衡量质量指标，用抽样人工审查来校准模型评分。这几层中的任何一层单独都不够；结合使用，它们覆盖了质量空间的不同部分。

将 AI 部署与应用部署解耦。 将提示词变更视为应用代码变更的团队，会对两者都比必要时更谨慎地发布，同时又比应该的更不安全。当提示词更新经历与 Schema 迁移相同的审查流程时，会减慢 AI 迭代速度。但当它完全绕过审查时，就没有门控。解决方案是单独的 AI 部署流水线——版本化的提示词和配置，在晋升前经过评估门控，独立于主应用发布序列。这是基础设施工作，但它是使其他一切变得更容易的结构性变化。

选择一个测量北极星并让它可见。 跟踪三十几个指标的团队，实际上一个都没有有效跟踪。选择一个反映功能核心用户价值的指标——任务成功率、答案相关性评分、用户接受率——并让它在每次部署时可见。最初不要作为阻断性门控，而是作为工程师实际会看的信号。观察一个数字的行为本身就会创造出任何政策文件都无法企及的责任感。

根本转变

避免棘轮效应的团队，并非不快速行动的团队。他们是改变了"完成"定义的团队。

一个功能不是在它于测试环境中的主路径上能运行时就算完成了。它完成的标志是至少拥有一个能捕获回归的评估。这门槛并不高。它意味着团队已经思考过功能应该做什么，写下了至少一个具体示例，并创建了一种机制来检测该示例何时会出问题。这需要的纪律与其说关乎工具，不如说关乎意图。

故障模式通常不是团队在哲学上反对评估，而是评估从未被优先考虑，因为总有一个功能看起来更重要。棘轮不在乎意图——只要每次部署都是在前一个未被测量的变更之上再叠加一个，它就会持续转动。

答案是将"没有评估覆盖"视为一种有持续成本的技术风险——不是未来要解决的问题，而是让当前工作更难、更慢的现实代价。内化这一点的团队，不会将评估基础设施视为功能工作之上的额外负担，而是视为使功能工作能够以速度持续推进的根基。