Ai产品经理面试-面试准备方法

使用建议

先选一个你真正参与过、能拿出过程证据的项目，按项目深挖整理事实卡和追问。

如果项目需要现场展示，用作品集与 Demo 准备补齐评测集、成本、边界和演示兜底。

AI PM 项目深挖的准备方法

项目深挖不是把项目介绍再讲一遍，而是证明你能对一个 AI 产品结果负责：知道问题从哪里来，为什么选这个方案，自己真正做了什么，如何判断效果，哪里失败过，以及下一次会怎么做得更好。面试官通常会从你的第一段概述中挑一个细节继续追问，准备的目标是让每个关键判断都有事实、证据和边界。

💤

事实：AI 产品的验收不能只写“功能跑通”，还要定义效果、能力边界、数据回流、成本和上线计划

这是AI 产品 PRD 怎么写与现有评测方法反复强调的差异。

建议：把项目准备成“事实卡 + 决策链 + 证据包”，不要背一篇无法应对追问的演讲稿。

一、先做一页项目事实卡

用一页纸把项目压缩成下面这张卡。每个关键结论旁边都放一个证据来源：产品文档、评测记录、埋点、会议决策、原型、上线复盘或你能合法展示的脱敏材料。

#BJlfcPditzCW text { white-space: pre; }#BJlfcPditzCW .fb0 { stroke: var(--N900-FG, 0.15); }#BJlfcPditzCW .fb0 {stroke: rgba(31,35,41, 0.15)}#BJlfcPditzCW .fx0 { stroke-miterlimit: 10; }#BJlfcPditzCW .fx0 {stroke-miterlimit: 10}#BJlfcPditzCW .fa1 { fill: rgb(187, 191, 196); }#BJlfcPditzCW .fa1 {fill: rgb(187, 191, 196)}#BJlfcPditzCW .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"; }#BJlfcPditzCW .fx1 {font-style: normal}#BJlfcPditzCW .fx2 { text-anchor: middle; }#BJlfcPditzCW .fx2 {text-anchor: middle}#BJlfcPditzCW .fx3 { dominant-baseline: central; }#BJlfcPditzCW .fx3 {dominant-baseline: central}#BJlfcPditzCW .fx4 { stroke: none; }#BJlfcPditzCW .fx4 {stroke: none}#BJlfcPditzCW .fc0 { fill: var(--text-caption); }#BJlfcPditzCW .fc0 {fill: #646a73}#BJlfcPditzCW .fa2 { fill: var(--text-link-disabled); }#BJlfcPditzCW .fa2 {fill: rgb(187, 191, 196)}#BJlfcPditzCW .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"; }#BJlfcPditzCW .fx5 {font-style: normal}#BJlfcPditzCW .fx6 { text-anchor: start; }#BJlfcPditzCW .fx6 {text-anchor: start}#BJlfcPditzCW .fx7 { dominant-baseline: alphabetic; }#BJlfcPditzCW .fx7 {dominant-baseline: alphabetic}#BJlfcPditzCW .fc1 { fill: rgb(0, 0, 0); }#BJlfcPditzCW .fc1 {fill: rgb(0, 0, 0)}#BJlfcPditzCW .fb1 { fill: var(--N900-FG, 0.15); }#BJlfcPditzCW .fb1 {fill: rgba(31,35,41, 0.15)}#BJlfcPditzCW .fb2 { fill: rgb(209, 217, 224); }#BJlfcPditzCW .fb2 {fill: rgb(209, 217, 224)}#BJlfcPditzCW .fa3 { fill: var(--bg-body); }#BJlfcPditzCW .fa3 {fill: #fff}ABC12345678910字段项目一句话背景目标你的角色方案关键取舍结果失败当前边界需要写清为谁解决什么问题，用什么 AI 能力完成什么任务用户、场景、原流程和痛点，为什么现在做用户目标、产品目标、业务目标分别是什么你负责的判断、交付和协调，团队其他人负责什么规则、RAG、模型调用、Agent 或人工流程各自做什么备选方案、选择理由、放弃了什么结果指标、效果指标、系统指标、成本和风险发生了什么，最早信号是什么，怎么修复现在能做什么、不能做什么、下一步是什么证据提示PRD 摘要、用户流程用户访谈、工单、业务目标目标指标、上线线任务拆分、评审记录架构图、工具清单评审结论、对比评测数据口径、评测报告Badcase、复盘、回归结果能力边界清单

数据不方便公开时，不要用猜的数字填空。**可以说明“只能分享相对变化/区间/趋势”，并把重点放在指标定义、对照方式、你的动作和结论边界上。

未经授权的用户规模、收入、成本和公司内部信息，不应写入作品集或面试答案。

二、背景与目标：先讲为什么值得做

一个有说服力的背景段落，建议按以下顺序：

谁遇到了什么任务困难；

现有流程如何完成，主要瓶颈在哪里；

为什么用 AI，为什么不是规则、搜索、人工或普通自动化；

项目阶段是什么，成功与失败分别如何定义。

目标要拆成三层，避免把“接入模型”当成产品目标：

#XzSmiCTGFZwV text { white-space: pre; }#XzSmiCTGFZwV .fb0 { stroke: var(--N900-FG, 0.15); }#XzSmiCTGFZwV .fb0 {stroke: rgba(31,35,41, 0.15)}#XzSmiCTGFZwV .fx0 { stroke-miterlimit: 10; }#XzSmiCTGFZwV .fx0 {stroke-miterlimit: 10}#XzSmiCTGFZwV .fa1 { fill: rgb(187, 191, 196); }#XzSmiCTGFZwV .fa1 {fill: rgb(187, 191, 196)}#XzSmiCTGFZwV .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"; }#XzSmiCTGFZwV .fx1 {font-style: normal}#XzSmiCTGFZwV .fx2 { text-anchor: middle; }#XzSmiCTGFZwV .fx2 {text-anchor: middle}#XzSmiCTGFZwV .fx3 { dominant-baseline: central; }#XzSmiCTGFZwV .fx3 {dominant-baseline: central}#XzSmiCTGFZwV .fx4 { stroke: none; }#XzSmiCTGFZwV .fx4 {stroke: none}#XzSmiCTGFZwV .fc0 { fill: var(--text-caption); }#XzSmiCTGFZwV .fc0 {fill: #646a73}#XzSmiCTGFZwV .fa2 { fill: var(--text-link-disabled); }#XzSmiCTGFZwV .fa2 {fill: rgb(187, 191, 196)}#XzSmiCTGFZwV .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"; }#XzSmiCTGFZwV .fx5 {font-style: normal}#XzSmiCTGFZwV .fx6 { text-anchor: start; }#XzSmiCTGFZwV .fx6 {text-anchor: start}#XzSmiCTGFZwV .fx7 { dominant-baseline: alphabetic; }#XzSmiCTGFZwV .fx7 {dominant-baseline: alphabetic}#XzSmiCTGFZwV .fc1 { fill: rgb(0, 0, 0); }#XzSmiCTGFZwV .fc1 {fill: rgb(0, 0, 0)}#XzSmiCTGFZwV .fb1 { fill: var(--N900-FG, 0.15); }#XzSmiCTGFZwV .fb1 {fill: rgba(31,35,41, 0.15)}#XzSmiCTGFZwV .fb2 { fill: rgb(209, 217, 224); }#XzSmiCTGFZwV .fb2 {fill: rgb(209, 217, 224)}#XzSmiCTGFZwV .fa3 { fill: var(--bg-body); }#XzSmiCTGFZwV .fa3 {fill: #fff}ABC1234层级用户层产品层业务层问题用户完成任务后得到什么功能要改变什么行为或流程对组织结果有什么影响例子更快找到可信答案、少做重复整理提高一次解决，降低无效追问/人工接管缩短处理周期、提高转化或降低单位服务成本

如果项目目标只是“验证一个方向”，就明确它是探索性目标：验证用户是否需要、验证 RAG/Agent 是否能达到最低效果、验证演示是否能推动立项。探索项目不应包装成已经证明了规模化业务价值。

三、个人贡献：把“我们”拆成“我做了什么判断”

面试官想听的不是你是否参与过会议，而是你对结果产生了哪些不可替代的影响。可以按四类整理：

#XDLgItTDvExQ text { white-space: pre; }#XDLgItTDvExQ .fb0 { stroke: var(--N900-FG, 0.15); }#XDLgItTDvExQ .fb0 {stroke: rgba(31,35,41, 0.15)}#XDLgItTDvExQ .fx0 { stroke-miterlimit: 10; }#XDLgItTDvExQ .fx0 {stroke-miterlimit: 10}#XDLgItTDvExQ .fa1 { fill: rgb(187, 191, 196); }#XDLgItTDvExQ .fa1 {fill: rgb(187, 191, 196)}#XDLgItTDvExQ .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"; }#XDLgItTDvExQ .fx1 {font-style: normal}#XDLgItTDvExQ .fx2 { text-anchor: middle; }#XDLgItTDvExQ .fx2 {text-anchor: middle}#XDLgItTDvExQ .fx3 { dominant-baseline: central; }#XDLgItTDvExQ .fx3 {dominant-baseline: central}#XDLgItTDvExQ .fx4 { stroke: none; }#XDLgItTDvExQ .fx4 {stroke: none}#XDLgItTDvExQ .fc0 { fill: var(--text-caption); }#XDLgItTDvExQ .fc0 {fill: #646a73}#XDLgItTDvExQ .fa2 { fill: var(--text-link-disabled); }#XDLgItTDvExQ .fa2 {fill: rgb(187, 191, 196)}#XDLgItTDvExQ .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"; }#XDLgItTDvExQ .fx5 {font-style: normal}#XDLgItTDvExQ .fx6 { text-anchor: start; }#XDLgItTDvExQ .fx6 {text-anchor: start}#XDLgItTDvExQ .fx7 { dominant-baseline: alphabetic; }#XDLgItTDvExQ .fx7 {dominant-baseline: alphabetic}#XDLgItTDvExQ .fc1 { fill: rgb(0, 0, 0); }#XDLgItTDvExQ .fc1 {fill: rgb(0, 0, 0)}#XDLgItTDvExQ .fb1 { fill: var(--N900-FG, 0.15); }#XDLgItTDvExQ .fb1 {fill: rgba(31,35,41, 0.15)}#XDLgItTDvExQ .fb2 { fill: rgb(209, 217, 224); }#XDLgItTDvExQ .fb2 {fill: rgb(209, 217, 224)}#XDLgItTDvExQ .fa3 { fill: var(--bg-body); }#XDLgItTDvExQ .fa3 {fill: #fff}AB12345贡献类型问题定义产品决策AI 协作结果与复盘追问自己是我发现/验证了哪个用户问题？如何排除伪需求？是我决定了范围、流程、兜底、指标、优先级或上线条件中的哪一项？我如何定义评测标准、组织 Badcase、协调模型/检索/工程方案？我通过什么数据发现问题，推动了什么修复，结论如何影响下一版？

推荐使用“我负责 X，和 Y 协作，做了 Z，依据是 A，结果是 B”的句式。涉及团队成果时要明确归属，不把算法、工程、设计或运营的工作全部说成自己完成；但也不要把自己的判断藏在“团队决定”后面。

四、关键取舍：准备一张决策表

每个重要取舍都按下面五格准备：

代码块

Plain Text

当时要解决什么问题？

有哪些可行方案？

我选择了哪一个，依据是什么？

放弃的方案有什么代价？

上线后事实是否支持这个判断？

AI PM 高频取舍包括：

如果当时没有做正式对比实验，也可以诚实说明：当时的证据是什么、判断有哪些不确定性、后来如何补评测。推测只能标成推测；例如从产品表现推测使用了 RAG，不等于你掌握了真实架构。

五、数据结果：从“涨了多少”讲到“为什么可信”

准备结果时不要只报一个漂亮数字。至少说明：

•

指标的定义和分母是什么；

•

基线是旧版本、人工流程、规则方案还是对照组；

•

观测了多久、样本来自哪里、是否按用户/场景分层；

•

变化是离线评测、线上 A/B、灰度还是用户反馈；

•

哪些因素可能同时影响结果，哪些结论暂时不能归因给 AI；

•

效果提升带来了什么成本、延迟、人工复核或安全代价。

可以用下面的结果卡回答：

代码块

Plain Text

主结果：哪个用户/业务结果发生了什么变化

证据：采用了什么基线、样本、时间和评测方法

中间指标：AI 效果和系统指标是否同步变化

代价：成本、延迟、人工接管或风险如何变化

限制：哪些场景没有覆盖，结论不能外推到哪里

如果“模型指标涨了，业务指标没涨”，不要急着把它解释成项目失败或业务不配合。可以沿着Badcase 分析方法论检查：评测集分布、指标定义、上下游体验、用户采纳和观测周期是否对齐。

六、失败复盘：用事实说明你如何学习

高质量复盘不是讲一个“我最大的缺点”，而是讲一次具体的判断偏差或系统失败：

预期是什么：当时的假设和上线标准；

实际发生什么：用户、评测、系统或安全信号如何偏离；

最早信号：什么时候本可以更早发现；

根因：区分模型、检索、Prompt、工具、数据、交互、预期和流程问题；

修复动作：谁做了什么，如何验证不再复发；

机制改变：是否新增评测集、监控、权限、回滚或产品边界；

下一次选择：如果重来，你会在什么节点换方案，为什么。

避免三种无效复盘：把责任归给“模型太笨”；只说“加强沟通”却没有机制；只讲结果变差，却不说明用户影响、风险和修复证据。

七、AI 技术边界：准备三层讲法

项目深挖不要求 PM 代替算法工程师推导模型，但要能把方案讲到可判断的程度：

第一层：用户流程

用户输入什么？系统检索/规划/调用什么？用户在哪里看到来源、等待、确认、编辑或转人工？出错时有什么兜底？

第二层：能力链路

•

RAG：知识从哪里来、怎么切片和检索、如何确认引用支持答案；

•

Agent：任务怎么拆解、有哪些工具、状态/记忆如何管理、何时人工确认；

•

Vibe Coding Demo：验证了哪个假设，哪些数据和能力只是原型，离生产还缺什么。

第三层：验收与运行

评测集怎么来、标准答案或 rubric 怎么定、线上 Badcase 如何回流、模型/Prompt/工具怎么回归、成本和延迟如何监控、什么条件触发灰度暂停或回滚。

可以参考Agent 产品生产化和Agent 评测与可观测性准备“生产化追问”。

八、常见追问与回答骨架

九、建议的练习顺序

先讲一句话：项目为谁解决什么问题，结果如何；

再讲短版：背景、目标、方案、个人贡献、结果和一个取舍；

再讲长版：补充架构、评测、成本、安全、失败复盘；

最后做压力测试：让朋友随机挑事实卡字段追问，回答不确定处时明确“事实/建议/推测”。

不要把所有技术细节都放在开场。讲解顺序应让面试官先听懂用户价值，再根据兴趣进入方案和证据；但你自己必须把深挖材料准备完整。

十、项目深挖自查清单

能在一句话中说清用户、任务、AI 能力和结果。

能区分项目背景、目标、个人贡献和团队贡献。

至少准备两项有证据的关键取舍，并能说出放弃方案的代价。

每个结果都有指标口径、基线、观测方法和不能外推的范围。

能讲一个失败 Badcase 的现象、根因、修复和回归。

能解释 RAG/Agent/模型/工具/人工在项目中的边界。

准备了成本、延迟、权限、数据安全和回滚的回答。

没有编造数字、用户规模、岗位职责或未公开的公司信息。

能按初级 / 中级 / 高级三段位切换讲法（见下一节），而不是只会背项目清单。

十一、项目经历三段位答法

选题启发：磊叔《100 个问题》Q11（大厂问「你做过什么 AI 项目」时，不同段位怎么答）。正文为原创框架，不复述 PDF 中的数字与轶事。

面试官问项目，真正想听的往往不是简历条目，而是你对做过之事有没有判断。同一项目，可以按目标职级切换讲法深度——准备时三档都写好，上场按岗位要求取用。

初级（做什么）：一句话说清用户、任务、AI 能力与结果；交代你的职责边界。适合开场 30 秒，但不要停在这里——否则听起来像项目协调员。

中级（为什么这么做）：在事实卡上挂至少两项取舍，例如为何 RAG 而非微调、置信度/转人工门槛如何定、为何先 Workflow 再 Agent。每项用「问题 → 备选 → 依据 → 放弃代价」说完；依据优先来自评测、成本、合规或用户证据，见上文「关键取舍」与RAG vs 微调面试题。

高级（学到什么 / 重来怎么做）：补一段具体失败或误判：预期是什么、最早信号、根因、修复、机制改变（评测集、监控、权限、回滚）。能讲清「上线后发现真正瓶颈不在模型分，而在提问引导 / 成本 / 分布 Gap」这类演进，才像对结果负责的人。评测与线上不对齐时，可链离线 Evals 全绿、线上时灵时不灵与Agent 评测与可观测性。

练习建议：先用中级档把两个取舍讲顺，再为每个取舍准备一个「若重来」的高级补充；初级档只作开场压缩版。数据不便公开时，讲相对变化、口径与验证方法，不编造绝对值。

AI PM 作品集与 Demo 准备

AI PM 作品集的价值不是展示“我会调用模型”，而是让面试官看到你如何把一个问题变成可验证的产品：范围怎么定、方案为什么成立、效果如何评估、成本是否算过、风险怎么兜底、现场演示失败时还能不能讲清楚。

事实：评测指南要求围绕真实任务定义成功标准并持续回归；Vibe Coding 更适合验证原型假设，涉及真实用户、真实数据和稳定服务时仍需要工程化的安全、权限、监控和交接。

建议：作品集按“问题—决策—证据—边界”组织，Demo 是证据的一部分，不是全部。

一、统一展示结构：从问题到证据

无论做 RAG、Agent 还是 Vibe Coding 项目，都可以用下面的主结构：

问题与用户：谁在什么场景下遇到什么任务困难；

目标与范围：要验证或改变什么，不做什么；

方案与关键决策：为什么选 RAG/Agent/规则/人工组合；

用户流程与 Demo：正常路径、失败路径、确认和兜底；

评测与结果：评测集、rubric、基线、线上反馈和限制；

成本与运行：单位任务成本、延迟、权限、日志和上线方式；

复盘与下一步：失败 Badcase、取舍、尚未解决的问题。

一页作品集可以只展示结论，详情页再展开证据。每个图表都写清数据口径和时间，所有未经授权的真实数据都做脱敏或改成不可识别的相对结果。

二、三类项目的展示重点

不要把三类项目混成同一套“接入模型”的故事。RAG 的关键风险多在数据覆盖、检索和依据；Agent 的关键风险多在自主规划、工具和副作用；Vibe Coding 的关键价值是验证方向，关键风险是把原型误当生产系统。

三、RAG 项目怎么展示

先讲知识问题

说明原流程为什么需要知识库：知识是否私有、更新是否频繁、是否要求可引用、人工查找或规则维护有什么瓶颈。再说明不适用的场景，例如无法提供可靠来源、需要实时交易状态但没有授权接口的任务。

展示检索到回答的链路

代码块

Plain Text

用户问题 → 查询改写/过滤 → 文档切片与检索 → 重排/引用

→ 模型基于依据生成 → 引用展示/无法回答时兜底

作品集中至少展示一次“找对”和一次“找错/找不到”的例子：为什么召回了这段内容、答案是否被内容支持、找不到时是否老实拒答或转人工。不要只截一张漂亮答案图。

准备 RAG 评测集

评测集应覆盖：高频正常问题、文档表达不同但语义相同的问题、需要多段材料的问题、知识缺失/过期问题、歧义问题和恶意/越权问题。评分可以拆为：

•

检索：目标文档是否被召回、排序是否足够靠前；

•

生成：答案是否正确、完整、与依据一致；

•

产品：是否展示来源、用户能否判断可信度、找不到时是否有合理出口。

具体方法可参考从零建设评测集和如何评估 RAG 知识库的准确率?。

四、Agent 项目怎么展示

先展示任务卡和工具地图

用一张图说明：用户目标、允许的子任务、只读资源、可写工具、禁止动作、完成证据和人工接管点。工具列表不要只写“支持搜索和执行”，要说明每个工具的权限和副作用。

用一条轨迹讲清 Agent 如何工作

代码块

Plain Text

演示时主动说明：

•

哪些步骤由模型动态决定，哪些由代码或 Workflow 固定；

•

工具失败时如何分类和退出；

•

哪些动作只能生成草稿，哪些动作需要用户明确确认；

•

每项任务的成本、延迟和最大循环在哪里限制；

•

如何通过日志和评测集证明不是“刚好跑通了一次”。

准备 Agent 轨迹评测

除了任务最终成功率，还要准备必要步骤完成率、工具业务成功率、重试率、错误归因、转人工率、风险动作拦截和成本/延迟分布。相关方法见Agent 评测与可观测性。

五、Vibe Coding 项目怎么展示

Vibe Coding 项目最适合展示“从一句话需求到可验证原型”的过程，不适合假装自己交付了一个有完整 SLA 的生产系统。建议展示：

原始问题和验证假设；

如何拆成 3-6 个可独立验证的迭代步骤；

关键提示、交互取舍和每轮验证结果；

空状态、加载、错误、空输入、超长输入和重复提交等边界；

使用了什么脱敏/虚构数据，哪些接口只是 Mock；

已知问题、未做能力、真实生产还需要哪些工程工作。

演示时不要把“能在本地跑”说成“可以直接上线”。从一句话需求到能跑的原型中的原型边界、数据安全、版本和工程交接清单可以直接用来准备追问。

六、评测集：作品集里最容易缺的一页

作品集不一定要公开全部数据，但应展示评测设计：

如果没有足够真实数据，明确写“这是小规模探索评测”并说明不能代表线上效果。评测集的目的不是制造一个好看的分数，而是让面试官相信你知道什么被证明了、什么还没被证明。

七、成本测算：从“调用了 API”讲到“完成一项任务”

准备一个可替换参数的成本表，不要在作品集里编造价格或规模：

代码块

Plain Text

月度可变成本

= 有效用户数 × 人均任务数 × 每项任务调用数

还要报告：

•

单次调用成本与单项有效任务成本；

•

重试和长轨迹对成本的放大；

•

缓存、模型路由、上下文瘦身和异步批处理的降本假设；

•

成本上限、告警、降级和停止自主执行的条件；

•

价格和模型版本的核验日期，动态价格以官方定价页为准。

成本估算方法见AI 产品成本测算入门和模型选型决策框架。面试中比“每月多少钱”更重要的是：你知道每个参数从哪里来，结果对哪些假设敏感，以及成本上涨时先牺牲什么、保住什么。

八、Demo 风险与备用路径

现场 Demo 的最大风险不是页面不好看，而是演示结果无法复现、无法解释或暴露安全问题。

备用路径不是把失败藏起来。正确做法是说明“实时链路此刻不可用”，切换到可验证的离线证据，并继续讲清系统真实边界。

九、面试讲解顺序：先价值，后技术，最后边界

推荐采用下面的顺序，控制每一层的细节深度：

一句话：用户、任务、AI 能力、结果；

问题：原流程为什么不够，为什么值得做；

Demo：走一条最短正常路径，明确用户看到了什么；

方案：只解释和当前问题有关的 RAG/Agent/工具/数据链路；

证据：评测集、基线、线上反馈、成本和延迟；

取舍：一个最关键的选择和被放弃的方案；

边界：失败、权限、安全、数据和不能承诺的效果；

下一步：如果继续投入，优先补什么，如何验证。

如果面试官追问技术，再展开架构；如果追问业务，回到任务完成和用户价值。不要用大量术语掩盖没有评测、没有成本或没有权限边界的问题。

十、作品集与 Demo 自查清单

每个项目都能在一页内讲清问题、用户、目标、范围和结果。

RAG 项目展示了知识来源、检索/引用和找不到时的兜底。

Agent 项目展示了任务边界、工具权限、状态、完成证据和人工确认。

Vibe Coding 项目展示了验证假设、迭代过程和生产边界。

每个项目都有评测集或至少有清楚的评测计划、rubric 和限制说明。

成本按单位有效任务测算，参数、价格核验日期和降级方案可解释。

Demo 有离线/截图/轨迹等备用证据，且不会接触真实敏感数据或副作用工具。

讲解顺序遵循问题—方案—证据—取舍—边界，不把 Demo 当成全部证明。

JD 写「熟悉大模型」，面试官的三档标准是什么？怎么自测？

难度:⭐⭐ 常规出现频率:高,几乎每个 AI PM JD 都会写「熟悉大模型 / LLM」,技术面常用它开场定档

考察点

•

能否把模糊的「熟悉」拆成可验证行为,而不是背术语表

•

是否诚实自报档位,并用项目证据支撑,而不是把「调过 API」写成「深度熟悉」

•

面对「为什么不用大模型 / 为什么不用更强模型」时,能否用约束与取舍回答

参考答案

一句话核心

面试官心里通常有三档:概念可用(L1) → 方案可判(L2) → 选型可辩(L3)。JD 的「熟悉」几乎没有信息量;你要先定自己的真实档位,再用一页证据自报家门。完整行为表与升档动作见正课能力模型 · 「熟悉大模型」三档自评。

三档标准(面试官听什么)

岗位目标档位不同:多数应用型 AI PM 把 L2 做稳通常够用;模型厂商 / 平台岗更常考到 L3。岗位差异见 AI PM 岗位类型盘点。

怎么自测(面试前 30 分钟可做)

第一关 · 过没过 L2

研发说「这个需求不适合用大模型」。若你只能点头或反问「那还能不能做」,多半还在 L1。若能立刻追出第二层原因并改方案,通常已跨过 L2:

•

是延迟扛不住,还是峰值下推理排队?

•

是单位任务成本算不过来,还是可以分级路由 / 缓存?

•

是数据不够 / 分布漂移 / 标注差,还是任务本身更适合规则或小模型?

•

是合规 / 可审计硬约束,还是效果波动用户不可接受?

能把「不适合」拆成可验证约束,就是在用产品语言管理模型能力。

第二关 · 有没有 L3 证据包

任选一个真实场景,检查你能否在 5 分钟内讲清四栏:约束 / 候选 / 取舍 / 复盘。若只能讲「我们上了 GPT」,没有评测样本、成本粗算或放弃理由,先别在简历写「深度熟悉」。选型流程见模型选型决策框架。

第三关 · 简历措辞是否越档

面试怎么答(结构)

先定档:「按你们 JD 的『熟悉大模型』,我自评在 L2:能做方案初判,L3 的平等选型我还在用项目练。」诚实比虚高更安全。

给一个场景证据:目标 → 候选路径 → 为什么选/不选 → 用什么样本或指标验收。

主动补边界:「我不推公式,但我能把注意力机制翻译成长文本与成本约束;细节我会对齐算法同学。」

原理补课优先看 Transformer 架构(PM 版);项目材料打包见项目深挖与作品集与 Demo。

追问延伸

•

追问 1:「你说熟悉大模型,讲讲 Transformer 对产品意味着什么?」 → 不背公式:长依赖与上下文窗口如何影响截断、延迟、费用;注意力计算随序列变贵,为何长文档常要 RAG/分段而不是一次性塞满。细节链正课 Transformer 文。

•

追问 2:「Prompt、RAG、微调、Agent,这个需求你怎么选?」 → 先问失败可接受度、知识是否常变、是否多步工具调用、是否有标注预算;给出初判 + 放弃理由,而不是「都很好」。

•

追问 3:「算法说必须用最强闭源模型,你怎么回应?」 → 对齐业务底线与预算:用小样本对照效果差、延迟与单位成本;能分级路由就分级;坚持「最强」时要求写清不可替代的评测证据。