20题逐题追问版

大约 27 分钟

《AI 应用开发岗面试标准背诵稿：20题逐题追问版》

这篇怎么用效果最好

不要“一口气读完”，按下面节奏练：

每次选 3~5 题，先读主答。
再把追问连续说一遍，训练抗压表达。
最后用“一句话加分总结”做收尾。

建议搭配模拟面试问答做实战演练。

1. 你怎么理解 AI 应用开发岗？

主问题标准回答：
AI 应用开发岗本质上是把大模型能力做成可落地的业务系统，而不是单纯调用模型 API。
它既要懂大模型相关能力，比如 RAG、Prompt、工具调用、输出控制，也要有扎实的后端工程能力，比如接口开发、异步任务、缓存、监控、权限和稳定性治理。
所以这个岗位本质上是“AI 能力 + 工程化落地 + 业务场景结合”。

追问 1：和普通后端开发最大的区别是什么？

回答：
普通后端主要处理确定性逻辑，输入输出相对稳定；AI 应用开发接入的是一个概率型组件，大模型输出不稳定，所以系统设计里要重点考虑约束、校验、重试、兜底和评估。
也就是说，AI 应用开发比普通后端更强调“和不确定性组件打交道”的能力。

追问 2：和算法岗的区别是什么？

回答：
算法岗更偏模型本身，比如训练、微调、推理优化和评测；AI 应用开发更偏模型之上的业务系统建设。
算法岗关注“模型能不能更强”，应用开发岗关注“模型怎么在真实业务里稳定可用”。

追问 3：这个岗位最核心的能力是什么？

回答：
我觉得有三块：

后端工程基础
对大模型应用链路的理解
业务落地和稳定性治理能力
因为最终不是做 demo，而是要做能上线、能监控、能排障的系统。

一句话加分总结：
AI 应用开发的重点不是“调用模型”，而是“把不稳定的模型能力做成稳定的业务能力”。

2. 为什么 AI 应用开发岗还需要后端基础？

主问题标准回答：
因为大模型只是系统中的一个能力组件，真正交付给用户的是完整服务。
实际项目里会涉及接口设计、数据库、缓存、异步任务、文件处理、权限控制、日志监控、告警、限流和成本优化。
如果没有后端基础，就很容易停留在“模型能跑通”，而做不到“系统能上线、能稳定运行”。

追问 1：你觉得后端能力在 AI 项目里最常用在哪？

回答：
我觉得最常用在四个地方：

文档上传、解析、向量化的任务链路
问答接口和模型服务封装
缓存、限流、监控和日志
权限控制和多租户隔离
这些其实都很偏工程落地。

追问 2：你原来的后端经验怎么迁移到 AI 应用开发？

回答：
迁移点很多，比如：

接口开发能力可以迁移到模型服务封装
异步任务经验可以迁移到文档处理和 embedding 流程
缓存经验可以迁移到问答缓存和检索缓存
权限和审计经验可以迁移到知识库隔离和安全治理
所以后端基础其实是 AI 应用工程化的重要底座。

追问 3：如果只有 AI 知识，没有工程能力，会有什么问题？

回答：
那很容易做出 demo，但难以上线。
常见问题是：接口不稳、并发顶不住、模型超时没兜底、缓存没设计、权限有漏洞、日志不全、线上出了问题排查困难。
所以 AI 项目最终拼的还是工程能力。

一句话加分总结：
AI 应用开发的“AI”决定上限，“后端工程能力”决定能不能真正上线。

3. 什么是 RAG？完整链路是什么？

主问题标准回答：
RAG 是检索增强生成，核心思想是在模型生成前，先从外部知识库检索相关资料，再把这些资料作为上下文提供给模型回答。
这样可以减少幻觉，并且让系统具备基于最新知识回答的能力。
完整链路一般包括：文档上传、解析清洗、chunk 切分、embedding 向量化、向量入库；在线查询时包括用户提问、query 改写、检索召回、rerank、Prompt 拼接、模型生成和结果返回。

追问 1：RAG 相比直接问模型最大的价值是什么？

回答：
最大的价值有三个：

降低幻觉
支持外部知识实时更新
让答案更可追溯
因为模型参数不是实时更新的，而 RAG 可以让它结合企业自己的最新资料回答。

追问 2：RAG 一定能解决幻觉吗？

回答：
不能完全解决。
RAG 可以显著降低“无依据乱答”的情况，但如果检索本身错了，或者上下文噪音太大，模型还是可能基于错误材料生成错误答案。
所以 RAG 是降低风险，不是彻底消灭风险。

追问 3：你觉得 RAG 最容易出问题的环节是什么？

回答：
我觉得最容易出问题的是检索前后的衔接：

前面是 chunk 和 embedding 是否合理
中间是 query 是否能召回正确内容
后面是给模型的上下文是否干净
很多看起来像“模型答错”的问题，本质上其实是“喂给模型的内容不对”。

一句话加分总结：
RAG 的本质不是“加一个向量库”，而是“给模型提供更可信的外部证据”。

4. 文档为什么要切 chunk？怎么切？

主问题标准回答：
文档切 chunk 是因为长文档直接检索效果通常不好。
如果整篇文档太长，语义会很混杂，召回时不容易精准命中；切成 chunk 后，每个片段语义更集中，更适合做向量检索和拼接上下文。
切分方式常见有固定长度切分、按段落切分、按标题层级切分、带 overlap 的滑窗切分，以及更复杂的语义切分。
切得太大容易噪音多，切得太小又容易丢上下文，所以需要结合业务场景调优。

追问 1：overlap 为什么有用？

回答：
overlap 是为了避免关键信息刚好出现在 chunk 边界处，被切断后语义不完整。
加一点重叠可以增强上下文连续性，提高检索命中率。

追问 2：chunk 越小是不是越好？

回答：
不是。
chunk 太小虽然语义更聚焦，但容易信息不完整，模型拿到后可能无法形成完整答案；
chunk 太大又会带来噪音和 token 浪费。
所以 chunk 设计本质是“召回精度”和“上下文完整性”的平衡。

追问 3：实际项目里怎么调 chunk？

回答：
我一般会结合三点：

文档结构特点，比如是不是标题层级明显
问题类型，是细粒度问答还是总结类问答
badcase 表现
如果发现检索总是召回不完整内容，可能 chunk 太小；如果总召回大段无关内容，可能 chunk 太大。

一句话加分总结：
chunk 设计不是纯参数问题，本质上是在做“检索粒度设计”。

5. Embedding 的作用是什么？

主问题标准回答：
Embedding 的作用是把文本映射成向量，让语义相近的文本在向量空间中距离更近。
这样系统就可以基于语义相似度做检索，而不是只依赖关键词匹配。
在 RAG 里，通常会把文档 chunk 预先转成向量存储，用户提问时再把 query 转成向量做相似度检索。

追问 1：为什么不用关键词检索就够了？

回答：
关键词检索适合字面一致的场景，但用户真实提问常常会有同义表达、口语化表达、缩写、别称，这时候纯关键词容易漏召。
embedding 可以更好地处理“说法不同但意思相近”的问题。

追问 2：embedding 模型怎么选？

回答：
主要看几个维度：

是否适配中文或目标语言
是否适配目标领域
语义检索效果
向量维度和成本
延迟和吞吐
如果业务是垂直领域，还要关注专业术语理解能力。

追问 3：embedding 一定越大越好吗？

回答：
不一定。
更大的模型可能效果更好，但成本、延迟和存储开销也更高。
实际要结合业务规模和收益做平衡，不是单纯追求最大最强。

一句话加分总结：
embedding 的核心价值是把“文字相似”升级成“语义相似”。

6. topK 和 rerank 分别解决什么问题？

主问题标准回答：
topK 主要解决“先召回哪些候选内容”，它偏向召回阶段；
rerank 主要解决“这些候选里谁更相关、顺序该怎么排”，它偏向精排阶段。
一般流程是先通过向量检索拿到 topK 候选，再通过 rerank 模型做更精细排序。
这样可以同时兼顾召回率和最终精度。

追问 1：为什么不直接只用 rerank？

回答：
因为 rerank 一般计算更重，不适合直接在全库上跑。
所以通常先用向量检索快速缩小候选范围，再用 rerank 精排，这样性能和效果更平衡。

追问 2：topK 应该设多大？

回答：
没有固定值，要根据知识库规模、文档密度和 rerank 能力来调。
topK 太小可能漏掉正确答案，太大则会增加噪音和后续成本。
实际通常通过测试集和 badcase 调参。

追问 3：如果 rerank 后还是不准怎么办？

回答：
那要继续往前排查：

query 是否表达清楚
embedding 是否适配
chunk 是否合理
文档内容本身是否可检索
因为 rerank 不是万能的，它只能在已有候选里重排，不能凭空补回没召回到的内容。

一句话加分总结：
topK 决定“有没有机会答对”，rerank 决定“最后能不能更稳地答对”。

7. 幻觉怎么处理？

主问题标准回答：
幻觉是大模型应用里的核心风险之一。
我通常会从五个层面处理：

提高检索质量：减少给模型错误或无关上下文
Prompt 约束：明确要求只能基于资料回答，资料不足就拒答
参数控制：降低 temperature，减少发散
引用来源：让答案和证据绑定
后处理和兜底：高风险场景加规则校验或人工审核

核心思路不是相信模型“自己不胡说”，而是从系统层面减少它胡说的机会。

追问 1：RAG 做了是不是就不会幻觉了？

回答：
不会。
RAG 只是降低幻觉，不是消灭幻觉。
如果检索错了，模型还是会基于错误资料生成“看起来合理”的答案，所以检索质量特别关键。

追问 2：什么时候你更愿意拒答？

回答：
当证据不足、相似度太低、召回片段很弱，或者场景风险高时，我更愿意拒答。
因为在企业场景里，错误回答的代价往往比“不回答”更高。

追问 3：怎么判断幻觉有没有降低？

回答：
可以做专门评估：

人工标注测试集
badcase 集
引用正确率
无答案问题上的拒答准确率
用户追问率和投诉率
不能只凭主观感觉判断。

一句话加分总结：
幻觉治理本质上是一个系统工程，不是单靠一句 Prompt 就能解决。

8. 检索不到内容怎么办？

主问题标准回答：
检索不到内容时，不能让模型自由发挥。
我通常会设置相似度阈值和最小证据门槛，如果没有足够可信的上下文，就触发拒答或兜底逻辑，比如提示知识库中暂无相关信息，并引导用户补充条件。
另外我会记录这类未命中问题，用来补知识库和优化检索链路。

追问 1：相似度阈值怎么定？

回答：
一般不会凭感觉定，而是基于测试集和实际 badcase 去调。
看不同阈值下，答对率、拒答率、误答率怎么变化，再结合业务风险取平衡。

追问 2：拒答会不会影响用户体验？

回答：
会有影响，但比错误回答更可控。
所以好的拒答不是简单说“不知道”，而是要给下一步引导，比如推荐相关问题、提示补充条件、或者转人工。

追问 3：怎么区分“真没答案”和“检索没做好”？

回答：
需要结合知识库覆盖率和检索链路排查。
如果知识里明明有，但一直检索不到，那是检索问题；
如果知识库本身确实没有，那才是真未覆盖。
所以未命中问题要分类分析，而不是一概当成“没有内容”。

一句话加分总结：
未命中处理不是简单拒答，而是知识库迭代和产品体验优化的重要入口。

9. 如何限制模型只基于知识库回答？

主问题标准回答：
限制模型只基于知识库回答，一般要从四层做控制：

Prompt 约束：明确只能依据提供资料回答
上下文控制：只传可信检索片段，减少噪音
拒答机制：资料不足时不允许强答
后处理校验：要求引用来源，必要时校验答案和证据是否一致

高风险场景下，不能只相信模型会听话，必须靠系统机制兜住。

追问 1：只靠 Prompt 可以吗？

回答：
通常不够。
Prompt 可以帮助约束，但模型仍可能借助自身参数知识补全，所以还需要上下文控制、拒答和后校验一起配合。

追问 2：如果模型还是补了知识库之外的内容怎么办？

回答：
那可以通过引用约束和后处理识别。
如果发现关键结论没有对应引用，或者答案出现上下文中不存在的关键实体，就可以判定为风险回答，进一步重试或拦截。

追问 3：为什么引用来源有帮助？

回答：
因为引用把“答案”和“证据”绑定起来了。
用户更容易判断可信度，系统也更容易做校验和审计。

一句话加分总结：
真正可靠的做法不是“要求模型听话”，而是“即使它不完全听话，系统也能把风险拦下来”。

10. Prompt 怎么设计？

主问题标准回答：
我设计 Prompt 通常会包含五部分：

角色定义
任务目标
行为约束
输出格式
异常处理规则

比如做知识库问答时，我会明确：

你是企业知识助手
只能基于提供资料回答
资料不足时要拒答
回答要简洁并附来源
不要补充未经资料支持的信息

Prompt 的重点不是“写得像人”，而是“规则清晰、输出可控”。

追问 1：Prompt 很长会不会更好？

回答：
不一定。
Prompt 太长会增加 token 成本，也可能让重点不突出。
很多时候，清晰简洁、结构化表达比堆很多话更有效。

追问 2：few-shot 什么时候加？

回答：
当任务需要稳定格式、固定风格、复杂分类边界时，few-shot 很有帮助。
但不是越多越好，通常挑少量有代表性的样例即可。

追问 3：Prompt 效果不好时，你怎么排查？

回答：
我会看三件事：

问题是不是 Prompt 本身不清晰
还是上下文质量不好
还是参数、模型能力不匹配
因为很多时候看起来像 Prompt 问题，根因其实在检索输入。

一句话加分总结：
Prompt 的本质不是“聊天话术”，而是模型行为规范。

11. JSON 输出不稳定怎么办？

主问题标准回答：
JSON 输出不稳定是很常见的问题。
我一般通过“约束、校验、修复、重试、降级”五层处理：

Prompt 明确 schema 和字段要求
优先使用 JSON mode 或 function calling
服务端做 schema 校验
轻量修复，比如提取 JSON 主体
失败重试，最后再做降级兜底

核心思路是，不把模型当成强类型接口，而是把它当成一个可能输出不稳定文本的组件。

追问 1：如果返回里混了说明文字怎么办？

回答：
可以先做预处理，提取最可能的 JSON 主体，再做解析和 schema 校验。
如果仍失败，就发起重试。

追问 2：function calling 为什么更稳？

回答：
因为它是模型官方支持的结构化输出能力，比纯 Prompt 约束自由文本更可控，格式稳定性通常更高。

追问 3：多次失败怎么办？

回答：
那就要降级，比如返回默认结构、错误提示，或者切换到更稳的处理链路。
不能无限重试，否则影响时延和成本。

一句话加分总结：
结构化输出不能靠“希望模型听话”，要靠“服务端校验 + 重试 + 兜底”。

12. 多轮上下文太长怎么办？

主问题标准回答：
多轮对话上下文不能简单一直累加。
我通常会结合“最近轮次 + 相关性保留 + 摘要记忆 + 结构化状态”来处理。
比如保留最近几轮强相关对话，把较早但仍有价值的信息压缩成摘要，把用户身份、订单号、任务目标这类长期有效信息结构化保存。
这样既能控制 token，又能保留关键上下文。

追问 1：为什么不能直接保留最近 N 轮？

回答：
因为任务型对话里，关键条件可能出现在更早轮次。
如果只按最近轮次截断，容易把真正重要的信息丢掉。

追问 2：什么信息适合结构化保存？

回答：
长期有效且字段化的信息适合结构化保存，比如：

用户身份
地区
产品类型
工单编号
任务目标
这些信息没必要每次靠原始聊天历史重复传给模型。

追问 3：历史摘要会不会失真？

回答：
有风险，所以摘要也要控制用途。
我通常把摘要作为长期记忆补充，而不是完全替代所有原文；关键任务里会保留必要原始对话。

一句话加分总结：
上下文管理的核心不是“保留更多”，而是“保留更有价值的信息”。

13. Agent 和工作流怎么选？

主问题标准回答：
我的理解是：

工作流 适合步骤固定、路径明确、可预定义的任务
Agent 适合路径不确定、需要动态决策和多工具调用的任务

在企业场景里，我一般优先工作流，因为它更稳定、更可控、也更容易排障；只有在确实需要动态规划时，才会考虑 Agent。

追问 1：为什么企业里不一定优先用 Agent？

回答：
因为 Agent 虽然更灵活，但也更容易带来不可控性，比如多步决策不稳定、工具误调用、死循环和调试困难。
而很多业务流程其实是固定的，用工作流更合适。

追问 2：举个适合 Agent 的例子？

回答：
比如“帮我查本月某区域销售数据，分析异常原因，再生成日报并发到邮箱”。
这个任务需要查数据、做分析、调用多个工具，且下一步可能取决于中间结果，就比较适合 Agent。

追问 3：举个适合工作流的例子？

回答：
比如文档上传 -> 解析 -> 摘要 -> 分类 -> 入库，或者工单分类 -> 分派 -> 回复建议生成。
这类流程稳定明确，更适合工作流编排。

一句话加分总结：
不是功能越智能越好，很多企业任务真正重要的是稳定、可控和可审计。

14. 模型超时怎么办？

主问题标准回答：
模型超时我会分成预防和兜底两部分处理。
预防上包括：控制输入长度、优化 Prompt、减少冗余上下文、合理配置超时、长任务异步化。
兜底上包括：有限重试、切换备用模型、降级回复、快速失败和监控告警。
核心目标是避免请求堆积，同时尽量保证用户体验。

追问 1：什么时候适合重试？

回答：
适合瞬时网络抖动、短时服务波动这类临时故障。
但重试次数必须有限，通常还要加指数退避，避免雪上加霜。

追问 2：什么时候应该直接降级？

回答：
当外部模型持续异常、请求量高、用户场景对实时性要求高时，就应该尽快降级，比如返回简版结果、提示稍后重试、或者切备用链路。

追问 3：长任务为什么要异步化？

回答：
因为有些任务本身就不适合在线等待，比如大文档分析、批量处理、复杂 Agent 多步执行。
这时改成异步任务更稳，也更容易控制超时。

一句话加分总结：
超时问题不只是技术问题，也是产品体验和资源治理问题。

15. 成本太高怎么办？

主问题标准回答：
AI 应用成本优化，我通常从四个方向看：

减少 token：缩短 Prompt、裁剪历史、减少无关上下文
模型分层：小模型做预处理，大模型做最终生成
缓存复用：热点问题缓存、检索缓存、embedding 缓存
减少无效调用：简单问题走规则或 FAQ，不必每次都打大模型

本质上是用更少的计算资源，完成同样或接近的业务效果。

追问 1：最直接有效的成本优化是什么？

回答：
通常是上下文优化和缓存。
因为很多成本浪费都来自传了太多无关内容，或者对高频问题重复调用模型。

追问 2：为什么要做多模型分层？

回答：
因为不同任务对模型能力要求不同。
像分类、改写、参数抽取这种任务，小模型往往就够；复杂总结和最终回答再交给大模型，更有性价比。

追问 3：成本优化会不会影响效果？

回答：
可能会，所以一定要做平衡和评估。
成本优化不是一味压缩，而是在效果、响应速度和费用之间找到合理点。

一句话加分总结：
成本优化不是“省几块钱”，而是决定 AI 系统能不能长期跑下去。

16. 如何评估一个 AI 问答系统？

主问题标准回答：
我一般从五个维度评估：

检索效果：Recall@K、命中率、排序质量
生成效果：准确率、幻觉率、引用正确率、拒答准确率
用户体验：首 token 时间、总响应时长、追问率
系统稳定性：超时率、错误率、成功率
业务价值：转人工率、问题解决率、人工答疑减少量

这样可以把“模型表现好不好”和“系统有没有业务价值”分开看。

追问 1：为什么不能只看最终答案对不对？

回答：
因为最终答案是检索和生成共同作用的结果。
如果只看最后结果，出了问题很难判断是检索没召回，还是模型生成错了，所以要拆层评估。

追问 2：怎么评估拒答做得好不好？

回答：
要看“该拒的时候有没有拒”“不该拒的时候有没有误拒”。
特别是无答案问题集，对拒答能力评估很关键。

追问 3：线上和离线评估有什么区别？

回答：
离线评估更适合调参数、对比方案；
线上评估更能反映真实用户体验和业务价值，比如追问率、满意度、转人工率。
两者最好结合。

一句话加分总结：
AI 系统评估不能只看“答得像不像”，还要看“答得准不准、稳不稳、值不值”。

17. Prompt Injection 怎么防？

主问题标准回答：
Prompt Injection 本质上是一种安全问题，用户试图通过输入让模型忽略系统规则、泄露敏感信息或执行危险操作。
防护不能只靠 Prompt，要做多层控制：

system prompt 和用户输入分层
恶意输入检测和风险识别
工具和数据最小权限
敏感信息不直接暴露给模型
输出审核
高风险操作二次确认

核心不是让模型“完全识别所有攻击”，而是即使遇到注入，也做不了越权事情。

追问 1：如果知识库文档本身带恶意指令怎么办？

回答：
这属于“检索内容注入”。
可以对文档做清洗、标记风险来源、限制文档中的指令性内容影响，并通过系统规则告诉模型：检索内容是参考资料，不是系统指令。

追问 2：只靠关键词过滤够吗？

回答：
不够。
关键词过滤可以挡住一部分明显攻击，但绕过方式很多，所以必须结合权限控制、工具最小授权和输出审计。

追问 3：最核心的防护点是什么？

回答：
我认为是权限边界。
因为即使 Prompt 被注入，如果模型没有访问敏感数据和危险工具的权限，风险也能大幅降低。

一句话加分总结：
Prompt Injection 的本质防护，不是“让模型更聪明”，而是“让系统权限更收敛”。

18. 权限怎么控制？

主问题标准回答：
AI 场景里的权限控制不能只做在文档下载层，还必须做在检索层和生成层。
因为一旦模型检索到了敏感内容，就可能总结输出给用户。
常见做法包括：

文档入库时打权限标签
检索时带用户权限过滤
工具调用二次鉴权
高敏感数据脱敏展示
全链路日志审计

最关键的是：权限要前置到“检索前过滤”，而不是生成后再遮盖。

追问 1：为什么生成后遮盖不够？

回答：
因为生成阶段一旦看到敏感内容，泄露风险就已经存在了。
所以真正安全的方式是从源头上让模型看不到不该看的内容。

追问 2：多租户怎么做隔离？

回答：
可以独立 collection，也可以共享索引 + tenant_id 强过滤。
如果数据敏感性高，我会更偏向隔离更强的方案。

追问 3：日志里需要注意什么？

回答：
日志也可能泄露敏感信息，所以要控制打印内容，必要时脱敏，同时保留足够审计信息用于追踪。

一句话加分总结：
AI 权限控制最重要的一点，是把权限拦在检索前，而不是输出后。

19. 项目里最难的问题是什么？怎么解决？

主问题标准回答：
我项目里比较难的问题是检索相关性不稳定。
一开始用户提问比较口语化，而知识文档表达偏书面化，导致向量检索虽然能召回一些内容，但经常不是最相关的片段。
我后面主要做了三件事：

调整 chunk 策略，尽量保留完整语义
增加 query 改写，把用户表达转成更贴近文档表达的形式
引入 rerank，对候选内容做精排

优化之后，常见 badcase 明显减少，答案相关性更高，也减少了很多“看起来像模型错，其实是检索错”的问题。

追问 1：你为什么先优化检索，而不是先换模型？

回答：
因为当时判断问题根因主要在输入质量，而不是模型能力本身。
如果检索上下文就不准，换更强模型也只是基于错误内容答题，性价比不高。

追问 2：你怎么验证优化有效？

回答：
我会看测试集命中情况、典型 badcase 表现、人工评估反馈，以及线上追问率变化。
重点是看优化前后有没有稳定改善，而不是只看个别样本。

追问 3：这个问题让你学到了什么？

回答：
让我更明确一点：
很多 AI 项目问题表面上出在模型输出，实际上根因在数据和检索链路。
所以要拆层排查，而不是动不动就归因到模型不行。

一句话加分总结：
最难的问题往往不是“模型不够强”，而是“怎么让模型拿到对的输入”。

20. 你怎么做项目介绍？

主问题标准回答：
我通常会按四步讲项目：

项目背景：业务痛点是什么
整体方案：系统链路怎么设计
个人职责：我负责哪些模块
难点和效果：遇到什么问题、怎么解决、结果如何

比如：
这个项目是做企业知识库问答的，目标是减少内部重复答疑、提升信息获取效率。
整体链路包括文档解析入库、检索召回、rerank、模型生成，以及权限、缓存和监控。
我主要负责文档处理链路和在线问答服务，重点优化了检索效果和输出稳定性。
项目上线后，问答可用性和响应效率都有提升。

追问 1：没有量化指标怎么办？

回答：
如果没有精确数据，也要尽量给出方向性结果，比如：

badcase 减少
相关性更高
用户追问减少
响应更快
但不能只说“效果挺好”。

追问 2：讲项目时最容易犯什么错？

回答：
我觉得最常见的是：

只讲技术名词，不讲业务目标
只讲系统功能，不讲自己职责
只讲做了什么，不讲为什么这么做
讲不出难点和效果对比

追问 3：如果面试官继续深挖，怎么准备？

回答：
最好提前把项目拆成模块准备：

为什么选 RAG
chunk 怎么切
embedding 怎么选
topK 怎么定
幻觉怎么处理
权限怎么控
怎么评估效果
这样不容易在细节追问时卡住。

一句话加分总结：
项目介绍的重点不是“讲全”，而是“讲清楚业务、架构、职责、难点和效果”。

最后：一份 30 秒收尾总结

如果面试最后想做个总结，你可以这样说：

我理解 AI 应用开发的核心，不是单纯把模型接进来，而是把模型能力稳定、可控、低成本地交付给业务。
所以我会同时关注三件事：第一是后端工程基础，第二是大模型应用链路，第三是异常处理和效果评估。
我希望自己不仅能把 demo 做出来，也能把系统真正做上线、做稳定。