9 篇博文 含有标签「product-strategy」

十四个月前，在你公司的某个角落，一位财务总监和一位平台负责人签署了一份为期数年的算力加速器资源承诺协议。他们根据前一个季度的遥测数据构建了一个峰值负载模型，谈到了比按需计费价格低 40% 到 70% 的折扣，并锁定了集群的规格——而你现在的产品路线图必须去适应这个规格。产品团队中没有人参与过那次会议。应用工程团队中也没有人见过那份电子表格。这份合同具有法律约束力，只有在履行承诺的前提下才能享受折扣，而它买下的容量边界，现在成了产品经理们正在规划的每一个第三季度功能的隐形天花板。

大多数团队直到第二年才会察觉到这个差距：容量合同本质上是路线图决策，但它们是由那些看不见路线图的人，使用不包含路线图信息的输入数据做出的。产品“三人组”认为他们正从一个清晰的优先级积压任务中挑选功能。财务部门认为他们正在优化一个固定的预算边界。在各自的语境下他们都是正确的，而冲突则会在规划会议上显现——当架构师提议为新的助手功能使用 700 亿参数模型时，平台负责人会平静地说，集群使用率已经达到 85%，如果不挤掉其他项目，这个模型根本放不下。

2026 年初，Atlassian 报告了一件公司历史上从未发生过的事情：企业席位数量下降。对于一家增长模式完全依赖于扩张收入（随着客户组织增长而销售更多席位）的公司来说，这是一个结构性警报，而非偶然波动。直接原因并非客户流失或产品失败。而是 Atlassian 自身的 AI 功能大幅提高了团队效率，以至于完成同样的工作量所需的席位更少了。

这就是 AI 效率悖论：构建一个真正为用户节省时间的功能，你可能正在训练他们减少对你产品的使用。你的 AI 越有用，你的定价模型崩溃得就越快。

2024 年初，谷歌的图像生成工具开始产生历史上不准确的结果，应对之策来得迅速：暂停所有人物图像生成功能。这一暂停持续了数月。想将该功能用于合法用途的用户毫无选择。等到功能重新上线时，采用率也很低——仅对一小部分订阅用户开放，受到严格限制，且声誉包袱尚未完全卸下。过度纠正本身成了一个新问题。

这是大多数团队在 AI 功能公开失败后都会掉入的陷阱。直觉没错——如果某个东西在造成伤害，就应该停止——但执行方式却错了。彻底下架功能，或者堆砌铺天盖地的护栏让其形同虚设，并不能重建信任。这只会表明你不知道如何负责任地运营 AI，也无法分辨那 0.1% 的错误输出与 99.9% 的正常输出之间的区别。

一个基于前沿模型的聊天功能，单次对话成本大约是 30 美分。而同功能的蒸馏版本，单次对话成本大约只有 0.3 美分。这并不是同一个产品的两种实现方式，而是两个截然不同的产品。它们有着不同的免费层级经济模型、不同的获客成本、不同的市场定位以及不同的竞争护城河。如果一个团队只是将蒸馏版本当作“更便宜的同款功能”发布，那就白费了这一招。

大多数工程组织仍将蒸馏视为研究团队的优化任务，认为是在功能“完成”后，为了挤出推理成本而对已经按前沿模型规格设计好的东西进行的后期处理。这种理解在数量级上就是错误的。Teacher 模型（教师模型）的选择、Student 模型（学生模型）的选择、用于评测 Student 的评估套件，以及 Student 最终部署的产品界面，本质上都是产品决策。它们决定了你同意放弃哪些能力、你为哪种流量形态进行设计，以及你正在开启哪种价格底线。如果把这些交给研究团队去针对 MMLU 进行优化，你最终发布的模型虽然在榜单上表现优异，但对产品本身毫无意义。

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

成本仪表盘本身就很有说服力。60% 的流量是“简单”的，快速评估显示较小模型在全局准确率指标上仅落后几个百分点，路由层在同一周内通过特性开关（feature flag）上线。成本曲线开始下行。财务部皆大欢喜。团队继续推进后续工作。

没有人注意到的是，周二下午走廉价路径、周三上午走昂贵路径的客户，现在实际上在使用两种不同的产品。这两个模型的失败方式不同。格式化方式不同。拒绝的内容不同。它们以不同的默认逻辑处理歧义、追问和部分输入。从客户的角度来看，助手一夜之间失忆了，而且没人能告诉他们原因——因为在公司内部，这次变更被归档为一次 FinOps 的胜利，而不是一次产品发布。

你的 AI 搜索刚刚上线。它速度快、支持对话，能处理过去基于关键词的搜索从未能胜任的复杂查询。功能评审一片好评，发布文章广泛传播。然而两周后，工单开始涌入——不是关于搜索的，而是关于客服组件、帮助文档和通知中心的。没有人动过这些地方。但用户突然愤怒了。

欢迎来到 AI 能力棘轮的世界。当你上线一个可以令人信服地展示智能的功能，就已经永久性地重新校准了用户对整个产品的可接受标准。棘轮咔哒一声向上拨动，永不回头。

这一模式是 AI 产品开发中讨论最少的失败模式之一。团队们庆祝各自的功能发布，却没有意识到他们正在将预期债务分摊给每一个什么都没有发布的团队。

Token 成本在两年内下降了 280 倍。企业 AI 账单却上涨了 320%。如果这听起来像个悖论，那是因为你还没有仔细研究按 Token 计费如何与那些真正让 AI 产品有价值的功能相互作用。

最有用的 AI 工作流——深度研究、多步推理、迭代优化、智能体工具调用——恰恰是消耗最多 Token 的。在纯按用量计费模式下，你最好的功能就是你最大的利润杀手。这不是暂时的规模化问题，而是 AI 创造价值的方式与计费方式之间的结构性错配。

你的 AI 功能拥有 12,000 名月活跃用户。参与度图表呈上升趋势。演示每季度依然能让利益相关者印象深刻。而你的用户正悄悄绕过它。

这是产品团队会逃避数月——有时甚至数年——的下线决策，因为每个表面指标都显示该功能运行良好。仪表盘显示了采用率。但它没显示的是，支持工程师在将每个 AI 生成的摘要转发给客户之前，都在手动纠正其中的三分之一；或者高级用户已经发现，点击三次“重新生成”就能产生可以接受的输出，并默默接受了这种工作流负担。