1. 先看这轮面试到底在考什么
1.1 这不是一场"背八股"面试，而是一场"系统能力面试"
这轮面试明显不是只考几个孤立知识点。它先用一个项目，把多 Agent 协同、评估、重排、幻觉治理、模型选型、成本意识等问题一路追到底；接着再切到大模型理论，问 SFT、RLHF、记忆机制、Harness、Claude Code 等；最后用网络、并发、锁和手撕题兜底。
也就是说，面试官要看的不是你会不会背几个术语，而是你能不能把一个大模型项目讲成闭环：有架构，有取舍，有评估，有优化，还有边界意识。
2. 项目深挖：多 Agent 协同遇到的问题，文章各章节怎么保证风格一致？
2.1 多 Agent 不是角色越多越好，而是分工越清越好
很多人一说多 Agent，就喜欢堆出一长串角色：规划、检索、写作、总结、编辑、审核、发布......但面试官真正关心的不是角色数量，而是这些角色之间是否形成了清晰的职责边界。
如果一个 Agent 既做大纲又做写作又做润色，那么多 Agent 的意义就不大；如果角色切得太碎，又会导致链路过长、延时高、上下文断裂、输出风格飘。最合理的方式，是围绕业务链路来拆：先有规划，再有章节生成，再有统一抛光，最后做质检和回收。
2.2 风格一致性的本质，不是"大家都写得像"，而是"系统有统一约束"
一篇文章不同章节由不同 Agent 写，最容易出现的不是语法错误，而是风格飘移。前面一个章节很口语化，后面一个章节很论文腔；前面用"多智能体"，后面改叫"多代理"；前面说给小白看，后面突然开始堆术语。
所以，真正保证风格一致，靠的不是"相信模型自己会统一"，而是四件事：第一，统一风格卡，包括目标人群、语气、禁用词、术语表；第二，统一大纲和章节职责，避免不同 Agent 抢写同类内容；第三，统一上下文记忆，让所有章节知道全文设定；第四，统一收口，让最终编辑 Agent 对全篇做一次整体抛光。
2.3 面试时最好怎么回答
可以这样答：多 Agent 协同的主要问题包括职责重叠、章节重复、风格漂移和延时成本增加。为了保证风格一致，我们会先定义统一的风格约束和术语表，再固定大纲和章节职责，并把前文摘要共享给所有章节 Agent，最后用专门的风格统一 Agent 做全文收口。
3. 评估怎么做？指标怎么来的？样本少时，指标是否可信？
3.1 评估这件事，最怕"只有分，没有故事"
面试官问评估怎么做，表面上是在问指标，实际上是在看你有没有建立"质量闭环"。真正成熟的回答，不是直接报一个分数，而是要说明：样本怎么构建，指标为什么这样定义，离线怎么做，线上怎么看，最后怎么回流优化。
在内容生成类项目里，常见指标并不只是一两个，它往往至少包括内容完整率、事实一致性、风格一致性、人工可用率、修改率、采纳率、延时和 token 成本。这里面有的是模型质量指标，有的是业务效果指标，有的是工程成本指标。
3.2 指标怎么得到？最稳的说法是"离线 + 线上"双轨
离线评测的作用，是让你在固定数据集上做版本对比，知道哪个策略更优；线上评测的作用，是让你知道真实用户是不是更愿意接受系统输出。
举个例子：如果你做的是文章草稿生成，离线可以看章节完整性、事实一致性和风格稳定性；线上可以看人工补充率、整体采纳率、用户是否反复重写、是否愿意直接使用。只有把这两部分结合起来，你说的"效果提升了"才站得住。
3.3 文档量不多，指标还能不能信？
这时候最好的态度不是硬说"很可信"，而是主动承认边界：文档量少时，离线指标更适合作为方向判断，而不是绝对结论。为了提高可信度，可以做分层抽样、重复实验、人工复核，再结合线上反馈共同判断。
这样的回答会比一味强调分数更成熟，因为它说明你知道样本量、覆盖度和统计稳定性本身也是工程现实。
4. 为什么精排不用 Cross-Encoder，要做规则重排？你怎么评估规则重排的效果？
4.1 这不是"谁更高级"的问题，而是"谁更合适"的问题
Cross-Encoder 在复杂语义匹配上通常比简单规则更强，这是很多人都知道的。但面试官追问"为什么不用"，往往并不是想听你否定 Cross-Encoder，而是想听你解释工程取舍。
如果业务场景要求低延时、高并发、强可解释性、候选集合又比较规整，那么规则重排往往更适合。它便宜、快、逻辑可解释、上线门槛低。如果系统还处在 0 到 1 阶段，先用规则重排快速跑通，往往比一开始就上重模型更现实。
4.2 规则重排效果怎么评估？
最好的答法是：在同一批候选集合上，对比规则重排前后以及和人工标注理想排序之间的差距。看 TopK 命中率是否提升，看最终生成质量是否受益，看延时和成本是否在预算内。
如果能进一步补一句"当候选规模变小、语义理解变复杂时，我们也考虑过逐步引入 Cross-Encoder 做二阶段精排"，答案就会更完整，因为这说明你不是固守规则，而是有进化路线。
5. 如果把项目规模扩大，但想进一步提升返回质量，你会在哪里改进？
5.1 先从输入和检索改，再从生成和门控改
很多人一听"返回质量不够好"，第一反应就是换个更强的大模型。其实这是最后一招，不是第一招。真正成熟的优化路线，应该先看输入是不是清楚、检索是不是够全、上下文是不是干净、Prompt 有没有明确约束、输出后有没有门控和事实校验。
也就是说，质量问题很少只出在生成层，它往往是一个链路问题。用户问题不规范，会让系统一开始就走偏；召回不全，会让模型"没粮可做"；上下文太脏，会让模型混淆；Prompt 太松，会让它自由发挥；没有门控，会让幻觉直接漏到用户面前。
5.2 如果想减少人工补充，核心是把"完整性检查"前移
系统生成的草稿需要人工补充，往往不是因为"写得不通顺"，而是因为"没写全"。所以减少人工最有效的方式之一，不是只做文风优化，而是把输出目标结构化，把必答点清单显式化，并对每一章做完成度检查。
比如写一篇技术文章，可以要求每一章都必须覆盖"定义、原理、例子、优缺点、总结"。如果某一项缺失，就触发局部补写，而不是等人工事后发现。
6. 怎么减少幻觉？你觉得大模型为什么会有幻觉？
6.1 幻觉不是 Bug，而是训练目标和应用目标之间的天然缝隙
大模型本质上是在做"根据上下文预测下一个 token"。这个训练目标天然追求的是"像话""流畅""概率高"，而不是"百分之百真实"。所以只要知识不足、上下文不够、任务表达模糊，它就可能用一种看似合理的方式把空白补上，这就是幻觉。
再往深一点说，幻觉常见的来源至少有三个：第一，模型参数记忆和外部事实之间不一致；第二，上下文不足，导致它只能"猜"；第三，系统没有足够强的约束与校验，让错误内容有机会直接输出。
6.2 治理幻觉最有效的思路：补事实、强约束、加门控
补事实，就是用 RAG、工具调用、数据库查询等方式，把应该依赖外部知识的内容从"猜"变成"查"；强约束，就是限制输出结构、要求引用依据、明确禁止编造；加门控，就是对低置信度答案做回退、重试或人工接管。
这样回答的优点是很工程化：不是空泛说"减少幻觉要优化模型"，而是说明你知道问题出在哪一层，以及每一层该怎么下手。
7. 整个项目消耗的 token 量怎么看？你用了哪个模型？为什么选它？
7.1 token 成本不是最后才看，而是系统设计一开始就该看
一次大模型请求的 token，通常来自系统提示词、用户输入、检索上下文和模型输出四部分。如果项目有多轮对话、多 Agent 串联、长上下文和多次重试，那么 token 开销会非常快地膨胀。
因此，一个成熟项目必须有 token 成本意识：哪些提示词是重复的、哪些上下文可以裁剪、哪些步骤可以下沉给小模型、哪些结果可以缓存，都是要提前设计的。
7.2 为什么选这个模型？最好的答案不是"它最强"，而是"它最合适"
模型选型最好的回答方式，是明确说出你的评估维度：效果、成本、延时、稳定性、上下文长度、接口可用性。也就是说，你不是拍脑袋选模型，而是在一组候选模型里，通过离线质量评测和线上业务指标，选到了最符合当前业务目标的那个点。
如果业务是高频实时调用，可能更偏重延时和成本；如果是高价值低频任务，可能更愿意牺牲成本换质量。这样的回答比单纯说"我们用某某模型，因为它很强"更能打动面试官。
8. 偏大模型八股：SFT 和 RLHF 有什么区别？如果让你做 RLHF，你怎么做？
8.1 先把 SFT 讲明白：它是"教会模型基本会答"
SFT，也就是监督微调，核心做法是给模型一批高质量的指令-答案对，让它学会按人类希望的方式回答。它更像是把基础模型"教会"：什么是好的回答格式，什么是业务期望的风格，什么任务该怎么答。
8.2 再讲 RLHF：它是"让模型更合人意"
RLHF 往前通常会先有一个 SFT 模型，然后收集人类偏好数据，比如同一个问题给多个回答，让人来选哪一个更好。接着训练奖励模型，让系统学会识别"什么回答更受偏好"，最后用强化学习方法继续优化主模型。
8.3 如果让你做 RLHF，最好的答法是"五步法"
第一步，先明确优化目标，是更安全、更有帮助，还是更符合某种风格；第二步，设计偏好数据采集策略，确保样本覆盖主场景和难场景；第三步，训练奖励模型；第四步，用 PPO、DPO 等方式优化主模型；第五步，用离线和线上评测验证收益，同时盯安全性和稳定性。
9. Skill、Harness、Claude Code 怎么理解？这些内容怎么迁移？
9.1 Skill 是"能力颗粒度"，Harness 是"执行外壳"
如果把一个 Agent 系统类比成工厂，那么 Skill 更像一个可复用工位，比如"总结文档""查知识库""写周报"；而 Harness 更像把这些工位真正串起来的产线系统，里面有模型调用、Prompt、工具、状态、重试、日志、评估和流程编排。
所以面试官问 Harness，不一定是在考某个特定开源库，而是在看你是否理解：一个好用的大模型工程系统，不只是模型本身，而是围绕模型的整套执行框架。
9.2 Claude Code 真正值得借鉴的，不是品牌名，而是工作方式
如果面试官问你对 Claude Code 的理解，最好的回答，不是只说它是个代码 Agent，而是拆它为什么好用：它强调计划执行、工具调用、文件级修改、上下文管理和人机协作循环。
这些能力完全可以迁移到自家系统里：例如，在一个内部代码 Agent 或文档 Agent 中，同样可以使用任务计划、状态跟踪、补丁式修改、工具回读、阶段性确认等机制。
10. 对记忆机制的理解：什么可以长期保留，什么只做短期？
10.1 判断标准不复杂，就看"稳定、复用、时效"
短期记忆更适合保存当前会话强相关的信息，比如最近几轮对话、当前任务状态、刚刚查到的工具结果，因为这些信息很快会过期。
长期记忆则适合保存长期稳定、反复会用到的信息，比如用户长期偏好、稳定业务规则、长期项目背景、常用术语习惯等。
判断某条信息该不该做长期记忆，可以问四个问题：它稳定吗？它复用价值高吗？它和用户或业务身份强相关吗？它会不会很快过期？只要前两项明显成立，通常就值得沉淀。
11. 传统八股：计算机网络、并发机制、锁，怎么答才不空？
11.1 不要只背定义，要带上"为什么在大模型系统里重要"
很多做 AI 应用的人，一被问到网络、并发、锁就开始慌，其实最好的办法不是死背课本，而是把这些知识挂回自己的系统。比如：为什么要懂网络？因为大模型服务本质上也是 RPC / HTTP 调用链，超时、重试、幂等、连接池、限流都和网络密切相关。
为什么要懂并发？因为你可能要同时调多个 Agent、多个工具、多个召回源，系统吞吐和尾延时离不开并发设计。为什么要懂锁？因为缓存更新、状态写入、任务抢占、并发回调都可能涉及共享资源竞争。
如果面试官问传统八股，你完全可以用"在我的 AI 系统里，它体现在哪"来回答，这样会比单纯背书更有说服力。
12. 手撕题：循环数组找最大子数组和，怎么讲思路才稳？
12.1 先把普通最大子数组和讲清楚，再讲循环
这类题最忌讳一上来就钻进代码。最稳的表达路径是：先说普通最大子数组和可以用动态规划或 Kadane 思想，在遍历过程中维护"以当前位置结尾的最大和"以及"全局最大和"；再解释循环数组的特殊性------最大子数组可能横跨头尾。
于是，循环问题就可以拆成两类：一类是不跨头尾，也就是普通最大子数组和；另一类是跨头尾，那么它就等价于"总和减去中间最小子数组和"。最后取两者最大值即可。
12.2 别忘了主动说边界条件
最关键的边界，是全为负数的情况。因为这时"总和减去最小子数组和"会失真，所以要单独处理。如果你在手撕题里主动把边界条件说出来，面试官对你的印象通常会更好。
13. 面试时最能加分的，不是"我知道"，而是"我能讲成体系"
很多人准备面试时，把知识点切得很碎：背一点 SFT，背一点 RLHF，背一点 RAG，再背一点手撕题。问题是，一旦面试官深入追问，就很容易断掉。
真正有竞争力的回答方式，是始终围绕一条主线：这套系统怎么做，为什么这样做，怎么评估它做得好不好，出了问题怎么优化，放大规模时要考虑什么，底层原理是什么。只要你能围绕这条线展开，哪怕面试官中途打断换题，你也能接得住。
14. 总结：这组题真正考的，是"大模型项目的系统化表达能力"
如果把整篇文章浓缩成一句话，那就是：这组题看起来很散，其实考的是同一件事------你是否真的理解一个大模型项目从设计、生成、评估、优化、对齐、记忆到工程落地的完整链路。
项目深挖部分，重点是多 Agent 协同、风格一致性、评估闭环、规则重排、幻觉治理、模型选型和 token 成本；偏大模型八股部分，重点是 SFT、RLHF、Harness、Claude Code 和记忆机制；传统八股与手撕题，则是为了确认你的基础能力是否扎实。
真正高质量的面试回答，不是术语多，而是逻辑顺：怎么做、为什么、怎么评估、怎么优化、有什么边界。只要这条线讲顺了，很多看起来很难的问题，都会变得有章可循。
附：30 秒面试快答模板
"这类大模型面试题其实可以分成四块：第一块是项目深挖，重点讲多 Agent 协同、风格一致性、评估闭环、规则重排、幻觉治理和模型选型；第二块是大模型理论，重点讲 SFT 和 RLHF 的区别、Skill/Harness 的理解、Claude Code 的工程启发以及短期与长期记忆；第三块是传统基础，比如网络、并发和锁；第四块是手撕题。回答时我会按'怎么做---为什么这样做---怎么评估---如何优化'这条线来讲，这样逻辑会更完整。"