网易互娱 AI应用开发 日常实习 一面二面

《面试题目》

一面

1. 开共享屏幕画出 coding agent 架构图，并阐述一个请求进来流程怎么走
2. 有了 MCP 为什么还需要 Skill？
3. MCP 有哪些实现方式，分别使用哪些协议？
4. 实习中是否遇到过模型限流的问题？错误码是多少？怎么处理？
5. 实习项目里对大模型 API 并发调用怎么控制的？
6. 有没有思考过不同的 coding agent 缓存命中率不同的原因？

二面（几乎全是业务场景题）

7. 你的实习项目中，你觉得遇到最大的困难是什么？怎么解决的？
8. 如何设计一套针对线上业务报错、通过 AI 自动化管线分析分类、自动修复并提交 Merge Request 闭环的系统？需要划分哪些模块？提供什么样的服务？用户应该怎么用？技术选型怎么做（Agent 框架、接收监控的接入层、数据库）？
9. 在由 Agent 持续修改代码的情况下，如何通过质量保障确保代码质量符合预期？
10. 系统上线后 AI 生成了大量代码导致人工看不过来时，人工审查的重点应该看什么？
11. 打开 GitLab 看到 AI 为某个需求提交了大量文件和代码时，具体应该看哪些文件或内容？
12. 如何让 AI 辅助代码审查？当 AI 审查完表示没有问题时，如何保证其审查结果可靠？
13. 当输入 MR 让 AI 审查，而 AI 回复「没问题，看完了」时，是否真的代表没有问题？
14. 怎么利用 AI 提升测试效率，避免每次写完需求都要人工把系统点一遍？
15. 当 AI 表示测试好了且单元测试全绿通过，是否意味着可以直接上线？
16. 当 AI 打开页面点了几下按钮并生成了一份详细测试报告时，如何判断这个测试是否充分？
17. 团队自动化开发久了出现 AI 制造「屎山代码」导致越来越改不动的情况，应该怎么处理和预防？
18. 如果团队在 CLAUDE.md 中写了三四十条规则且连续开发了两三个月，如何确认仓库是否真的在遵循这些规则，以及如何确定有没有产生不可控的技术债务？
19. 分享你最近了解过的新的 AI 知识？

《参考解析》

MCP 与 Skill 的关系：MCP 解决的是「工具与数据的标准化接入」——它定义了一套协议（传输上用 stdio 或 HTTP + SSE / Streamable HTTP，消息用 JSON-RPC），把 server 暴露的 tools、resources、prompts 统一给客户端消费，好处是写一次 server 就能被所有支持 MCP 的客户端使用。Skill 解决的是「任务怎么做」——它把流程说明、脚本、参考资料打包成可复用的能力单元，靠渐进式披露按需加载，避免上下文膨胀。两者的分工可以概括为：MCP 提供「手」（能调用什么），Skill 提供「方法」（该怎么用、按什么步骤）。面试官问「有了 MCP 为什么还要 Skill」，答案就是：MCP 给的是原子能力，复杂任务还需要编排知识、领域约定和参考文档，而这些塞进工具描述里会爆上下文。

限流与并发控制：模型网关的限流通常返回 HTTP 429（或厂商特有的错误码 / 业务码），处理方式是区分「可重试」（429、5xx、超时）与「不可重试」（400 参数错误、401/403 权限、内容审核拒绝）；可重试的用指数退避 + 抖动 + 上限重试，并在多 key / 多渠道之间做轮换与故障转移。并发控制用信号量或带并发上限的队列（令牌桶做速率限制，信号量做并发限制），配合请求优先级（用户实时请求优先于离线任务）、超时与熔断（连续失败就快速失败一段时间）。缓存命中率差异的原因可以答：提示词结构是否稳定（前缀是否变化会破坏 KV Cache）、上下文是否包含时间戳等易变内容、有没有把长文档重复塞入、以及缓存策略（精确匹配 vs 语义缓存）和 TTL 设置。

AI 自动修复报错的系统设计：模块划分建议：接入层（订阅监控 / 日志 / 工单系统的事件，做去重与聚合，避免同一异常触发多次修复）、分析层（聚类与根因定位，检索相关代码与历史相似工单）、修复层（Agent 生成补丁，跑沙箱环境验证）、验证层（单测、静态检查、必要的端到端用例）、提交层（建分支、提交 MR、带上分析与复现说明）、以及运营层（人审队列、指标看板、反馈回流）。关键设计原则是「AI 提交 MR 但不自动合并」——人始终在环路上；同时要有幂等（同一报错只修一次）、限流（别把 CI 打爆）与审计（每一步可追溯）。技术选型上，Agent 框架按团队熟悉度与可控性选（自研状态机往往比全功能框架更好调试），接入层用消息队列削峰 + 幂等消费，数据库存事件、补丁、MR 与结果的关联记录。

AI 代码审查可信吗：不可信是默认答案，关键是给出理由和补救。AI 审查擅长风格、明显缺陷、常见安全模式与一致性检查，但它的局限是：缺乏运行时信息（不知道真实流量和线上配置）、容易对「看起来对」的实现放过、会漏掉跨模块的隐式契约、以及存在自洽性偏差（它自己的假设不会被挑战）。要提高可靠性：给足上下文（相关文件、测试、变更原因），要求它输出结构化的检查项与证据（引用具体行号与规则），对高风险改动做交叉审查（换模型 / 换 prompt 再审一次），并且用「已知缺陷的回归集」持续测审查器本身的效果。至于「AI 说没问题是否真没问题」——正确的回答是把它当筛选器而不是裁判：人审的重点放到接口契约、状态与并发、数据一致性与回滚方案这些 AI 最容易漏的地方。

测试与屎山治理：用 AI 提效测试的路径：根据需求与 diff 生成用例草稿（人审后补边界）、用 Playwright / 端到端脚本把关键链路固化（比「AI 点几下」可复现得多）、用变更影响分析决定回归范围、以及把 flaky 用例与覆盖率趋势纳入看板。「AI 点了几下按钮生成了详细报告，怎么判断测试充分」——要看报告是否包含：覆盖了哪些页面与状态、断言了什么（不能只看「页面打开成功」）、有没有覆盖异常与边界（空数据、权限不足、网络失败）、是否可复现（脚本化）、以及失败时的证据（截图、日志、请求记录）。屎山的预防靠流程而非工具：控制单次改动规模、强制评审与测试门禁、定期重构排期、把架构约定写进规则文件，并且定期用「规则落实审计」（随机抽样若干 PR 人工核对是否真的遵守了 CLAUDE.md 的规则，以及统计返工率、缺陷密度、平均修复时长这类技术债指标）来判断有没有失控。

这一轮的特点：这场面试几乎没有标准八股，全部是「如果你来设计，你会怎么做」——考的是系统设计与工程判断。面试官的问题本身就是很好的复习提纲：把「AI 参与研发流程」拆成生成、验证、审查、测试、治理五个环节，每个环节准备一两个真实案例，就能撑住这类面试。作者第一问「画架构图」也提示了准备方法——能随手画出一个 Agent 系统的完整数据流与失败路径，是这类岗位最基础的表达能力。