为什么你的 AI 路线图不应该有 12 个月的计划

我上个季度合作的一个团队花了六周时间构建了一个“智能文档分类器”——微调模型、评估框架、自定义 UI，以及整个生产流水线。它在周二上线。接下来的周一，一个全新的通用模型发布了，在同样的评估中，它以零样本 (zero-shot) 的方式击败了他们的微调模型，且无需任何基础设施投入。他们整个第二季度的 OKR 变成了一个仅包含一行 API 调用的包装器。路线图在 12 个月前承诺要“掌控分类技术栈”。而这项承诺在墨迹未干之前就已经错了。

这并非孤例。行业追踪器记录显示，仅在 2026 年第一季度，各大实验室就发布了 255 个模型，到 3 月份为止，平均每周约有三次意义重大的前沿模型发布。成本已经崩溃：API 定价自 GPT-3 以来下降了 97%，顶级供应商之间的差距在大多数基准测试中已缩小到统计噪声范围内。当底层技术变化如此之快时，一份为期 12 个月的特性路线图就不再是计划——而是一份你无法重新审视的赌注清单，这些赌注是根据在你交付第二个项目之前就会过时的信息做出的。

人们很容易在读到这里后得出“停止规划”的结论。这是一个错误的教训。正确的教训是，规划的单元必须改变。一份按日期承诺特性的路线图假设构建块的成本和能力是稳定的。事实并非如此。你实际拥有的是一个能力押注组合，每个押注都有验证周期和终止条件。将该组合视为特性路线图是一个范畴错误，它在各个团队中表现为相同的三种失败模式。

AI 长期路线图失败的三种方式

第一个失败是无护城河特性。你致力于构建的东西，到你交付时，平台供应商将作为默认功能免费提供。PDF 提取、基础摘要、简单分类、转录、基于嵌入的搜索——这些在 2023 年都是可防御的产品表面，而现在只是模型供应商定价页面上的一个勾选项。如果你 18 个月的路线图中的特性依赖于当前的能力差距，那么你就是在与一条对你不利的曲线赛跑。你的路线图越长，其中处于不断上升的水位线以下的部分就越多。

第二个失败是错误的底层技术押注。你致力于一种技术路径——微调、特定的代理 (agent) 框架、特定的嵌入模型、自定义 RAG 流水线——六个月后，一种新的模型架构或能力使整个技术栈过时。在 2024 年构建复杂检索流水线的团队，眼睁睁地看着长上下文模型将他们一半的工作压缩进了一个系统提示词中。构建复杂工具编排层的团队，眼睁睁地看着原生工具调用能力取代了他们的自定义路由。这种赌注不在于特性，而在于底层技术，而底层技术已经发生了迁移。

第三个失败是冻结的假设。你致力于以特定方式解决用户问题，但你也锁定了关于用户会容忍什么、他们会接受什么延迟、特性应该采用什么 UX 形式的假设。然后，真实的运营数据在第四个月到来，并反驳了每一个假设。在正常的产品中，你会重构计划。但在“已批准的 12 个月路线图”中，你会完成你承诺的事情，以一种没人要求的形式交付一件你认为他们想要的东西，并称之为执行。今天撰写的 AI 路线图中，超过 60% 在九个月内实际上已经过时——而组织的反应通常是照样交付，因为另一种选择需要承认计划是错误的。

路线图的替代方案：能力押注组合

如果“按日期交付特性”是错误的单元，那么什么是正确的？能够站得住脚的模式是将 AI 工作视为一系列小型、有时间限制的能力押注组合，每个押注的结构都让你能够快速判断它是否奏效，如果不奏效，则可以干净利落地终止它。

能力押注不是“在第三季度前构建特性 X”。它是一个假设：我们相信能力 Y 应用于用户群体 Z，会产生可衡量的结果 W。 它包含三样路线图项所不具备的东西：一个可证伪的断言、一个固定的时间窗口（通常为 4-8 周）以及一个明确说明何时停止的终止条件。投资组合的比喻很重要，因为不需要每个押注都成功——系统设计时就允许部分失败，任何一个押注的失败都是信号，而不是挫折。这更接近于研究实验室的运行方式，而不是传统产品团队的规划方式，这就是重点：这项工作与应用研究的共同点多于交付已知良好的特性。

加载中…