哔哩哔哩公益平台二面 OC

面试时间

2026_0811-17:00

面试内容

讲一下组件库 Skill 相关的具体工作内容
Skill 方案与向量数据库 RAG 方案的优劣对比
为什么需要额外维护 README 文档？底层逻辑是什么？大模型本身已经可以直接读取代码
Skill 方案如何做性能优化相关处理？
如何依据设计稿划分模块 A 和模块 B 的边界？
SDD AI 研发链路的具体应用场景，你承担的核心工作是什么？
在 AI 研发全链路当中你的完整参与情况
AI 自动化研发流程当中是否有人工审核兜底机制？
AI 代码生成的运行环境是什么？
PRD 与代码对比环节，是否可以让 AI 基于历史逻辑自主分析生成方案？
微前端场景下 AI 无法跨仓库读取代码该如何处理？
PRD 滞后会议沟通、开发途中需求变更，如何补齐 AI 所需上下文？
Figma 和本地组件库之间的比对机制是什么？
反问：公司以及组内 AI 工具额度情况

面试复盘总结

1) 这轮面试的核心

这轮面试基本不考传统八股，而是在深挖 AI 研发链路能不能工程化落地。

面试官重点关注的不是“有没有用 AI”，而是：

组件库 Skill 是否真的能提升生成质量。
Skill、README、RAG、代码索引之间的边界是否清楚。
AI 自动研发链路是否有人工兜底和质量控制。
跨仓库、需求变更、设计稿对齐这些真实工程场景怎么处理。

2) 组件库 Skill 可以怎么讲

组件库 Skill 的核心目标，是让 AI 在生成页面或组件时，不再凭通用知识“猜组件”，而是按照团队内部组件库的真实约束来写代码。

可以从四层回答：

组件说明：组件名、使用场景、props、事件、插槽、约束。
代码示例：常见业务场景下怎么组合组件。
禁用规则：哪些组件不推荐使用，哪些写法容易出 bug。
验收方式：生成后跑类型检查、lint、构建和页面自测。

面试表达可以这样说：

我做组件库 Skill 的目的不是把代码重复喂给模型，而是把组件库中对研发最关键的“使用规则”和“组合范式”结构化沉淀下来。AI 直接读源码可以知道组件长什么样，但很难稳定理解业务里应该怎么用、哪些 props 是团队约定、哪些场景不能这样写。Skill 更像是一份面向 Agent 的组件使用手册。

3) Skill 与向量数据库 RAG 的优劣对比

Skill 和 RAG 不是互相替代关系，适合解决的问题不同。

维度	Skill	RAG
核心作用	固化规则、流程和最佳实践	从大规模资料中检索相关上下文
适合内容	稳定、强约束、需要遵守的规范	体量大、变化快、需要查找的知识
优点	可控、低延迟、确定性更强	覆盖面广、可动态更新
缺点	需要人工维护，覆盖范围有限	召回可能不准，上下文噪声较多
典型场景	组件库使用规则、代码规范、工作流	文档检索、历史代码检索、知识库问答

可以总结成一句：

Skill 适合沉淀“必须遵守的规则”，RAG 适合解决“资料太多需要查找”的问题。组件库使用这种高频、稳定、强约束场景，我会优先用 Skill；如果组件库文档非常大，再结合 RAG 做补充检索。

4) 为什么还要维护 README，不能让模型直接读代码？

模型确实可以读代码，但直接读代码有几个问题：

上下文成本高：源码太长，模型容易把上下文浪费在实现细节上。
抽象层级不稳定：代码描述的是“怎么实现”，README 描述的是“这个模块负责什么”。
业务意图缺失：很多业务约定、边界、历史原因不一定体现在代码里。
检索效果不稳定：没有模块摘要时，Agent 很难快速判断该读哪个文件。
维护成本转移：不写 README，不代表没有成本，只是把理解成本转移给每次使用 AI 的上下文窗口。

更好的回答：

README 的底层价值是给代码加一层语义索引。源码解决实现问题，README 解决定位和理解问题。AI 当然可以直接读代码，但如果每次都从源码里推断模块职责，成本高、噪声大、稳定性也差。模块级 README 可以让 Agent 先判断“该不该读这个模块”，再决定读哪些具体文件。

5) Skill 方案的性能优化

Skill 性能优化不是传统意义上的运行时优化，而是 上下文使用效率优化。

可以从这些点讲：

分层加载：先加载总览，只有命中具体组件时再加载详细规则。
按场景拆分：表单、表格、弹窗、图表分别维护，避免一次塞入全部组件说明。
减少重复示例：示例要覆盖关键模式，不追求数量堆叠。
结构化格式：固定字段如 When to use、Props、Example、Pitfalls，方便模型定位。
和检查工具结合：不要指望 Skill 解决所有问题，类型检查和 lint 负责兜底。

面试里可以强调：

Skill 的性能优化核心是减少无效上下文，让模型在更短的 token 内拿到更高密度的决策信息。

6) SDD AI 研发链路怎么讲

SDD 可以理解为 Spec Driven Development：先把需求结构化，再让 AI 基于 Spec 产出方案、代码和测试。

一条完整链路可以这样描述：

需求输入 -> PRD/会议纪要整理 -> Spec 拆分 -> 技术方案 -> 任务计划 -> AI 编码 -> 自动检查 -> 人工 Review -> 合并上线

你承担的核心工作可以聚焦在：

把非结构化需求整理成 AI 可执行的 Spec。
为 Agent 提供组件库 Skill、模块 README、代码索引等上下文。
设计 AI 生成代码后的验证流程，比如 lint、type check、build、Browser Agent 自测。
在关键节点做人工审核，防止 AI 自作主张改业务逻辑。

7) 人工审核兜底机制

AI 自动化研发不能完全无人值守，尤其是业务逻辑、权限、数据写入、支付、发布这些环节。

可以这样回答：

我的理解是 AI 可以自动完成草稿实现和部分验证，但关键节点必须有人审。比如 Spec 生成后要人工确认需求没有偏差；代码生成后要 review 状态流转、异常分支和权限边界；自动测试失败或出现不确定结果时要人工接管。AI 的定位是加速器，不是责任主体。

8) 微前端跨仓库上下文怎么处理

如果 AI 无法直接跨仓库读取代码，可以用几种方式补齐上下文：

接口契约：把子应用暴露的 props、事件、路由、生命周期整理成契约文档。
模块摘要：每个仓库维护模块级 README，由主仓库引用。
产物索引：把多个仓库的组件元信息、类型声明、CHANGELOG 汇总成统一索引。
按需授权读取：任务需要时临时挂载相关仓库，只给最小必要上下文。
Mock 与契约测试：主应用不直接依赖子仓库源码，而是通过契约测试保证集成正确。

一句话总结：

跨仓库场景不能假设 AI 能读到所有源码，应该把跨仓库依赖收敛成契约和索引，让 AI 依赖稳定接口，而不是依赖隐式源码上下文。

9) 需求变更如何补齐 AI 上下文

PRD 滞后、会议口头沟通、开发中需求变更，是 AI 研发链路里很现实的问题。

处理方式：

会后把口头变更补成变更记录。
Spec 增加 revision 或 changelog。
每次继续任务前，让 AI 先读取最新 Spec 和变更摘要。
重要变更必须重新生成任务计划，而不是在旧计划上硬改。
对已经生成的代码做 PRD diff，检查哪些地方需要同步修改。

可以这样讲：

AI 不怕需求变更，怕的是上下文不一致。只要把变更沉淀成结构化 revision，并让 Agent 每次执行前读取最新版本，就能降低它基于旧需求继续开发的风险。

10) Figma 和本地组件库比对机制

这个问题可以从“设计资产”和“代码组件”的映射关系来讲：

组件命名映射：Figma 组件名和本地组件名建立对应关系。
属性映射：设计稿 variant 对应代码 props，例如 size、type、status。
Token 映射：颜色、字号、间距、圆角等使用统一 design token。
差异检查：如果设计稿使用了本地组件库没有的变体，标记为需要人工确认。
生成约束：AI 生成代码时优先使用已有组件和 token，不随意手写样式。

面试表达：

Figma 到代码不是像素级复制，而是把设计稿里的组件、variant 和 token 映射到本地组件库。比对机制的关键是识别设计稿用了哪些组件能力，本地组件库是否已有对应实现；如果没有，就进入人工确认或组件扩展流程。

11) 本轮面试的复盘重点

这轮面试最需要准备的是 AI 工程化闭环，也就是：

上下文怎么给 -> AI 怎么生成 -> 如何验证 -> 出错谁兜底 -> 结果如何沉淀

以后遇到类似面试，可以围绕这句话回答：

我关注的不是让 AI 一次性写出所有代码，而是构建一条稳定链路：通过 Spec、Skill、README 和代码索引给 AI 足够准确的上下文，通过自动检查和人工 review 控制质量，再把问题沉淀回规则和文档里，让下一次生成更稳定。