美团 AI应用开发一面

1. 先做一下自我介绍，重点讲你做过的系统背景和你负责的核心链路

2. 你在团队里主要负责哪部分，怎么证明这部分不是“打杂型开发”

3. 你把整个系统架构讲一下，如果让我听完就能知道瓶颈可能在哪里

4. 技术栈选型的时候你会怎么做取舍，尤其是 Redis 和消息队列为什么这么选

选型不是比组件名气，而是比业务约束。Redis 适合做热点缓存、轻量状态、分布式协调和短期去重，但不适合承接强一致主数据；消息队列适合解耦、削峰和异步补偿，但不适合所有需要实时可见结果的主流程。真正的取舍点在于数据是否允许延迟、失败是否可补偿、顺序是否重要、消费是否要求可重放、以及业务能否接受最终一致。很多系统不是选错中间件，而是拿一个组件去解决本来不属于它的问题。

5. 如果不让你用现成 MQ，让你从零设计一个简化版消息队列，你会先保证什么

我不会一上来追求高吞吐，而是先定义消息模型和可靠性边界。最小可用版本至少要有顺序追加写、消息位点、消费者确认、重试和持久化。因为没有这些，所谓消息系统只是一个内存 List。再往后才是分区、副本、刷盘策略和长轮询拉取。真正难的点不是把消息存起来，而是同时处理“生产成功但消费者未确认”“消费者失败重试”“重复消费”“服务重启后位点恢复”这些场景。

class Message {
    long offset;
    String topic;
    String key;
    byte[] body;
}

6. 高流量下 MQ 挤压了，你不会只说扩容吧，你会怎么拆问题

消息堆积只是现象，不是结论。先看生产速度是不是突然突刺，再看消费端是不是因为某个下游退化导致平均处理耗时变长，还要确认是不是重试消息把正常流量淹没了。真正排查时要拆成分区是否均衡、消费组实例是否有效工作、单条消息处理耗时、失败率、死信增长、下游依赖 RT 和线程池活跃度。如果只是盲目扩容消费者，可能只会把数据库、缓存或者 RPC 服务一起压垮。

7. 如果订单链路要求局部有序，消息队列一般怎么做，不同 key 的并发又怎么保住

局部有序通常不是全局排队，而是按业务 key 分区，比如按订单 ID、用户 ID 或门店 ID 做 hash，让同一个 key 的消息始终落到同一个 partition。这样消费者只需要保证分区内顺序消费即可，不需要全局串行。问题在于热点 key 会拖慢整个分区，所以工程上经常要配合状态机设计，把真正需要严格顺序的步骤收窄，而不是把所有事件都绑定到同一个串行流里。顺序性的本质是业务约束，不是中间件配置开关。

8. 项目数据放在 MySQL 里，你做过哪些真正有效的优化，而不是“加索引”三个字

真正有效的优化通常不是单点操作，而是查询模式、表结构和访问路径一起改。比如把宽表拆成冷热字段、把高频回查改成覆盖索引、把低选择性条件从 where 中移出去、把大范围分页改成基于主键游标扫描、把历史数据归档减少主表膨胀。再往深一点，还会做 SQL 改写、慢查询指纹分析、索引下推验证和批量写入优化。很多线上问题看起来像数据库慢，实质是应用层访问模式不合理。

select id, status, update_time
from delivery_order
where shop_id = ?
  and status = ?
  and id > ?
order by id
limit 100;

9. 假如用户打开页面后整个流程都很慢，你怎么从前到后排查，而不是直接猜数据库

这种问题最好按链路切层。先确认前端是不是资源加载慢、DNS 或 TLS 是否异常、接口是不是串行调用过多；再看网关、鉴权、下游聚合接口、缓存命中、数据库和异步回填逻辑。排查时不能只盯最慢的那个点，还要看是否有级联放大，比如一个缓存 miss 导致多个回源 SQL，又叠加一个外部服务超时，最终页面所有模块都被拖慢。真正靠谱的方式是拿 trace 做全链路拆解，而不是凭经验瞎猜。

10. 如果确认是网络问题导致请求慢，你会怎么展开，不要停留在“可能丢包”

网络问题不能只说丢包和带宽不够。要看是客户端到接入层、接入层到服务、服务到数据库还是跨机房链路出了问题。具体要看 TCP 重传、连接建连时延、队头阻塞、MTU、Nagle、四层负载均衡回源、NAT 表、内核 backlog 和短连接风暴。很多线上“网络慢”其实是连接复用不足、负载不均、服务端 accept 不及时或者 DNS 抖动。真正定位网络问题，必须把它还原成连接建立、数据发送和响应返回三个阶段。

11. 如果网络没问题，那后端侧你优先从哪些信号判断故障发生在哪里

我通常先看四类信号：应用线程状态、GC 和内存、连接池和线程池、以及下游依赖 RT。因为很多后端故障表面像“服务慢”，实际上是线程池排队、连接池耗尽、锁竞争、频繁 Full GC 或者某个 RPC 依赖雪崩。只看应用日志很容易被表象误导，必须把 metrics、trace 和 thread dump 结合起来看。线上排查真正讲究的是先判断属于 CPU 型、IO 型、锁等待型还是资源耗尽型，再决定下一步抓什么。

jstack <pid> > threads.log
jstat -gcutil <pid> 1000
ss -s

12. 你有没有评估过系统能支撑多大规模，如果流量继续涨，哪些地方会最先出问题

这种问题不能报一个拍脑袋数字。比较像样的回答是说容量评估要按入口 QPS、平均 RT、P99、缓存命中、数据库并发、消息堆积上限和下游 SLA 一起估。通常最先出问题的不是 CPU，而是线程池、连接池、热点分片、缓存节点和数据库写放大。因为这些资源一旦饱和，系统吞吐不会线性下降，而是直接进入尾延迟恶化和超时重试放大的阶段。真正的扩容策略也不会是“机器翻倍”，而是热点隔离、限流、异步化和存储分片共同推进。

13. 你在项目里遇到过最难的线上问题是什么，最后是怎么解决的

比较典型的一类难题是状态不一致。比如订单主流程已经成功，但补偿链路因为消息重试和超时回查叠加，导致某些订单被重复触发退款或重复推送。最后的处理往往不是修一个 if，而是重做幂等模型、状态迁移约束、消息键设计和补偿任务幂等标记。线上复杂问题真正难在它通常不是单点 bug，而是多个“都没错”的组件叠在一起之后造成系统层面的错。

14. 你怎么处理大模型的幻觉问题，如果这部分能力要进生产，不是写一句“请基于事实回答”就够了吧

当然不够。生产环境里处理幻觉，核心不是提醒模型别编，而是收紧证据边界和输出权限。比如要求答案必须引用检索证据、没有证据就拒答、高风险动作必须通过规则校验、工具结果必须结构化回填。再往工程上做，会补一致性检查、事实抽取、答案后验判分和人工升级机制。幻觉真正危险的地方不在于“错”，而在于“错得很像真的”。

{
  "answer": "建议延迟触发二次调度",
  "evidence": [
    {"doc_id": "policy_19", "span": "暴雨等级达到橙色时可触发延迟策略"},
    {"doc_id": "event_3021", "span": "目标区域当前气象预警为橙色"}
  ],
  "need_human_review": true
}

15. 你的系统是单 Agent 还是多 Agent，这个选择是怎么做出来的

这个问题不能答成“多 Agent 更高级”。我更倾向于从任务结构出发，如果任务本身只是“检索 + 推理 + 输出”，单 Agent 加工具通常更稳，链路短、状态简单、调试容易。只有在职责天然能拆分，比如规划、执行、审计、复核互相边界明确时，多 Agent 才真正有价值。否则一旦拆得过细，上下文传递成本、错误放大和调试难度都会显著上升。系统设计真正重要的是控制复杂度，而不是追求架构名词。