4 篇博文 含有标签「roadmap」

有一句特定的短语应该让每一位工程主管立刻叫停会议：“只要模型变强，这就没问题了。”说这句话的人通常信心满满，有时还会配上一张展示能力曲线向上弯曲的幻灯片，而这几乎总是标志着路线图悄然从一份计划变成了某种预测。

这种区别比听起来更重要。计划是你所控制的一系列事情：你将编写的代码、你将构建的集成、你将运行的测试。预测是对你无法控制的事情的押注 —— 在这种情况下，是一个尚不存在的模型，它由一个从未承诺过交付日期的供应商按其时间表发布。当你围绕 “上下文窗口将翻倍” 或 “到第三季度推理能力将足够好” 来规划功能时，你并没有消除问题中最难部分的风险。你只是把它转移到了别人的发布日程表上，并宣称已经完成了。

看看任何 AI 产品的路线图，你都会发现用来列出准备发布之物的分栏：一个新的智能体、一个更好的检索流水线、一次模型升级、一次微调。每一项都是一个“诞生”。看板上没有任何一项代表“死亡”。没有一栏是留给你将停止支持的模型、将停用的提示词、将归档的评估集或将关闭的功能的。路线图从构造上来说就是乐观的——它们是你承诺去创造的未来清单。

对于确定性软件来说，这种遗漏并无大碍，因为你两年前发布的功能在你不改动它时大多能保持运行。但对于 AI 系统来说，这却是无声的灾难，因为无论你是否触碰它们，你发布的东西都在腐化。针对 GPT-4 的特性而优化的提示词，在提供商调整模型的那一天就会退化。针对去年的失败模式编写的评估套件，将不再能衡量任何真实的问题。你所依赖的模型可能会收到一个你并未规划的 60 天弃用通知。一份只规划发布的路线图，在它未追踪的每一行中都在积累隐形负债。

你的 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）的问题。路线图是为那个底层平台十年才更新一次的世界而发明的。现在的平台每季度更新一次，而这种产出物却没有跟上。

演示总是成功的。这是 AI 产品开发中最昂贵的一句话。产品经理看到模型处理好了理想路径（happy path），工程师发布了该功能的直观版本，六周后，支持队列里塞满了指标未能预见的投诉。模型本身没有退化。提示词（prompt）也没有变糟。只是该功能的形态并非模型所擅长的，而团队在工作开始前没有办法指出这一点。

相当大一部分已发布的 AI 功能都是以这种方式失败的——不是因为模型不好，而是因为任务错了。产品需要的输出是确定性的，而引擎是随机性的。用户对长尾误差的容忍度是千分之一的错误率，而模型的失败分布比这更厚。单位经济效益（unit economics）要求的延迟预算只有你在可负担范围内模型所能提供的一半。评估质量所需的地面真值（ground truth）并不存在，也无法低成本创建。这些都不是模型问题。它们是任务形态（task-shape）问题，应该在写下第一条提示词之前就被筛选出来。