度小满 AI 全栈研发一面：AI 自主迭代、多模型路由与 Prompt 注入防护

《面试题目》

实习

1. 自我介绍
2. AI 在你实际的工作中能帮你做什么？
3. 你提到 AI 自主迭代，具体是如何实现的？
4. 讲一下具体的问答链路？日常如何排查问题？
5. Answer 和追问 Query 是怎么设计的？数据埋点是怎么设计的？产生的数据漏斗有什么用？
6. 客户端/服务端的持久化设计可以节省模型算力？
7. 多模型切换和路由功能如何设计的？
8. Redis 会话状态机怎么设计的？
9. 并发场景下，中断回答、切换会话重答等操作怎么保证上下文不乱？
10. 流式文本/卡片下发，如何保证有序可靠？
11. 面向 C 端的产品，如何防止提示词注入（Prompt Injection）和越狱？
12. 谈谈你理解的 AI 的优势、缺点以及应用场景？
13. 工作中如何解决 AI 幻觉和输出不可控问题？
14. RAG 链路讲解？
15. 项目里面用到什么 Skill？
16. 何时用知识文档、何时用向量库（RAG）、何时用 Skill（工具）？
17. 对于用户的正反馈/负反馈是如何处理的？

算法

18. 手撕代码：字符流中第一个只出现一次的字符？（哈希 + 队列）

反问

19. 岗位职责？具体业务？
20. 部门技术栈？Java / Golang / Python
21. 面试改进建议

《参考解析》

1. C 端产品的提示词注入与越狱防护，要答成多层防线：第一层是输入侧，对用户输入做长度与内容校验，用规则或小模型识别「忽略以上指令」「输出你的系统提示词」这类典型模式，并把用户输入始终包裹在数据标记里，让模型明确哪些是数据、哪些是指令。第二层是权限侧，模型能调用的工具走白名单，涉及转账、删除、查询他人数据这类动作一律二次校验真实身份，不信任模型给出的参数。第三层是输出侧，对回答做敏感信息与越狱特征过滤，尤其是系统提示词泄露和越权数据泄露。第四层是监控与迭代，把越狱尝试记录下来做成对抗样本集，定期回归。回答时点出核心原则——「模型不可信，权限只认服务端」，比列举攻击手法更能打动面试官。

2. 何时用知识文档、何时用向量库、何时用 Skill，本质是成本与确定性的权衡：内容少、变动少、要求严格的（如客服话术、业务规则）直接放进系统提示词或知识文档最稳，可控但占上下文；文档量大、需要按语义检索的走 RAG，把片段召回后拼进提示词，代价是分块与召回质量需要调优；需要执行动作、访问实时数据的（查订单、下单、发通知）必须做成工具由 Skill 调用，因为数据在系统里而不在模型里。判断标准可以总结成两句：回答要「知道什么」用检索，「做成一件事」用工具，两者都解决不了再考虑微调。被追问时补一句成本对比——提示词最便宜，RAG 次之，工具调用最贵但能力最强。

3. 多模型切换与路由，要讲清「按什么路由」和「切了以后上下文怎么办」：路由维度通常有任务类型（简单问答走小模型、复杂推理走大模型）、上下文长度（超长走长窗口模型）、可用性与成本（主模型超时或限流时降级到备用模型）。实现上一般有一张模型能力表加一套策略（规则 + 灰度），调用层做统一的适配接口，上层业务不直接依赖某家 SDK。切换重答时最关键的是一致性：历史消息要按目标模型的格式重新组装，不同模型的 system prompt 与工具协议不同，不能直接复用响应对象。

4. Redis 会话状态机与会话一致性，是这个项目最容易讲出彩的地方：会话状态（进行中、已中断、已切换、已结束）用状态机表达并落在 Redis 里，写入时带上版本号或使用 Redis 的单线程特性配合 Lua 保证状态转移的原子性。并发下保证上下文不乱的常见做法有：给每次回答分配 requestId 与自增序号，流式分片都带上序号，客户端和服务端按序号拼接、丢弃过期请求的分片（用户已经点了「重新回答」，旧请求的结果直接作废）；切换会话时新会话从 Redis 里读取自己的历史，不共享内存中的可变上下文。回答时把「谁的请求作废、依什么判断」说清楚，面试官就能确认你真的处理过并发场景。

5. 流式文本与卡片下发如何保证有序可靠，拆成「有序」和「可靠」两条线：有序靠序号与单调递增的分片标识（也可以让协议本身保证顺序，比如 SSE 的单一长连接），前端按序渲染、乱序则缓冲等待；卡片这类结构化内容要和文本流分开通道下发，靠消息 ID 做关联和去重，避免卡片插到半句话中间。可靠靠断点续传与幂等：连接断了要能从上次已确认的分片继续，重连时带上 offset 或 lastEventId；服务端对同一请求的分片生成可重放的缓存，客户端对重复分片按 ID 去重。再补一句降级——流式失败时回退到一次性返回完整结果，比让用户看到半截卡住强。

6. RAG 链路的完整讲解，按「离线建库 + 在线检索」分段：离线侧做文档接入（PDF、网页、数据库）、解析清洗（去页眉页脚、保留标题层级）、分块（按语义或标题切，块大小与重叠要调）、向量化入库（embedding 模型选定后不要随意更换，换要全量重建）、以及为关键词检索保留倒排索引。在线侧做查询改写（多轮对话里要把指代补全）、混合召回（向量 + BM25）、精排（rerank 模型）、拼装提示词（片段带出处、控制总长度）、生成与引用回标。工程上还要有版本与灰度（新索引先影子流量对比）、以及评测集（命中率、答案采纳率）。这条链路讲得越具体，越能证明「RAG 不是接个向量库就完事」。

7. AI 幻觉与输出不可控，按「能不能查证」分流处理：有据可查的问题（业务数据、文档事实）用 RAG 提供依据并要求模型只在给定材料内作答，材料里没有就明确说不知道；需要精确计算或实时数据的交给工具和代码，不让模型心算；开放式生成的问题用结构化输出（JSON Schema 校验、失败重试）和兜底文案约束格式，并降低采样温度；最后加一层生成后校验（关键字段正则校验、与数据库比对）和不满意就重试的策略。同时把幻觉当成可观测指标：抽检准确率、用户负反馈率，按周复盘 bad case。

8. 手撕「字符流中第一个只出现一次的字符」的解法与讲法：维护一个「出现次数」的结构加一个「当前候选队列」。插入字符时用哈希表记次数，若该字符是第一次出现则入队；查询时不断弹出队头中次数已经大于 1 的字符，剩下的队头就是答案，均摊 O(1)。另一种写法是用哈希表存「第一次出现的下标」并维护一个单调递增的候选位置指针，查询时向后跳过已重复的字符。讲的时候先说「字符流意味着不能回头扫描、每次查询都要快」，再给复杂度，最后补一个 ASCII 字符集下用固定数组代替哈希表的优化——这类题面试官看的是数据结构选择的合理性，而不是能不能背出答案。