Ai产品经理面试-案例分析与估算题
拆解现有产品、估算成本与收益、设计指标体系。
模型准确率从 90% 提升到 95%,对业务价值如何量化?
难度:⭐⭐⭐ 进阶 出现频率:高,常见于有算法/数据背景的团队或 B 端 AI 产品岗
考察点
•
能否把技术指标翻译成业务语言,而不是停留在"准确率提升了 5 个百分点"
•
是否会用基线 → 拆解 → 估算 → 验证的框架做价值量化
•
是否理解准确率提升的边际收益递减,以及不同业务场景下"5%"的含义完全不同
💤
参考答案
一句话核心:准确率提升的价值 = 在错误成本 × 业务量 × 错误率变化的框架下,算清"少错了多少、每少错一次值多少钱",再减去模型升级成本。
第一步:明确"准确率"的定义
面试中先澄清口径,体现严谨性:
#FVQkckyXeinz text { white-space: pre; }#FVQkckyXeinz .fb0 { stroke: var(--N900-FG, 0.15); }#FVQkckyXeinz .fb0 {stroke: rgba(31,35,41, 0.15)}#FVQkckyXeinz .fx0 { stroke-miterlimit: 10; }#FVQkckyXeinz .fx0 {stroke-miterlimit: 10}#FVQkckyXeinz .fa1 { fill: rgb(187, 191, 196); }#FVQkckyXeinz .fa1 {fill: rgb(187, 191, 196)}#FVQkckyXeinz .fx1 { font: 400 12px MonospacedNumber, LarkHackSafariFont, LarkEmojiFont, LarkChineseQuote, -apple-system, BlinkMacSystemFont, "Helvetica Neue", Tahoma, "PingFang SC", "Microsoft Yahei", Arial, "Hiragino Sans GB", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"; }#FVQkckyXeinz .fx1 {font-style: normal}#FVQkckyXeinz .fx2 { text-anchor: middle; }#FVQkckyXeinz .fx2 {text-anchor: middle}#FVQkckyXeinz .fx3 { dominant-baseline: central; }#FVQkckyXeinz .fx3 {dominant-baseline: central}#FVQkckyXeinz .fx4 { stroke: none; }#FVQkckyXeinz .fx4 {stroke: none}#FVQkckyXeinz .fc0 { fill: var(--text-caption); }#FVQkckyXeinz .fc0 {fill: #646a73}#FVQkckyXeinz .fa2 { fill: var(--text-link-disabled); }#FVQkckyXeinz .fa2 {fill: rgb(187, 191, 196)}#FVQkckyXeinz .fx5 { font: 400 13px MonospacedNumber, LarkHackSafariFont, LarkEmojiFont, LarkChineseQuote, -apple-system, BlinkMacSystemFont, "Helvetica Neue", Tahoma, "PingFang SC", "Microsoft Yahei", Arial, "Hiragino Sans GB", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"; }#FVQkckyXeinz .fx5 {font-style: normal}#FVQkckyXeinz .fx6 { text-anchor: start; }#FVQkckyXeinz .fx6 {text-anchor: start}#FVQkckyXeinz .fx7 { dominant-baseline: alphabetic; }#FVQkckyXeinz .fx7 {dominant-baseline: alphabetic}#FVQkckyXeinz .fc1 { fill: rgb(0, 0, 0); }#FVQkckyXeinz .fc1 {fill: rgb(0, 0, 0)}#FVQkckyXeinz .fb1 { fill: var(--N900-FG, 0.15); }#FVQkckyXeinz .fb1 {fill: rgba(31,35,41, 0.15)}#FVQkckyXeinz .fb2 { fill: rgb(209, 217, 224); }#FVQkckyXeinz .fb2 {fill: rgb(209, 217, 224)}#FVQkckyXeinz .fa3 { fill: var(--bg-body); }#FVQkckyXeinz .fa3 {fill: #fff}AB1234需澄清项准确率 vs 精确率 vs 召回率按什么粒度统计基线场景为什么重要90%→95% 可能是精确率提升(少误杀),也可能是召回率提升(少漏检),业务含义不同按请求、按用户、按订单?不同粒度下 5% 对应的绝对数量差很大是整体准确率还是某个关键子场景的准确率
第二步:拆解业务影响链路
代码块
Plain Text
模型输出 → 人工/系统决策 → 用户行为 → 业务结果(收入/成本/风险)
按场景举例:
代码块
Plain Text
场景 A:智能客服意图识别(90%→95%)
错误一次 ≈ 转人工或用户流失
价值估算:
日请求量 100 万 × 错误率从 10% 降到 5% = 每天少错 5 万次
假设 30% 转人工,单次人工成本 3 元 → 日省 5万×30%×3 = 4.5 万元/天
再叠加用户流失挽回(需用 A/B 实验验证)
场景 B:内容审核(90%→95% 精确率)
提升的是"误杀率"下降,价值在于减少优质内容被错误拦截
价值 = 少误杀条数 × 单条内容预期 GMV/曝光价值
场景 C:信贷风控(90%→95% 召回率)
提升的是"漏放"减少,价值 = 少漏放笔数 × 单笔预期坏账损失
第三步:建立量化公式
代码块
Plain Text
其中:
•
Δ错误数 = 业务量 × (旧错误率 - 新错误率)
•
单次错误成本需分 direct cost(人工、赔付)和 indirect cost(流失、品牌)
•
模型升级成本 = 算力 + 标注 + 研发人天 + 延迟增加带来的体验损失
第四步:给出结论框架(而非精确数字)
#HaXmaTEWCXcb text { white-space: pre; }#HaXmaTEWCXcb .fb0 { stroke: var(--N900-FG, 0.15); }#HaXmaTEWCXcb .fb0 {stroke: rgba(31,35,41, 0.15)}#HaXmaTEWCXcb .fx0 { stroke-miterlimit: 10; }#HaXmaTEWCXcb .fx0 {stroke-miterlimit: 10}#HaXmaTEWCXcb .fa1 { fill: rgb(187, 191, 196); }#HaXmaTEWCXcb .fa1 {fill: rgb(187, 191, 196)}#HaXmaTEWCXcb .fx1 { font: 400 12px MonospacedNumber, LarkHackSafariFont, LarkEmojiFont, LarkChineseQuote, -apple-system, BlinkMacSystemFont, "Helvetica Neue", Tahoma, "PingFang SC", "Microsoft Yahei", Arial, "Hiragino Sans GB", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"; }#HaXmaTEWCXcb .fx1 {font-style: normal}#HaXmaTEWCXcb .fx2 { text-anchor: middle; }#HaXmaTEWCXcb .fx2 {text-anchor: middle}#HaXmaTEWCXcb .fx3 { dominant-baseline: central; }#HaXmaTEWCXcb .fx3 {dominant-baseline: central}#HaXmaTEWCXcb .fx4 { stroke: none; }#HaXmaTEWCXcb .fx4 {stroke: none}#HaXmaTEWCXcb .fc0 { fill: var(--text-caption); }#HaXmaTEWCXcb .fc0 {fill: #646a73}#HaXmaTEWCXcb .fa2 { fill: var(--text-link-disabled); }#HaXmaTEWCXcb .fa2 {fill: rgb(187, 191, 196)}#HaXmaTEWCXcb .fx5 { font: 400 13px MonospacedNumber, LarkHackSafariFont, LarkEmojiFont, LarkChineseQuote, -apple-system, BlinkMacSystemFont, "Helvetica Neue", Tahoma, "PingFang SC", "Microsoft Yahei", Arial, "Hiragino Sans GB", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"; }#HaXmaTEWCXcb .fx5 {font-style: normal}#HaXmaTEWCXcb .fx6 { text-anchor: start; }#HaXmaTEWCXcb .fx6 {text-anchor: start}#HaXmaTEWCXcb .fx7 { dominant-baseline: alphabetic; }#HaXmaTEWCXcb .fx7 {dominant-baseline: alphabetic}#HaXmaTEWCXcb .fc1 { fill: rgb(0, 0, 0); }#HaXmaTEWCXcb .fc1 {fill: rgb(0, 0, 0)}#HaXmaTEWCXcb .fb1 { fill: var(--N900-FG, 0.15); }#HaXmaTEWCXcb .fb1 {fill: rgba(31,35,41, 0.15)}#HaXmaTEWCXcb .fb2 { fill: rgb(209, 217, 224); }#HaXmaTEWCXcb .fb2 {fill: rgb(209, 217, 224)}#HaXmaTEWCXcb .fa3 { fill: var(--bg-body); }#HaXmaTEWCXcb .fa3 {fill: #fff}ABCD1234维度错误绝对量(百万日请求)错误绝对量(万级日请求)已接近人工水平(98%+)90%10 万/天1000/天2% 错误95%5 万/天500/天更优价值判断减半,价值显著需看单次错误成本是否够高边际价值可能不如优化长尾场景
PM 应给出的结论:不是"95% 一定更好",而是"在 XX 业务量、XX 错误成本假设下,ROI 为正/需实验验证/不如把资源投到召回率"。
追问延伸
•
追问 1:"如果老板只关心准确率数字,你怎么沟通?" → 用一页纸把技术提升映射到业务指标(转人工率、客诉率、审核通过率),建议用 A/B 实验让数据说话,而不是争论百分点。
•
追问 2:"95% 还不够,业务要求 99%,你怎么排优先级?" → 分析剩余错误的分布:是否集中在长尾/边缘 case?是否可以通过规则兜底 + 人工复核达到更高的有效准确率,而不必把模型裸分推到 99%?预期管理与代价拆解见正课 主观任务怎么评 · 90→99 预期管理。
•
追问 3:"准确率提升了,但延迟也增加了 200ms,怎么权衡?" → 把延迟纳入成本侧:用体验指标(跳出率、完成率)量化延迟损失,与准确率收益做净价值比较。
DeepSeek 开始峰谷定价,你怎么看 AI 产品的商业模式?
难度:⭐⭐⭐ 进阶 出现频率:中,常见于战略/商业化方向或偏 ToB 的 AI PM 岗
考察点
•
能否从成本结构、用户行为、竞争格局三个维度分析 AI 产品定价,而非只评论"便宜/贵"
•
是否理解峰谷定价背后的供需逻辑,以及它对产品设计和用户运营的连锁影响
•
能否提出可落地的商业模式框架,而不是泛泛而谈"按量付费"
💤
参考答案
一句话核心:AI 产品的商业模式本质是把不确定的推理成本转化为可预期的用户价值,峰谷定价是成本侧波动向定价侧传导的必然产物,PM 要关注的是它如何重塑产品形态和用户行为。
框架一:AI 产品的成本结构拆解
代码块
Plain Text
总成本 = 模型推理成本 + 基础设施 + 研发摊销 + 数据/标注 + 客户获取
其中模型推理成本有几个独特属性:
•
按 token 线性增长,不像传统 SaaS 的边际成本趋近于零
•
随模型能力升级而上升,同样任务可能因换模型而成本翻倍
•
存在明显的时间波动:算力供需、批处理 vs 实时推理、缓存命中率
峰谷定价的本质:把供给侧的成本波动通过价格信号传导给需求侧,引导用户在低成本时段使用。
框架二:常见 AI 产品商业模式对比
框架三:峰谷定价对产品的影响
对用户侧:
•
非实时任务(文档总结、批量翻译、代码审查)可引导至低谷时段,降低用户成本
•
实时对话类场景难以错峰,需在定价和产品体验间做取舍
•
产品可增加"定时任务""排队处理"等功能承接低谷流量
对 PM 的设计启示:
功能分层:实时 vs 异步,对应不同定价档位
额度设计:订阅包含基础额度 + 峰谷差价返还/积分
成本可视化:让用户看到"此刻调用成本",培养错峰习惯(B 端尤其有效)
缓存与复用:相同 query 命中缓存,成本趋近于零,可不对用户重复计费
框架四:竞争格局下的战略选择
回答收束:峰谷定价不是简单的"晚上便宜",而是 AI 产品从"软件逻辑"转向"资源调度逻辑"的信号。PM 应思考:哪些功能可以异步化?如何用产品机制让用户自愿错峰?如何在定价透明度与商业灵活性之间平衡?
追问延伸
•
追问 1:"如果你是某 AI 写作产品的 PM,你会怎么设计定价?" → 拆用户场景:即时写作(高峰、高单价) vs 批量润色(可异步、低谷);订阅含月额度,超额按量;企业版按席位 + 共享额度池。
•
追问 2:"用户抱怨成本不可预期,你怎么解决?" → 产品侧:成本预估器、消费上限告警、缓存复用;商业侧:包月封顶、预付费折扣;技术侧:小模型路由 + 大模型兜底。
•
追问 3:"开源模型越来越便宜,闭源 API 怎么活?" → 卖的不只是模型:稳定性、合规、工具链、微调服务、SLA;或转向垂直场景的整体解决方案,而非裸 API。
•
追问 4:"订阅、Token、按结果三种,你怎么选?" → 按决策树走:有履约中台优先交易;要账单可预期走订阅/席位+用量;结果可归因再试点按结果;对 C 端慎透传裸 Token。完整树见正课。
如何用 AI 优化生鲜电商的库存周转?
难度:⭐⭐⭐ 进阶 出现频率:中高,零售/供应链/电商方向的 AI PM 岗
考察点
•
能否识别生鲜电商的核心矛盾(高损耗 vs 高缺货),而不是泛泛说"用 AI 预测需求"
•
是否会拆解问题到可落地的 AI 能力点(预测、定价、补货、清仓),并说明优先级
•
是否理解 AI 方案需要与业务约束(保质期、冷链、供应商起订量)结合
💤
参考答案
一句话核心:生鲜库存优化的目标是在保质期约束下最大化销售额、最小化损耗,AI 的价值在于把"凭经验补货"变成"按置信度分层决策"。
第一步:拆解业务问题
生鲜电商库存的核心指标:
💤
核心矛盾:多备货 → 缺货少但损耗高;少备货 → 损耗低但缺货多。AI 要帮你在两者之间找到动态最优。
第二步:AI 能力地图(按落地优先级)
代码块
Plain Text
需求预测 → 智能补货 → 动态定价/促销 → 跨店/跨仓调拨
需求预测(基础层,优先做)
输入特征:
•
历史销量(同期、同星期几)
•
天气、节假日、本地活动
•
价格、促销、竞品动态
•
商品属性(保质期天数、是否爆款)
输出:未来 N 天各 SKU 的销量预测 + 置信区间
PM 关键决策:预测粒度(SKU × 门店 × 天)与数据可得性的平衡。
智能补货(核心价值层)
把预测转化为补货建议,需叠加业务约束:
代码块
Plain Text
建议补货量 = 预测销量 + 安全库存 - 当前库存 - 在途
安全库存 = f(预测不确定性, 保质期, 缺货惩罚, 损耗惩罚)
AI 相比传统规则的优势:安全库存可以按 SKU 动态调整——爆款少备安全库存(周转快),长尾多备(不确定性高)。
动态定价与临期促销(损耗控制层)
•
距保质期剩余 X 天 → 自动触发折扣梯度
•
用强化学习或弹性模型估算"降价幅度 vs 售出概率"
•
与会员推送、首页曝光联动,加速清仓
跨店调拨(网络优化层)
A 店滞销 + B 店缺货 → 触发调拨建议,减少整体损耗。需考虑冷链物流成本和时效。
第三步:效果量化框架
ROI 估算:假设月采购额 5000 万,损耗率从 10% 降到 7% → 月省 150 万损耗;需减去 AI 系统建设 + 算力 + 运营人效成本。
第四步:落地路径与风险
常见坑:
•
只看预测准确率,不看采购员是否采纳(建议再好,人不执行等于零)
•
忽视供应链硬约束(起订量、配送频次),导致建议不可执行
•
冷启动 SKU 无历史数据,需用品类均值 + 快速学习机制
追问延伸
•
追问 1:"预测模型准确率已经 85% 了,但损耗率没下降,你怎么排查?" → 拆链路:预测准但补货建议没被采纳?采纳了但配送不及时?促销规则没触发?用漏斗分析定位瓶颈,而非继续调模型。
•
追问 2:"新品没有历史数据,怎么处理?" → 相似品迁移学习、品类先验、首周人工 + 快速反馈闭环;PM 可设计"新品试销期"产品机制,用小批量快周转验证。
•
追问 3:"AI 建议和采购员经验冲突,采购员不采纳怎么办?" → 产品化:展示 AI 建议的置信度和依据(天气、同期数据);从"替代"转向"辅助",让采购员一键采纳或标注 override 原因,反哺模型。
估算日活 100 万的 AI 对话产品每月模型调用成本
难度:⭐⭐ 常规 出现频率:极高,字节/美团/快手等大厂 AI PM 面经高频出现
考察点
•
能否把开放性问题拆解为可假设、可计算的参数
•
是否理解 token 计费逻辑,以及影响成本的关键变量(模型选型、对话轮次、上下文长度)
•
估算不要求精确,但要求假设合理、计算过程清晰、能主动说明敏感性
参考答案
一句话核心:月成本 ≈ DAU × 人均日对话轮次 × 每轮 token 数 × 每 token 单价 × 30 天,关键是把每个参数拆开并给出合理假设。
第一步:明确产品形态(先问清 or 主动假设)
面试中可主动设定场景,体现结构化思维:
假设这是一个 ToC AI 助手(类似 ChatGPT 移动端),用户以多轮文本对话为主,使用中等能力模型(GPT-4o mini / DeepSeek-V3 级别)。
第二步:参数拆解与假设
注意:一定要分开算输入和输出,因为多数 API 输出 token 单价是输入的 2-4 倍。更精细的估算:
第三步:计算过程
代码块
Plain Text
更精细(区分输入输出):
代码块
Plain Text
月输入 token = 264B × (800/1100) ≈ 192B → 192,000 × $0.15 ≈ $28,800
月输出 token = 264B × (300/1100) ≈ 72B → 72,000 × $0.60 ≈ $43,200
月合计 ≈ $72,000/月 ≈ 52 万人民币/月
给出区间比精确数字更重要:"在以上假设下,月模型成本大约在 50 万 - 130 万 人民币之间,取决于模型选型和用户活跃度。"
第四步:成本构成扩展(加分项)
模型推理不是全部成本,完整估算应提及:
第五步:敏感性分析(体现 PM 思维)
结论:日活 100 万的对话产品,月模型成本通常在数十万到百万人民币量级;成本优化应优先关注上下文长度管理、模型分级路由、缓存三个杠杆。
追问延伸
•
追问 1:"老板觉得成本太高,你会从哪几个方向降本?" → 模型分级(简单问题走小模型)、Prompt 压缩(减少历史上下文)、缓存(高频问题)、限制免费用户轮次/上下文。详见 降本专题。
•
追问 2:"你怎么估算人均 8 轮,而不是 3 轮或 20 轮?" → 说明数据来源:可参考公开 benchmark、同类产品的留存/时长数据、或自己产品的历史数据;给出区间并做敏感性分析。
•
追问 3:"如果加上图片/语音多模态,成本怎么变?" → 图片按张计费(通常远高于文本),语音按秒计费;多模态场景下单次请求成本可能是纯文本的 5-20 倍,需单独估算渗透率和频次。
某功能接入大模型后成本涨了 10 倍,如何降本?
难度:⭐⭐⭐ 进阶 出现频率:高,考察实战思维和成本意识
考察点
•
能否系统性拆解 LLM 成本构成,而不是只说"换个小模型"
•
是否理解降本手段的优先级和 trade-off(效果 vs 成本 vs 延迟 vs 体验)
•
能否给出分阶段落地方案,并说明如何验证降本不显著伤害核心业务指标
💤
参考答案
一句话核心:
先定位成本暴涨的根因,再按"无损降本 → 低损降本 → 结构性优化"三层递进,绝不一上来就砍模型能力。
第一步:成本诊断(先算账再动手)
代码块
Plain Text
总成本 = 请求量 × 单次请求成本
单次请求成本 = f(模型单价, 输入token, 输出token, 是否走RAG/Agent多步调用)
先回答三个问题:
产出:一张成本分布图——按功能、按用户层级、按请求复杂度拆分,确定优化靶点。
第二步:三层降本策略
第一层:无损降本(优先做,效果基本不变)
第二层:低损降本(需 A/B 验证)
模型路由示意:
代码块
Plain Text
用户请求 → 意图分类(极小模型,几乎零成本)
├── 简单(70%) → 小模型处理
├── 中等(25%) → 中模型处理
└── 复杂(5%) → 大模型处理
第三层:结构性优化(产品 + 商业层面)
第三步:落地节奏
第四步:向老板汇报的框架
"成本涨 10 倍的原因主要是 [请求量涨 X 倍 + 单次成本涨 Y 倍]。我计划分三步:
两周内通过 Prompt 优化和缓存降 40%,不影响用户体验;
一个月内上线模型路由,再降 30%,核心指标波动控制在 2% 以内;
季度内评估自部署,目标总成本回到涨前水平的 1.5 倍以内(功能多了,完全回到原水平不现实)。"
追问延伸
追问 1:"模型路由如果误判了,把复杂问题发给小模型,用户体验崩了怎么办?" → 设 fallback 机制:小模型置信度低或用户点"不满意"时自动升级;监控路由准确率,持续优化分类器。
追问 2:"业务方说不能降效果,只要降本,你怎么办?" → 用数据说话:列出每个优化手段的效果损失预估(通常无损手段就能降 40-50%);若仍不够,讨论功能分层或商业定价,把成本转嫁给愿意付费的用户。
追问 3:"缓存会不会导致回答过时?" → 区分场景:FAQ、政策解读等稳定内容适合缓存;实时信息(股价、天气)不缓存或短 TTL;产品侧标注"回答时间"增加信任。
分析一个你最近觉得做得好的 AI 产品,好在哪里?
难度:⭐⭐ 常规 出现频率:高,几乎每个 AI PM 面试都会问到的"开场热身题"
考察点
•
是否真的深度体验过 AI 产品,而不是只看过新闻和评测文章
•
能否用结构化框架拆解一个产品,而不是停留在"好用""智能"这类空泛评价
•
能否体现产品判断力:说出"好"的同时,能不能看出它的取舍和边界
💤
参考答案
一句话核心:
选一个自己真实高频使用的产品,从「解决什么问题 → 怎么用 AI 解决 → 为什么这个设计是对的 → 换我会怎么改」四层展开,不要停留在功能罗列。
第一步:选对产品——避免的三个坑
推荐选自己每周都用、且能说清具体使用场景的产品,哪怕是一个小功能(如某 App 的智能补全、某工具的自动摘要),讲透比讲大更有说服力。
第二步:拆解框架
代码块
Plain Text
用户问题 → AI 的介入点 → 技术方案(推测)→ 产品设计的取舍 → 效果与边界
以「输入法的 AI 联想/续写」为例:
用户问题:打字慢、不知道怎么把话说得体面
AI 介入点:不是全自动代写,而是给 2-3 个候选,用户一键选择——保留了用户的最终决策权
设计取舍:候选数量克制在 2-3 个(选择过多反而增加决策成本);响应必须在几十毫秒内,所以更可能用小模型或缓存,而非每次都调用大模型
效果与边界:好用的场景是短句、日常对话;长文正式写作场景它不会强行接管,这是"知道自己能力边界"的产品克制
第三步:给出"如果是我会怎么改"
这是把分析升华为产品判断力的关键,例:
•
增加"追问式"续写,而不只是补全下一句
•
针对不同联系人调整语气候选(对老板 vs 对朋友)
•
用小模型先做候选生成,置信度低时才升级调用大模型,控制成本
追问延伸
追问 1:"你觉得这个产品有什么做得不好的地方?" → 提前准备 1-2 个具体的体验瑕疵(如候选重复、语气不合适的场景),并说明你会怎么改进,展示批判性思维而非一味夸赞。
追问 2:"如果让你负责这个产品,下一步优先做什么?" → 用"影响用户量 × 提升幅度 × 实现成本"给出一个优先级判断,而不是罗列愿望清单。
追问 3:"你怎么知道它用了 AI,而不是规则/传统算法?" → 从体验特征反推:输出是否有一定的不确定性/多样性、是否能处理没见过的输入、响应速度和成本特征等,展示技术边界认知。
如果你是某 AI 搜索产品的 PM,你的北极星指标是什么?
难度:⭐⭐⭐ 进阶 出现频率:高,常见于搜索/问答类 AI 产品岗位
考察点
•
是否理解北极星指标要同时满足"能代表用户价值"和"能被团队各环节影响"两个条件
•
能否区分 AI 搜索与传统搜索在指标体系上的本质差异(答案型 vs 链接列表型)
•
是否会用指标树而非单一指标解释复杂产品,同时依然能收敛出一个北极星
💤
参考答案
第一步:说明为什么不能照搬传统搜索的指标
第二步:定义候选北极星指标
一次问答解决问题率:用户发起一次提问,得到答案后没有立刻改写问题重新提问、没有转向传统搜索/其他渠道、且在合理时间内没有回来追问同一问题——即视为"被解决"。
可以用三个维度交叉验证是否被解决:
行为信号:是否有追问/改写(负向)、是否复制/分享答案(正向)
显式反馈:点赞/点踩、引用来源是否被点开核实
留存信号:该类问题在后续是否重复出现(说明没被真正解决)
第三步:搭建指标树,支撑北极星指标
代码块
Plain Text
一次问答解决问题率(北极星)
├── 答案质量:准确率、幻觉率、引用可信度
├── 覆盖能力:有答案 vs "不知道"的比例、长尾问题覆盖率
├── 效率体验:首字延迟、完整答案生成时长
└── 信任建立:引用点击率、反馈参与率
这样团队里不同角色都能找到自己的抓手:算法团队盯准确率和幻觉率,工程团队盯延迟,产品团队盯反馈机制设计——但对外汇报时收敛为一个北极星,不让指标体系变成"既要又要"的借口。
第四步:说明指标会随阶段调整
•
冷启动期:先看「覆盖率」和「有答案率」,不追求极致准确,先解决"有没有"的问题
•
成长期:切换到「一次解决率」,开始关注答案质量和用户信任
•
成熟期:叠加「留存/回访率」,证明用户把它当作稳定的信息获取入口而非一次性尝试
追问延伸
追问 1:"这个指标怎么防止被"刷"出来?" → 说明反作弊设计:结合行为信号交叉验证(如同一用户短时间内相似 query 判定为未解决),避免只依赖单一显式反馈(点赞可被诱导)。
追问 2:"如果解决率提升了,但用户量在下降,你怎么看?" → 说明北极星指标不能单独看,要配合「护栏指标」(如 DAU、留存)一起监控;解决率提升可能是筛掉了低质量流量,需要拆分新老用户、不同问题类型来定位原因。
追问 3:"这个指标怎么和商业化目标结合?" → 解决率是先决条件——用户觉得"有用"才会留存和付费;可以进一步拆分「高价值问题解决率」(如专业咨询类)作为商业化转化的前置指标。
AI 功能上线后留存很差，你怎么分诊？
难度:⭐⭐⭐ 进阶 出现频率:中高，AI 功能运营 / 指标体系向面试常见；选题启发自磊叔《100 个问题》Q50、Q61、Q62、Q64
考察点
•
能否把「留存差」当成结果而非病因，用路径/漏斗断点分诊，而不是一上来换模型或改 Prompt
•
是否识破 DAU 假繁荣：新奇冲高、无效活跃、重试膨胀、入口绑架、聚合掩盖
•
能否写清成功与回访事件（队列起点、时桶、行为队列激活假设），并对低频场景改口径
💤
参考答案
一句话：先核对「活跃 / 成功 / 回访」定义，再沿死亡路径找最大断点，用队列（不是总 DAU）验证粘性；动作按断点选型，需要因果再开实验。
第一步：先问「差的是不是同一件事」
面试官说「留存很差」，先澄清三件事，否则后面全是空谈：
分母：有资格用户、曝光用户，还是「点过一次入口就算」？
回访事件：再次登录，还是再次完成同类任务 / 再次采纳？后者才接近 AI 功能价值。
时桶：日 / 周 / 月是否对齐产品自然周期（日活工具 vs 周报助手不同）？
只有 DAU 涨、采纳与队列留存缺失——默认未证明成功（详正课）。
第二步：排除假繁荣
第三步：沿死亡路径找最大断点
代码块
Plain Text
有资格 → 触达 → 理解边界 → 有效启动 → 任务成功 → 用户采纳 → 愿意回访 → 业务结果
哪个跳掉得最狠，就先修哪里（主指标 + 动作方向）：
采纳/回访断点可再套 Agentic UX 的能力 / 交互 / 信任 / 成本时延 / 组织流程归因，避免所有问题开成「再训一版」。
第四步：用队列读图，落到动作
•
获取队列：按首次有效使用日/周看第 1 / 7 / 30 时桶；纵向比产品是否变好，横向看掉崖落在哪一段。
•
行为队列：对比「首周做过 X」vs「没做过」的后续留存；X 应是价值行为（首次被采纳、带工具回执闭环、保存/导出），不要把「多聊几轮」当激活。
•
低频刚需：用周/月时桶，或「下次同类任务到达时仍选 AI」的选择率，别硬用日留存向老板叙事。
场景举例（电商 AI 客服助手）
老板说「上线两周留存很差」。你先发现：DAU 靠开屏推送撑着；有效启动后任务成功率尚可，但采纳率低、转人工升；新队列第 3 天断崖。分诊结论：断点在采纳与信任（一次高后果翻车 + 不可编辑），不是模型「不够聪明」。动作：引用/证据、可撤销确认、低风险场景先建信任；推送降权后看自然队列；改动用正式 A/B 验证一次解决率与转人工护栏。
追问延伸
追问 1：「DAU 很高但留存很差，算不算成功？」 → 不算证明成功。DAU 最多当流量诊断；要同时看有效启动、任务成功/采纳、队列留存、单位有效任务成本与护栏。
追问 2：「你怎么定激活行为？」 → 用行为队列找与后续回访差距稳定且可解释的 X，再用实验验证因果；候选偏采纳/闭环，而非会话轮次。
追问 3：「要不要对标行业 7 日留存 X%？」 → 不要当普适红线。品类、入口强度、ToB 周期差一个数量级都正常；用自家历史队列与对照组建基线，再设上线线与目标线。