前阵子密集面了好几家头部互联网公司的大模型应用开发岗前后一共三轮技术面加一轮HR面。整个过程看下来最大的感受是这个岗位的考察重心已经从“会不会调Prompt”转移到了“能不能扎实做工程”。LangChain、Python、RAG、Agent、评估、部署这些关键词在每一轮面试里都会被反复拆开追问。这篇实录不写面经流水账而是把我看到的高频考点、现场卡壳的题、以及复盘后总结出的解题套路完整还原出来。无论你是刚开始学Python和大模型应用开发的新人还是已经有一定项目经验、准备跳槽的工程师这份记录应该都能帮你把复习路线理清楚。1. 大模型应用开发岗的面试画像与考察权重1.1 岗位核心需求不是会聊天而是会交付大厂挂出来的“大模型应用开发工程师”“LLM应用工程师”“AGI应用研发”这类岗位JD里通常写得很热闹但拆开看核心就三块一是基于RAG做知识库和问答系统二是基于Agent做工具调用和自动化流程三是把这些能力落地成稳定、可控、可观测的线上服务。很多候选人容易误判岗位以为面试重点是背模型参数、聊Prompt技巧。实际上面试官更关心的是你拿到一个业务问题后能不能拆解成“需要哪些组件、每个组件怎么选型、数据怎么组织、效果怎么量化”。比如同样是做客服问答有的候选人只会说“我用LangChain搭了个管道”有的候选人会从文档拆分的粒度讲到检索召回率再讲到命中后如何用重排模型修正排序。后一种回答面试官眼里明显有光。面试中反复出现的高频考点也很集中LangChain和LangGraph的使用与原理、基于LangChain的RAG流程、Python基础与并发、FastAPI服务化、Agent中间件和工具调用、向量数据库选型、评估体系。这篇文章后面每一节都会覆盖到。1.2 面试轮次与能力权重我遇到的典型流程是两到三轮技术面加一轮HR面部分团队还会先发一份笔试题或在线代码测评。技术面基本按照“基础代码 - 项目深挖 - 系统设计”的梯度递进。轮次主要考察点常见时长淘汰特征第一轮Python、数据结构、LangChain基本使用45-60分钟基础题卡壳代码写不顺第二轮RAG项目细节、Agent设计、评估指标60-90分钟只会背概念讲不清取舍第三轮系统设计、稳定性、成本、协作60分钟方案空洞缺少可落地细节HR面稳定性、团队协作、学习能力30分钟价值观或沟通明显不匹配从权重上看代码和工程能力的占比远高于“对AI模型理论的了解程度”。我一个朋友把Transformer结构背得滚瓜烂熟结果面试官只问了一句“你做过的项目里模型效果是怎么评测的”他就愣住了。这个细节很能说明问题大模型应用开发本质是软件工程不是模型训练面试官要的是能交付的人。2. Python基础考察每一道送分题都可能翻车2.1 高频Python问题与翻车点大模型应用开发岗位的代码面不会考特别偏门的算法但会把Python语言本身的特性挖得很细。因为LangChain也好、LangGraph也好底层都是Python重度工程你如果连基本的语言机制都解释不清楚后面很难让人相信你能看懂框架源码或排查业务问题。我遇到的几个高频题可以拿出来说一说。第一个是可变默认参数。面试官给出一段代码def add_item(item, items[]): items.append(item) return items print(add_item(a)) print(add_item(b))如果你只说“输出是[a]和[a,b]”其实还没拿到分。关键是解释为什么默认参数在函数定义时只创建一次所有调用共享同一个列表对象。正确的写法是def add_item(item, itemsNone)函数体里再判断if items is None: items []。这个知识点本身简单但能看出候选人有没有真正理解Python的对象模型。RAG工程里经常需要维护上下文缓存、中间结果列表如果对可变对象和引用关系不敏感很容易写出隐蔽的内存共享Bug。第二个是GIL。面试官通常追问“Python多线程到底能不能加速计算密集任务”。答案是线程在CPU密集场景下受GIL限制同一时刻只有一个线程执行Python字节码所以改用多进程或异步。但在IO密集场景比如并发调用大模型API、读取多个文档GIL影响很小用asyncio或者线程池都是合理选择。这个点也直接连着后面的LangChain异步调用、FastAPI并发处理属于必背项。第三个是装饰器和上下文管理器。我面过一个团队面试官直接让用手写一个带重试的装饰器。这在大模型应用里太常用了因为调用LLM接口经常遇到限流、超时、临时报错。我当时写了一版带指数退避的重试装饰器面试官立刻追问“如果被装饰函数支持异步怎么办”这就逼着你现场再写一套async def的包装逻辑。所以复习Python不能只看语法要把functools.wraps、asyncio.wrap这类细节都过一遍。还有深拷贝浅拷贝、生成器与迭代器的区别、__call__和闭包、with语句的实现等几乎都是同样的考察方式先问现象再问为什么最后让你现场应用。这几年用LangChain开发的人多了大家反而把Python基本功落下了这其实是面试里淘汰率最高的一块。2.2 手写并发代码复盘IO密集与asyncio有一轮面试让我现场实现一个“并发抓取多篇文章内容并统计关键词出现次数”的小功能。看起来不复杂但里面有几个容易暴露水平的细节。我当时的解法是用asyncio加aiohttp做并发请求再结合LangChain的文本切分思路最后用普通字典计数。核心代码长这样import asyncio import aiohttp async def fetch(session, url): async with session.get(url) as response: return await response.text() async def main(): urls [https://example.com/doc1, https://example.com/doc2] async with aiohttp.ClientSession() as session: pages await asyncio.gather( *(fetch(session, url) for url in urls), return_exceptionsTrue ) counts {} for page in pages: if isinstance(page, Exception): continue for word in page.split(): counts[word] counts.get(word, 0) 1 print(counts) asyncio.run(main())写完后面试官没有立刻说对错而是连环追问如果某些请求特别慢整体耗时会被拖住怎么办gather里return_exceptionsTrue的作用是什么如果采集任务变成CPU密集比如PDF解析、图片OCR你还会用asyncio吗。这几个问题分别考的是超时控制、异常隔离、以及对GIL和进程模型的理解。正确思路是给每个请求加asyncio.wait_for设置合理超时时间CPU密集部分使用进程池ProcessPoolExecutor或者把任务拆到独立worker里而不是硬塞进事件循环。比如你用RapidOCR这类开源OCR工具做文档解析时模型推理本身吃CPU很厉害如果和Web服务跑在同一个进程里很容易把CPU打满。实际情况中我们通常用独立的OCR服务或任务队列来解决而不是靠Python的异步魔法硬扛。2.3 环境准备和依赖管理也是隐性考点面试前把本地环境搞好是基本盘但很多人忽略这一点。我见过不少候选人简历上写着精通LangChain结果让他共享屏幕跑个Demo连虚拟环境都没有包装得乱七八糟这印象分直接归零。大模型应用开发的本地环境我建议按这套标准来准备先装Python最好用官网发布的稳定版本不要用系统自带的旧版本接着配好虚拟环境工具现在uv是一个非常高效的选择创建环境比venv快不少依赖解析也稳。语言模型相关的依赖一般是openai、langchain、langchain-openai、langgraph、langchain-community操作文档时还会用到pypdf、docx、redis等库。Linux服务器上部署时很多团队会直接用Docker。面试官可能问“你知不知道numpy、opencv这类包在Docker里为什么容易装失败”答案是很多二进制包需要系统库支持比如OpenCV依赖libgl、libglib等Python安装包本身装完后还需要apt装底层依赖。如果迁移到RapidOCR场景问题更明显底层推理引擎要额外下载模型文件和动态库CPU占用还很大。在这类问题上你如果能说出“我在Ubuntu容器里装OpenCV时遇到过libGL.so.1缺失靠安装libgl1解决”这种真实经历面试官会觉得你真的是在工程线上待过而不是只会跟着教程跑demo。3. LangChain与Agent考点从RAG链路到LangGraph编排3.1 为什么大厂考LangChain考的是抽象表达能力LangChain在大模型应用开发里几乎成了标配。不过面试官很少直接问“LangChain是什么”而是会从抽象层面去考。正确的理解方式是LangChain提供了一套标准化的接口和组合方式让你把模型、提示词、文档、检索器、工具串成一个可组合、可扩展的管道。LangChain的核心抽象是Runnable协议。我用很多之后最大的体会是它让组件之间的拼装变得非常自然常见的LCEL写法是chain prompt | llm | output_parser这条管道里的每一步都实现了Runnable接口可以统一支持同步调用invoke、流式输出stream、批量调用batch以及对应的异步版本。面试官如果问你LangChain和LangGraph怎么选核心思路也就基于这个差异LangChain适合线性确定性流程LangGraph适合有分支、循环、状态流转的复杂Agent场景。另一个高频坑是版本差异。LangChain从0.1迭代到0.2、0.3老的API变化非常大。如果面试时还在说from langchain.llms import OpenAI或者继续用旧版LLMChain面试官就知道你很久没有跟版本了。现在更常见的做法是from langchain_openai import ChatOpenAI模型调用直接用ChatOpenAI(...).invoke(...)。这个细节提醒我们看LangChain项目一定要先锁定版本再做语法兼容。3.2 基于LangChain的RAG流程完整搭建RAG是大模型应用开发面试的核心题几乎没有一场不考。基于LangChain的RAG流程完整链路就是加载、切分、向量化、存储、检索、生成这六步每一环都可以深挖。先看文档加载。常用的PyPDFLoader、TextLoader、Docx2txtLoader解决的是不同文件格式的读取。这里有个经验PDF如果本身是扫描件直接用PyPDFLoader只能拿到空白页必须走OCR流程。很多实际项目里Pdf到文本就已经损失了很多信息所以要在加载阶段就做好质量校验。再看文本切分。最常用的是RecursiveCharacterTextSplitter核心参数是chunk_size和chunk_overlapfrom langchain_text_splitters import RecursiveCharacterTextSplitter splitter RecursiveCharacterTextSplitter( chunk_size512, chunk_overlap80, separators[\n\n, \n, 。, , , ], )chunk_overlap的意义在于避免一句话在中间被切断让上下文信息有一定的重叠。面试官经常问“chunk_size是不是越大越好”答案是否定的。块太大向量化之后语义被稀释检索不精准而且占用的上下文窗口也更多块太小语义信息不完整检索出来的片段经常读不懂。实际项目里我更倾向于从512起步在评测集上分别跑256、512、768看哪个分块粒度最贴合业务文档结构。向量化环节涉及Embedding模型选型。线上的选择往往是开源模型和商业API的权衡。开源部署要考虑显存和推理延迟商业API要考虑成本和数据合规。检索端最常用FAISS做本地方案生产环境则更多用Milvus、Qdrant或pgvector。面试时讲清楚自己的选型依据效果比堆名词好得多。最后生成环节往往要做Prompt设计把检索到的上下文放入系统提示词中。需要提醒的是生成不是终点还要做引用溯源和答案质量检查否则用户很容易被幻觉误导。3.3 MultiVectorRetriever等高级检索是加分点只讲最基础的向量相似度检索已经很难拿高分了。面试官更想听你在检索质量上做过哪些进阶优化。MultiVectorRetriever就是一个能明显提分的知识点。它的核心思路是“用小文档做检索用大文档做生成”或者“用摘要向量做召回返回原始原文”。这在行业里常常被称为small-to-big或parent-document理念。举个例子。一份合同里有几十页我们把它切成多个小块分别向量化。用户问“违约责任怎么约定”最匹配的可能是某个摘要片段的向量但最终喂给大模型的不应该只有那个摘要而应该是包含这段内容的完整条款段落。这样既保证了召回命中率又保证了生成的上下文足够完整。MultiVectorRetriever的典型配置就是同时维护一个向量库和一个文档存储检索时先根据向量找到对应ID再去文档存储里取出完整文档。它的兄弟方案叫ParentDocumentRetriever思路大同小异。面试官通常不会只问“你会不会用”而是追问“什么场景下必须用这种方案”。这时候就答当文档信息高度跨段落分布、单块512字符无法承载完整答案时就必须做父子结构。如果业务文档以FAQ或独立条目为主直接切块向量化也能工作得很好就不需要上复杂方案。3.4 LangGraph、function calling与Agent框架对比Agent相关的问题在面试里的比重逐年上升。比起单纯考LangChain的AgentExecutor现在面试官明显更偏好LangGraph。原因很简单LangGraph把Agent变成了一张显式的状态图节点对应模型调用或工具执行边对应状态流转你能在里面实现循环、条件分支、人工介入可控性比老的Agent框架高很多。一个非常小的LangGraph流程代码可以这样写from typing import Annotated, TypedDict from langgraph.graph import StateGraph, START, END from langgraph.graph.message import add_messages class AgentState(TypedDict): messages: Annotated[list, add_messages] def call_model(state): return {messages: [llm.invoke(state[messages])]} def run_tool(state): return {messages: [tool.invoke(state[messages][-1].content)]} graph StateGraph(AgentState) graph.add_node(agent, call_model) graph.add_node(tool, run_tool) graph.add_edge(START, agent) graph.add_conditional_edges(agent, should_continue, {continue: tool, end: END}) graph.add_edge(tool, agent) app graph.compile()这个结构里模型决定要不要调用工具工具结果再返回给模型整个循环依赖状态完成。面试时能画出这张图并且说明为什么需要循环而不是一次性调用基本就过关了。热点框架方面现在大家还会对比LangChain的DeepAgents、Claude的Agent能力等。实际感受是这类方案从Demo到生产还差得远差距主要在三块一是长任务中的计划稳定性Agent很容易在步骤变多后偏离主线二是工具调用的容错性真实API经常返回异常结构或超时框架的默认行为不够鲁棒三是上下文压缩多轮工具调用后历史消息长得可怕必须做裁剪、摘要、状态压缩。能聊出这些坑代表你真的在用Agent而不是只看过演示视频。4. 真实面试题拆解RAG、Agent可控性与服务化4.1 千万级文档知识库设计题这是第三轮系统设计的高频题基本描述是“公司有千万级文档要做成知识库问答你怎么设计”。如果只答“用向量数据库加LangChain”就太单薄了面试官要的是完整链路和工程取舍。我的答题框架一般分五层。第一层是数据接入层处理PDF、Word、网页、音视频转写等核心是解析质量。第二层是文档处理层做清洗、OCR、去重、版面分析、表格转Markdown然后按业务需要选择普通切块或父子文档结构。第三层是索引层选择混合检索。只用向量检索的问题很明显合同编号、版本号、人名这类精确词向量化后经常召回不准确所以要加BM25关键词检索把两部分结果融合。第四层是重排层用一个交叉编码器对召回的候选做精细排序把最相关的片段顶到前面。第五层是服务层处理多租户隔离、权限过滤、缓存、流式输出。候选人这里最容易暴露的最大问题是没有评估概念。面试官追问“你怎么知道你的方案比另一个方案好”时最好的回答是准备一批带答案的测试集计算RecallK、MRR、Answer Accuracy这些指标。RAG项目的核心不是选某个炫酷组件而是有一个能持续衡量效果的数据闭环。4.2 Agent幻觉和可控性怎么答Agent类岗位的面试中“你怎么控制幻觉、怎么保证Agent不乱跑”几乎必考。这个问题的回答质量直接拉开差距。我的建议是按“事前提示约束、工具结果强校验、人工审批兜底、事后可观测”四个层级回答。事前提示约束是最基础的让Agent只根据工具返回结果作答不编造数据。工具结果强校验是指在调用搜索引擎、数据库、计算器这类工具后必须检查返回内容是否包含有效数据简单场景可以解析JSON字段重要场景可以加规则校验或小模型验收。人工审批兜底在业务里尤其重要例如自动修改配置、自动发消息、自动下单这类高风险动作必须加一个人工确认节点LangGraph里可以用interrupt实现暂停等用户确认后再继续执行。事后可观测则是把所有推理轨迹记录下来这一步排障的时候特别重要。我还会补一个观点不要追求Agent完全自由发挥而是要给它明确的工作流边界。能用一个线性工作流解决的问题没必要上复杂的Agent循环。Agent越自由幻觉和失控风险越大这是实践换来的教训。4.3 FastAPILangChain工程化方案现在很多团队已经不满足于只做一个Notebook里的Demo了常见架构是FastAPI做服务层LangChain/LangGraph做编排层再配合任务队列和向量库。这个组合在面试里被问到的概率非常高。最基础的流式接口是这样from fastapi import FastAPI from fastapi.responses import StreamingResponse from pydantic import BaseModel app FastAPI() class ChatRequest(BaseModel): question: str session_id: str | None None app.post(/chat) async def chat(req: ChatRequest): async def event_stream(): async for chunk in chain.astream({question: req.question}): yield fdata: {chunk.content}\n\n return StreamingResponse(event_stream(), media_typetext/event-stream)这个接口背后要思考的点非常多并发控制怎么做、用户会话隔离怎么做、超时和重试策略是什么、连续输出中断后怎么补偿、日志和链路追踪怎么接。另一个工程坑是同步的LangChain调用放在异步FastAPI里会阻塞事件循环所以要么使用astream要么把耗时调用放到线程池。这些都是生产环境必须处理的细节面试官听到你能主动聊出来就会认为你不是只写过单机Demo。4.4 成本评估与可观测性现在团队对大模型应用的线上成本非常敏感面试的最后一轮不放过大模型服务商务成本所以系统设计题往往要求你顺带估算成本。比如一个RAG问答服务用户每次提问涉及向量检索和一到两次模型调用。假设请求量是每日十万次单次问答平均消耗几千token按主流API价格估算一天的纯模型成本就是不小的一笔数字。面试时候可以算出单请求成本、月成本、缓存之后节省的比例。常用优化方案包括对相似问题做语义缓存、用便宜的小模型做意图识别和路由、把长文档预计算压缩为摘要、减少不必要的工具调用。可观测性方面推荐聊Langfuse这一类LLM可观测工具。它能把每一次输入的Prompt、输出的Token数、检索来源、模型版本、延迟全部记录下来。我在面试里讲过一个排障案例用户投诉答案不准通过观测平台发现其实检索召回的段落是正确的但Prompt里上下文顺序不对导致模型挑错了重点。这个案例一讲出来面试官立刻就觉得你对线上质量有真实的管理经验。5. 三轮技术面现场还原与解题思路5.1 第一轮被追问的RAG召回问题第一轮面试我经历过一次很典型的追问。面试官让我讲一个RAG项目我按照习惯讲完加载、切分、向量化、检索、生成之后他突然问“如果用户的提问是‘合同里违约金怎么写’你召回到的内容却是合同基本条款你会怎么排查。”这个问题考的是定位问题的能力。我当时差点顺着说“换一个Embedding模型”但后来意识到他要的是系统性排查。正确的排查思路是先看召回结果本身是向量检索返回了错误片段还是向量检索没问题但重排后把错误片段排到了前面。然后把“第七百个文档”这一条从输入到输出的链路每个环节都采样一遍。如果Query在语义上和合同违约责任条款确实相似但未召回问题可能出在切分粒度上如果召回了但没进最终上下文问题可能出在重排或Prompt组装。面试官听完后追问了一句“你能给出一个具体的数据指标来验证你的修改有效吗”这时我讲了RecallK和MRR这两个指标的含义并说明我会在固定的测试集上对比修改前后的检索排名。这样回答下来他基本就没有继续在这个问题上纠结了。5.2 第二轮项目深挖时怎么讲清楚第二轮项目深挖面试官会把你简历上每一个技术点都撕开看。这里最容易犯的错是把项目讲成“功能清单”比如“我用LangChain实现了问答系统、接入了飞书、支持上传PDF”听上去什么都做了但每块都很浅。正确的讲法要有主线业务问题是什么、技术方案为什么这么选、上线之后效果如何衡量、最难的Bug是什么。举一个我亲历的例子客服知识库上线后很多用户问题根本不在预设文档里比如问“我最近浏览器打不开网页怎么办”文档库里没有完全一样的FAQ。方案是加一个“未命中处理”分支先做检索置信度判断低于阈值就转人工或者引导用户重述。这个分支上线后用户满意度提升转人工率下降。讲这种有数据、有决策过程的项目效果远远好于罗列一堆框架名。面试官也会问团队协作和迭代机制。比如“你做这个系统Prompt由谁维护模型升级怎么办”。现在的成熟团队会把Prompt纳入版本管理跟代码一起走评审发布模型升级时先在评测集上跑回归再灰度放量。这个回答体现的不是代码能力而是工程成熟度在大模型岗面试中非常加分。5.3 第三轮系统设计与跨团队协作第三轮系统设计面试官经常给一个模糊需求比如“公司内部要做一个帮工程师查代码文档的AI助手”然后让你从零设计。这个题我会按四步走。第一步澄清需求用户主要查什么、对答案时效性要求多高、是面向内部几千人还是外部千万用户。第二步确定架构文档采集管道、解析服务、向量库、重排服务、问答服务、缓存层和日志系统。第三步说明关键细节代码类文档用普通文本切分很容易切碎所以最好按函数、类、文件三个层级组织用MultiVectorRetriever做父子检索。第四步估算资源和成本每天查询量、平均token消耗、向量库存储量、GPU/API成本。跨团队协作方面面试官还会问“如果你是核心开发怎么推动这个项目落地”。可以讲怎么跟业务方收集高频问题、怎么让文档团队提供高质量数据、怎么和平台团队申请计算资源。大模型项目本质上是数据和工程协同的项目单靠一个人调Prompt是做不成规模的。5.4 反问环节技术面最后基本都会留时间给你反问。很多人问的是“团队用什么框架、加班多不多”这类问题没错但很难体现专业度。我更建议问三个层面的问题。第一层是业务层面比如“你们当前最典型的一个AI应用场景是什么用户最不能接受的失败是怎样的”。这个问题能帮你了解岗位的真实业务边界。第二层是技术层面比如“你们线上RAG的召回评估是怎么做的有固定的评测集吗”。这个问题能判断团队是不是工程化成熟。第三层是成长层面比如“这个岗位未来半年最需要突破的技术难点是什么”。这三个问题问下来面试官通常会觉得你是有备而来而不是来碰运气的。6. 备面避坑清单与30天冲刺路线6.1 大厂面试常见淘汰点清单整理自己和其他朋友被淘汰的经历有一些问题高度重复。核心问题往往不是技术难题不会而是暴露在几个基础能力短板上。淘汰原因典型表现改善方式只背API不聊原理能说出LangChain组件名但说不清为什么这样设计多画组件关系图多问自己“为什么”项目没有评估项目效果全靠“感觉还行”建立测试集计算Recall、MRR、准确率环境准备不过关现场跑Demo时缺包、版本冲突用虚拟环境加锁文件提前跑通完整流程缺少异常处理意识不聊超时、限流、重试、并发所有系统题都主动补充健壮性设计版本老化还在用LangChain 0.0.x的旧API对齐最新稳定版注意兼容性变化还有一个比较隐蔽的淘汰点是“技术选型没有理由”。比如候选人说“我用Milvus做向量库”面试官问“为什么不用PGVector”答不上来。哪怕你只是技术方案评审时选型也要能说出理由比如数据规模、部署复杂度、查询性能、运维成本。不需要选型最完美的方案但一定要能论证方案。6.2 30天冲刺路线如果你准备时间有限我建议按30天做一个比较紧凑的冲刺计划。第一周解决环境和基础问题装好Python和虚拟环境配置好VS Code安装numpy、sklearn、langchain、langgraph等常用依赖跑通一个最简单的LCEL调用。第二周做RAG专项从PDF加载、文本切分、Embedding、向量存储到检索自己动手搭一个带重排的知识库问答项目并用测试集评估。第三周做Agent专项用LangGraph实现一个能调用搜索、计算器、数据库的Agent加上人工确认节点把幻觉控制方法落到代码里。第四周做系统设计和模拟面试把项目整理成有逻辑、有数据的故事线自己拿录音笔模拟面试复盘每一轮的卡壳点。这中间无论跟哪个课程、看哪套教程都要记住“跟课只能入门独立复现才能过面试”。比如现在有Spring AI加DeepSeek的实战课很好的入门材料但面试官不会因为你跟完课就认可你最终还是要看你自己的项目和思考。6.3 最后再分享几个实操体会这些体会是我自己踩坑踩出来的不一定写进教材但很值得参考。选型上不要为了炫技引入过多新框架。RAG项目里最优先考虑的永远是数据质量和评估闭环而不是把LangChain、LlamaIndex、向量库、Agent轮番换一遍。一个稳定的短链路方案配合靠谱的数据清洗往往比一个复杂的长链路方案更有效。线上环境里一定要给所有外部调用设置超时和重试。LLM接口有时候会慢到超出你的容忍度不设置超时一个异常请求就能占住一个worker很久最后把整个服务的排队时间拉得很长。我现在的习惯是便宜的小模型优先做路由把请求分类后分给对应处理逻辑既能降低成本也能减少主链路被无关问题干扰的概率。还有一个细节是Log。Agent类应用的排查比普通接口难很多因为没有日志就等于黑盒。建议每一步模型调用、工具调用、检索结果都打上结构化日志后续无论做评测、复盘还是面试讲项目都有据可依。面试讲项目的时候把日志和评估数据拿出来会明显比单纯讲“我做过”更有说服力。大模型应用开发的面试变化很快但底层逻辑还是那句老话把一个真实问题解决到位比泛泛了解一堆新技术更有价值。准备的时候多一些“为什么”少一些“背和抄”你在面试里自然就能脱颖而出。