2 篇博文 含有标签「ai-product-management」

走进一个季度业务复盘（QBR）会议，问问谁的名字写在那个 AI 功能旁边。看看会发生什么。PM 指向平台团队。平台团队指向编写评估工具集（eval harness）的研究工程师。研究工程师指向那个一直在发关于成本图表邮件的 FinOps 分析师。FinOps 分析师又指回了 PM。四个人，一个功能，零个负责人。评估分数已经连续六周下滑，却无人排查，因为监控仪表盘躺在一个上次更新还是发布次日的 Notion 页面里。

这是 2026 年各组织交付 AI 功能最可预见的结果。该功能是由一个攻坚小组（tiger team）发布的，而该小组在发布新闻稿发出的那一刻就解散了。埋点是由一个没有产品授权的基础设施团队生搬硬套上去的。Prompt 是代码库中的一个 prompts/v3.txt 文件，其 Git blame 记录分散在九个工程师身上，谁也不记得为什么第 47 行要写那些内容。面向用户的入口由一位 PM 负责，但他的 OKR 在两个季度前就已经转向了下一个发布项目。这个功能在技术上处于生产环境，技术上有负责人，但在结构上已经沦为孤儿。

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