AI 项目怎么讲
难度：⭐ | 高频指数：🔥🔥🔥 | 应用岗相关度：★★★
面试回答
常见问法
- 简历里的 AI 项目能详细讲一下吗？
- 你在这个项目里具体做了什么，最难的部分是什么？
- 为什么选这个方案而不是别的，对比过哪些？
- 数据从哪来，效果怎么评估的？
- 上线之后遇到过什么问题，怎么解决的？
- 这个项目大概花了多少成本，单次调用多少钱？
回答
讲 AI 项目最容易踩的坑是——全程在说”我接了 OpenAI / LangChain / 向量库”，听完面试官会觉得这就是个调 API 的活，没有技术深度。
真正能拿分的讲法是按 STAR + 工程视角展开：背景（业务在解决什么）→ 难点（为什么不是调 API 就完事）→ 方案（你怎么设计的，对比过什么）→ 数据（哪来的、怎么标的、怎么评估的）→ 上线（链路、监控、成本）→ 反思（重做会改什么）。每一段都要有自己的判断和取舍，不是工具罗列。
工程上的判断标准是：面试官真正想问的不是”你用了什么”，而是”你为什么这么用”以及”出了问题你怎么办”。前者证明你会查文档，后者才证明你做过项目。
面试时要表现出的姿态是：对系统全链路有掌控感——检索召回率多少、Prompt 改过几版、Eval 跑了多少次、单次成本多少、P95 延迟多少——这些数字才是项目真实度的证据。
追问
- 这个数字（比如准确率、召回率）是怎么测出来的，测试集多大？
- 如果用户量翻 10 倍，你的架构哪里会先崩？
- 模型涨价 / 被禁用了你怎么迁移？
- 项目里最让你后悔的一个技术决定是什么？
- 团队里其他人负责什么，你具体写了哪部分代码？
- 这个效果跟基线（baseline / 不用 AI 的方案）比好多少？
原理展开
1. 为什么”讲项目”是面试核心
校招或社招的 AI 应用岗，面试时间常常有一半甚至更多花在项目上。原因很简单：八股可以背，项目造不了假——只要稍微追问几句，有没有真的做过、做到什么深度，立刻见分晓。
面试官在项目环节想验证三件事：
- 业务理解：你知不知道这个 AI 应用是给谁用、解决什么痛点、商业价值在哪
- 技术深度：你能不能讲出系统的关键设计、为什么这样设计、有没有别的选择
- 工程能力：上线了吗、效果怎么衡量、出问题怎么救、成本怎么控
只讲第一点像 PM，只讲第三点像运维，三件事都能讲清楚才是合格的应用岗工程师。
2. 项目表达的黄金结构
实战里最有效的是 5 分钟可压缩、15 分钟可展开的模板：
1. 背景（30s-1min）：业务场景 + 用户痛点 + 为什么用 AI
2. 难点（1-2min）：为什么不是调 API 就完事，技术挑战在哪
3. 方案（2-5min）：整体架构 + 关键模块 + 对比过哪些方案
4. 数据（1-2min）：数据来源、清洗、标注、Eval 集构造
5. 上线（1-2min）：部署形态、监控指标、成本、延迟
6. 反思（30s-1min）：重做会改什么、未来怎么演进短版本先给”背景 + 方案概要 + 一个最亮的技术点 + 量化结果”，等面试官选感兴趣的追问再展开。不要一上来就 15 分钟连珠炮——面试官没耐心，也没法引导节奏。
3. “背景”段：别只讲是什么，要讲为什么
差的讲法：
我们做了一个智能客服机器人，用了 GPT-4 和 RAG。
好的讲法：
公司有 200 万 SKU 的客服场景，人工每天处理 5 万单咨询，70% 都是重复的”物流 / 退换货 / 商品参数”问题。目标是用 AI 把这 70% 自动化掉，把人工省下来处理高价值咨询。当时业界刚开始尝试 RAG，我们判断 FAQ 数据足够结构化，适合走”检索 + 生成”路线而不是 fine-tune。
差别在于：好的背景段已经隐含了技术选型的理由——为什么不是规则、为什么不是 fine-tune、为什么 RAG 合适，都铺垫好了。
4. “难点”段：避免”调了个 API”印象的关键
这一段决定面试官对项目深度的判断。要主动讲三类难点：
- 技术难点：检索召回率低 / Prompt 不稳定 / 长上下文成本爆炸 / Agent 卡死 / 幻觉严重
- 业务难点：领域术语模型不认 / 用户问题极度发散 / 多轮上下文管理 / 隐私合规
- 工程难点：延迟优化 / 成本控制 / 灰度发布 / Eval 体系搭建 / 线上回滚
每个难点要讲：遇到的现象 → 你怎么诊断的 → 试了哪些方案 → 最后选了什么 → 效果。
差的讲法只到第一步：“Prompt 不稳定就多试几次”——这等于没讲。 好的讲法是完整链条：“最初 Prompt 在长文档场景下幻觉率 30%，我们做了 ablation 发现是 retrieval 召回了无关 chunk 导致的，于是把 chunk size 从 1000 调到 400 加 overlap，又加了 rerank 模型，最终幻觉率降到 8%。”
有过程、有数字、有结论，这才叫做过项目。
5. “方案”段：架构图 + 取舍
讲方案最好能口头描述出架构图：
用户问题 → 意图分类 → [闲聊 / FAQ / 复杂查询]
↓
Embedding 检索（Top-20）
↓
Rerank 模型（取 Top-3）
↓
Prompt 拼装 + LLM 生成
↓
Guardrail 输出校验
↓
返回用户 + 落日志然后讲关键取舍：
- 为什么用 Embedding + Rerank 两段而不是单段：单段召回精度不够，rerank 模型贵但能拉高 Top-3 准确率
- 为什么用 GPT-4 而不是 7B 开源：业务对准确率敏感，单条成本 0.02 美元在 ROI 内可接受
- 为什么意图分类用单独小模型：能挡掉 60% 的简单流量，省 LLM 成本
对比过的方案要讲，没对比过的不要硬讲——面试官一追问”你试过 X 方案没”立刻露馅。
6. “数据”段：常被忽略但极加分
应用岗很少有人主动讲数据，所以这段是差异化机会：
- 训练 / 微调数据：从哪来、多少条、怎么清洗、怎么标的（人工还是 LLM 蒸馏）
- Eval 集：怎么构造的、多少条、覆盖哪些场景、是不是分版本管理
- 线上数据回流：用户反馈怎么收集（点赞点踩 / 人工抽检）、坏 case 怎么进迭代
Eval 集构造的常见路径：
1. 业务方提供典型 case（覆盖主场景）
2. 线上抽样真实问题（覆盖长尾）
3. 人工写边界 case（覆盖攻击 / 异常）
4. 模型自动生成 case（扩量）
最终 500-2000 条，按场景分桶，每次改 Prompt 都跑一遍讲到这一层，面试官就知道你做的是工程而不是 Demo。
7. “上线”段：链路 + 监控 + 成本
这一段证明你真的把项目推到了用户面前，而不是停在 PoC。要给出的关键数字：
- 部署形态：单机 / K8s / Serverless，QPS 多少，P95 延迟多少
- 监控指标：调用成功率、Token 用量、单次成本、用户满意度
- 成本：日均调用次数 × 单次成本 = 月成本，对比节省的人工成本算 ROI
- 故障案例：模型抖动 / API 限流 / 上下文超限怎么处理的，有没有降级方案
没上线的项目也可以讲，但要诚实——讲清楚是 PoC 阶段，重点说你怎么验证方案有效、怎么估算上线后的成本和性能。诚实比包装更能拿分。
8. “反思”段：体现成长性
最容易被忽略的段落，但加分最快。模板：
- “如果重做，我会先把 Eval 集建好再迭代 Prompt——当时是反过来做的，导致前两周改 Prompt 全凭感觉”
- “应该早一点引入 rerank，省了至少两周的 Prompt 调优时间”
- “线上才发现成本失控，事前没做单次成本预算，这块是流程上的疏漏”
敢讲缺点反而显成熟——面试官见过太多”我们做得很完美”的项目，听到真实的反思会眼前一亮。
9. 不同岗位的侧重点
讲项目不是一套讲法走天下，要根据岗位调整重心：
| 岗位 | 重点讲什么 | 弱化什么 |
|---|---|---|
| 应用层 / Agent 开发 | Prompt 工程、工具编排、Eval、产品化 | 模型训练细节 |
| RAG / 知识库 | 检索召回、Rerank、Chunk 策略、引用归因 | Agent Loop |
| 模型层 / 算法 | fine-tune / DPO / 数据构造 / 评测 | 前端集成 |
| 基础设施 | 推理优化、vLLM、缓存、限流、成本 | 业务效果 |
| 全栈 | 端到端链路、监控、Eval、上线节奏 | 单点深度 |
面试前花 5 分钟看 JD，把项目按对应岗位重新组织一遍话术——同一个项目可以讲出三种侧重，关键是知道对方想听什么。
10. 提前准备的对照数据清单
为了不被追问问倒，每个项目至少要能脱口而出这些数字：
- 数据规模：训练集 / Eval 集多少条
- 效果指标：准确率 / 召回率 / 用户满意度 / 业务指标提升百分比
- 性能指标：QPS、P95 延迟、单次 Token 数
- 成本指标：单次调用成本、日均成本、对比基线 ROI
- 团队规模与你的角色：几个人、你负责哪几个模块
- 时间线：从立项到上线多久、迭代过几个版本
这些数字才是项目真实度的证据——背不出来的项目，面试官会自动打折。
对比总结
| 段落 | 差的讲法 | 好的讲法 |
|---|---|---|
| 背景 | 我们做了个 AI 客服 | 200 万 SKU、5 万单/日、70% 重复问题，AI 自动化 ROI 测算清晰 |
| 难点 | 用了 RAG | 召回率从 60% 调到 85% 的 ablation 过程 |
| 方案 | 接了 LangChain | 架构图 + 三个关键取舍 + 对比过的两个备选 |
| 数据 | （不讲） | Eval 集 1500 条分 5 桶，每周线上回灌 50 条坏 case |
| 上线 | 上线了 | QPS 200、P95 1.2s、单次 0.015 美元、月成本 9000 美元 |
| 反思 | 没什么坑 | Eval 应该先做，否则全凭感觉调 Prompt |
易错点
- 全程在讲模型名称和框架名称——给人感觉是工具用户而非系统设计者
- 没有量化指标——准确率、延迟、成本一个都说不出来
- 没有对比基线——不知道 AI 方案比传统方案好多少，无法证明价值
- 过度包装——把团队成果说成个人成果，被追问”你具体写了哪部分代码”答不上来
- 避谈失败——所有项目都”很成功”，面试官立刻怀疑真实性
- 没准备时间线 / 团队规模 / 个人角色——这三个问题几乎必问
- 不区分 PoC 和上线——PoC 项目硬讲成线上项目，被追问监控指标就崩
记忆技巧
记两个锚点：
- 六段结构：背景 → 难点 → 方案 → 数据 → 上线 → 反思
- 一句口诀：讲项目不是讲工具，是讲”为什么这么选”和”出了问题怎么办”——前者证明你会思考，后者证明你真做过
面试速答版
讲 AI 项目我会按六段走：先用 30 秒讲业务背景和 AI 价值，再花 1-2 分钟讲技术难点（为什么不是调 API 就完事），然后 2-5 分钟讲方案架构和关键取舍（对比过哪些方案、为什么这么选），接着讲数据和 Eval 集怎么构造的，再讲上线后的 QPS / 延迟 / 成本 / 监控指标，最后用 30 秒讲如果重做会改什么。
工程上的关键认知是：面试官真正想问的不是”你用了什么”，而是”你为什么这么用”和”出了问题怎么办”。所以每个段落都要有自己的判断、量化的数字、真实的取舍，避免”我接了 OpenAI 和 LangChain”这种工具堆砌的讲法。
面试加分版
如果想多讲一层，可以补：
- 同一项目按岗位调整侧重：应用岗讲 Prompt 和 Eval，算法岗讲数据和微调，基础设施岗讲推理优化和成本——投不同 JD 前花 5 分钟重新组织话术
- 主动暴露一个真实的设计缺陷或踩坑：比”我们做得很完美”可信度高 10 倍，面试官见过太多包装项目
- 提前准备数字清单：数据规模、效果指标、性能指标、成本、团队规模、时间线——这六组数字脱口而出，项目真实度立刻拉满