双钟问题：当模型供应商的迭代节奏打乱你的路线图

你的 AI 产品上有两个正在走动的时钟，且它们并不同步。模型厂商的更新节奏大约是季度性的——2026 年 2 月发布 Claude Opus 4.6，3 月发布 GPT-5.4，4 月发布 Claude Opus 4.7，一周后发布 GPT-5.5。而你的产品路线图在 1 月份就已经确定，直到 7 月才会再次评估。在这期间，你花了 8 个工程周构建的功能可能变成了一个单行 API 参数，而团队中没有人有一套流程来察觉这一点。

这不是一个预测问题。这些发布早有预兆——任何阅读变更日志（changelog）的人都能预见到。这是一个规划产出物（planning-artifact）的问题。路线图是为那个底层平台十年才更新一次的世界而发明的。现在的平台每季度更新一次，而这种产出物却没有跟上。

这种失效模式是对称的，且在两个方向上都令人尴尬。一个团队承诺投入九个月构建一个长文本检索流水线；在第四个月，下一个 Sonnet 版本发布了，自带 2M token 窗口，那个定制的流水线在质量、延迟和成本上都显得落后——但路线图没有退出机制，所以团队还是把它做完了。另一个团队则在等待“下一个模型”才开始开发某个功能，而实际上今天的模型已经可以胜任了，结果具备“能力底线”（capability-floor）思维的竞争对手先发制人，占领了市场。这两支团队都是在 2026 年的基础设施上进行 2019 年式的产品管理。

能力假设就是依赖项，像命名依赖项一样命名它们

构建流水线会固定（pin）库版本，因为没人相信传递依赖会保持不变。依赖 AI 能力的路线图也应该这样做——指明你所假设的能力，并固定你假设的特定模型和版本。“我们押注在当前的 Sonnet 级别下，200K 上下文路由的 p95 延迟在 4 秒以内”是一个路线图项。“我们将 AI 添加到合同审查流程中”则不是。

这种纪律开启了像阅读 CVE 订阅源一样阅读模型发布公告的习惯。当新模型落地时，你会梳理路线图并询问每个能力假设：新发布是增强了它、削弱了它，还是让定制实现变得多余。大多数季度，大多数项的答案是“无变化”。但每年总会有一两次发布让某个工作流过时，或者让以前不可能的功能变得轻而易举，那些明确了依赖关系的团队在当天就能察觉，而不是等到三个月后。

这与安全积压（security backlog）的心智模型相同。没人幻想一次性审计能捕获所有 CVE；你接受漏洞会在季度中途出现，并拥有一套分级处理（triage）流程。AI 能力发布需要同样的运营化处理，而不是每季度的形式化审查。

季度能力审查，应被视为真正的规划仪式

这种做法成本最低的版本是每季度一次两小时的会议，由工程主管、AI 主管以及负责 AI 路线图的 PM 参加。议程是固定的：梳理本季度的每个模型发布，梳理每个路线图项，针对每一对组合，记录该项是否应该重新定义范围、加速、取消或保持原样。任何被取消的项都需要书面理由以便吸取教训；任何被加速的项都需要在同一周内做出人员重新调配的决定。

失败的版本是那种会议开了但没有产生任何决策。“是的，我们应该研究一下”不是决策。审查的产出是一份带负责人的路线图修改列表，并在周一生效。如果连续两个季度审查都毫无产出，那你就做错了——要么你的路线图没有真正的 AI 依赖（如果是这样，就别叫它 AI 路线图），要么你的团队没有评估新版本与现有承诺的工作。

之所以选择季度而不是月度，是因为大多数月份没有重大发布。之所以不能是年度，是因为在 2025 年或 2026 年的任何 12 个月窗口期内，都至少包含三个能实质性改变“什么是可构建的”发布。节奏匹配（Cadence-matching）正是这一仪式的核心意义。

能力底线与能力天花板的投资组合

并非每个路线图项都应以相同方式响应模型升级。某些押注是基于当前能力构建的，应该当作未来没有新能力来交付——客户现在就在付钱，“等待下一个版本”算不上一个功能。其他押注则明确假设了下个季度的能力，否则就无法实现——一个需要 4 小时自主任务完成能力的长程研究型智能体是 2026 年的押注，而不是 2024 年的，基于当前能力交付它只会是必然产品的劣质版本。

团队常犯的错误是无意识地全盘押注其中一方。一个只交付“能力底线”功能的团队看起来执行力很强，但却错失了未来一年模型发布的所有潜在收益。一个只交付“能力天花板”（capability-ceiling）功能的团队每六个月拿出一个华丽的演示，但没有东西上线。这两者都很容易陷入，且身处其中几乎无法察觉。

解决办法是将这种划分视为预算，而非一种感觉。“60% 的 AI 工程时间用于能力底线工作，30% 用于能力天花板，10% 用于弃用和迁移”是领导者应该能大声说出来的话。一旦有了这个数字，你就可以讨论它是否适合你的阶段和市场——并且能察觉到六个月后它是否因为没人关注而发生了偏离。

一个不再是某人电子表格里的弃用日历

模型提供商根据他们发布的计划停用模型，而且这些计划会在规定的日期准时执行。原始的 Claude 3 Opus 在 2026 年 1 月 5 日退役。Claude 3.5 Sonnet v2 在 2025 年 8 月被弃用，并于 2026 年 2 月 19 日关闭。Claude 3.7 Sonnet 有一个为期六个月的弃用窗口，于 2026 年 5 月 11 日结束。OpenAI 的 Assistants API 在 2025 年 8 月被弃用，并于 2026 年 8 月 26 日正式关停。这些日期都不是意外；但每一个日期都至少让一个没有在日历上记录日期的团队收到了告警。

一个真正的弃用日历应该存在于你存放其他基础设施截止日期的地方 —— 你的故障处理系统、团队日历或路线图规划工具。它应该包含提前 90 天的预警、负责人以及迁移工作量估算。如果迁移工作并不简单，它在截止日期前至少一个季度就应该在路线图中有专门的一行记录。如果迁移很简单，它仍然需要占一行，因为简单的迁移正是你发现自己的评估套件（eval suite）已经在不同的分布上静默运行并通过了三周的地方。

被弃用搞得焦头烂额的团队并不是那些没看公告的团队。而是那些看了公告，认为没问题，然后从未把日期写进日历的团队。遗忘曲线才是那个 Bug。

在准入阶段就为 AI 路线图项目附上终止标准

AI 产品规划中最昂贵的 Bug 是缺乏明确的取消路径。一个团队致力于构建自定义的 OCR 流水线；六个月后，多模态模型发布了原生文档理解功能，在每个基准测试中都击败了该流水线。但团队还是发布了该流水线，因为路线图中没有“这不再是工程时间的良好投入”这种表述。沉没成本已成事实；真正的损失是接下来六个月的机会成本。

解决方法是程序性的，而非文化性的。每一个 AI 路线图项目，在准入阶段都要在旁边写下一个终止标准（kill criterion）。“如果前沿模型发布了原生支持，且在成本降低 50% 的情况下，质量达到我们标准的 10% 以内，我们就终止这个项目。”“如果我们的评估套件显示与基础模型相比没有质量差距，我们就终止这个项目。”“如果在 90 天时衡量的差异化差距比 30 天时更窄，我们就终止这个项目。”这个标准不需要完美；它需要是可编写的、可证伪的且可见的。

这种标准迫使人们在项目开始、成本还很低的时候进行没人想做的对话，而不是在第九个月、成本很高昂的时候。它还给了团队在不丢面子的情况下放弃工作的许可，这在大多数时候才是真正的阻碍。工程师们知道他们的流水线何时不再优于基础模型。他们只是需要一个书面理由来把它说出来。

模型版本锁定，但要保持清醒

人们很容易倾向于永久锁定每个模型版本，并将任何升级视为单独的规划事件。在受监管的行业中，这是一个站得住脚的立场；但在大多数其他情况下，这会让你落后于那些每季度都在升级的竞争对手一年。正确的默认做法是锁定生产版本，同时有一个处于评估中的活跃“下一代”版本，并且每个季度发布一个切换窗口，将通过评估的“下一代”版本变为生产版本。

不明显的成本在于评估套件。锁定并升级的节奏好坏全看版本间的回归检测能力。那些在没有评估套件的情况下按季度升级的团队，实际上是在用户身上进行单团队的 A/B 测试；而拥有强大评估套件的团队在发布后一周内就能知道新模型是提升了质量、出现了退化还是保持中立。评估套件不是一个副作用项目 —— 它是让这种节奏变得安全的核心。

这也解释了为什么“GPT 套壳”有时是贬义词，有时却是一门可持续的生意。那些没有评估、没有微调、没有特定领域脚手架的套壳 —— 任何人都可以在一个周末重造出来的东西 —— 被正确地视为占位符。而那些拥有多年评估数据、封闭的分发渠道以及捕获客户特定上下文的工作流的套壳，则具备升级韧性，因为真正重要的表面积不是模型，而是模型周围的一切。两个时钟问题主要是那些尚未建立起这种表面积的产品所面临的问题。

领导层的觉悟

路线图作为一种规划产物，假设平台是稳定的。但 AI 并不是一个稳定的平台，假装它是稳定的是团队账目上最昂贵的乐观形式。在这种环境下表现出色的团队并不是那些预测模型发布的团队 —— 没人能做到 —— 而是那些已经理顺了规划流程，使得新版本的发布可以在一周内被消化，而不是争论一个季度的团队。

这项工作并不显赫。路线图上的一个能力假设列。每季度一次带有真实决策的两小时评审。一个存在于值班日历旁的弃用日历。在准入阶段附带的终止标准。一个带有实际数字的能力下限/上限预算。这些都不是研究级的工程。所有这些，决定了一个团队的路线图是在与下一个版本接触后幸存下来，还是在季中就变成了一件博物馆陈列品。

如果你的团队交付 AI 已经超过一年，却还没有建立起这些机制，那么下一个模型的发布将会让这一点暴露无遗，无论你是否愿意。与其让模型提供商替你增加第二个时钟，不如主动在你的规划流程中加入它。