快手 AI 全栈二面
面试时间
2026_0917-16:00
面试内容
- 自我介绍
- 介绍 B 站的 AI Agent 效能分析平台项目
- B 站内部如何衡量 AI 的使用效果？
- AI 代码生成率一般怎么统计？结合快手实习经历聊一下
- AI 生成代码，你觉得要如何做比对？
- 介绍蓝色光标 AIGC 视频制作平台，你参与了哪些 AIGC 相关部分？
- 你做过哪些 AI 开发相关的内容？
- 你做过哪些偏后端的开发项目？
- 介绍全链路 AI 研发探索项目，你主要负责什么？
- 全链路 AI 研发探索项目最大的难点是什么？
- 全链路 AI 研发探索项目落地情况怎么样？电商内部推广效果如何？
- 怎么衡量全链路 AI 研发探索项目的效果？只看生成代码量吗？
- 谈谈你对全栈工程师的理解
- 是否有针对性计划深耕后端？
- 百度 Data Agent 项目，会话级状态隔离与事件缓冲机制相关问题：多对话共享同一个消息池会出现什么问题？问题产生的根源是什么？有什么更好的实现方式？
- 对于 AI Coding 工具，是仅使用还是了解底层实现？
- 谈谈你理解的大模型是什么
- 大模型擅长什么？有哪些局限性？
- 如何约束大模型，解决它的问题？
- 除简历之外，还用大模型做过哪些事情？
- 你是如何评测自己写的 Codebase Index 方案的？
- 反问环节
面试官反馈
面试官结尾反馈：目前经历大多集中在前端，后端、纯 Agent / 大模型技术经验偏少，需要继续加强；在 AI 全栈岗位竞争中，纯前端背景可能会比较吃亏。
面试复盘总结
1. 这场面试重点考察什么
这轮二面重点不是继续追问某个前端 API，而是判断候选人能不能从“前端参与 AI 项目”进一步成长为“能够负责 AI 应用完整链路的工程师”。
面试主线可以概括为：
项目经历 -> 效能指标 -> AI 研发落地 -> 后端能力 -> Agent 原理 -> 大模型认知其中，面试官反复确认了三件事：项目是否真正落地、效果是否有数据支撑、候选人是否具备后端和 Agent 底层能力。
2. AI 效能不能只看生成代码量
AI 代码生成率可以作为观察指标，但不能直接代表研发效率。统计时需要先定义口径，例如：
- AI 生成的代码是否进入了最终提交。
- 生成代码是否经过人工大幅修改。
- 是按代码行数、提交次数，还是按功能任务统计。
- 测试代码、配置文件、格式化代码是否纳入统计。
- AI 生成的代码是否真正减少了开发时间和返工成本。
更完整的衡量方式应该同时关注：
| 方向 | 参考指标 |
|---|---|
| 产出效率 | 需求交付周期、任务完成数、开发耗时 |
| 代码质量 | 缺陷率、回滚率、测试通过率、Review 修改量 |
| AI 使用质量 | 一次生成成功率、人工接管率、重复调用次数 |
| 成本控制 | Token 消耗、模型调用次数、单任务成本 |
| 团队收益 | 返工次数、知识复用率、跨成员协作成本 |
比较 AI 生成代码和人工代码时，也不能只做字符串 diff。可以结合提交记录、代码归属、任务关联、测试结果和人工修改比例，判断 AI 产出是否真正进入了有效交付。
3. 全链路 AI 研发项目怎么讲
介绍全链路 AI 研发探索项目时，可以按照下面的结构回答：
需求输入 -> Spec 拆解 -> 上下文准备 -> AI 编码 -> 自动测试 -> Browser Agent 验证 -> 人工 Review -> 交付沉淀项目最大的难点通常不是“让 AI 写出代码”，而是让 AI 在真实业务中稳定地写对代码：
- 业务上下文分散在多个仓库、文档和组件库中。
- AI 生成的代码可能符合语法，但不符合团队规范或历史设计。
- 长任务执行过程中需要保存状态，并支持失败重试和人工接管。
- 需求变化后，原有 Spec、测试和实现需要同步更新。
- AI 产出需要通过构建、测试、页面交互和人工审核多重验证。
因此项目效果不能只看生成了多少代码，而要看是否让交付过程更快、更稳定、更可复用。
4. 多对话共享消息池的问题
如果多个会话共享同一个消息池，常见问题包括：
- 会话 A 的消息被会话 B 消费或展示。
- 流式输出事件串线，导致页面内容错乱。
- 一个会话结束时清理消息，误删另一个会话仍在使用的数据。
- 消息顺序无法保证，重连后出现重复消费或丢失。
- 多个订阅者修改同一份状态，产生竞态条件。
根源是消息状态的生命周期没有绑定到会话，系统把“全局消息流”误当成了“会话消息流”。
更合理的实现方式是按 conversationId 或 sessionId 隔离状态：
conversationId
-> event buffer
-> message list
-> subscriber set
-> connection status事件进入系统后，先根据会话 ID 路由到对应的事件缓冲区，再由该会话的订阅者消费。事件需要携带唯一 ID、序号和状态，重连时根据最后消费位置补发，避免重复和丢失。前端也应该按会话维护独立的消息状态，而不是把所有对话放在一个数组里。
5. 如何理解大模型
大模型可以理解为基于大规模数据训练出来的概率生成模型，它根据当前上下文预测下一步最可能出现的内容。它擅长处理语言理解、内容生成、代码补全、信息归纳、模式提取和多步骤任务分解。
但它不是天然可靠的知识库或执行引擎，局限主要包括：
- 可能产生幻觉，生成看似合理但实际错误的内容。
- 对长上下文、隐含约束和复杂状态的理解不稳定。
- 无法自动知道实时变化的业务规则和仓库状态。
- 数值计算、精确逻辑和长链路执行可能出错。
- 输出质量依赖上下文、工具设计和验证机制。
约束大模型需要把它放进一个可控的工程系统：
- 用 Spec、规则和 Skill 明确目标、边界和团队约定。
- 用结构化输出约束返回格式。
- 用 MCP 或工具调用让模型访问真实数据和确定性能力。
- 用代码索引和模块文档补齐项目上下文。
- 用测试、类型检查、构建、页面验证和人工 Review 做结果兜底。
6. Codebase Index 如何评测
Codebase Index 不能只看索引是否生成成功，更重要的是它是否帮助 Agent 更快、更准确地找到需要的代码。可以设计一组有明确答案的任务集，分别比较无索引、全文搜索和 AST 索引三种方案：
- 召回效果：是否找到了正确文件、组件、函数和类型。
- 定位精度：返回结果中无关代码的比例有多高。
- 任务成功率：Agent 是否能基于索引完成修改并通过测试。
- 定位耗时：从提问到找到有效上下文需要多久。
- 上下文成本：读取文件数量、Token 数量和模型调用次数。
- 维护成本：代码修改后索引更新是否及时，增量更新是否稳定。
可以重点记录 Top-K 命中率、一次任务成功率、平均读取文件数、Token 消耗 和 人工修正率。如果索引减少了读取量，同时没有降低任务成功率，才说明方案真正有效。
7. 面试后的补强方向
这场面试反馈比较明确：当前优势是前端、AI 工具接入和研发流程探索，短板是后端、纯 Agent 和大模型基础。
后续可以有针对性地补齐：
- 后端工程：Node 服务、Java 服务基础、鉴权、任务队列、缓存、日志和部署。
- 数据库：SQL、索引、事务、数据建模，以及 Agent 场景中的安全查询。
- Agent 原理：上下文管理、规划、工具调用、记忆、状态机、重试和人工接管。
- 模型基础：Transformer、Embedding、RAG、结构化输出、Function Calling 和推理限制。
- 评测体系：离线数据集、成功率、成本、时延、稳定性和人工修正率。
这场二面的核心提醒是：AI 全栈并不是会接模型的前端工程师，而是能够把模型、工具、数据、服务端和产品交互组织成可靠系统的工程师。前端经验是入口，但需要继续向后端基础和 Agent 底层深入。