跳转至

AI 产品经理面试指南

AI 产品经理面试指南

同样准备了一个月，为什么有人面试时侃侃而谈，有人一遇到「没准备过」的题就卡壳？差别不在背了多少题，而在答题框架是否可复用。AI 产品经理的面试考点高度稳定，翻来覆去就是概念题、产品设计题、案例题、行为面这几种——掌握题型结构与答题套路，新题也只是旧框架的变体。

本文按题型给出典型题与答题框架：先记结构，再把自己的经历填进去。

题型一：概念题（考察技术认知）

概念题考的不是背诵定义，而是你能不能把技术概念翻译成产品决策。面试官真正想听的是：这个技术选择背后的权衡是什么。

1. RAG 与模型微调有什么区别？各自适用什么场景？

考察点： 是否理解「知识注入」与「行为塑造」的本质差异，以及成本、更新频率、可解释性上的工程权衡。

答题要点：

  1. 一句话区分：RAG 是给模型「查资料的权限」，微调是改变模型「做事的方式」——前者解决「不知道」，后者解决「做得不像」
  2. RAG 适用：私有知识问答、知识频繁更新、需要引用可验证的场景；检索不到就是检索不到，问题定位得清楚
  3. 微调适用：行为稳定、格式统一、风格一致的场景，比如固定话术、输出 JSON、特定领域语气
  4. 关键权衡：微调成本高（数据标注 + 训练 + 评估），更新一次要重跑；RAG 更新只需换文档；微调不能可靠注入新知识，还可能带来遗忘
  5. 产品经理结论：知识类需求先上 RAG，行为类需求考虑微调，两者常组合使用——RAG 管知识，微调管表达

追问：

  • 知识库文档经常改版，你的方案会怎么变？
  • 微调后效果变差，你如何定位是数据问题还是训练问题？

相关阅读： RAG、大模型基础

2. Prompt 工程与模型能力边界是什么关系？

考察点： 是否把 prompt 当成「万能钥匙」——测试对能力边界的清醒认知，以及「先验证再设计」的习惯。

答题要点：

  1. 关系定性：prompt 是撬动模型已有能力的杠杆，不是创造能力的魔法——边界之外，prompt 再精巧也无效
  2. prompt 能做的：结构化的指令、few-shot 示例、思维链引导，把模型已有的能力稳定地激发出来
  3. 边界内的问题：检索不到的资料、训练截止后的知识、超出推理能力的任务——这些要靠 RAG、工具调用、换模型解决
  4. 过度引导的反噬：prompt 把模型往特定方向「硬掰」，反而更容易诱发幻觉和答非所问
  5. 产品动作：需求落地前先用 Playground 验证「模型到底能不能做到」，再决定写 prompt、加检索还是砍需求；同时把 prompt 当代码管理（版本化、评测、回归）

追问：

  • 给同一产品的所有场景写一套 prompt，还是分开管理？
  • 模型升级后提示词需要跟着改吗？

相关阅读： 提示词工程、模型能力与边界

3. 什么是 Agent？和传统自动化流程差在哪？

考察点： 是否理解「决策主体」的变化——从规则到模型的跃迁，以及由此带来的可控性代价。

答题要点：

  1. 定义：Agent = LLM + 工具 + 循环决策，能从「回答你的问题」到「帮你把事情做完」
  2. 与传统自动化对比：传统流程是预先编排的固定步骤，输入可枚举、行为可预期；Agent 由模型自主规划，能处理开放式任务
  3. 关键差异在决策主体：规则决定「遇到 A 就做 B」，Agent 决定「下一步该做什么」——灵活但不确定
  4. 产品代价：不可预期意味着必须设计任务边界、进度可见、确认节点、失败兜底（最大步数、超时、人工接管）与成本上限
  5. 务实边界：复杂长程任务成功率有限，商用场景普遍是「工作流 + 人工复核」，别一上来就全自动多 Agent

追问：

  • Agent 的哪一步必须人工确认？为什么？
  • 如何判断一个任务适合 Agent 而不是固定工作流？

相关阅读： Agent 与工作流

题型二：产品设计题（考察落地能力）

产品设计题最忌「想到哪说到哪」。面试官看的不是方案多炫，而是你有没有一套可复述的结构，以及有没有主动谈「出错怎么办」。

1. 从 0 设计一个 AI 功能/产品，你怎么做？

考察点： 结构化思维 + 对 AI 不确定性的敬畏。用不用 AI 产品开发生命周期（CC/CD） 框架作答是明显的分水岭。

答题要点：

  1. 用户场景：先回答「给谁、解决什么问题、在什么任务里用」，别一上来就谈模型选型
  2. 能力边界 + 验证方案：用 Playground 快速试「模型现在能不能做到」，把需求钉在能力范围内，再做最小原型验证用户真的需要
  3. 评测 + 兜底：从第一天建种子评测集（20 条起步）、定线上指标（采纳率、任务完成率、重试率），并设计出错路径——置信度阈值降级、人工接管、「不知道」的标准回答
  4. 商业化：核算 token 成本与人工抽检成本，确认毛利与定价撑得住
  5. 收束：按代理权分级切版本——v1 高控制低代理（只做推荐/草稿），v2 逐步放权（给建议方案），v3 高代理（自动执行 + 人工兜底）；每升一级拿评测数据「赚取」代理权，而不是一次性授满

追问：

  • 你的 v1 至少要跑出什么数据，才敢放开到 v2？
  • 用户不信任 AI 的建议，你怎么设计？

相关阅读： AI 产品开发生命周期（CC/CD）

2. 一个 AI 需求找上门，你怎么决定做不做？

考察点： 通用需求判断力 + AI 特有风险意识，是否把「技术可行」排在「用户价值」前面。

答题要点：

  1. 先过通用三维度：频率与强度（高频 × 强烈）、用户规模（影响多少人）、付费潜力（愿不愿意掏钱）——三维度都不高的需求，AI 做得再炫也不做
  2. 再做 AI 特判：模型能不能做到（Playground 快速验证）、数据从哪来、幻觉风险能不能兜住、反馈怎么回流
  3. 算成本：每次调用都有 token 成本，高频场景成本失控比功能失灵更致命
  4. 留替换空间：把模型调用封装成接口，别把 prompt 写死在业务里——换模型等于换能力边界与成本结构
  5. 给结论与路径：明确「做 / 不做 / 降级做」，说清验证方式与验收标准，一句话回答「为什么现在做」

追问：

  • 三维度打分不错但 AI 幻觉风险高，你怎么办？
  • 如果技术负责人说「模型做不到」，你怎么回应？

相关阅读： 需求分析

题型三：案例题（考察产品 sense）

案例题考察的是日常积累：有没有真的用过、拆过、复盘过产品。没有积累靠临场编，一问细节就露馅。

1. 拆解一个你常用的 AI 产品

考察点： 能否把产品还原成决策过程，而不是只夸「好用」。

答题要点：

  1. 选一个你真用过、能说清细节的产品——过于大众的撞题率高，过于冷门的自己讲不清
  2. 按产品拆解框架走：定位（帮谁/解决什么/为什么现在做）→ 任务场景 → 技术方案（为什么这么选）→ 交互与体验（如何建立信任、出错如何兜底）→ 商业（收费/成本/护城河）→ 成败归因
  3. 每个环节给「一句话判断 + 一个证据」，证明不是背的
  4. 至少提一个「如果重来我会怎么改」，体现产品 sense
  5. 主动区分「事实」与「推测」，标注信息日期

追问：

  • 它换成更便宜的模型会怎样？
  • 你觉得它下一步会往哪走？

相关阅读： 产品拆解

2. 讲一个 AI 产品失败的案例，并复盘

考察点： 失败归因能力 + 兜底设计意识。没做过也没关系，讲行业案例，关键在于归因深度。

答题要点：

  1. 选一个「上线后输出失控/幻觉」类案例（公开可查的客服机器人、AI 搜索等），一句话讲清发生了什么
  2. 归因到系统设计而不是「模型不行」：上线前没有代表性评测集、错误直接展示给用户（无兜底）、代理权给太快（跳过人工确认直接自动执行）
  3. 给出改进路径：种子评测集 + 失败案例库回填、置信度阈值/人工接管、把版本降回 v1 重新用数据「赚代理权」
  4. 拔高收尾：评测与兜底是 AI 产品的默认配置，不是上线后补的补丁

追问：

  • 如果错误率一直降不下来，你会在什么情况下选择下线？
  • 这个案例换成你来做，第一步会做什么不同的事？

相关阅读： 评估与评测、AI 产品开发生命周期（CC/CD）

题型四：行为面（考察经历与素质）

行为面考的是真实经历，框架只有一条：STAR——情境（Situation）→ 任务（Task）→ 行动（Action）→ 结果（Result），最后加 1-2 句「从中学到什么」。结果要具体（数字、时间、对比），别停在「效果不错」。

1. 讲一次你用数据/评测推动决策的经历

考察点： 数据思维与影响力——你是否把决策建立在证据上，而不是资历或感觉上。

答题要点（STAR）：

  1. 情境：当时的项目状态，为什么需要一个决策（上线新模型？改 prompt？砍功能？）
  2. 任务：你要推动什么，阻力是什么（研发觉得没必要？业务急着上？）
  3. 行动：怎么拿数据——建种子评测集、新旧对照跑分、每周人工抽检、定义线上指标
  4. 结果：决策被采纳或修正，带来什么变化（指标提升、成本下降、避免一次事故）
  5. 学到什么：没有评测就没有发言权；数据说服比职位说服更持久

追问：

  • 评测集只有 20 条，会不会以偏概全？
  • 如果数据显示你的方案错了，你会怎么做？

相关阅读： 评估与评测

2. 讲一次「AI 能力边界」让你调整需求的故事

考察点： 是否敬畏能力边界——是硬扛着上线，还是把约束当设计输入。

答题要点（STAR）：

  1. 情境：原需求是什么，看起来多合理（比如「自动总结全部历史对话」）
  2. 任务：你需要在期限内交付
  3. 行动：先用 Playground 小样验证，发现模型做不到（长上下文遗忘、复杂推理不稳），于是调整需求——重切边界、拆成 v1 先做能做的部分、或改交互让用户补充信息
  4. 结果：低配版如期交付、体验可控，等高配方案在模型升级后补上
  5. 学到什么：能力边界不是障碍，是需求的一部分；把「模型做不到」翻译成「产品怎么做」，才是 AI PM 的价值

追问：

  • 你怎么向业务方解释「砍需求」？
  • 什么情况下你会选择换模型而不是改需求？

相关阅读： 模型能力与边界

题型五：反问与报备（容易被忽略）

「你有什么想问的？」不是客套——反问的质量直接暴露你的专业水位。问对了，比多答一道题更加分。

值得反问面试官的问题

  1. 「团队如何做评测？有种子评测集和线上指标吗？」——传递：我懂 AI 产品不靠拍脑袋
  2. 「模型多久升级/换一次？升级流程是怎样的？」——传递：我关心能力边界与替换成本
  3. 「线上出错怎么兜底？有没有人工接管机制？」——传递：我有兜底思维
  4. 「这个岗位和研发/算法怎么协作？谁定义评测标准？」——传递：我关心落地，不是只画饼
  5. 「团队踩过最大的坑是什么？」——传递：你想了解真实情况，也给面试官一个表达机会

报备原则

面试中不懂装懂是大忌——AI 迭代太快，面试官也是从业者。承认「这块我还没实操过，我的理解是……」并给出学习计划，远比硬编一个方案加分。

面试准备清单

一周速成（应急）

  1. 过一遍本页概念题，把 3 个技术概念讲到自己能复述
  2. 准备 2 个 STAR 故事（数据推动决策 + 能力边界调整需求），练到能讲 3 分钟不卡壳
  3. 按产品拆解框架完整拆 1 个你常用的 AI 产品
  4. 手写 1 道「从 0 设计 AI 功能」的作答，按 CC/CD 框架走一遍
  5. 想好 3 个反问问题

一个月的节奏

  1. 前两周：按学习路线查漏补缺，重点过 AI 基础与评测方法
  2. 拆解 3-5 个 AI 产品，每个写 500 字复盘，形成自己的「案例库」
  3. 亲手做一次小评测：拿 20 条真实问题建种子评测集并记录过程——「我做过一次评测」远比「我背过评测理论」有说服力
  4. 最后一周：模拟面试 2-3 次，找人追问，练「框架先行」的临场反应
  5. 通用产品基本功不牢的，先看自学产品经理补地基

黑话可以蹭，但要准确

面试用词可以蹭黑话，但必须准确——「RAG」「Agent」「对齐」「幻觉」「思维链」用错了比不用更扣分。出口前先查产品经理黑话速查，确认知道确切含义。

鉴别「伪 AI PM」岗

面试是双向选择。遇到以下信号要警惕——这可能不是 AI 产品岗：

  1. JD 只写「会用 ChatGPT 等 AI 工具」，没有模型能力、评测、数据相关的要求
  2. 面试全程不问你怎么评测、怎么兜底，只问执行细节
  3. 职责全在运营执行层（写文档、催进度、做表格），没有产品决策权

总原则

  1. 框架先行：任何题都先给结构再填细节——「先框架后内容」本身就是产品思维
  2. 数据说话：把决策落到评测指标与样本上，是 AI PM 与普通 PM 的分水岭
  3. 兜底思维：主动讲「出错怎么办」，AI 产品经理的信任感从这里来

来源声明：本文题型分类结构参考破壁BreakingWall 的 AIPM Wiki面试题库板块（CC BY-NC-SA 4.0），题目与解析由本站自行撰写。

欢迎贡献更多典型题与答题框架（见如何参与）。

相关阅读：求职全流程资源（公司、岗位、面经、过来人感悟）见求职专题。

发现错误？想一起完善？ 在 GitHub 上编辑此页！
本页面贡献者：AI-PM Wiki Team
本页面的全部内容在 CC BY-SA 4.0 和 SATA 协议之条款下提供，附加条款亦可能应用