先看岗位，再确定准备范围
大模型应用开发、算法训练与推理系统岗位关注的工作不同。先把职位描述中的职责逐条写下来，标注自己做过、理解但未实践、还不熟悉的部分。本文重点是应用开发的项目表达，不是一份所有岗位通用的题库。
不要把一个教程项目包装成真实上线系统。可以明确说明是个人实验，再讲清楚数据、实现和验证方法；这比堆砌技术名称更经得起追问。
用一个真实项目串起回答
选择一个你能解释完整链路的项目，准备六项信息：用户遇到什么问题、输入与输出是什么、你负责哪部分、为什么这样设计、怎样验证、还有哪些限制。没有线上数据时，就说明是离线实验，不虚构准确率、并发量或商业效果。
例如介绍知识问答项目时，不要只说“我用了 RAG”。可以先说明资料范围、更新方式、回答需要带来源的原因，以及没有可靠证据时系统应如何回应。
RAG：把问题拆成可排查的环节
准备讲清楚资料处理、检索、上下文组织和答案生成之间的关系。面对答错的样本，先判断是资料里没有答案、检索没有找到、找到了但上下文不够，还是生成阶段错误使用了证据。
练习回答这几个问题：文档变化后怎样更新？怎么验证切分策略？检索结果无关时如何处理？权限不同的用户能否看到同一份资料？回答中引用的来源能否真正支持结论？先描述自己的实现，再说明尚未完成的部分。
智能体：先说明为什么需要工具调用
如果普通流程足以完成任务，不必为了“智能体”这个名称增加复杂度。面试时可以解释哪些步骤需要模型判断，哪些步骤应该由明确规则控制。
对会执行写入、发送或删除操作的工具，需要准备说明授权确认、参数校验、失败重试和重复执行保护。不要只展示一次顺利的演示；也要能解释工具超时或返回错误时会发生什么。
评测：用样本和失败案例说话
整理一组你有权使用的测试问题，覆盖普通问题、模糊问题、无答案问题和越权请求。为每个问题写清可接受的回答条件，而不是只看回答是否流畅。
对比方案时保持测试条件一致，并记录失败样本。若只有少量人工检查，应明确样本量与局限，不能把局部结果说成系统整体质量保证。把问题分类后，解释下一步会改数据、检索、提示还是流程。
成本与延迟：先测量，再谈优化
准备说明请求耗时主要出现在哪些步骤、输入长度怎样变化、哪些请求重复，以及失败重试是否放大成本。没有测量过的部分，坦率说明计划怎样观测。
提出缓存、缩短上下文或更换模型等方向时，也说明可能损失什么，以及怎样验证这个取舍。面试官通常还会继续追问异常路径；把这些边界提前整理出来，比单独记结论更有帮助。
把准备落到下一次练习
今天先完成一页项目说明和三个失败案例，再做一次模拟追问。可以用每日计划模板安排任务，用项目回答结构梳理经历。
在获得参与方同意、遵守面试规则的前提下，妙答鸭可帮助记录对话、整理参考思路和复盘卡点。它不替代技术实践，也不保证获得 Offer。