跳转到主要内容

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

阅读需 1 分钟Tian PanTian Pan

我上个季度合作的一个团队花了六周时间构建了一个“智能文档分类器”——微调模型、评估框架、自定义 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 周)以及一个明确说明何时停止的终止条件。投资组合的比喻很重要,因为不需要每个押注都成功——系统设计时就允许部分失败,任何一个押注的失败都是信号,而不是挫折。这更接近于研究实验室的运行方式,而不是传统产品团队的规划方式,这就是重点:这项工作与应用研究的共同点多于交付已知良好的特性。

会员专享

余下内容仅对会员开放。

会员可读完整内容 —— 每一个公开发布的观点背后,那些框架、决策与推理的全貌。

  • 完整文章,包含未公开存档的部分
  • 可落地的工作框架,附带权衡与决策依据
  • 新文章抢先看,先于公开发布

随时取消 · 一次订阅,畅读全部

参考资料

保持联系,关注我获取更多内容

阅读需 10 分钟

你的评估套件就是你拒绝编写的产品需求文档

PRD 中模糊的形容词(如 “有帮助” 和 “简洁”)在模型面前很难生存 —— 评估套件才是这些决策真正落地的场所。请将评估视为产品规格,而非仅仅是测量工具。

insider
ai-engineering
阅读需 9 分钟

何时选择 LLM,何时选择简单启发式规则:四因素决策框架

四因素框架——信号质量、人类性能上限、数据可用性和可逆性——帮助工程团队判断 AI 真正创造价值的时机,以及何时简单的规则系统才是正确选择。

insider
machine-learning
阅读需 10 分钟

AI 功能的 PRD:为什么你的旧模板会让你在悬崖边失足

确定性的 PRD 缺乏对模型错误、发布评估门槛或系统提示词所有权的定义。这四个章节将为你解决这些问题。

insider
ai-engineering
阅读需 10 分钟

发现的能力:当用户上线了你团队从未规划的功能

每一个足够强大的模型都会暴露出你团队从未规划过的行为。用户发现了它们,并在其基础上构建了工作流,然后将下一次模型升级视为一种回归。这里有一种产品准则,能将这些“发现的能力”转化为由你真正掌控的决策。

insider
ai
阅读需 10 分钟

你的微调模型是一个你需要维护的分支

微调是对他人代码库的一次分支(Fork),而每一次基座模型的发布都是一次你并未计划的上游变基(Rebase)。弃用时钟、LoRA 适配器移植壁垒,以及当提示词加检索胜过拥有模型权重时的分支经济学规则。

insider
llm