美团秋招AI后端一面二面面经（食杂零售）

《面试题目》

一面

1. 你之前使用过小象超市吗？
2. 请做一下自我介绍。
3. 你在京东科技信用风险研发部和 AI 效能部的两段经历，分别是什么时间？是否都属于同一段实习？
4. 两段实习的工作时长和工作量占比如何？哪一段时间更长？
5. 京东实习结束后拿到转正 Offer 了吗？
6. 请介绍一下你在该业务线的业务内容、主要工作、项目产出和印象深刻的挑战。
7. 该业务中的 Agent 框架是你加入前已经搭建好的，还是你加入后从头建设的？
8. 你的工作偏业务接入层、涉及的链路节点有限，你是如何理解完整业务链路的？
9. 你了解该业务相关的风控策略或业务知识吗？
10. 这段实习中最有挑战的任务是什么？你是怎么解决的？
11. 这个问题从用户侧来看，会表现为什么样的交互现象？
12. 请介绍一下你在 AI 效能部的第二段实习经历。
13. 你在实习中主要负责 Agent 优化和业务 Skill 开发吗？为什么需要编写这么多 Skill？
14. 该 Agent 平台使用了哪些技术栈？底层是如何实现的？
15. 你开发的各种 Agent 任务和 Skill，是否都运行在同一个底层 Agent／OpenManus 框架上？
16. Agent 平台有哪些任务接入入口？
17. 你了解 Agent 平台的部署架构吗？具体是怎么部署的？
18. Java 服务与 Python 实现的 OpenManus Agent 使用什么协议通信？是 HTTP、RPC，还是两者都有？
19. 对于需要用户交互的 Agent 任务，系统是否支持流式返回？
20. 请介绍一下 SSE 协议，以及它与普通 HTTP 请求的区别。
21. 你在实习开发过程中主要使用哪些编程语言？是否全部使用 Java？
22. 为什么项目中还需要编写爬虫？
23. 实习过程中主要使用哪种数据库？
24. 你们使用的数据库是 MySQL，还是只兼容 MySQL 协议的内部数据库？
25. 实际开发中是否需要自己读写数据库，并处理慢查询、索引优化等问题？
26. 你的实习工作是否主要偏应用层和接入层，因此直接进行数据库读写和调优的场景比较少？
27. 你在学校学习过数据库相关课程吗？
28. 遇到慢 SQL 时，有哪些排查和优化思路？
29. 哪些情况下 SQL 可能走全表扫描？
30. 你在编写 SQL 方面有哪些经验或心得？
31. 在业务 Skill 中，什么情况下适合通过脚本实现，什么情况下不适合使用脚本？
32. 设计 Skill 时，会考虑 Agent 执行时的上下文吗？如何控制上下文规模？
33. 平时 AI 对你的开发帮助大吗？主要体现在哪些方面？
34. 在 Codex 和 Claude Code 之间，你更倾向使用哪一个？它们各自有什么优缺点？
35. 手写代码：实现外卖订单合并与配送路径优化，要求先按订单优先级处理，同一优先级内根据当前位置选择最近订单。
36. 你实现外卖订单合并与路径优化的主要思路是什么？
37. 骑手每送完一单后当前位置都会变化，其他订单与当前位置的距离也会变化，这一点应该如何处理？
38. 是否可以先按优先级对订单分组，再在每个优先级组内使用贪心算法，每次选择距离当前位置最近的订单，并在送达后更新当前位置？
39. 你怎么看现在的 AI Coding？你觉得这方面「卷」吗？
40. 你还有什么想了解或向面试官提问的吗？

二面

1. 初试面试官有没有向你介绍当前岗位主要负责什么？
2. 请做一下自我介绍。
3. 你现在还在京东实习吗？实习是否已经结束？
4. 京东是否给了你实习留用或转正机会？
5. 请介绍一下京东信审 Agent 链路的完整流程。
6. 这套 Agent 技术主要应用在什么业务场景？解决了什么问题？
7. 信审链路中的线程池隔离、状态缓存和分布式锁分别解决了什么问题？
8. 如果缓存或分布式锁因为网络抖动失效，会产生什么后果？
9. 信审业务使用的 H5 页面是你们全栈开发的，还是由专门的前端同学开发？
10. 你在团队中是独立开发还是与 Mentor 协作？Mentor 是否参与编码？
11. 你做过前端开发吗？
12. 团队开发过程中是否使用 AI Coding？
13. 你们使用 AI Coding 的完整开发流程是什么？是否属于 Vibe Coding？
14. 你们采用的是哪套 AI Coding 工作流，例如 SDD、Superpowers 或其他流程？
15. 你们有没有为 AI Coding 建设知识库？
16. 建设了哪些类型的知识库？
17. 为什么项目知识库中没有完整记录现有工程架构、技术选型、数据模型和代码位置？
18. 你开发过哪些 Agent Skill？
19. 选择一个你认为做得比较好的 Skill，详细介绍一下。
20. 商品价格查询 Skill 是否涉及权限控制？
21. 商品价格是否属于敏感信息？应该如何进行鉴权和数据范围控制？
22. 京东使用的 Redis 是自研服务吗？Redis 集群是如何部署的？
23. Redis 使用的是哨兵模式、集群模式，还是其他高可用方案？
24. 信审链路的日均新增审核量是多少？
25. 该链路的峰值 QPS 是多少？
26. 如果业务 QPS 某天突然增长数倍，会对审核链路产生什么影响？你会如何处理？
27. 请介绍一下车抵贷多证件解析项目。
28. 多证件解析完成率从 83.6% 提升到 92.5%，具体做了哪些优化？
29. 这个指标是如何统计出来的？如何证明提升由你的改动带来？
30. 优化后剩余的识别失败主要由哪些原因造成？
31. 对剩余的识别失败场景，你们如何处理和兜底？
32. 请介绍该 Agent 项目中 Planner、Executor 和 Critic 的设计。
33. Planner、Executor 和 Critic 分别负责什么？
34. Critic 在整个工作流中主要解决什么问题？
35. Critic 发现证据不足后，定向补证是如何实现的？
36. 补充证据后仍然无法支持结论怎么办？
37. 定向补证和重新执行是否有最大次数限制？为什么这样设置？
38. 该项目获得了 300+ Star，是否有真实用户反馈？
39. 有没有用户反馈过 Critic 判断错误？这种 Bad Case 如何处理？
40. 请介绍一下项目中的令牌桶限流方案。
41. 令牌桶在 Redis 中使用什么数据结构实现？如何保证计算和更新的原子性？
42. 代码审查题：检查一段 RocketMQ 消费者的 onMessage 代码，找出其中的问题。
43. onMessage 中同步执行完整业务逻辑可能产生什么问题？
44. RocketMQ 消费方法是否需要返回值？消费成功和失败是如何通知 Broker 的？
45. 如果 onMessage 中的代码执行了十分钟仍未结束，可能产生哪些问题？
46. 长时间消息消费可能如何影响消费超时、重试、重复消费、线程占用和消息积压？
47. 哪些开发工作适合交给 AI，哪些工作必须由自己掌控？
48. 代码 CR 是由你自己完成，还是主要交给 AI 完成？
49. AI Coding 在实际开发中大约能为你提升多少效率？这个数字如何衡量？
50. 你现在主要使用哪些大模型和 AI Coding 工具？
51. 你使用过智谱、Kimi 等国产模型吗？
52. 最近使用 AI 或研究新技术时，哪个场景或案例让你印象最深？
53. 该项目解决的核心问题是什么？它最核心的价值是什么？
54. 你使用过 MySQL 吗？
55. MySQL 聚簇索引和非聚簇索引的叶子节点分别存储什么？
56. 在实际项目中，如何判断一条 SQL 是否使用了索引？
57. 如何通过 EXPLAIN 判断 SQL 使用了哪个索引？
58. AI Coding 题：使用 AI 实现一个美团订单详情页面，你会怎么做？
59. 你会通过自然语言和 Vibe Coding 的方式生成页面吗？
60. 如果只给出「实现一个订单详情页面」的需求，你会如何自行设计页面内容和交互？
61. 订单详情页面是否需要提供支付入口？
62. 页面中的支付、取消订单、确认收货等按钮是否可以真正点击和交互？
63. 如何手动修改前端代码，使「确认收货」按钮点击后跳转到美团首页？
64. 如果不能使用 AI 自动修改，你会定位并修改哪一部分代码？
65. 算法题：求数组中最小的 K 个数。
66. 你是否直接对整个数组进行了排序？时间复杂度是多少？
67. 如果不允许使用 Arrays.sort，还有哪些实现方法？
68. 如何使用大小为 K 的最大堆解决最小 K 个数问题？
69. QuickSelect 如何解决最小 K 个数问题？平均和最坏时间复杂度分别是多少？
70. 你有什么问题想向面试官了解？
71. 你之前是否使用过小象超市？
72. 你如何看待从金融技术场景转到更偏零售业务研发的岗位？

《参考解析》

1. SSE 与普通 HTTP 请求的区别：SSE 是一条长连接上的单向推送，响应头是 text/event-stream，服务端按 data: 分帧持续写，客户端逐条解析，并自带断线重连与 Last-Event-ID 续传语义；普通 HTTP 是一问一答，响应写完连接就结束。Agent 任务要把中间步骤（思考、工具调用、结果）持续吐给前端，SSE 比轮询省连接、比 WebSocket 轻，代价是单向——客户端不能借这条通道上行——而且要处理网关与反向代理的缓冲，很多情况下不关掉 buffering，前端会等整段结束才看到内容。

2. Java 服务与 Python Agent 的通信：跨语言只能走进程间通信。HTTP/REST 最简单、可观测、好排查，代价是每次调用的序列化与连接开销；gRPC 这类 RPC 性能与接口契约更好，但要维护 IDL 与代码生成；长任务通常再叠一层消息队列解耦。常见的组合是「同步查询走 HTTP、长任务走 MQ 加回调」。判断标准是别为同一件事引两种协议——多一种协议就多一套超时、重试、鉴权与链路追踪配置，运维成本比那点性能收益更贵。

3. Skill 用脚本还是提示词：分界线是「确定性」。规则固定、输入输出可枚举、需要精确计算的（取数、格式转换、字段校验）写成脚本或工具，让模型只负责选参数；需要理解语义、跨系统协调、输出开放的（写报告、判断意图）留给模型加提示词。全写成脚本会让 Skill 失去泛化能力，全交给模型则不稳定且贵。上下文控制上，Skill 描述只留触发条件与边界，实现细节和长文档放到工具里按需读取，大结果集先在工具内裁剪再回灌，避免一次任务把上下文塞满。

4. 慢 SQL 与全表扫描：先用慢查询日志或 APM 捞出 TOP SQL，再用 EXPLAIN 看 type、key、rows、filtered 与 Extra。走全表扫描的常见原因：没有可用索引、索引区分度太低、对索引列做函数运算或隐式类型转换、like '%x' 前置通配、or 连接了非索引列、联合索引不满足最左前缀、优化器估算后认为走索引回表更贵而主动选全扫、order by/group by 用不上索引。优化手段按代价排序：补或调整联合索引、用覆盖索引避免回表、改写 SQL 让条件可走索引、深分页改游标、大表归档或分区。

5. Redis 令牌桶的原子性：令牌桶要「按经过时间补令牌」和「取令牌」两步原子完成。用 Hash 存当前令牌数与上次补充的时间戳，把读、算、写放进一段 Lua 脚本用 EVAL 执行，靠 Redis 单线程保证脚本不被打断；时间源建议统一（脚本内取 TIME 或由调用方传入），避免各节点本地时钟不一致导致补多补少。脚本返回值要能告诉调用方是否拿到令牌、还需等多久。限流器本身不能失败就放行——脚本报错时应按拒绝处理，这是限流组件最容易写错的地方。

6. RocketMQ 的 onMessage 里同步跑完整业务：onMessage 运行在消费线程池里，同步跑十分钟会先把线程占满，线程池打满后其他队列没人拉取，消息迅速积压；消费位点迟迟不提交，触发 Broker 的消费超时与重试，消息被重复投递，业务必须幂等；重试次数耗尽后进死信队列，还得人工处理。正确做法是 onMessage 内只做轻量校验与投递（落库或转发到业务线程池、另一条消息），长耗时逻辑异步化并用幂等键去重。另外消费成功靠正常返回或返回成功状态，抛异常才走重试，所以「把异常吞掉当成功」同样危险。

7. 聚簇索引与二级索引：InnoDB 的主键索引是聚簇索引，叶子节点直接存整行数据，按主键查一次就能拿到所有列；二级索引的叶子节点存的是索引列加主键值，要取非索引列就得拿主键回表再查一次聚簇索引，除非查询列被索引完全覆盖。由此有两条实践结论：主键要短且递增，避免页分裂和二级索引膨胀；能覆盖就用覆盖索引减少回表。判断有没有走索引看 EXPLAIN 的 key、possible_keys、rows 与 Extra，Using index 是覆盖索引，Using filesort、Using temporary 是需要警惕的信号。

8. 最小 K 个数：最大堆与 QuickSelect：Arrays.sort 是 O(n log n)，面试要的是更优解。维护一个大小为 K 的最大堆：遍历数组，堆未满直接入堆，堆顶比当前元素大就弹出堆顶再入堆，最后堆里就是最小的 K 个，时间 O(n log K)、空间 O(K)，适合 n 很大而 K 很小或数据流式的场景。QuickSelect 是快排 partition 的单边递归：每轮看基准位置与 K 的关系只递归一侧，平均 O(n)、最坏 O(n²)，随机化基准或三数取中可以缓解；它原地进行、额外空间 O(1)，但会改动原数组，最坏情况必须在面试里主动交代。