平台就绪差距：当 AI 功能先于运维基础设施上线时

发布并不是 AI 功能上线的那一刻，而是平台团队开始接手一个他们从未有机会参与设计的生产系统的瞬间。

产品团队开发了一个功能原型。演示在管理层反响很好。发布日期定了。而在幻灯片与正式上线之间，这个功能在任何人构建评估测试框架 (eval harness)、提示词注册表 (prompt registry)、路由层、成本仪表板、回滚原语、了解智能体 (agent) 运作方式的值班轮岗制度，或针对新供应商 API 密钥的密钥轮换策略之前，就已经上线生产环境了。功能运行正常。演示指标一片大好。而平台团队现在却要为一个基础原语 (primitives) 尚不存在的运维系统负责。

这就是“平台就绪差距” (platform-readiness gap)，也是为什么那些在发布时看起来很健康的 AI 项目，往往在开发到第五个功能时就变得无法管理的最常见原因。

差距为何形成

这种差距并非规划上的失误，而是结构性的。产品团队的考核指标是发布。平台团队的考核指标是可用性 (uptime)、成本和事故数量。第一个指标奖励速度，第二个指标奖励谨慎。当产品团队拥有一个可运行的演示版本并对董事会做出承诺时，阻力最小的路径是直接发布并让平台随后跟进。阻力最大的路径则是为了等待平台搭建完毕而推迟发布。

这种不对称性在 AI 功能上比传统服务更为明显。传统的 Web 功能可以继承成熟的平台——负载均衡器、错误预算、蓝绿部署、请求追踪、租户成本仪表板——而发布大多只是挂载到现有的原语上。AI 功能则几乎没有任何可继承的东西。当失败模式是一个模型在你的评估集从未采样过的输入类别中，每一千次请求就自信地给出一个错误答案时，根本没有“部署到预发布环境并观察错误率”这样的对等操作。这些原语必须针对每个功能重新发明，而大多数公司仍处于发明它们的第一个或第二个周期中。

结果是，每一项事后的平台投资都被迫在最糟糕的时刻进行。紧急开关是在需要它的故障期间设计的；租户级成本遥测是在暴露了其缺失的成本飙升期间安装的；冻结的提示词注册表是在模型回归期进行版本化的，而那时大家才发现没人知道生产环境运行的是哪个提示词。每一个原语的出现，都比它本可以预防事故的时刻晚了两周。

四种滚雪球式的债务

当你观察多家公司的这种差距时，会反复出现四种平台债务。每一种起初都很廉价，但后期修复的成本会呈指数级增长。

评估债 (Eval debt)。 发布演示即是评估。没有保留测试集，没有回归测试套件，没有自动化评分。当模型供应商推送静默更新时，你除了等待用户投诉外，没有办法检测到功能质量的下降。到评估框架建成时——通常是在经历第三次回归之后——团队不得不顶着时间压力，追溯性地对数月的生产流量进行标注，以引导出一个有意义的测试集。

提示词债 (Prompt debt)。 提示词作为字符串字面量存在于应用代码中，跨服务复制，在热修复中被修改，从未进行版本管理。团队无法回答：“当这个客户在周二投诉时，运行的是哪个提示词？”提示词更新事故是 LLM 生产问题的主要原因，而没有提示词注册表的团队根本无法进行二分法排查 (bisect)。事后构建注册表意味着要通过 git blame 对几十个内联字符串进行意图重构。

回滚债 (Rollback debt)。 没有回滚原语。功能指向配置中硬编码的模型 ID；切换回之前的模型意味着代码变更、构建和部署。没有流量切分层，没有灰度发布 (canary)，也没有值班工程师能在凌晨 2 点不需要代码审查就能按下的紧急开关。当不可避免的糟糕发布发生时——比如一个新的供应商模型在处理 95% 的输入时表现更好，却破坏了你企业客户依赖的 5%——响应时间是以小时计，而不是以秒计。

成本债 (Cost debt)。 功能会产生供应商账单。账单归属于单个账户。当成本飙升发生时，没人知道是哪个租户或哪条代码路径驱动的。租户级成本遥测是每个成熟 SaaS 平台在计算和存储方面都具备的功能，但在发布时几乎从未接入 Token 消耗。在成本事故发生后构建它，意味着在财务部门询问为什么 AWS 账单月环比增长 40% 的同时，还要重写请求路径的探测逻辑 (instrumentation)。

这四种债务之所以会产生复合影响，是因为它们共享依赖关系。你在没有提示词注册表的情况下无法构建可靠的回滚机制，因为只回滚模型而不回滚提示词会产生一种没人测试过的状态。你在没有成本遥测的情况下无法构建有意义的评估套件，因为大规模评估需要预算。如果没有将追踪 (traces)、提示词、模型版本、成本和用户群体关联起来的可观测性，你就无法回答“这次回归是真的还是噪声？”。这些原语是耦合的。在没有它们的情况下发布功能，意味着你同时欠下了这四种债务，而你将不得不按照事故逼迫的顺序，而非总成本最小化的顺序来偿还它们。

导致系统持续崩溃的政治动态

关于平台就绪差距，最残酷的一个事实是：没有任何团队的激励机制会奖励去弥补这一差距。产品团队因产品发布而获得功劳，却不承担任何稳态成本。平台团队承担了差距带来的运维成本，但在导致该问题的设计阶段却没有任何话语权。工程领导层在一个仪表盘上看到了成功的发布，在另一个仪表盘上看到了日益沉重的值班负担，却无法将两者联系起来，因为从发布到负担显现之间存在 6 到 12 个月的延迟。

CFO 看到供应商账单增长，要求 AI 团队优化成本。AI 团队却无从优化，因为他们无法将支出归因于具体的功能、租户或代码路径。CISO 询问谁负责轮换新供应商的 API 密钥，得到的回答是“负责集成的工程师，但他已经调岗了”。审计人员要求提供客户投诉期间生产环境中使用的提示词记录，得到的回答是“我们没有记录”。

这些人都没有错。他们问的是一个成熟平台应该能够回答的问题。团队无法回答这些问题并非因为渎职，而是因为在发布之前，从未确立过将 AI 功能视为运维系统——而非演示 demo——的纪律。

必须确立的纪律

解决方案并非纯技术性的，尽管它会产生技术产物。解决方案是一个“发布准入机制”，它将 AI 功能从原型转向生产的时刻转变为一种强制约束机制。这是一份平台就绪清单，在任何 AI 功能发布前进行评审，每个项目都关联到一名签署确认的平台负责人。

这份清单应该足够精简以便于实际使用，同时也应足够具体，以防止团队敷衍了事。实际项目包括：

• 评估覆盖率：一个保留的测试集，至少包含功能明确针对的用户群；一套在每次提示词更改和模型版本升级时运行的回归测试套件；以及一份在发布前功能必须达到的质量阈值文档。
• 提示词版本控制：每个提示词都记录在注册表中，包含作者、时间戳、变更理由以及所提升版本的测试套件结果。生产环境代码中不得出现内联字符串字面量。
• 回滚路径：支持按比例分配的流量路由原语，针对每个功能和每个租户的终止开关（kill switch），以及在发布前（而非发布后）执行的回滚演练。
• 成本遥测：按功能和租户划分的 Token 支出，按模型和代码路径细分，并在任何维度超出预算时发出告警。
• 值班覆盖：值班轮换人员必须阅读过运维手册，执行过回滚演练，并且能够区分“模型表现异常”与“模型宕机”。
• 密钥归属：为每个供应商凭据指定负责人、轮换策略，以及当负责人调岗时的交接流程。
• 退役计划：功能如何关闭、数据如何处理，以及谁负责下线流程。

每个项目都应该有一个平台团队预建的默认方案，这样满足准入门槛就是一个配置选择，而不是一个从零开始的工程项目。如果平台团队还没有预建默认方案，那么准入机制就还不应存在，正确的做法是在批准下一次发布之前先构建平台。

将平台债务视为一级预算项

除了准入机制外，领导层的举措是让平台债务像技术债务一样可见。每一次发布都会产生债务——平台未设计的供应商集成、现有层无法表达的路由规则、测试套件不支持的评估格式。这些债务是真实的，会产生利息，而且目前还没有出现在任何人的季度计划中。

解决办法是追踪它。当发布发生时，平台团队记录下所产生的债务，并将其关联到产生该债务的功能上。设定一个预算：允许带入下一次发布的债务上限。在第一版的平台债务还清之前，产品团队不能发布 AI 功能的第二版。批准发布的管理者在批准的同时，也在批准使其可运行的平台投资。

这听起来很官僚。但这是已知防止差距复合增长的最廉价方法。如果没有它，一年发布五个 AI 功能的团队，其平台债务将是发布一个功能的团队的五倍——其值班负担、成本意外和回归事故也大致与该债务成正比。

人员配置的影响也值得直接指出：平台团队的规模应该根据生产环境中 AI 功能的数量来确定，而不是根据发布的数量。发布是一个离散事件，而运维一个功能是持续的负载。一个为发布而配置规模的团队，在运维上会悄无声息地落后，直到故障率迫使你进行清算。

领导层对话背后的真正选择

剥离掉运维术语，这个选择其实是在两种 AI 策略之间进行，领导团队需要明确做出选择，而不是默认而为。

一种策略是“先发布功能，以后再考虑运维”。对于第一个功能来说这没问题。如果团队运气好，第二个功能也行得通。但到第五个功能时，这将会是灾难性的，因为债务会复合增长，团队现在整天忙于救火，而这些事故如果能在两年前构建好底层原语，本是可以避免的。

另一种策略是“按计划稳步构建平台”。发布速度较慢，头条新闻较少，但底层有一个真实的平台。这需要的勇气是：愿意告诉执行团队，下一次发布暂时不会发生，因为上一次发布的平台债务尚未偿还。那次谈话会令人不快。但正是这次谈话决定了公司的 AI 策略在三年后是可运行的，还是悄然破产。

大多数公司都处于第一种策略中，却并未意识到自己做出了选择。他们在产品团队在平台建立之前发布第一个 AI 功能时就做出了选择，而且在发布评审中没有人提出那个本该被问到的问题：“周一谁来运维这个？”

如果你说不出那个人的名字，指不出他们将使用的运维手册，并指向他们演练过的回滚方案，那么这个功能就还没准备好发布。Demo 准备好了，但系统还没有。