01. 项目介绍在面试里应该怎么讲？如何突出技术深度？

简单回答

项目介绍要用 “背景 → 问题 → 方案 → 结果” 的结构，控制在 3~5 分钟内讲完。技术深度不靠堆名词，而是体现在 “为什么这样选” 和 “遇到了什么坑、怎么解决的”*上。面试官听项目介绍，本质上是在评估三件事：你是不是真的做过、你的技术判断力如何、你能不能把复杂的事情讲清楚。

详细解释

面试官在听什么

很多候选人讲项目介绍时犯两个典型错误。一是像背产品文档——“我们的系统支持多轮对话、支持 RAG、支持 Agent、支持多模态……”，罗列了一堆功能但面试官完全感受不到你在其中做了什么、遇到了什么挑战。二是一上来就钻进技术细节——“我们用了 BGE-M3 做 Embedding，Chunk 大小设的 512，overlap 设的 64……”，面试官还不知道你这个系统解决什么问题就被一堆参数淹没了。

面试官真正想听到的是：这个项目解决了什么业务问题（为什么要做）→ 技术上的核心挑战是什么（难点在哪）→ 你的方案是什么、为什么这么选（你的技术判断力）→ 最终效果怎么样（你做的事有没有价值）→ 你个人在其中的角色和贡献是什么（区分 “团队做的” 和 “你做的”）。

推荐的讲述结构

一句话概括项目。 “这是一个面向企业内部的智能知识问答系统，帮助员工快速查询公司制度和技术文档。”——让面试官 5 秒内知道你做的是什么。

业务背景和问题。 简短说明为什么要做这个项目、解决了什么痛点。“公司有几千份制度文档和技术文档，员工查找信息效率很低，平均一个问题要翻 20 分钟文档。我们的目标是做到 30 秒内给出准确答案。”——不要展开太多业务细节，面试官不关心你们公司的业务流程，关心的是技术挑战。

技术架构的核心选型和设计。 这是展示技术深度的核心环节。不要平铺直叙地描述架构图的每个组件，而是围绕 “核心技术决策” 来讲。每个决策要包含 “选了什么” 和 “为什么选它而不是其他方案”。

比如：“我们选择了 RAG 架构而不是微调，主要考虑是文档更新频率高——每周都有新制度发布，微调跟不上更新节奏，而且需要能引用原文给用户验证。”

比如：“检索用的是向量检索加 BM25 的混合方案。纯向量检索在精确匹配制度编号和专有名词上效果不好，加了 BM25 之后 Recall@5 从 72% 提到了 85%。”

这种 “做了什么 + 为什么 + 效果数据”*的表达方式能同时展示技术判断力和实际结果。

遇到的核心挑战和解决方案。 这是区分 “做过” 和 “做深”的关键。面试官最感兴趣的是你遇到了什么意料之外的问题、怎么分析和解决的。

比如：“上线后发现一个严重问题——很多制度文档是表格形式的，直接按段落切 Chunk 把表格切碎了，检索效果很差。我们后来专门做了表格识别和提取，把表格转成 Markdown 格式作为独立 Chunk 处理，表格类问题的准确率从 40% 提升到了 78%。”

这种 “发现问题 → 分析根因 → 做了什么 → 效果如何” 的故事链条，比任何技术名词的堆砌都更能体现技术深度。

量化结果。 有数据就说数据——“Recall@5 从 72% 提到 85%”、“用户满意度从 60% 提到 82%”、“平均响应时间从 3 秒降到 1.2 秒”。没有精确数据可以说大致量级——“准确率提升了约 20 个百分点”、“查询效率提升了一个数量级”。避免“效果有明显提升”这种没有信息量的说法。

你的个人贡献。 如果是团队项目，要清楚说明你负责哪部分。“我主要负责检索链路的优化，包括 Chunk 策略、Embedding 模型选型和微调、以及混合检索的实现。Prompt 设计和模型选型是另一个同事负责的。”——面试官不会因为你没做全栈而扣分，但会因为你含糊不清搞不清楚你到底做了什么而减分。

怎么展示技术深度

技术深度不是靠提到多少技术名词，而是靠以下几点。

展示 trade-off 意识。 “我们对比了 Milvus 和 ES，最终选了 ES，因为团队已经有 ES 运维经验，而且我们需要混合检索，ES 天然支持。Milvus 在纯向量检索性能上更好，但引入新组件的运维成本对我们来说不划算。”——这种 “两个选项各有优劣、基于具体约束做了选择” 的表达比“我们用了 ES”有深度得多。

展示迭代思维。 “第一版用固定长度切 Chunk，效果一般。第二版改成按标题层级切分，Recall 提升了 8 个点。第三版发现长表格还是有问题，又加了表格专项处理。”——让面试官看到你不是一次做完就交差，而是在持续分析问题、迭代优化。

展示对失败和教训的反思。 “我们最初尝试过用 LLM 做 Query Rewrite，但发现在我们的场景下改写后的 query 反而检索效果更差——因为我们的文档用词很规范，用户的原始关键词反而是最好的检索 query。后来去掉了 Rewrite 步骤，效果反而提升了。”——承认 “试过但不 work” 比假装一切都很顺利更可信，也更能体现技术成熟度。

时间控制

项目介绍控制在 3~5 分钟。太短说明讲不清楚或项目太浅，太长说明抓不住重点或表达能力有问题。准备一个 3 分钟的精简版和一个 5 分钟的详细版。面试官感兴趣的部分他会追问，你不需要在介绍阶段就把所有细节讲完。

需要避免的常见问题

不要背诵。面试官听得出来你是在背稿还是在真的讲自己做过的事。准备要点但不要逐字背。

不要说“我们用了 LangChain”就完了。框架是工具，面试官关心的是你用它解决了什么问题，不是你会用它。

不要夸大。说“系统准确率 99%”面试官一定会追问——RAG 系统几乎不可能做到 99% 准确率。被拆穿了比不说还糟糕。

不要忽略失败。一个没有遇到过困难的项目要么是假的、要么是你做得太浅。

面试时可以这样答

项目介绍我一般会按 “一句话概括 → 业务痛点 → 核心技术方案 → 关键挑战和解决 → 量化结果 → 个人贡献” 这个结构讲，控制在三到五分钟。

技术深度的关键不在于提到多少新技术名词，而在于展示技术判断力——为什么选 A 不选 B、遇到了什么意料之外的问题、怎么分析和迭代的。比如 “我们试过 Query Rewrite 但在我们场景下效果反而更差，最后去掉了”，这种 “试过但不 work” 的经验比 “我们用了 xxx 框架效果很好” 更有说服力。

还有一点很重要，如果是团队项目，要清楚说明自己负责哪部分，不要用“我们”含糊带过所有事情。面试官判断不了你的能力边界，反而会扣分。

常见追问

1. 你在这个项目中遇到最大的技术挑战是什么？
2. 如果重新做这个项目，你会改变什么？
3. 这个项目的效果你是怎么评估的？