8 篇博文 含有标签「ai-strategy」

发布并不是 AI 功能上线的那一刻，而是平台团队开始接手一个他们从未有机会参与设计的生产系统的瞬间。

产品团队开发了一个功能原型。演示在管理层反响很好。发布日期定了。而在幻灯片与正式上线之间，这个功能在任何人构建评估测试框架 (eval harness)、提示词注册表 (prompt registry)、路由层、成本仪表板、回滚原语、了解智能体 (agent) 运作方式的值班轮岗制度，或针对新供应商 API 密钥的密钥轮换策略之前，就已经上线生产环境了。功能运行正常。演示指标一片大好。而平台团队现在却要为一个基础原语 (primitives) 尚不存在的运维系统负责。

这就是“平台就绪差距” (platform-readiness gap)，也是为什么那些在发布时看起来很健康的 AI 项目，往往在开发到第五个功能时就变得无法管理的最常见原因。

一家物流公司花费了 80 万美元、历时十二个月，尝试用 AI 优化路线规划。项目结束时，他们的路线效果仅比原有启发式规则略有提升。高管层随后否决了接下来三个 AI 提案。一家外卖公司面临同样的路线问题，却用一套显式业务规则在一个晚上就解决了。

两支团队都学到了一个代价高昂的教训：在实时约束、司机偏好和时间窗口交织的路线优化问题中，AI 并非 正确的解法——这是一个组合调度问题。你想要学习的模式并不隐藏在数据里；它们是运营部门的人早就知道的显式领域逻辑。

这种情况在各行各业不断上演。2025 年麻省理工学院的一项研究发现，95% 的企业 AI 试点项目未能产生任何可衡量的业务影响，尽管总投资高达 300 至 400 亿美元。最主要的失败原因不是模型差或数据不足，而是团队在 AI 根本不是正确工具的问题上构建了 AI 解决方案。

科技行业的传统智慧——快速行动、尽早发布、建立护城河——在模型改进曲线的特定阶段会在 AI 领域变得致命。2023 年，数十个团队围绕一项单一能力建立起了可行的业务：让用户上传 PDF 并提问。随后，OpenAI 在 ChatGPT 中添加了原生文件上传功能。这些业务的死亡不是因为行动太慢，而是因为它们行动得太早。

这并非孤立事件，而是构建在快速迭代基础模型之上的结构性特征。大多数发布时机框架是为速度较慢的技术曲线设计的。你过去用于决定何时发布 SaaS 功能的框架并不适用于 AI——输入不同，失败模式也完全不同。

你支持团队的一位高级 CSM 花了一个周末搭建了一个内部 Slack 机器人。他们自己编写了系统提示词（system prompt），并将其指向了公开文档、Zendesk 已解决工单的导出数据以及变更日志（changelog）。六周后，它能回答团队以前需要手动输入的约 40% 的一级（tier-1）问题。你的工程团队架构中没人知道它的存在。当平台团队第一次发现它时，安全部门的人会问，为什么一个服务账号会在凌晨 3 点访问 Zendesk 的 API。

默认的反应是恐慌。封锁 API 令牌。发送一封关于未经授权 AI 的全公司邮件。在下一次治理审查中增加一张幻灯片。然后承诺平台团队将在下个季度，按照正式的路线图（roadmap）构建“官方版本”。

这种反应忽略了实际发生的情况。CS 团队并没有擅自行动 —— 他们构建了一个工程团队尚未交付的产品的可用原型。他们拥有真实的反馈数据、真实的提示词迭代周期和真实的用户反馈。而你的平台路线图里这些都没有。将这个机器人视为合规违规行为，会丢掉你的 AI 计划今年能获得的最准确的优先级信号。

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

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

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

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

你的模型在留存测试集上达到了 91% 的准确率。p95 延迟低于 200ms。与之前的规则系统相比，错误率降低了 40%。从每一个技术指标来看，这个项目都是成功的。六个月后，领导层取消了它。

这不是假设。80% 的 AI 项目未能实现预期的商业价值，而这些失败的大多数并不是由于模型性能不足。它们源于工程师所衡量的内容与决策者所能理解的内容之间的鸿沟。技术团队使用的语言，高管无从评估——在缺乏可理解信号的情况下，领导层默认持怀疑态度。

指标翻译问题并非沟通软技能，而是一门工程纪律，而大多数团队把它当作可选项，直到融资审查前夕才想起来。

2025 年，42% 的公司放弃了大部分 AI 计划，高于一年前的 17%。令人震惊的不是放弃率，而是延迟。这些项目中的大多数在最终被叫停之前，已经处于各种“快准备好了”的阶段长达 6 到 12 个月。演示是成功的。指标看起来合情合理。团队投入了大量精力。于是，这个功能在证据早已指向关停之后，依然继续徘徊，消耗着预算和信誉。

AI 领域最难的产品决策不是构建什么，而是何时停止构建一个技术上可行但实际上无用的东西。