一个典型的工作日长什么样
拿我在应用层 AI 产品团队的一天举例。早上第一件事不是看邮件,是看数据看板:昨天的调用量、成功率、用户满意度(点赞点踩率)、平均响应时长,还有成本曲线——昨天调用量涨了 20%,是真实增长还是某个客户在刷接口,这个要先搞清楚。然后是晨会,跟传统团队最大的区别是晨会上有算法工程师,议题经常不是「功能做完没有」,而是「这轮效果提升多少、还剩哪几类 badcase」。
上午的大块时间通常给效果相关的工作:抽 50 条昨天的真实用户对话过一遍,把翻车 case 分类标记——是检索没召回、模型理解错意图、还是回答格式不对。这个活很枯燥,但它是 AI 产品经理最不可替代的工作,后面细说。下午一般是方案和对齐:写新功能的需求文档、跟设计对交互、跟算法讨论「用户要的更专业的回答」到底卡在哪一层。傍晚常常是临时插进来的事:老板转发了一个竞对新功能让评估要不要跟,或者线上出了个模型答非所问的舆情 case 要紧急处理。
特有的活之一:badcase 分析是日常主食
传统 PM 看数据看转化率、留存率;AI 产品经理除此之外,每天要花相当时间做 badcase 归因。模型效果的改进不是算法闷头调参就行的,得有人把线上翻车的 case 捞回来,分类、定优先级、判断归因层。比如教育问答产品,用户问「这道数学题怎么解」,模型答错了——可能是题库检索没命中(数据问题),可能是题面拍照 OCR 错了(工程问题),也可能是模型推理能力不够(模型问题)。三种归因对应三种完全不同的解决方案和负责方。这个活算法工程师干不了,因为他不知道业务上哪类 case 严重;运营干不了,因为判断不了归因层。它就是为 AI 产品经理量身定做的。
特有的活之二:跑评测、定标准
传统功能上线前测试跑用例,过了就发。AI 功能上线前,PM 要组织效果评测:拿标注好的评测集让模型跑一遍,看指标达不达线。比如一个写作助手的新版本,你要定:语法正确率不低于 98%、风格符合度人工抽检 85 分以上、单次生成成本不能超过 0.05 元。达标才放行,不达标就打回去并附上 badcase 清单。这意味着 AI 产品经理要维护两样传统 PM 没有的东西:一个持续更新的评测集,和一套随业务演进的效果标准。版本迭代时对比的不是「功能列表变了吗」,而是「同样 500 条评测题,分数从 82 涨到 87 没有」。
特有的活之三:成本是每天的事
传统 SaaS 的边际成本接近零,多一个用户几乎不花钱;AI 产品每次调用都在烧钱,所以成本意识渗透在每天的工作里。设计功能时要想:这个需求真的需要最大的模型吗,换小模型效果掉多少、成本省多少?豆包、Kimi 这些产品免费给用户用,背后是产品团队把模型路由、缓存、提示词压缩这些降本手段抠到了极致。我见过一个团队把高频问题做缓存加小模型分流,成本直接砍掉 60%,效果损失不到 3 个点——这种方案就是 PM 牵头设计的,因为它本质是产品策略不是纯技术问题。
跟传统 PM 的差异总结
归纳一下:传统 PM 的日常重心是「定义功能、推进开发、看转化数据」;AI 产品经理的日常重心是「定义效果标准、分析 badcase、平衡效果和成本」。写 PRD 的时间会少一些,看 case、跑评测的时间多出来一大块;协作对象里多了算法;确定性思维要换成概率思维——永远有模型搞不定的输入,你的工作是让搞不定的部分别伤到用户体验和业务底线。另外还有个隐性差异:AI 产品经理要花时间跟踪模型能力的进展,上个月做不了的功能这个月可能就能做了,这件事传统 PM 完全不用操心。
不同阶段的日常也不一样
补一句诚实的:上面是产品已上线的状态。0 到 1 阶段,日常更像传统 PM——做调研、定场景、验证可行性,只是验证手段从「做个 demo 给用户看」变成「拿 50 个真实问题测模型能不能答」。而 1 到 10 阶段,评测和 badcase 的比重会越来越大。能区分阶段来讲,才说明真在团队里待过。