考察点
这是科大讯飞业务技术面的原题,也是 AI 产品岗面试的「国民题」——几乎每家都会以某种形式问。正因为人人都被问,区分度反而大:背答案的人会列一堆名词,干过的人会讲出工作方式的真实变化。面试官想知道的是:你入职之后,是真能用 AI 产品的节奏干活,还是带着传统互联网产品的肌肉记忆,做出一个「假装智能」的功能。这道题没有标准答案,但有明确的扣分项——把差异说成「AI 产品要用大模型」这种废话,或者把 AI PM 描述成「不用懂技术只要懂用户」。追问常落在:AI PM 到底要不要懂技术、懂到什么程度、你觉得自己哪块最强哪块要补。
参考答案
需求验证:先验证「能不能」,再验证「要不要」
传统产品的需求验证,核心是验证用户要不要——做个原型、发版灰度,看转化和留存就知道了,功能本身的确定性很高,按钮点了一定响应。AI 产品多了一层前置的不确定性:模型能不能做到。想做「拍照识题并讲解」,第一问不是用户要不要(肯定要),而是当前模型在这类题目上的准确率够不够撑起一个可用的功能。所以 AI PM 的需求验证动作完全变了:不是画原型,而是拉评测集。我的习惯是,立项前先花一两周收集 200-500 条真实样本,用现成模型跑一遍,看准确率的分布——不是看平均分,是看「有多好」和「有多差」,因为用户体验由最差的那部分决定。验证过不了就换场景或降级方案,这一步能省掉后面几个月的无效开发。传统 PM 没有这个环节,因为传统功能没有「能力边界」这个概念。
技术协作:从「提需求」变成「共建指标」
传统 PM 和研发的关系相对线性:我写 PRD,你实现,验收看功能对不对。AI 产品里这套走不通,因为「对不对」本身没有确定答案——模型输出是概率性的,你说「效果不好」,算法问你「不好是多少、在哪类 case 上不好」,答不上来协作就卡死了。所以 AI PM 的日常协作里多了几件传统 PM 不干的活:定义评测指标和验收口径,和算法对齐「什么叫达标」;建 badcase 库,把用户反馈按失败类型归因——是数据问题、能力问题还是 prompt 问题,不同类型找不同的人解决;参与数据工作,标注规范、数据量评估经常要 PM 牵头,因为 PM 最懂业务上要什么分布。一句话概括:传统 PM 交付的是需求文档,AI PM 交付的是需求文档加一套「让模型可以被持续改进」的机制。
评估指标:从单一业务指标到双层指标
传统产品看业务指标基本够用:转化、留存、GMV。AI 产品必须是双层结构——底层是模型能力指标(准确率、召回、幻觉率、延迟),上层是业务指标。两层都得看,而且要会拆因果:留存掉了,是模型质量掉了,还是流量结构变了?只埋业务点位不埋模型指标,出问题根本没法定位。另一个真实差异是评估成本高:传统功能 AB 实验看两周转化就行,AI 功能上线前还得做离线评测,上线后 AB 之外还要抽检输出质量,因为指标涨了但输出变傻的情况真实存在——比如模型学会说车轱辘话拖长会话,会话时长涨了,实际体验烂了。
上线迭代:上线不是终点,是数据回流的起点
传统功能上线后,迭代靠新需求驱动。AI 产品上线后的第一件事是设计数据回流:用户的哪些行为(采纳、复制、点踩、追问)能作为质量信号收回来,进 badcase 库,再变成下一版 prompt、评测集或微调数据。这套循环跑通了,效果是复利;跑不通,模型上线什么样半年后还是什么样,而用户预期是在涨的,等于持续退步。所以 AI PM 的排期表里永远有一项传统 PM 没有的固定开支:评测和 badcase 处理的持续人力,我一般按算法迭代周期固定预留,不预留的项目最后都会还这笔债。
核心技能的差异
落到人身上,我认为差三件:一是技术判断力,不需要会训模型,但要能判断「这个需求是 prompt 能解决的、要微调、还是现阶段做不了」,判断错了整个排期都是假的;二是评测设计能力,把「效果好」翻译成可执行的指标和评测集,这是 AI PM 最硬的活;三是概率思维,接受产品里有一部分输出就是错的,把精力花在管理错误率、设计兜底上,而不是追求零错误——追求零错误的人会把团队拖死。
可能的追问
- AI PM 需要会写代码吗? 答:不需要以写代码为生,但需要「能自己动手验证」的水平——我的标准是会写 prompt、会调 API 跑批量测试、会用脚本处理几百条数据看分布。到不了这个程度,评测和 badcase 分析就得全程求人,节奏被卡在别人手里。
- 你觉得自己在 AI PM 技能上最强的短板是什么? 答:诚实回答 + 给补法,例如对模型训练细节的理解还停在「知道每个环节在干什么、影响什么」的层面,到不了和算法讨论超参的程度,补法是跟完一次完整的微调项目,把数据清洗到效果回归全链条亲手过一遍。
- 传统 PM 转 AI PM,最容易踩的坑是什么? 答:把模型当成功能稳定的黑盒——按传统习惯验收「功能对不对」,而不是验收「能力的分布」;上线后被长尾 badcase 打懵,才发现需求阶段从来没讨论过错误率预算。