快手主站增长前端一面面经 | 面经

快手主站增长前端一面

面试时间

2026_0730-16:00

面试内容

自我介绍
讲一个你觉得比较有意思的项目
UI 是怎么设计的，是基于经验找材料吗？
是直接写代码，还是做了 Figma 设计稿？
在这个项目里面你做了什么？有做 SEO 优化吗？
做这个项目平台的目标是什么？
使用 Next 的时候遇到过什么问题？
useAsyncFetch 这类请求方法里面大概实现了什么功能？
有没有遇到过同一段逻辑需要在前端和服务端执行，但需要不同实现逻辑的案例？
讲一讲你在 AI 相关方向做的事情，挑选一个完善的项目介绍
为什么把模块结构写在各个模块下的 README，而不是直接写在 AGENTS.md 里引用？
有什么衡量方式可以证明自动生成 README 这件事带来的收益是正向的？
这件事体感上有什么正面例子？
了解过业界在代码索引这个方向做的相关工作吗？
ts-morph 是用来做什么的？
如果是 Vue 写的组件，要怎么提取注释信息？
讲一讲你在快手业务中做的事情
在快手业务中你觉得比较有趣的工作是什么？
在做模型选型切换的时候有没有做数据收集？如何判断选用的模型是否符合需求？
在这件事情中你的重点负责内容是什么？
Browser Agent 自测相关，你做了哪些工作？
Node 写的 MCP 的功能是什么？
为什么使用 MCP 的方式，而不是使用 Skill？
AI 自然语言检索与自动建联 Agent 工作流是什么？
在这个 Agent 工作流中你重点做的事情是什么？
你的实习预期是什么？
前两段实习为什么很快就结束？现在为什么在找新实习？
打开之前写过的代码，讲解里面的逻辑
项目里大多数代码都是 AI 写的吗？
使用 AI 开发时你的工作流是什么样的？
AI 写完代码后如何保证代码正确性，是否会 review 全部代码？
测试用例里面都写了什么内容？
AI 自动测试发现问题、误报的情况怎么样？
Spec 用的是哪一套方案？
使用 Spec 的过程中遇到过什么问题？Spec 不好用的点是什么？
在这个领域尝试过哪些工具？为什么最后选择 OpenSpec？
电商业务中是基于 OpenSpec 范式来写的吗？
反问：你们组大概做哪些业务？

面试复盘总结

1) 这场面试的核心画像

这轮面试不像传统前端八股，更多是在考察候选人是否真的能把 AI 工程化能力 落到业务研发流程里。

面试官追问的主线大概有四条：

项目目标是否清晰：做项目不是为了炫技，而是要能说明目标、收益和使用场景。
AI 工作流是否可控：AI 写代码之后，如何 review、测试、验收、人工接管。
基础设施是否有技术深度：Codebase Index、MCP、Skill、OpenSpec、Browser Agent 不能只讲概念。
业务理解是否扎实：快手业务中做了什么，为什么要做拖拉拽低代码，模型选型如何判断效果。

2) Codebase Index 可以怎么讲

Codebase Index 的重点不是“把代码塞给模型”，而是先把代码结构化，再让 Agent 能低成本检索和理解。

可以从这几层回答：

解析层：用 ts-morph 或 TypeScript Compiler API 解析 TS/TSX 文件，提取函数、组件、类型、导出符号、注释、起止行号等信息。
结构层：把文件路径、模块职责、符号关系、import/export 关系组织成索引数据。
检索层：根据自然语言查询召回相关模块、组件、函数和 README，而不是全仓库盲读。
更新层：文件变化后做增量更新，至少能按文件粒度重新解析；实时编辑场景可以监听文件变更或在任务开始前刷新索引。
消费层：把检索结果注入 Agent 上下文，让 AI 先读相关代码，再做实现或回答。

如果不使用 RAG，也可以通过更轻量的方式提升检索效果：

维护模块级 README，让模块职责和入口更清楚。
建立路径、组件名、导出符号、注释的倒排索引。
给常用模块加人工标签，比如 form、chart、auth、layout。
用 AST 提取结构化摘要，减少模型直接读长代码的成本。

3) Skill 和 MCP 的回答边界

这场反复问到为什么用 MCP、为什么写 Skill。可以这样拆：

Skill 解决“怎么做”
MCP 解决“能调用什么”
OpenSpec 解决“需求如何结构化”
Workflow 解决“这些东西如何串成稳定流程”

Skill 适合沉淀规则、组件库使用方法、代码风格、业务约束；MCP 适合把外部工具、文件系统、文档检索、代码索引、浏览器自测等能力标准化暴露给 Agent。

所以“为什么 MCP 而不是 Skill”的回答可以是：

如果只是告诉 AI 怎么使用某个组件，用 Skill 就够了；但如果要让 AI 动态查询代码索引、读取模块文档、执行自测或调用内部服务，就需要 MCP 这种工具协议。Skill 是说明书，MCP 是可调用能力。

4) AI 写代码后如何保证正确性

这类问题不要回答“AI 写完我看一下”。更好的表达是把验证链路讲完整：

需求层：先把需求拆成 Spec，明确输入、输出、边界和验收标准。
实现层：AI 生成代码后，人工 review 关键路径、状态流转、异常分支和安全边界。
静态检查：跑 lint、type check、单测、构建。
交互验证：前端页面用 Browser Agent 或 Playwright 检查主要路径。
回归记录：把 AI 出错的地方沉淀成规则、测试用例或 Skill。

可以补一句：

AI 可以提升实现速度，但最终责任还是工程师承担，所以我会把 AI 产物当成初稿，而不是直接合并的最终代码。

5) 这场面试最需要准备的数据

面试官多次追问“如何衡量收益”，所以讲 AI 和工程提效项目时，最好提前准备指标：

方向	可以准备的指标
README 自动生成	文档覆盖率、模块理解耗时、Agent 首次成功率
Codebase Index	检索命中率、无关上下文比例、定位代码耗时
Browser Agent 自测	自动发现问题数、误报率、人工接管率
SDD/TDD 工作流	需求返工次数、测试通过率、交付周期
模型选型	成功率、响应时延、成本、稳定性、人工修正次数

这场面试给我的提醒是：AI 项目不能只讲“用了什么工具”，还要讲 为什么这样设计、怎么证明有效、失败时怎么兜底。