快手 AI 全栈一面
面试时间
2026_0910-19:00
面试内容
开场与实习背景
- 你可以先简短地做一个自我介绍。
- 一直做的都是一些前端的工作，是吧？
- 后端一般是怎么做的？用什么样的框架、一些中间件，大概是怎么搞后端的？
Agent 项目深挖
- 在 AI 这块做了很多 Demo 和尝试，有没有哪一个投入精力多、拿得出手的 Agent 项目，可以完整讲一下？
- 减少读取次数、降低 Token 消耗，这个评测要达到什么样的水平，算是合理水平？
- 省 Token、降低调用次数，能保证上下文的质量是没问题的吗？
- 看你项目里面还有性能优化这一块内容，可以聊聊性能优化是什么样的背景，你是怎么实现的？
- 那个漫画小说网站，是开源的还是自己研究玩的？
AI 研发效能与 SDD
- 看到你专业技能写了 AI 研发效能架构，你目前的 AI 开发是一种什么样的研发范式？
- 你刚才提到 OpenSpec，还有 SDD，你怎么理解 SDD？平时是怎么使用它的？
- 你实习过 B 站、百度、快手、蓝色光标，每家公司在 AI 研发方式上，你有没有做过一些对比？
AI 全栈岗位与开放性问题
- 我们这个是 AI 全栈岗位，你怎么理解 AI 全栈？如果你来做这个岗位，你认为需要具备什么样的能力和认知？
- Git 仓库不只有一个，涉及跨仓库开发，AI 辅助编码研发，跨仓要怎么维护会比较好？
- 你的技能偏向 Node 生态，但快手、小红书服务端是 Java 生态，这种情况你怎么处理？
- 数据库 DB 相关这些，是不是没有怎么接触过？
算法环节
- 出算法题，口述思路也可以。
- 现在会刷力扣吗，有刷题习惯吗？
反问与补充交流
- 你这边有没有什么想跟我沟通、想问我的问题？
- 其他公司岗位设置和快手这边差不多吗？是不是已经很少有单独的智能岗，大多都是 AI 全栈？
- 那你肯定还要持续学习 AI 相关的东西，后端多多少少也要再多接触一些。
面试复盘总结
1. 这场面试的重点
这场面试表面上是 AI 全栈岗位，实际上主要考察三类能力：
- 能不能把 Agent 项目讲清楚，说明背景、方案、指标和实际收益。
- 是否理解 AI 研发效能的完整链路，而不是只会调用模型或编写 Prompt。
- 是否具备从前端向后端、数据库和跨仓库工程协作扩展的意识。
面试官的问题从个人经历开始，逐渐深入到 Agent 细节、Token 与上下文质量，再延伸到 SDD、跨仓库协作、后端技术栈和数据库，整体是在判断候选人是否具备承担完整 AI 应用研发链路的能力。
2. Agent 项目要讲清楚四件事
介绍一个投入精力较多的 Agent 项目时，可以按照下面的顺序展开：
业务背景 -> 用户问题 -> 整体架构 -> 自己负责的部分 -> 效果指标 -> 失败兜底不要只介绍使用了哪些模型、框架或工具，更重要的是说明：
- 为什么需要 Agent，而不是普通接口或固定流程。
- Agent 如何拆分任务、选择工具和组织上下文。
- 自己负责了哪些前端、服务端、工具协议或工程化工作。
- 项目如何验证效果，是否降低了人工操作、Token 消耗或代码维护成本。
- 当模型输出错误、工具调用失败或上下文不足时，系统如何重试、降级和人工接管。
3. 降低 Token 不能牺牲上下文质量
减少读取次数和 Token 消耗，本质上不是单纯地让模型“少看一点”，而是提高每一次上下文输入的信息密度。
可以从这些方向回答：
- 先通过目录、模块 README、符号索引定位相关代码，再读取具体实现。
- 根据任务类型选择上下文，不把无关文件、重复文档和历史对话全部传入。
- 优先提供接口、类型、调用关系和关键实现，避免只截取孤立代码片段。
- 对检索结果设置相关性和数量上限，防止召回过多噪声。
- 通过离线评测和线上日志观察任务成功率、人工修正率、Token 成本和响应耗时。
合理的目标应该是综合指标，而不是只看 Token 数量：
总成本 = Token 消耗 + 调用次数 + 响应时延 + 人工修正成本如果 Token 降低了，但任务成功率下降、人工返工增加，就不能算真正的优化。因此需要同时关注上下文命中率、一次成功率、工具调用成功率和最终交付质量。
4. 如何理解 SDD
SDD 可以理解为 Spec Driven Development，即以规格说明驱动开发。它把模糊需求先转成结构化的目标、约束、任务和验收标准，再让 AI 参与方案设计、编码和测试。
一条完整的链路可以概括为：
需求输入 -> Spec 拆解 -> 技术方案 -> 任务计划 -> AI 编码 -> 测试验证 -> 人工 Review -> 合并交付SDD 的价值不是增加文档，而是让 AI 在执行前拥有明确的上下文，让团队在需求变化时有地方同步决策。对于跨仓库、多人协作和长时间运行的 AI 任务，Spec 还能作为任务边界和验收依据。
5. 如何比较不同公司的 AI 研发方式
比较实习经历时，不要简单评价哪家公司“更先进”，可以从研发成熟度和落地方式来对比：
- AI 使用范围：是个人辅助编码，还是已经进入团队研发流程。
- 上下文管理：是否有
AGENTS.md、Skill、模块 README、代码索引等沉淀。 - 质量保障：是否有测试、构建、Browser Agent 自测和人工审核。
- 任务执行：是否支持长任务、远程执行、状态同步和人工接管。
- 结果衡量：有没有成功率、交付周期、返工次数、成本和稳定性指标。
这样既能体现自己的观察，也能避免把不同业务场景下的技术方案进行简单比较。
6. AI 全栈工程师需要什么能力
AI 全栈并不只是“前端加一点后端，再接一个大模型”，而是要能够把 AI 能力完整落到产品和研发系统中：
- 产品理解：知道什么问题适合用 Agent，什么问题用确定性流程更可靠。
- 前端能力：能够设计流式输出、任务状态、工具调用、错误提示和人工接管等交互。
- 服务端能力：理解 API、鉴权、任务队列、重试、超时、流式协议和日志追踪。
- 模型与工具能力：理解上下文、结构化输出、Tool Calling、MCP、Skill 和 Agent 编排。
- 数据能力：掌握基本的数据库、SQL、数据建模和查询性能分析。
- 工程能力：能够处理测试、部署、监控、成本控制和跨仓库协作。
核心目标是对最终结果负责，而不是局限在某一个技术栈中。
7. 跨仓库 AI 协作怎么维护
跨仓库开发的难点不只是代码分散，更在于依赖关系、版本约束和上下文不完整。可以从这些方面设计：
- 为每个仓库维护清晰的
README、AGENTS.md或模块级说明，明确入口、规范和运行方式。 - 记录仓库之间的依赖关系、接口契约、版本要求和变更影响范围。
- 为公共组件、协议和工具建立稳定的文档与示例，避免 AI 每次重新推断。
- 任务开始时先确认涉及哪些仓库，再分别获取必要上下文。
- 跨仓库变更拆成可验证的小步骤，每个仓库独立执行检查，最后做联调。
- 把常见错误和团队决策沉淀为规则、Skill、测试用例或自动检查。
如果使用 Node 生态的 Agent 工具协作 Java 服务端，也不必要求所有代码都用同一种语言实现。关键是理解服务端的接口、数据流、异常处理、构建测试和部署约束，并通过文档、类型定义和接口测试建立边界。
8. 数据库基础需要补齐
面对“数据库接触不多吗”的问题，可以诚实说明当前经验，同时体现学习和协作能力。至少需要掌握：
- SQL 的查询、过滤、聚合、排序、分页和多表 JOIN。
- 索引的作用，以及索引失效、慢查询和分页性能问题。
- 事务、隔离级别、幂等和常见数据一致性问题。
- 前端或 Agent 生成 SQL 时，如何做权限限制、参数校验和只读保护。
对于 Data Agent 或自然语言查询场景，还要特别关注 SQL 的安全性和可解释性：生成的 SQL 不能直接无保护执行，需要经过语法检查、权限校验、超时限制，必要时还要经过人工确认。
9. 面试准备提醒
这类 AI 全栈面试建议提前准备一张项目数据表，至少写清楚：
| 项目方向 | 建议准备的内容 |
|---|---|
| Agent 项目 | 背景、工具链、状态流转、失败兜底、自己负责部分 |
| 上下文优化 | 读取次数、Token 成本、命中率、一次成功率 |
| AI 研发效能 | 交付周期、返工次数、测试通过率、人工接管率 |
| 性能优化 | 指标基线、优化手段、优化后的数据和副作用 |
| 跨仓库协作 | 仓库关系、版本管理、接口契约、联调方式 |
| 全栈能力 | Node、Java 服务协作、SQL、部署和监控基础 |
这场面试最重要的提醒是：AI 全栈岗位既要能讲清楚 AI，也要能回到真实的软件工程。模型只是系统中的一个环节，真正拉开差距的是上下文组织、工程约束、质量验证和对业务结果的负责。