AI 功能与 OKR 的错位：为什么季度节奏会破坏 AI 路线图

团队承诺“在本季度交付 AI 摘要生成器”，在第十周通过了技术门槛，在全员大会上庆祝胜利，然后正式上线。六周后，遥测曲线开始向错误的方向弯曲——无声且缓慢，没有人为其制作仪表盘，因为没有人负责这个曲线的走向。OKR 已经被标记为绿色。下个季度的 OKR 已经围绕新功能的发布起草好了。摘要生成器现在成了某个人的次要维护工作，到季度末评审时，团队开始纳闷，为什么在没有任何明显变化的情况下，该功能的客户满意度下降了 15 分。

这不是团队的缺陷，而是运营模式的缺陷。季度 OKR 是为软件校准的，在这种模式下，一个功能可以被界定范围、构建、交付，然后很大程度上就可以不管它，直到下一次重大版本更新。AI 功能不具备这种特性。它们有一条上线曲线和一条持续曲线，而持续曲线才是大部分价值——以及大部分风险——真正所在。将它们视为带有发布日期的交付物的 OKR 模板，悄悄地产生了一系列在下一个规划周期之前就已失效的演示产品。

为什么确定性 OKR 适合确定性软件

标准的季度 OKR 契约假设了三件事。功能范围可以提前界定——你可以写下“交付 X”并大致了解 X 的含义。功能在第一天就是可衡量的——结账流程要么完成购买，要么不完成，你可以发布一套回归测试套件来证明其正确性。而且功能在上线后是稳定的——除非客户发现了 Bug，否则在第十二周运行的代码在第二十周仍然有效。

这些假设在任何实质意义上都不适用于 AI 功能。在界定范围开始时，告诉你功能是否可交付的评测（Eval）套件并不存在；它必须作为一项独立的交付物来构建，而编写一个好的评测往往比构建它所评分的原型更难。在精心挑选的测试用例上表现良好的提示词（Prompt），一旦遇到真实流量带来的分布偏移（Distribution Shift），就很难维持效果。在真实流量中，用户会用你意想不到的方式措辞、输入格式错误的内容，并以你的原型从未见过的方式串联请求。而且系统在上线后本身就是不稳定的——这并非因为代码变了，而是因为模型变了、分词器（Tokenizer）变动了、检索索引发生了偏移，以及随着功能教会用户如何使用它，用户行为也发生了变化。

行业数据直白地支持了这一点。一种常被称为“90 天退化曲线”的模式描述了生产环境中的 LLM 功能如何在生命周期的第一个季度内悄然失去质量——这并非源于任何人编写的代码故障模式，而是源于微小偏移的累积。Gartner 预测，到 2025 年底，30% 的生成式 AI 项目将在概念验证（PoC）后被放弃，宽泛地说，这只是从更远一个季度的视角观察到的同一种模式。功能被构建出来了，但功能没有得到持续维护。

对于 AI 功能来说，“完成”究竟意味着什么

管理层必须推动的观念转变——并且必须反复推动，因为确定性软件的肌肉记忆非常强大——即：AI 功能在上线时并没有完成。只有当它拥有一个持续质量计划和一个明确的责任人时，它才算真正完成。

这句话承载了大量的信息。“持续质量计划”意味着对于生产环境中的“好”有一个明确的指标，有明确的衡量频率，有明确的行动阈值，以及有明确的行动手册。“明确的责任人”意味着一个唯一的人，他的名字出现在仪表盘上，他的日历上有评审会议，他的绩效考核反映了那条曲线是呈上升还是下降趋势。如果没有这些，功能就会进入一种“幽灵所有权”状态，质量下降变成了集体行动问题，只能由在投诉降临那天声音最大的客户来促成处理。

由此得出的推论是，OKR 不应该写成“交付 AI 摘要生成器”。它应该更接近于“以质量阈值 X 和评测覆盖率 Y 交付 AI 摘要生成器，然后在接下来的一个季度中由明确责任人 Z 维持质量阈值 X”。这不是一个单一的关键结果。这是一个配对的承诺——一个上线指标和一个持续质量指标——至少跨越两个季度进行跟踪。OKR 的形式必须与工作的形式相匹配，而工作并不会在上线时结束。

评测覆盖率是领先指标，而非交付物

在确定性软件中，测试是你为了以后重构的权利而支付的税。它们是交付物，因为“你写测试了吗”是一个代码评审问题，但它们不是任何有意义的事情的领先指标。构建要么通过，要么不通过。

在 AI 中，评测覆盖率是衡量功能是否具备上线条件的领先指标。如果一个团队在界定 AI 功能范围时，没有预留的评测集、经过校准的裁判（Judge）、冻结的基准，以及能够区分“提示词变好了”还是“裁判变宽松了”的归因学科，那么他们界定的是一个无法衡量的功能。一个无法衡量的功能就是一个无法抵御偏移、无法进行回归测试或无法改进的功能。评测套件是所有其他工作运行的基础。

这意味着在规划周期开始之前必须达成一个硬性前提：评测覆盖率不是一个 OKR；它是衡量一个功能是否可以成为 OKR 的准入标准。如果团队还没有为某个领域构建评测集，那么本季度就不能在该领域界定功能范围。他们只能界定评测的范围。在第一次执行时，管理层会觉得这是在退步。到第二次时，他们会觉得这是规划 AI 工作的唯一明智方式。

由此得出的推论是，已上线功能的评测覆盖率是一项需要持续维护的资产，而不是一次性的交付物。模型会升级，分词器会变动，工具 Schema 会偏移。除非根据当前的生产堆栈重新设定基准，否则针对上个季度检查点校准的评测在本季度可能衡量的是噪音。评测套件的维护必须是一个正式任务项，而不是闲暇时间才做的项目。

随功能数量扩展的维护负担

一旦你有一个 AI 功能上线，维护负担仅占一名工程师时间的极小部分。一旦你有十个，它就不再是一个小数目了。数学逻辑很简单：每个发布的功能都有一个需要重新验证的提示词 (prompt)、一个需要维护的评估集 (eval set)、一个需要重新建立索引的检索索引 (retrieval index)、一个可能已经发生偏移的工具模式 (tool schema)、一个可能已指向新检查点 (checkpoint) 的模型别名 (model alias)，以及一个需要人工阅读的质量仪表盘。这些工作都不会出现在发布路线图中，但都会出现在维护清单上。

可扩展的人员分配逻辑与确定性软件的默认逻辑正好相反。在确定性软件中，新功能开发工程师与维护工程师的比例可以长期大幅向新工作倾斜，因为已发布功能的维护负担会逐渐趋于零。而在 AI 领域，已发布功能的维护负担并不会衰减——每个功能的维护量大致保持恒定，总负担随功能数量线性增长。一旦跨过某个阈值（对大多数团队来说，大约是五到十个生产环境中的 AI 功能），这个比例就必须反转。否则，你发布的功能将超出你的维持能力，产品组合会在自身的重量下崩溃。

这是没被写进路线图的隐形成本，它悄无声息地产生了一个症状：所有功能都在发布，但没有一个在改进。团队很忙，仪表盘排满了，功能都标记为“上线”。然而，每个功能的质量曲线都在向错误的方向弯曲，因为没人有精力去维护它们。

设计符合工作特性的 OKR

一些模式可以帮助 OKR 模板与 AI 功能的实际运行逻辑保持一致。

用成对的目标取代单一的发布指标。每个发布的功能都有两个指标：发布指标（是否在日期 Y 前达到阈值 X）和持续质量指标（是否在随后的 N 周内保持阈值 X）。第二个指标是跨越规划边界的——第 Q+1 季度会自动继承第 Q 季度发布的每个 AI 功能的质量 KR。这迫使规划周期分配维护容量，而不仅仅是发布容量。

将评估覆盖率作为准入标准。缺乏足够评估覆盖率的功能不能被纳入季度范围。构建评估本身就是一个交付物。这能阻止一种反复出现的失败模式：将一个功能强行塞进路线图，而团队目前甚至还没有工具来衡量它。

分配明确的维护人力。维护已发布的 AI 功能是一个挂名的项目，而不是某人日历角落里的空闲时间。具体比例因团队而异，但对于运行多个 AI 功能的团队来说，这绝不是可以忽略不计的误差。如果没有预算，维护就不会发生。

通过功能开关发布，并制定明确的上线计划。将“在日期 Y 发布”替换为“在功能开关控制下进行 N% 的灰度发布，根据指标 Z 扩大到 M%”。这使发布事件与质量标准解耦，并将发布过程本身变成一个可衡量、可逆的过程，而不是既定事实。

明确追踪 AI 债务。提示词早于其重新验证日期、检索索引超过其刷新周期、模型固定在已废弃的检查点——这些都是维护债务项，应该出现在追踪清单上，就像基础设施团队追踪过时的依赖版本一样。如果它是隐形的，它就会无上限地累积。

架构层面的认知

这个论点最深刻的版本是：AI 功能是产品，而非交付物。交付物有发布日期和终态；产品则有运营生命周期、负责人、对抗熵增的质量基准，以及一个主要关于维持和增量改进而非发布下一个新东西的路线图。确定性软件的 OKR 模板将功能视为交付物，这大体上是正确的；但照搬这一模板的 AI OKR 将 AI 功能视为交付物，这大体上是错误的。

这不只是一个小小的视角调整。它改变了招聘对象、团队结构、绩效考评方式、季度规划运作方式，以及领导层衡量 AI 产品组合健康状况的标准。一个内化了“AI 功能是具有生命周期的产品”的团队，会分配维护容量，招聘具有维护型心态的人才，并将评估覆盖率视为基础设施。而没能做到这一点的团队将不断发布在规划周期之间逐渐退化的演示 demo，在曲线变差时归咎于模型提供商，并且每两个季度重新吸取一次相同的教训。

做对这一点的团队并不一定比没做对的团队发布得更快。他们的发布速度可能相同，但六个月后，他们的产品组合会是健康的。做错的团队会在一个周期内看起来极具生产力，但在下一个周期却忙于处理上一个周期留下的烂摊子。OKR 模板只是一个小小的工具，但其背后的运营模型才是产生复利的关键——而 AI 对于那些假装工作比实际更简单的运营模型是毫不留情的。