AI Day 47
AI Day 47: 产品面试模拟(1)：AI产品设计题
AI Day 47: 产品面试模拟(1)：AI产品设计题
2026-05-18
产品面试AI产品设计CIRCLES写作助手知识库AI客服面试陷阱
日期: 2026-05-18 阶段: Phase 4 — 面试冲刺 (System Design + Product + Architecture) 主题: Product Interview Simulation — AI Product Design Questions 进度: Day 1-46 ✅ | Day 47 ← current 标签: #产品面试 #AI产品设计 #CIRCLES #写作助手 #知识库 #AI客服 #面试陷阱
学习路径 (50-Day Full Tree)
AI/LLM 深度技术学习 50天计划
├── 第一阶段：模型基础 (Day 1-15) ✅
│ ├── Day 1-7: Transformer/量化/训练/Prompt/RAG/向量DB/FineTune ✅
│ ├── Day 8-11: 推理优化/长上下文/多模态/Reasoning ✅
│ └── Day 12-15: Agent/MCP/评估/阶段总结 ✅
│
├── 第二阶段：工程实践 (Day 16-30) ✅
│ ├── Day 16-18: 应用架构/安全/可观测性 ✅
│ ├── Day 19-21: 生产级RAG三部曲 ✅
│ ├── Day 22-25: Agent工程化四部曲 ✅
│ └── Day 26-30: 成本/编排/测试/案例/总结 ✅
│
├── 第三阶段：金融零售AI应用 (Day 31-42) ✅
│ ├── Day 31: 金融AI(1)：智能风控与反欺诈 ✅
│ ├── Day 32: 金融AI(2)：智能投顾与量化策略 ✅
│ ├── Day 33: 金融AI(3)：合规科技与监管AI ✅
│ ├── Day 34: 金融AI(4)：信贷全链路AI ✅
│ ├── Day 35: 金融AI总结 — PM视角的AI重塑金融 ✅
│ ├── Day 36: 零售AI(1)：推荐系统与个性化 ✅
│ ├── Day 37: 零售AI(2)：智能客服与对话系统 ✅
│ ├── Day 38: 零售AI(3)：供应链预测与优化 ✅
│ ├── Day 39: 零售AI(4)：智能营销与用户增长 ✅
│ ├── Day 40: 零售AI总结 — PM视角零售智能化全景 ✅
│ ├── Day 41: CeFi × DeFi × AI 融合架构(上) ✅
│ └── Day 42: CeFi × DeFi × AI 融合(下) + 职业定位 ✅
│
└── 第四阶段：面试冲刺 (Day 43-50)
├── Day 43: 系统设计面试(1)：企业LLM平台 ✅
├── Day 44: 系统设计面试(2)：生产级RAG系统 ✅
├── Day 45: 系统设计面试(3)：AI Agent系统 ✅
├── Day 46: 系统设计面试(4)：推荐系统 ✅
├── Day 47: 产品面试模拟(1)：AI产品设计题 ← 你在这里
├── Day 48: 架构面试模拟(2)：AI系统架构题
├── Day 49: 行为面试 + AI领域特色问题
└── Day 50: 50天总结 — 知识地图与下一步
一、AI产品面试 vs 传统产品面试
1.1 AI产品面试的独特之处
传统产品面试:
"设计一个外卖App" / "改进微信搜索"
→ 关注: 用户需求 / 功能设计 / 指标 / 商业模式
→ 技术是黑盒, 不需要深入理解实现
AI产品面试:
"设计一个AI写作助手" / "为银行设计AI客服"
→ 关注: 同上 + 技术理解深度 + AI特有的挑战
→ 技术不是黑盒, 你需要知道:
├── 哪些能力LLM擅长, 哪些容易出错
├── Hallucination/延迟/成本/安全的实际影响
├── 如何评估AI输出质量
└── 如何设计人机协作而非纯自动化
1.2 面试官真正在考察什么
层次1: 产品Sense (40%)
├── 用户需求洞察: 你能找到真正的痛点吗?
├── 优先级判断: 什么先做什么后做?
├── 指标设计: 如何衡量AI产品的成功?
└── 商业思维: 这个产品如何赚钱?
层次2: 技术理解 (30%)
├── 可行性判断: 当前AI能不能做到?
├── 架构认知: RAG/Agent/微调分别适合什么场景?
├── 限制理解: Hallucination/Token成本/延迟
└── 评估方法: 如何衡量AI输出质量?
层次3: 落地能力 (30%)
├── MVP定义: 最小可行产品是什么?
├── 迭代策略: 如何从V1到V2?
├── 风险意识: 什么可能出错? 如何兜底?
└── 合规考量: 数据隐私/监管/安全
1.3 AI产品面试 vs 系统设计面试
产品面试 系统设计面试
时间 30-45 min 45-60 min
起点 用户 & 场景 需求 & 规模
核心输出 功能方案 + 指标 架构图 + 接口
技术深度 概念级(能讲清why) 实现级(能画清how)
画图 用户流程图/功能矩阵 C4/序列图/数据流
评估标准 商业价值 + 用户价值 可扩展性 + 可靠性
共同点:
→ 都需要先澄清需求
→ 都需要讲清Trade-off
→ 都需要展示结构化思维
二、答题框架：CIRCLES for AI Products
2.1 原版 CIRCLES 框架
C — Comprehend (理解场景) → 明确公司/产品/背景
I — Identify Users (识别用户) → 用户是谁? 分群
R — Report Needs (报告需求) → 用户痛点 & 需求
C — Cut Through (筛选优先) → 优先级排序
L — List Solutions (列出方案) → 至少3个方案
E — Evaluate (评估权衡) → Trade-off分析
S — Summarize (总结) → 1-2句话总结推荐
2.2 AI产品改良版: CIRCLES-T
C — Comprehend (理解场景)
+ AI能力边界: 当前LLM/ML能做什么, 不能做什么?
+ 行业AI成熟度: 这个领域AI应用到什么阶段了?
I — Identify Users (识别用户)
+ 用户的AI素养: 用户能理解AI输出吗? 会不会过度信任?
+ 利益相关方: 谁受AI影响? (内容创作者/审核员/合规)
R — Report Needs (报告需求)
+ AI特有需求: 准确性/可控性/可解释性/隐私
+ 非功能需求: 延迟/成本/安全/合规
C — Cut Through (筛选优先)
+ 技术可行性: 这个需求AI当前能实现到什么程度?
+ 风险矩阵: 如果AI出错, 后果有多严重?
L — List Solutions (列出方案)
+ AI方案分级: 纯规则 / ML / LLM / Agent / 人+AI混合
+ 渐进式AI: 从简单到复杂的演进路径
E — Evaluate (评估权衡)
+ AI特有Trade-off: 准确率vs覆盖率/成本vs质量/速度vs安全
S — Summarize (总结)
T — Technical Depth (技术深度) [AI产品特有]
+ 模型选择逻辑
+ 数据需求
+ 评估方案
三、题目1：设计一个AI写作助手
3.1 题目
"Your company wants to build an AI writing assistant. Design the product from scratch. Think about target users, core features, technical approach, and business model."
3.2 Step 1: Comprehend — 理解场景 (3 min)
先澄清:
Q: "面向什么类型的写作? 通用写作还是垂直场景?"
→ 假设: 面向知识工作者的通用写作助手 (类Notion AI / Jasper)
Q: "独立产品还是集成到现有产品?"
→ 假设: 独立产品, 有自己的编辑器
Q: "目标市场? ToB 还是 ToC?"
→ 假设: ToB + ToC都覆盖, 但先从ToC个人用户切入
Q: "有什么约束? 预算/团队规模/上线时间?"
→ 假设: 种子轮团队20人, 需要3个月出MVP
3.3 Step 2: Identify Users — 用户分群
用户分群 (按使用频率和场景):
┌─────────────────────────────────────────────────────────┐
│ Persona 1: 内容创作者 (30%) │
│ 角色: 自媒体/博主/公众号作者 │
│ 痛点: 写作效率低, 缺乏灵感, 改稿耗时 │
│ 频率: 每天使用, 高频高价值 │
│ AI素养: 中高, 用过ChatGPT │
├─────────────────────────────────────────────────────────┤
│ Persona 2: 职场白领 (40%) │
│ 角色: 写周报/邮件/方案/PPT │
│ 痛点: 重复写作, 不擅长表达, 想提高效率 │
│ 频率: 每周3-5次, 中频 │
│ AI素养: 中等, 可能初次使用AI写作 │
├─────────────────────────────────────────────────────────┤
│ Persona 3: 学生/研究者 (20%) │
│ 角色: 论文/报告/作业 │
│ 痛点: 学术写作规范, 参考文献整理, 语言润色 │
│ 频率: 集中使用(期末/论文季) │
│ AI素养: 高, 但有学术诚信顾虑 │
├─────────────────────────────────────────────────────────┤
│ Persona 4: 企业团队 (10%) │
│ 角色: 市场部/内容团队/客服团队 │
│ 痛点: 品牌一致性, 多人协作, 内容量大 │
│ 频率: 每天, 需要团队协作功能 │
│ AI素养: 参差不齐, 需要培训 │
└─────────────────────────────────────────────────────────┘
优先用户: Persona 1 (内容创作者) + Persona 2 (职场白领)
理由: 高频需求 + 明确痛点 + 付费意愿 + 占比70%
3.4 Step 3: Report Needs — 需求分析
核心需求 (按优先级):
P0 — Must Have (MVP):
1. 智能续写: 根据上文自动补全/扩展
2. 改写润色: 改变语气/风格/简化/扩展
3. 大纲生成: 给定主题生成文章结构
4. 多语言支持: 中英至少
P1 — Should Have (V2):
5. 全文生成: 给定标题+大纲生成完整文章
6. 风格模仿: 学习用户的写作风格
7. SEO优化: 关键词建议/标题优化
8. 语法检查: 拼写/语法/标点纠错
P2 — Nice to Have (V3):
9. 多模态: 根据文本配图建议
10. 协作功能: 团队共享模板/品牌语料库
11. 数据分析: 写作数据统计/进步追踪
12. 插件生态: 集成到各平台(Notion/飞书/Word)
AI特有需求 (贯穿所有版本):
├── 准确性: 生成内容不能有事实错误
├── 可控性: 用户能控制输出的方向和风格
├── 隐私: 用户内容不被用于训练
└── 速度: 输出响应 < 2秒(streaming)
3.5 Step 4: Cut Through — 功能优先级矩阵
影响力 High
│
P0: 智能续写 │ P1: 全文生成
P0: 改写润色 │ P1: 风格模仿
P0: 大纲生成 │
│
─────────────────────┼──────────────── 实现难度
│
P0: 多语言 │ P2: 多模态
P1: 语法检查 │ P2: 插件生态
│
影响力 Low
MVP功能 (3个月):
→ 智能续写 + 改写润色 + 大纲生成 + 基础编辑器
→ 支持中英双语
→ Streaming输出 + 基础用户体验
3.6 Step 5: Solutions — 技术方案
方案对比:
方案A: 纯API调用 (最快)
架构: 前端编辑器 → API Gateway → OpenAI/Claude API
优点: 开发快(1-2月), 质量高, 成本可预测
缺点: 依赖第三方, 隐私风险, 差异化弱
成本: $0.01-0.03/次请求
方案B: 自建模型 + RAG (差异化)
架构: 编辑器 → 自建模型服务 → Fine-tuned模型 + RAG
优点: 数据自主, 可深度定制, 长期成本低
缺点: 开发慢(6月+), 需要ML团队, 质量不确定
成本: 前期投入大, 长期边际成本低
方案C: 混合架构 (推荐)
架构: 编辑器 → 路由层 → 基础功能用开源模型 / 高级功能用商业API
优点: 平衡速度与差异化, 渐进迁移, 成本可控
缺点: 架构复杂度, 需要维护两套
成本: 中等, 可优化
推荐: 方案C (混合架构)
Phase 1 (MVP): 主用Claude/GPT API, 快速上线
Phase 2: 引入开源模型处理简单任务(续写/润色), 降本
Phase 3: 训练自有模型处理核心场景, 建立壁垒
3.7 Step 6: Evaluate — 关键指标
北极星指标: 周活跃用户的AI功能使用次数 (WAU × AI calls/user)
层次化指标体系:
用户获取:
├── 注册转化率: 访问→注册 > 15%
├── 激活率: 注册→首次使用AI功能 > 60%
└── 获客成本(CAC): < $5/用户
用户活跃:
├── DAU/MAU: > 30%
├── 日均AI调用次数: > 5次/活跃用户
└── Session时长: > 15分钟
AI质量:
├── 用户接受率: AI输出被用户采纳 > 50%
├── 编辑距离: 用户对AI输出的修改量 < 30%
├── 重新生成率: 用户点击"重新生成" < 20%
└── 反馈评分: 满意度 > 4.0/5.0
商业指标:
├── 付费转化率: 免费→付费 > 5%
├── ARPU: > $15/月
├── 留存率: 30天留存 > 40%
└── LTV/CAC: > 3x
3.8 Step 7: 商业模式 & 竞争
商业模式: Freemium + 订阅
Free:
├── 每天10次AI调用
├── 基础续写/润色
└── 单文档
Pro ($12/月):
├── 无限AI调用
├── 全部AI功能
├── 风格定制
└── 多文档管理
Team ($25/人/月):
├── 团队协作
├── 品牌语料库
├── 管理后台
└── 优先支持
Enterprise (定制):
├── 私有化部署
├── 自定义模型
├── SSO/合规
└── SLA保障
竞争格局:
┌──────────────┬────────────────┬─────────────┬──────────────┐
│ 竞品 │ 强项 │ 弱项 │ 我们的机会 │
├──────────────┼────────────────┼─────────────┼──────────────┤
│ Notion AI │ 深度集成编辑器 │ 写作专精不足 │ 专注写作场景 │
│ Jasper │ 营销内容强 │ 通用写作弱 │ 更通用 │
│ ChatGPT │ 通用能力强 │ 无编辑器体验 │ 更好的写作UX │
│ Grammarly │ 语法检查强 │ 生成能力弱 │ 生成+润色一体 │
│ Copy.ai │ 营销文案 │ 长文弱 │ 长文支持 │
└──────────────┴────────────────┴─────────────┴──────────────┘
差异化策略:
1. 写作体验优先: 不是聊天框, 是真正的编辑器+AI
2. 中文场景深耕: 国内写作习惯/平台适配
3. 学习用户风格: 用得越多越像你的风格
四、题目2：设计一个企业AI知识库
4.1 题目
"A mid-size company (500 employees) wants an internal AI knowledge base. Employees should be able to ask questions and get accurate answers from company documents. Design this product."
4.2 场景分析
企业知识库的核心挑战:
信息碎片化:
├── 文档散落: Confluence/飞书/本地文件/邮件/Slack
├── 格式多样: PDF/Word/PPT/Markdown/表格/图片
├── 版本混乱: 哪个是最新版? 谁改过?
└── 知识沉没: 老员工离职, 知识跟着走
传统搜索的痛点:
├── 关键词搜索: 必须猜对关键词才能搜到
├── 结果排序: 返回100个文档, 不知道哪个有用
├── 跨文档: 答案分散在3个文档中, 需要自己拼接
└── 理解门槛: 新员工看不懂专业文档
AI知识库的价值:
├── 自然语言提问: "我们的年假政策是什么?"
├── 跨文档汇总: 自动从多个文档提取并汇总答案
├── 引用溯源: 每个答案标注来源文档和段落
└── 持续学习: 新文档上传后自动纳入知识库
4.3 需求定义
用户分群:
新员工 (Onboarding):
需求: 快速了解公司制度/流程/工具
典型问题: "报销流程是什么?" "新人入职清单?"
频率: 前3个月高频, 之后降低
业务人员 (Day-to-day):
需求: 查找产品文档/客户案例/合同模板
典型问题: "XX产品的定价策略?" "类似客户的解决方案?"
频率: 每天2-5次
管理层 (Decision):
需求: 查找政策/数据/历史决策
典型问题: "去年Q3营收数据?" "竞品分析报告?"
频率: 每周几次, 但要求准确
IT/Admin:
需求: 管理文档/权限/系统维护
典型操作: 上传文档/设置权限/查看使用统计
频率: 日常维护
4.4 MVP 定义 (3个月)
MVP功能:
核心功能:
├── 文档上传: 支持PDF/Word/Markdown/PPT
├── 自动解析: 文档 → 分块 → 向量化 → 索引
├── 智能问答: 输入自然语言 → RAG检索 → 生成回答
├── 引用标注: 每个回答标注来源文档+页码
└── 基础权限: 部门级文档隔离
技术架构 (MVP):
┌─────────────────────────────────────────────┐
│ Web Frontend (React) │
│ ┌──────────┐ ┌──────────┐ ┌──────────────┐ │
│ │ Chat UI │ │ Doc Mgmt │ │ Admin Panel │ │
│ └────┬─────┘ └────┬─────┘ └──────┬───────┘ │
└───────┼────────────┼───────────────┼─────────┘
│ │ │
┌───────▼────────────▼───────────────▼─────────┐
│ API Gateway │
├──────────────────────────────────────────────┤
│ ┌──────────┐ ┌───────────┐ ┌───────────┐ │
│ │ QA Svc │ │ Index Svc │ │ Auth Svc │ │
│ │(RAG+LLM) │ │(Chunking) │ │(RBAC) │ │
│ └────┬─────┘ └─────┬─────┘ └───────────┘ │
├───────┼──────────────┼──────────────────────-┤
│ ┌────▼─────┐ ┌─────▼─────┐ ┌───────────┐ │
│ │ Vector DB│ │ Doc Store │ │ User DB │ │
│ │(Pinecone)│ │ (S3+PG) │ │(Postgres) │ │
│ └──────────┘ └───────────┘ └───────────┘ │
└──────────────────────────────────────────────┘
4.5 迭代路线
V1 (MVP, Month 1-3):
├── 基础RAG问答
├── 文档上传+解析
├── 引用溯源
└── 部门权限
V2 (Month 4-6):
├── 多轮对话: 支持追问和上下文
├── 反馈循环: 用户点赞/点踩 → 优化检索
├── 自动更新: 对接Confluence/飞书API自动同步
├── 表格理解: 解析Excel/表格中的数据
└── Slack/飞书集成: 在聊天工具中直接提问
V3 (Month 7-12):
├── 知识图谱: 文档之间的关系可视化
├── 专家路由: 无法回答时推荐相关专家
├── 文档质量评估: 标记过时/矛盾的文档
├── 多模态: 理解流程图/截图中的信息
└── 分析看板: 高频问题/知识盲区/使用统计
4.6 成功指标
核心指标:
回答质量:
├── 回答准确率: > 85% (人工抽检)
├── "有帮助"评分: > 70% 的回答被标记有用
├── 引用准确率: > 90% 的引用指向正确来源
└── 无法回答率: < 15% (问题在知识库范围内)
使用指标:
├── WAU/总员工: > 50%
├── 平均每人每周提问: > 3次
├── 对话轮次: 平均 < 3轮得到满意答案
└── 搜索替代率: 从传统搜索迁移 > 60%
业务价值:
├── 新员工Onboarding时间: 缩短 > 30%
├── 内部工单减少: HR/IT支持请求 -40%
├── 知识查找时间: 从平均20min → 2min
└── 员工满意度(NPS): > 40
五、题目3：为银行设计AI客服
5.1 题目
"A retail bank wants to add AI-powered customer service. Design the product considering regulatory compliance, accuracy requirements, and the need for human handoff."
5.2 合规约束分析 (银行场景的特殊性)
银行AI客服 vs 普通AI客服:
┌─────────────┬──────────────────────┬─────────────────────┐
│ 维度 │ 普通AI客服 │ 银行AI客服 │
├─────────────┼──────────────────────┼─────────────────────┤
│ 出错代价 │ 用户体验差 │ 合规风险/资金损失 │
│ 隐私要求 │ 一般 │ 极高(PII/金融数据) │
│ 监管 │ 宽松 │ 银保监/央行严格监管 │
│ 审计 │ 不需要 │ 所有对话需可审计 │
│ 可解释性 │ Nice to have │ Must have │
│ 人工介入 │ 可选 │ 必须有升级通道 │
│ 可用性 │ 99.9% │ 99.99% │
│ 回答标准 │ 大致正确 │ 精确合规, 不能有歧义 │
└─────────────┴──────────────────────┴─────────────────────┘
合规红线 (绝对不能触碰):
1. 不能给出具体投资建议 ("建议您买XX基金")
2. 不能泄露客户信息
3. 不能承诺收益率
4. 不能代替人工处理投诉
5. 所有对话必须留痕可追溯
5.3 架构设计：三层防护
银行AI客服架构:
客户
│
┌────────▼────────┐
│ Channel Layer │ (App/Web/电话/微信)
└────────┬────────┘
│
┌────────▼────────┐
│ Intent Router │ 意图识别 + 风险分级
└────────┬────────┘
│
┌────────────┼────────────┐
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ 简单查询 │ │ 业务咨询 │ │ 高风险 │
│ (L1 AI) │ │(L2 AI+人)│ │ (L3 人工) │
└──────────┘ └──────────┘ └──────────┘
余额查询 产品咨询 投诉处理
交易记录 利率说明 账户纠纷
网点查询 还款计划 大额转账
费率查询 贷款试算 欺诈报告
三层模型:
L1 — 纯AI自动回答 (70%的问题):
├── 场景: 账户查询/费率/网点/常见FAQ
├── 技术: 规则引擎 + RAG (银行知识库)
├── 准确率要求: > 98%
├── 风控: 固定话术模板, AI只填充变量
└── 示例: "您的储蓄账户余额为¥12,345.67, 截至2026-05-18 10:30"
L2 — AI辅助 + 人工确认 (25%):
├── 场景: 产品咨询/还款方案/复杂业务
├── 技术: LLM生成草稿 → 人工审核后发送
├── 流程: 客户提问 → AI生成回复草稿 → 客服人员审核/修改 → 发送
└── 示例: AI试算贷款方案, 客服确认后发给客户
L3 — 纯人工 (5%):
├── 场景: 投诉/纠纷/大额操作/情绪激动
├── 触发: AI检测到风险关键词/情绪/超出能力范围
├── AI角色: 辅助人工(提供客户历史/建议话术)
└── 示例: 客户投诉被误扣费, 立即转人工
5.4 人工协同机制
AI → 人工升级的触发条件:
自动升级 (系统判断):
├── 情绪检测: 愤怒/焦虑/不满情绪 > 阈值
├── 风险关键词: "投诉"/"欺诈"/"起诉"/"曝光"
├── 能力边界: AI信心度 < 70%
├── 合规红线: 涉及投资建议/收益承诺
├── 敏感操作: 账户冻结/大额转账/密码重置
└── 循环检测: 同一问题AI回答3次未解决
客户主动升级:
├── 随时可选: 对话界面始终展示"转人工"按钮
├── 透明告知: "我是AI助手, 如需人工服务请点击此处"
└── 无缝衔接: 转人工时自动携带对话上下文
升级后的AI角色 (辅助人工):
├── 自动摘要: 为人工客服生成对话摘要
├── 知识推荐: 推荐相关知识库文章给客服
├── 话术建议: 根据场景建议回复模板
└── 实时合规: 检查人工回复是否合规
5.5 风险控制
银行AI客服的风险矩阵:
风险1: 回答错误导致客户损失
场景: AI错误告知利率/费用/政策
防护: 金融数据必须从核心系统实时查询, 不允许AI生成
回退: 所有金额/利率使用模板填充, 不用LLM生成
风险2: 信息泄露
场景: AI将A客户信息回复给B客户
防护: 严格Session隔离 + 上下文不跨用户 + 定期清理
审计: 所有对话加密存储, 定期审查
风险3: 合规违规
场景: AI给出投资建议/"保证收益"等违规表述
防护: 输出过滤层 → 合规关键词检查 → 违规拦截
模板: 高风险话题使用固定合规话术, 不允许AI自由生成
风险4: 系统故障
场景: AI服务宕机, 客户无法获得服务
防护: 降级方案 → FAQ引导 + 一键转人工 + IVR备份
SLA: 99.99%可用性, 故障切换 < 30秒
六、常见陷阱 & 高分技巧
6.1 AI产品面试 5 大陷阱
陷阱1: 只谈功能, 不谈技术 ❌
错误: "我们用AI做智能推荐/智能搜索/智能客服"
问题: 面试官不知道你是否真正理解AI
正确: "推荐场景我们用Embedding相似度做召回, 用LLM做个性化重排,
RAG确保推荐理由有事实依据"
陷阱2: 忽略AI安全与伦理 ❌
错误: 全程讨论功能, 不提风险
问题: 面试官认为你缺乏风险意识
正确: 主动提到Hallucination处理/数据隐私/偏见检测/
人工兜底机制
陷阱3: 过度设计, 一步到位 ❌
错误: 直接描述一个完美的终态产品
问题: 缺乏迭代思维, 不了解MVP概念
正确: 清晰的 MVP → V2 → V3 演进路径,
每个版本解决什么问题, 为什么这样排序
陷阱4: 把AI当万能 ❌
错误: "所有功能都可以用AI实现"
问题: 不理解AI的能力边界
正确: "这个场景AI准确率可能只有70%, 所以我们设计了
人工审核环节, V1先做辅助, 验证效果后再自动化"
陷阱5: 缺乏指标思维 ❌
错误: 只谈定性的"用户体验好"
问题: 无法衡量产品成功
正确: 给出具体的北极星指标 + 分层指标体系,
特别是AI质量指标(准确率/接受率/重新生成率)
6.2 高分答题策略
策略1: 先说"不做什么"
"在银行场景, AI绝对不能做的是: 给投资建议、承诺收益、
处理投诉. 这些必须留给人工."
→ 展示你对风险的敏感度
策略2: 用数据说话
"根据行业数据, AI客服通常能处理70%的L1问题,
这意味着我们可以将人工客服从100人减少到30人,
每年节省约500万人力成本."
→ 展示你的商业sense
策略3: 展示技术理解的"恰到好处"
PM不需要: "我们用HNSW算法做向量检索, batch size设为32..."
PM需要: "我们用RAG确保回答基于真实文档, 向量检索的召回率
是关键指标, 如果低于80%就需要优化分块策略."
→ PM的技术理解是'能做出正确决策', 不是'能写代码'
策略4: 主动提Trade-off
"这里有个关键取舍: 如果我们用更大的模型, 回答质量更高,
但延迟从1秒增加到3秒, 成本也翻3倍.
我的建议是: 简单问题用小模型(快+便宜), 复杂问题用大模型(准)."
→ 面试官最看重的就是Trade-off思维
策略5: 融入个人经验
"在我做的momoweb3项目中, 我实际体验过RAG的局限性:
当文档更新但向量库没同步时, 会给出过时的答案.
所以我认为知识库产品必须有自动同步+版本管理."
→ 真实经验比理论更有说服力
6.3 STAR-T 针对AI产品的改良
传统 STAR:
S(uation) → T(ask) → A(ction) → R(esult)
AI产品 STAR-T:
S(cenario): 场景 — 什么行业/什么用户/什么痛点
T(echnical Context): 技术背景 — AI能做什么/不能做什么
A(pproach): 方案 — 如何设计/分几个阶段
R(esult): 结果 — 指标/影响/学到什么
T(rade-off): 取舍 — 做了什么权衡/为什么
示例:
S: 银行客户每天有5000个咨询电话, 80%是简单查询
T: LLM能处理FAQ, 但银行对准确率要求极高(>98%)
A: 设计三层架构: AI自动/AI+人工/纯人工
R: AI处理70%查询, 人工成本降低50%, 客户满意度不变
T: 牺牲了一些自动化率(本可达85%), 换取了合规安全
七、更多练习题 (自测)
产品设计题:
1. 设计一个AI驱动的代码Review工具
2. 为医院设计一个AI分诊系统
3. 设计一个AI驱动的电商客服(vs银行客服有何不同?)
4. 设计一个AI简历筛选产品
5. 为教育公司设计AI个性化学习系统
每题练习建议:
→ 设定30分钟计时
→ 用CIRCLES-T框架
→ 写出完整答案, 特别注意:
├── 技术可行性判断
├── AI特有风险
├── 分阶段演进
└── 关键指标
八、今日总结
Day 47 核心收获:
1. AI产品面试 = 产品Sense(40%) + 技术理解(30%) + 落地能力(30%)
2. CIRCLES-T框架: 在经典CIRCLES基础上增加技术深度层
3. 三道典型题的完整解答:
├── 写作助手: 用户分群→混合架构→Freemium商业模式
├── 企业知识库: RAG核心→MVP→迭代路线→成功指标
└── 银行AI客服: 三层防护→合规红线→人工协同→风险控制
4. 五大陷阱: 不谈技术/忽略安全/过度设计/AI万能论/缺乏指标
5. 高分策略: 先说不做什么→数据说话→恰当技术深度→主动Trade-off
面试心法:
"AI产品面试不是考你背了多少AI术语,
而是考你能否在技术可能性和用户价值之间找到最佳平衡点."
明日预告: Day 48 — 架构面试模拟(2)：AI系统架构题 从"遗留系统+AI反欺诈"到"多模型管理平台", 练习白板画图 & Trade-off沟通