“每周模型”路线图：当厂商承诺变成确定性依赖

一位产品经理拉出了下个季度的路线图。其中三个功能被标记为“依赖下一代模型”。没人问如果下一代模型延期、比演示版本缩水 20%、或者发布的版本仅限你的客户没有资格使用的企业级层级，会发生什么。六个月后，这三种情况都发生了，团队现在正在针对实际发布的模型重建两个季度的架构——而这个模型的形态与他们当初计划的完全不同。

这就是“每周模型路线图”：将尚未发布的能力声明视为确定性的依赖。这是将 12 个月的计划变成 30 个月计划最可靠的方法之一。而在当时，这看起来几乎没有风险，因为每个厂商的演示都让人觉得大势所趋。计划的破坏是隐形的，直到延期产生复合影响。

这种模式出现在那些直到崩盘前一直看起来很健康的进度报告中。工程进度按时交付。Prompt 已经调优。评估（Evals）通过了。然后，路线图所围绕的模型要么没能面世，要么发布的等级低于预期，要么其特性破坏了预设的架构。路线图的失败并非因为团队没能履行承诺，而是因为团队承诺了别人的承诺，而那些承诺从始至终都只是愿景。

厂商路线图是营销，而非合同

当基础模型厂商说“下一个版本将处理长周期工具调用”时，工程团队听到的是一份 API 合同。而厂商自己的团队却不这么认为。前沿实验室的发布时间表受到安全评估、红队测试结果、算力可用性以及竞争态势的限制——而这些在六个月前都是无法预知的。这并不是厂商的失败，而是训练运行的本质，其结果经常连开发者自己都会感到意外。

只要留心，这种差距的证据随处可见。一家顶级实验室旗舰版本的 Q1 2026 截止日期已经错过了一个多季度，而且还在延期。另一家公司将其最受期待的 2026 模型仅发布给了约 40 个精选的企业合作伙伴，而不是公开版，因为内部安全评估发现某些能力对公众开放风险过大。第三家厂商在单个季度内对同一个“下一代”模型的变体进行了三次更名、重新划定范围并重新发布——每一个都是真实的产品，但每一个都破坏了基于先前版本构建的团队的架构假设。

任何基于“下一个模型会解决这个问题”而制定的路线图，有四分之三最终都会走向这三种结局：延期、受限或重新定标。这种可能性并非抽象的推测，而是最常见的常态。

“模型如约而至，但并非如你所愿”的三种形态

当一种能力最终落地时，更常见的失败不是它没出现，而是它以“错误的装束”出现。计划使用某种形态能力的团队得到了另一种形态，而他们为计划形态编写的代码现在需要重写。

规格不对 (Wrong envelope)。 演示展示了具有推理能力的模型支持百万级 token 上下文。发布时，百万级上下文出现在一个更便宜、更快但推理能力较弱的变体上——或者在 200K 窗口中提供了完整的推理能力。如果架构假设两者兼得，那就必须有所取舍。计划使用单次调用工作流的团队，现在需要编写估算中从未包含的分块 (chunking) 和聚合 (aggregation) 代码。

层级不对 (Wrong tier)。 能力确实出现了，但仅限于特定的层级，被挡在企业合同、更高的 token 定价或特定的区域端点之后。对于拥有财富 500 强客户的 B2B 团队来说，这通常没问题；但对于专业消费者 (prosumer) 产品，单位经济效益 (unit economics) 就会崩溃。路线图项在技术上确实交付了，但在生产中使用它的路径却被没人负责的商务洽谈挡住了。

可靠性形态不对 (Wrong reliability shape)。 基准测试过了，评估也通过了，但客户仍在抱怨。这是基准测试与现实差距最昂贵的表现。模型越来越多地针对流行的公开评估进行优化——一些从业者称之为“刷分 (benchmaxxing)”——但真实的企业工作负载是混乱且依赖上下文的，与任何已发布的排行榜任务都不相同。Agent 在 CRM 类工作流中的目标完成率通常低于 55%，即使底层模型在基准测试中名列前茅，因为一个 20 步的链条在每步可靠性为 95% 的情况下，复合后的整体成功率仅为 36%。一个基于头条数据假设“Agent 能力已足够好”的路线图，现在欠下了整条未被纳入范围的可靠性工程债。

为什么聪明的团队不断进行这种博弈

如果模式如此明显，为什么优秀的初创产品负责人还要不断签署这种协议？三种力量共同作用。

第一是演示不对称性。厂商的发布材料展示的是最佳情况的追踪、精挑细选的 Prompt，以及一个已经知道什么可行演示者。任何花了一个周末尝试复现发布会演示的工程师都知道，“在脚本化运行中可行”与“在我们的数据上可行”之间的差距。但当内部意识到这种差距时，路线图已经向上汇报并确定了。诚实的评估——“这可能对我们的用例有效，但在生产流量上尝试一个月之前我们无法确定”——来得太晚，无法改变计划。

第二是竞争压力。竞争对手宣布了一项似乎依赖于未发布能力的功能。领导层看到了公告，并询问你为什么没有同样的计划。工程师无法在不显得像是在推诿 (sandbagging) 的情况下写出反驳，因为另一种方案——“我们应该基于现有的模型构建”——感觉像是放弃了未来。没人想成为那个反对一个最终按时交付的能力的人。于是，这种博弈便开始了，通常是无声的。

第三是组织架构的惩罚机制。如果路线图因为厂商模型延期而延误，那是领导层可以向上交代的理由。但如果路线图基于现有模型发布，而竞争对手依赖新模型的版本效果更好，那就是工程判断失误，而工程判断失误会毁掉职业生涯。激励机制倾向于押注未来，因为厂商导致的延期，其负面后果是可以转嫁给外部的。

准则：将“当前可用”作为默认计划

这种反向准则并非对模型的发展前景持悲观态度。相反，它拒绝让未来的能力成为今天架构的核心支撑。基于目前普遍可用的最佳模型的实测能力进行构建，并将每一次新发布视为一次机会主义的升级，而非一种依赖。

这要求在编写路线图（roadmap）的方式上做出一些具体改变。

将计划分为“现在可行”和“以后会更好”两部分。路线图中的每一项都应标明经过验证的具体模型版本，以及在你自己的评估集（evals）上的实测通过率——而不是供应商提供的。例如，“在我们的支持工单测试集上，模型 A 的表现为 87%”是一项承诺；而“根据供应商的演示，在下一代模型上可行”则只是一个愿望。

当某个功能需要尚未发布的东西时，应明确预估能力风险。如果路线图中的某项确实取决于尚未交付的模型，那么该项的时间表就不只是工程开发工作，而是工程开发工作加上至少 50% 的能力风险系数（针对任何前沿实验室的发布）。大多数团队会将这种风险隐藏在工程估算中，这就是为什么进度滑坡总是看起来像意外。

设计架构时，应使模型切换的成本降到最低。当模型只是稳定接口背后的可替换组件时，押注未来模型的风险就会大大降低。如果团队通过网关进行路由、对提示词（prompt）进行版本管理，并针对多个候选模型持续运行评估（evals），那么他们就能在模型发布的当周利用更好的模型，而无需背弃原有计划。如果团队将提示词硬编码为特定供应商的行为，则无法做到这一点。

持续针对当前可用的后备方案进行评估。如果计划是“发布后使用下一代，否则使用模型 A”，那么模型 A 的路径就不能仅仅停留在理论上。它必须是一个可以工作的分支，每周进行测试，并如实记录产品性能会差多少。许多团队在延期之日才发现，由于无人维护，他们的“后备方案”实际上根本无法工作。

将新模型视为天气，而非基础设施

让这一切成本降低的心态转变很小但很敏锐：停止将供应商的模型发布视为基础设施升级，而要开始将其视为天气。天气是真实的。天气是有影响的。你会围绕天气做计划。但你不会建造一座承重梁取决于未来三季特定预报的房子。

以这种方式运营的团队会获得一系列不同的胜利。当某种能力真正落地并对他们有效时，他们可以在一周内采用它，因为其架构早已支持灵活切换。当发布延期或受限时，他们不需要重新制定计划——只需继续在现有的模型上发布产品。路线图对供应商的时间表具有了韧性，而“对供应商时间表的韧性”是目前 AI 产品工作中，能获得进度信心的最廉价来源。

更难的调整在于文化。团队中必须有人站出来大声说“我们正在为现有的模型而构建”，使其成为默认选择，而非谨慎的后备方案。那个人偶尔会出错——有时下一代模型确实按时交付且效果极佳——因此他们需要领导层的支持来坚持做这类决策。否则，路线图在起草时看起来充满灵感，在兑现时读起来却像是一份复盘报告。

基于未发布的能力进行规划并非远见卓识。这实际上是将你的进度外包给了一个进度不受你控制、没有 SLA、没有合同且没有沟通渠道的团队。一份好的 2026 年 AI 路线图应假设每个供应商都至少会失约一次，每项头条功能都会以意想不到的形式出现，而你实际发布时所使用的模型就是你现在拥有的那一个。当更好的模型出现并完美契合你的接口时，进行升级。如果没有，你的计划依然有效。