AI API 已弃用陷阱与稳定性应对

你刚花了三个 sprint 集成一个炫酷的新 AI API。Pull Request 已经合并，监控一切正常，产品团队甚至已经开始规划基于它开发的下一个功能。然后，你打开了收件箱：

“重要更新：[功能名称] 已弃用”

你围绕它构建的能力呢？正在被“重新调整”。翻译一下就是：它并没有像宣传的那样正常工作，现在你得重写代码了。

这并非假设。Google、OpenAI 和 Anthropic 都曾推出某项功能，为其包装品牌，然后又悄悄将其撤回。为什么这些实验室会在尚未完全理解自己构建的东西之前就发布产品？这是一个系统性问题，而最终承担技术债务的，却是我们开发者。

为什么开发者受到的冲击比任何人都大

营销口径发生变化时，他们只需要更新一份演示文稿。供应商撤回一项功能时，你却要重写代码。

实际发生的情况是这样的：

伪装成迭代的契约破坏。 一个原本号称“多模态”的模型，变成了“针对文本优先工作流进行优化”。于是，你的图像处理流水线开始在生产环境中报错。

版本管理表演。 模型版本号升级了，但其行为却发生了根本性变化。你的集成测试全部通过，面向用户的准确率却下降了 20%。

文档漂移。 API 文档仍在介绍已经被软弃用的能力。直到遇到速率限制或意料之外的错误码，你才发现问题。

消费级应用可以迅速转向，企业系统却做不到。而你维护的代码库恰好处在两者之间，被迫承受每一次破坏性变更。

集成之前需要检查什么

你无法彻底消除风险，但可以避开最危险的雷区。下面是我现在会重点检查的内容。

1. 版本稳定性记录

不要相信 roadmap，要检查 changelog：

• 次要版本多久会引入一次破坏性变更？
• 弃用是否会提前公告并提供迁移窗口，还是事后才补充到 release notes 中？
• 是否存在公开的 issue tracker，用于讨论行为回退问题？

如果一家供应商在六个月内悄悄改变了三次模型行为，那就应该假定，这就是你未来需要面对的变更频率。

阅读真正的 SLA，而不是营销网站上的宣传：

❌ "Enterprise-grade reliability"
✅ 99.9% uptime on inference endpoints, 30-day notice on deprecations

如果 SLA 没有提及 API 稳定性或行为一致性，那就相当于没有 SLA。

3. 逃生舱架构

从第一天开始，就要以可替换性为目标进行设计：

# Bad: Tight coupling to vendor SDK
result = openai.ChatCompletion.create(model="gpt-4", ...)

# Better: Abstraction layer
class LLMProvider(Protocol):
    def complete(self, prompt: str) -> str: ...

class OpenAIProvider(LLMProvider):
    def complete(self, prompt: str) -> str:
        return openai.ChatCompletion.create(...)

# Swap providers without touching business logic
provider: LLMProvider = get_provider()  # Config-driven
result = provider.complete(prompt)

如果更换供应商意味着需要重写一半的应用，那么你其实已经输了。

4. 为所有功能添加 Feature Flag

像对待任何实验性的第三方依赖一样对待 AI 功能：

• 用 Feature Flag 包裹相关调用，以便随时立即禁用
• 将输入、输出和延迟与核心指标分开记录
• 准备一条不依赖 AI 可用性或正确性的降级路径

这不是多疑，而是把外部 API 当作它本来就是的东西：网络调用。

还有一个更加隐蔽的问题：供应商往往会在某项能力尚未经过大规模验证之前，就先为它进行品牌包装。名为 “Advanced Reasoning” 或 “Extended Context” 的功能听起来像是一份承诺，但无论从法律还是技术角度看，它都只是营销话术。

作为开发者，我们需要对此提出质疑：

• 如果某项能力至关重要，就要求供应商以书面形式明确其行为，例如写入 SLA、API 契约或回归测试
• 如果供应商不愿承诺具体的准确率或一致性指标，就把它视为实验性功能
• 如果某项功能已经处于 “beta” 状态一年，它并不会变得稳定——这就是它的稳定状态

这对你的下一个 Sprint 意味着什么

如果你正在集成 AI 工具，尤其是在无法容忍意外故障的系统中，就应该像审查任何其他第三方依赖一样严格审查它：

• 将模型输出视为不可信输入
• 对集成进行版本管理，以便能够回滚
• 监控行为漂移，而不只是服务可用时间
• 为重新集成预留时间，因为这件事迟早会发生

AI 工具带来的竞争优势是真实存在的，采用 AI 的确可以构建护城河。但前提是，你必须把系统建在稳定的地基上。专注于 AI 自动化和软件开发的公司经常看到团队在这个问题上栽跟头：概念验证惊艳无比，生产部署却脆弱不堪。

AI 供应商正在快速发布产品，因为市场奖励速度，而不是稳定性。这一点不会改变。能够改变的是我们的集成方式：保持怀疑，建立抽象层，并准备好退出方案。

因为下一封功能撤回邮件，已经有人在起草了。

如需采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。