面试总挂不是因为技术菜？教你把知识讲成故事的表达心法
前阵子我帮一个做 RAG 的朋友模拟面试。技术上他真不差：向量库、召回排序、Chunk 策略、Embedding 模型切换，问什么都知道。可一到“讲讲你做过的项目”，他就开始像背配置清单：用了 LangChain、接了 Milvus、做了 Prompt 优化、上线了监控……五分钟后，面试官只回了一句：“听起来你做了不少，但我没听出来你到底解决了什么问题。”
这类场景太常见了。很多人挂面试，不是不会，而是“会得很碎、说得很散”。面试官想听的不是知识点堆砌，而是你如何识别问题、做出判断、推动结果。技术决定你能走多深，表达决定别人愿不愿意继续听你走下去。
尤其在 AI 工程岗位上，大家都会聊 LLM、Agent、RAG，真正拉开差距的，往往不是名词量，而是你能不能把知识讲成一个可信、有取舍、有结果的故事。
面试官为什么总觉得你“懂得不少，但不敢用”？
很多 AI 面试失败，不是败在“不会”，而是败在“像个搜索结果”。你回答问题时，列了一堆概念：Function Calling、Memory、ReAct、MCP、RAG、评测体系、推理加速……听上去很全，但没有重点，也没有顺序。面试官很难判断，你到底是项目真正的推进者，还是看过几篇文章的“信息搬运工”。
我这几年观察下来，面试官心里通常在判断三件事：
- 你是否理解问题，而不是只认识术语；
- 你是否做过选择，而不是把所有方案都念一遍；
- 你是否拿到结果，而不是停留在“理论上可以”。
这也是为什么，同样讲 RAG，有人一开口就让人想追问，有人讲三分钟就让面试官想切题。前者通常会说：“一开始我们发现用户投诉答案像‘半对半错’，不是模型能力不够，而是召回进来的文档噪声太高。后来我们把固定 1000 字切块改成按语义段落切分，再加 rerank，命中率明显提升。”
你看，这段话里有问题、有判断、有动作、有结果，面试官自然就知道你不是在背书。
反过来，如果你说：“我们用了 RAG 架构，包含切块、Embedding、向量检索和重排模块，同时也考虑了 Prompt Engineering 和上下文优化。”
没错，但太像 PPT。它不能证明你真的踩过坑。
面试不是知识竞赛，而是可信度测试。
AI 岗位尤其如此，因为这个领域变化太快，没人指望你什么都背全，但会特别在意你有没有形成稳定的认知框架。你能不能把新概念接到旧经验上，能不能把一个技术点讲到工程落地，能不能把“我知道”变成“我做过，我理解，我还能复盘”。
所以，问题不在于你知道得少，而在于你没有把知识组织成“能让别人相信你”的结构。
我常用的表达模型：STAR 不够，试试“问题-判断-动作-结果-复盘”五步法
很多人知道 STAR，但在 AI 工程面试里，单纯按 Situation、Task、Action、Result 讲，常常还是太平。因为 AI 项目有一个特点：方案不是线性的，很多价值体现在“为什么这样选，而不是那样选”。所以我更推荐一个适合技术面试的表达框架：
PJARR：Problem（问题）- Judgment（判断）- Action（动作）- Result（结果）- Review（复盘）
这五步法的关键，在于把“思考过程”显性化。
1）Problem：先讲清楚你解决的到底是什么
不是“做了一个 Agent 平台”，而是“客服知识库更新太快，原来的 FAQ 检索命中率低，人工转单率高”。
问题越具体，后面的方案越有说服力。
2）Judgment：讲出你的判断依据
为什么不用纯微调？为什么先做 RAG 而不是直接上多 Agent？为什么选 rerank 而不是盲目加长上下文？
这一步最能体现技术成熟度。你不是“用了什么”，而是“为什么这么用”。
3）Action：动作要有层次
不是一句“做了优化”，而是拆成几个关键动作：数据清洗、切块策略调整、召回链路分层、评测集搭建、线上监控补齐。
动作越具体，越容易让面试官相信你真的上过手。
4）Result：别只说“效果更好了”
最好给数据。比如：
- 首 token 时间从 5 秒降到 1.8 秒；
- 检索命中率从 62% 提升到 81%；
- 人工转单率下降 27%；
- 单次调用成本下降 35%。
5）Review：复盘比成绩更打动人
讲讲你后来觉得哪里还能做得更好，或者哪次判断其实走了弯路。
面试官不怕你犯错，怕的是你只会报喜不报忧。
这个模型的核心是：不要把项目讲成流水账，要把项目讲成“我如何做决策”的过程。
一旦你这样说，哪怕项目规模不大，面试官也会觉得你有工程主心骨。
案例一：同样是讲 RAG，普通回答和高分回答差在哪？
我拿一个特别常见的题目举例：“讲讲你做过的 RAG 项目。”
很多人的普通版回答，大概是这样：
我们做了一个企业知识库问答系统，整体用了 LLM 加 RAG。数据先切块，再做向量化存入向量数据库，查询时检索相关内容拼到 Prompt 里生成答案。后面还做了一些 Prompt 优化和召回优化。
这段没毛病，但几乎没有记忆点。你说的是“标准组件”，不是“你的工程能力”。
如果按 PJARR 来讲，高分版可以这样组织：
我们最初接到的问题不是“做一个知识库”，而是客服同学反映，机器人回答看起来很像，但经常引用错制度版本，导致用户不信任。
我先排查了链路，发现不是模型幻觉为主，而是检索阶段把过期文档和新制度一起召回了。也就是说，问题核心不在生成，而在检索质量和版本控制。
后来我们做了三件事：第一，文档入库前加了版本标签和生效时间；第二，把原来固定长度切块改成按标题层级和语义段切分；第三，在向量召回后增加了一个 rerank，并把“最新版本优先”写入排序逻辑。
调整后，离线评测里 Top3 命中率从 64% 提升到 86%，线上错误引用旧文档的工单占比下降了 40% 左右。
这件事让我意识到，RAG 项目最容易犯的错，是把注意力全放在模型上，结果真正的问题藏在数据治理里。
这就是差距。高分回答不是更复杂，而是更像一个真实项目。它让面试官听见了你的判断：你知道问题在检索，不在生成；你做的动作有针对性；你拿得出结果；你有复盘。
会名词的人很多，能把名词背后的工程矛盾讲清楚的人不多。
如果你想更进一步，甚至可以顺手带出你对 AI 工程化的理解，比如：
- 为什么不能只看 demo 效果，要建立离线评测集；
- 为什么检索质量不稳定时，Prompt 再怎么调也只是补丁；
- 为什么“先能跑”不等于“能上线”。
这类表达，会让面试官感觉你不是在做一个玩具项目，而是在做一个需要对结果负责的系统。
案例二：Agent 项目最容易说虚，怎么把“会用框架”讲成“会做系统”？
再看另一个高频问题：“你做过 Agent 吗？”
很多候选人的回答，一上来就是： “做过，我们用了多 Agent 架构，有 Planner、Executor、Memory，还支持工具调用。”
面试官内心通常会自动翻译成一句话：你用过现成框架，但我不知道你解决了什么。
Agent 相关项目的表达，最忌讳空。因为大家都能画架构图，但真正难的是：什么时候该拆 Agent，什么时候不该；工具调用失败怎么办；长链路任务如何观测；上下文如何裁剪；评估怎么做。
一个更有说服力的说法应该像这样：
我们不是为了追热点才做 Agent，而是因为原来单轮问答模式处理不了“跨系统查询+生成报告”这种任务。用户需要的是一句自然语言指令，系统能自动拆解步骤：先查数据库，再请求工单系统，再整理成周报。
最开始我们尝试一个大 Prompt 把所有工具都塞进去，结果发现两个问题：一是工具描述太多，模型选错工具的概率变高；二是链路一长，失败点很难定位。
所以后来我们没有盲目做多 Agent，而是做了一个轻量 Planner + Tool Executor 的两层结构。Planner 只负责拆步骤，Executor 负责参数校验、重试和错误回退。
这样改完以后，复杂任务成功率从 58% 提升到 79%，平均排障时间从半天缩到 40 分钟左右，因为每一步都有日志和状态记录。
复盘下来，我觉得 Agent 不是“角色越多越高级”，而是边界越清晰越可维护。
你看，这里面最值钱的不是“Planner”“Executor”几个词，而是你讲清楚了为什么一开始方案不行、为什么这样改、改完带来了什么。
如果你担心自己讲项目时容易飘，最简单的检查方式是：
把“我们用了 XXX 框架”这类句子删掉，再看剩下的内容能不能成立。
如果删完就没东西了，说明你讲的是工具，不是能力。
别只会说，最好能“现场证明”你会想：一个面试里能加分的代码例子
很多工程岗面试到后面，面试官会追问：“那你是怎么实现的？”
这时候，能给一个小而完整的代码片段，比空谈架构有说服力得多。尤其在 RAG 或 Agent 场景里，你不需要贴一整套系统，只要展示关键思路。
比如下面这个简化版的 RAG 检索重排逻辑，就很适合在面试里讲。它体现了三个工程意识：召回、过滤、排序。
from typing import List, Dict
from datetime import datetime
def retrieve_documents(query: str, vector_store, top_k: int = 8) -> List[Dict]:
# 1. 向量召回
candidates = vector_store.similarity_search(query, k=top_k)
# 2. 过滤过期文档
now = datetime.now().date()
valid_docs = []
for doc in candidates:
expire_at = doc.metadata.get("expire_at")
if expire_at and datetime.strptime(expire_at, "%Y-%m-%d").date() < now:
continue
valid_docs.append(doc)
# 3. 结合业务规则做简单重排
def score(doc):
semantic_score = doc.metadata.get("score", 0)
is_latest = 1 if doc.metadata.get("is_latest_version", False) else 0
doc_type_bonus = 0.2 if doc.metadata.get("doc_type") == "policy" else 0
return semantic_score + is_latest * 0.5 + doc_type_bonus
ranked = sorted(valid_docs, key=score, reverse=True)
return [
{
"content": doc.page_content,
"score": score(doc),
"title": doc.metadata.get("title", "unknown")
}
for doc in ranked[:3]
]
这段代码不复杂，但在面试里很好用。你可以围绕它讲三层内容：
- 第一层：为什么不能只依赖向量相似度，因为业务里“最新版本”比“语义最像”更重要；
- 第二层：为什么要过滤过期文档，这能减少模型“答得像但答错版本”的问题；
- 第三层：如果继续优化，可以把这个规则排序替换成学习排序或接 rerank 模型。
这时候，面试官会觉得你不是在背“RAG 四件套”，而是在真正理解一条链路里每一步如何影响最终答案质量。
真正加分的代码，不是炫技代码，而是能证明你理解工程权衡的代码。
你缺的不是资料，而是一个把零散知识变成“可表达资产”的系统
很多人准备 AI 面试时，习惯是这样的：刷帖子、看公众号、收藏 GitHub、抄几页术语解释，然后焦虑地发现自己“好像看了很多，真要说又说不出来”。原因很简单：你获得的是信息，不是结构；你记住的是结论，不是路径。
AI 领域尤其容易这样。今天流行 Vibe Coding，明天大家讨论规范驱动开发，后天又在比各种 AI 编辑器，再过几天 Agent 工程化、评测体系、RAG 新范式又冒出来。你如果只是追热点，最后脑子里就像开了 30 个标签页，没有一个真正闭环。
我一直觉得，一个好的学习仓库，真正有价值的地方不在“资料多”，而在于它能帮你做三件事：
- 把知识点放进一张可导航的地图里；
- 把热门概念还原成真实工程问题；
- 把前沿内容整理成可学习、可复习、可表达的材料。
这也是为什么我最近挺认可一类“成长型知识库”项目。它不只是堆链接，而是持续把 AI 工程师真正需要的内容往前推进：从大模型基础，到 RAG、Agent、工程化，再到开发模式变化、工具链对比、资源整理，甚至连新内容的补充和迭代都能看出维护者在认真做“查漏补缺”。
我挺看重一个细节：很多仓库一开始很热闹，后面就断更了；但真正有用的知识库，应该是会持续吸收新变化的。比如面向 AI 工程师的内容，不只是旧八股，而是会把新的开发范式、工具实践、行业讨论纳进来，再重新整理成适合学习和面试表达的结构。这种更新能力，本身就是它与“收藏夹”最大的区别。
你准备面试时，最怕的是“知道这个词，但说不出自己的理解”。
而一个好的知识系统，会逼你把“看到过”升级成“我能讲明白”。
你和 offer 之间，很多时候差的不是一个新知识点，而是一个能把旧知识重新组织起来的框架。
最后，给你 3 个马上能用的建议
最后，我想把这篇文章落到最实际的地方。
第一，别再背“标准答案”，把你做过的 3 个项目按 PJARR 五步法 重写一遍。每个项目控制在 2 分钟和 5 分钟两个版本。你会立刻发现，原来自己不是没内容，而是没结构。
第二，准备 AI 面试时，不要只记术语，要为每个高频主题补上 4 个问题：它解决什么问题？为什么这么选？踩过什么坑？结果怎么验证？
只要这四个问题能答出来，你的表达就会从“知道概念”变成“有工程判断”。
第三，给自己建一个“可表达知识库”。看完一篇关于 RAG、Agent、评测或工具链的内容，不要只收藏，试着用 5 句话写成你自己的版本。能复述，才算真正吸收；能举例，才算真正掌握。
如果你也在准备 AI 工程师面试，或者正在补齐 AIGC、LLM、Agent、RAG、AI 工程化这条线的知识，我建议你去看看这个持续更新的开源项目：
GitHub：github.com/zhouzhupian…
它不是那种看完就忘的“资料堆”，更像一套能帮助你建立知识结构、补齐盲区、练习表达的成长型仓库。你可以去点个 Star，提个 Issue，或者直接 PR 一起完善。也欢迎你留言聊聊：你面试里最难讲清楚的 AI 项目，究竟卡在哪一步？
