AI 驱动功能的“完工”定义：工程化永恒的 Beta 测试

在传统软件中，发布功能以合并代码（merge）告终。单元测试通过。集成测试通过。QA 签字认可。你切换标志（flag），除非在生产环境中出现 bug，否则你就可以继续接下来的工作。这个功能就“完成”了。对于 AI 驱动的功能，那个时刻并不存在 —— 如果你假装它存在，你就是在累积稳定性债务，这最终会演变成用户信任问题。

原因很简单，但很少有人围绕它进行设计：确定性软件对于相同的输入每次都会产生相同的输出。AI 功能则不然。这并非因为 bug，而是因为其行为由一个存在于代码库之外的模型定义，该模型基于反映不断变化的世界的数据进行训练，并由那些随着看到更多可能性而不断提高期望的用户使用。

这并不是恐慌或避免发布 AI 功能的理由。这是一个重新思考“完成”意味着什么的契机 —— 并建立组织和技术基础设施，使“稳定但不断进化”感觉像是高质量，而不是不完整。

导致 AI 功能漂移（Drift）的三大力量

AI 功能的行为会沿着三个独立的轴线退化，分别理解每一个轴线至关重要，因为它们需要不同的缓解策略。

模型漂移 (Model drift) 发生在底层模型发生变化时。你的供应商 —— 无论是 OpenAI、Anthropic、Google 还是其他人 —— 都会定期更新他们的模型。有时这些更新伴随着详细的发布说明。但通常行为变化是细微的：不同的响应长度、略微不同的格式、语气的转变、拒绝请求的不同阈值。如果你没有固定（pin）模型版本，你的功能行为会在供应商发布更新的那一刻发生变化。如果你固定了版本，你会面临另一个问题：最终该版本会被废弃，你必须进行迁移，并在最糟糕的时机发现行为差异。

世界漂移 (World drift) 发生在模型训练的世界与用户生活的世界发生偏离时。2021 年训练的信用风险模型在当时可能有 95% 的准确率，但到 2024 年底可能只有 87% —— 并不是因为模型变了，而是因为经济背景、消费者行为和底层风险模式都发生了转变。对于依赖知识的 AI 功能（任何依赖于时事、公司信息、产品细节、法规事实的功能），如果没有监控，这种漂移是持续且隐形的。

期望漂移 (Expectation drift) 发生在用户对 AI 能力的心理预期进化速度超过你的功能进化速度时。当用户第一次看到一个像样的 AI 写作助手时，只要逻辑连贯，他们就会感到欣喜。六个月后，在使用了竞争对手和更新的工具后，当初让他们印象深刻的质量现在会让他们感到沮丧。这并非不理智 —— 这是用户在任何快速进步的产品类别中形成期望的方式。但这意味着一个发布时处于市场前 80% 水平的功能，可能会在没有改动一行代码的情况下悄然滑落到前 50%。

Evals 是规范，而非测试

构建保持“完成”状态的 AI 功能，最根本的转变是将评估（evals）视为规范（specifications），而非测试。在确定性软件中，测试验证代码是否符合规范。在 AI 系统中，evals 就是 规范。

这种重新构思之所以重要，是因为它改变了你编写它们的时间以及你用它们做什么。测试是在代码存在后编写的，用于验证行为。Evals 需要在功能发布之前就存在，因为它们是用机器可验证的术语陈述功能预期行为的唯一方式。

一个强大的 AI 功能评估套件包括：

• 黄金输入和预期输出 (Golden inputs and expected outputs)：一个精心挑选的数据集，包含 200–500 个具有标准答案（ground-truth）或标注质量评级的代表性提示（prompts）。生产级系统最终会跟踪数千个此类案例，并从每次生产故障中添加新案例。
• 行为不变性 (Behavioral invariants)：无论模型版本如何都必须保持的属性 —— 例如，“响应不得包含其他用户的 PII（个人身份信息）”、“摘要不得超过 200 个 token”、“结构化输出必须解析为有效的 JSON”。
• 回归基准 (Regression baselines)：每个模型版本节点的输出质量快照，这样当你升级时，你可以衡量行为差异，而不是通过用户投诉来发现它。

当模型供应商通知你即将进行版本更改时，这个评估套件就成了你的迁移清单。你针对新模型运行它，对比结果，并决定这些变化是改进、中性还是需要在切换版本前调整提示词的退化。

如果没有这种基础设施，模型升级就成了你在支持队列中才会发现的突发事件。

诚实地宣布 1.0 版本

压力之下，每个产品团队的本能都是宣布“正式发布 (General Availability)”并继续下一步。对于 AI 功能来说，这种本能既有正确的一面，也有危险的一面。

你应该宣布 1.0。另一种选择 —— 无限期的“beta”标签 —— 会让用户习惯于不稳定性，并为不优先考虑质量创造一个方便的借口。用户对 beta 版软件和生产级软件的投入程度是不同的，如果你希望他们将你的 AI 功能集成到核心工作流程中，你需要向他们发出信号，表明它已经准备就绪。

但“准备就绪”的含义需要诚实地沟通。GitHub 在这方面的模式很有启发性。当 Copilot Workspace 从技术预览版转向正式发布时，公告明确表示该功能将继续发展 —— 新的模型集成、扩展的功能、改变的行为。GA 宣言意味着“生产级稳定的基础设施，承诺不破坏核心体验，重大行为变更会提前通知”。它并不意味着“冻结”。

这是值得内化的关键区别：稳定性是关于接口的承诺，而非行为的承诺。当你宣布 AI 功能进入 1.0 时，你所保证的是：

• API 合约不会在没有版本化迁移路径的情况下发生变化。
• 你会在模型版本变更影响生产环境之前进行沟通。
• 你会维护评估套件并监控质量退化。
• 你会提供报告行为问题的机制以及响应的时间表。

你不保证的是：明天的输出会与今天的完全相同。

对行为预期进行版本化，而不仅仅是 API

大多数团队都会对 API 端点进行版本化。很少有人对行为预期进行版本化。这种差距正是 AI 功能信任度悄然流失的地方。

行为版本化意味着将你的 eval 黄金集视为一个版本化产物，并像对待 API Schema 一样严谨对待它。当你更改系统提示词时——即使是微小的调整——你都创建了一个新的行为版本。你需要对其运行完整的评估套件，记录结果，并将差异（diff）与提示词更改一起提交。这创建了一个可审计的功能行为演变历史。当用户询问为什么输出结果与六个月前不同时，这变得至关重要。

这里的工具链仍处于成熟阶段，但模式是稳定的：版本控制中的评估快照、配置中的模型版本锁定、行为契约的语义化版本控制。当你准备升级模型版本时，你会在历史评估快照上运行新模型，并在任何用户看到它之前刻画出增量（delta）特征。

一些团队还在尝试所谓的“行为 SLO”——关于输出属性的明确、机器可验证的陈述，这些陈述不仅在 CI 中监控，也在生产环境中监控。“p95 响应延迟低于 2 秒”是一个熟悉的运营 SLO。“99.9% 的请求中，结构化输出符合 Schema 验证”是一个行为 SLO。“在留出评估集上的摘要质量评分高于 0.75”也是一个行为 SLO。像对待基础设施 SLO 一样对待这些指标，会迫使你思考一个问题：你到底承诺了什么，以及你是否正在衡量它？

没人回答的治理问题

这是一个大多数工程团队都在回避的对话：谁来决定一个 AI 功能是否已经退化到需要回滚的地步？

在传统软件中，回滚决策通常很明确——一个 Bug 导致了错误行为，回滚就能修复它。在 AI 系统中，“行为变化”与“回归”之间的界限是模糊的。模型现在变得更冗长了，这是回归吗？模型拒绝了更多请求，这是安全性提升还是质量下降？响应格式发生了细微偏移。用户目前还没有投诉，但如果他们注意到了会怎样？

如果没有明确的治理，这些问题将由问题浮现时碰巧正在查看仪表板的人来解决。那不是流程——那是运气。

AI 功能的最小化治理模型包括：

• 行为契约的指定负责人——能够批准提示词更改、模型版本升级和评估阈值调整的人。
• 针对系统提示词和模型配置的变更评审流程——独立于代码评审，强制要求明确承认行为可能会发生变化。
• 行为事故流程——当评估分数跌破阈值时会发生什么，谁会被传唤（page），有哪些回滚选项，以及面向注意到了回归的用户的沟通模板是什么样的。
• 定期评审机制——至少每季度一次，明确询问：我们的功能行为是否仍然符合我们在产品描述中所承诺的？

这听起来很官僚，直到你的 AI 功能在提供商更新后第一次开始表现诡异，而你却没有任何成文的流程来决定该怎么办。

在不侵蚀信任的情况下沟通“功能正在演进”

诚实面对 AI 功能演化的风险在于，用户会听到“不稳定”并减少投入。而不诚实的风险在于，行为变化感觉像是回归，用户同样会减少投入——但还带着怨恨。

行之有效的框架是你在那些运营得最好的 AI 产品中已经见过的：将演进视为改进，而非不稳定。

OpenAI 的模型更新发布说明明确指出了行为变化。Anthropic 的发布说明描述训练变化时带有足够的背景技术细节，让资深用户理解发生了什么变化以及为什么。两者都将用户视为技术合作伙伴，这些用户从了解变化中获益，而不是需要被屏蔽复杂性的普通客户。

对于面向产品的 AI 功能，这转化为：

• 针对行为变化的发布说明，而不仅仅是新功能。如果你调整了系统提示词导致输出长度发生变化，这值得记录在变更日志（changelog）中。
• 版本标识，让用户在报告问题时有据可查（“我使用的是摘要器的 2.3 版本，它开始出现 X 现象”）。
• 反馈机制，要足够具体且具备可操作性——不是“这个回复有帮助吗？”，而是“这个回复回答了你的问题吗？”以及“格式是否符合你的预期？”

会注意到行为漂移的用户是你的高级用户——他们是将你的 AI 功能最深度地集成到工作流中的人。这些正是你最不能失去其信任的用户。将他们视为功能演进的合作伙伴，而不是需要被保护免受其影响的客户，既是诚实的方法，也是战略上正确的做法。

“完成”的真正含义

一个 AI 功能只有在满足以下条件时才算真正完成：

1. 一套黄金评测集（Golden eval set），以机器可验证的方式定义了该功能的预期行为。
2. 一套监控机制，能在 CI 中运行评测，并在生产环境中生成行为级 SLO 仪表盘。
3. 针对系统提示词（System prompt）、模型版本和行为契约的版本控制策略。
4. 一套针对行为变更的治理流程，以及在出现问题时的回滚方案。
5. 一套沟通基础设施——包括更新日志、版本标识、反馈循环——在功能演进时让用户保持知情。

这不仅仅是发布一个功能。它更像是发布一个带有运维操作手册（Ops runbook）的产品。这样做的好处是，以这种方式构建的功能可以真正地演进——每一次模型升级都能被慎重地吸收，每一次行为变更都能被理解和沟通，每一次回归都能在用户发现之前被捕获。

另一种选择是直接宣布完成，然后在六个月后发现，你发布的功能已经不再是生产环境中运行的那个了。这并不是一种偶发的故障模式。对于 AI 驱动的功能来说，如果你不针对性地进行工程化设计，这就是默认的结果。