美团 AI应用开发 一面

本地商业

1. 先做一下实习时候的业务介绍，有什么提升

2. AI Coding 功能从能演示到能交付，中间差的到底是什么

差的不是模型会不会写代码，而是系统有没有交付闭环。演示阶段只要能在几个样例上生成看起来对的 patch 就行，但生产可交付要求它能处理不完整需求、脏仓库、编译失败、依赖缺失、测试不稳定和回滚策略。真正落地时必须加任务约束、静态检查、sandbox、单测回归、补丁审计和失败分级，否则所谓“生成功能”只是把风险后移给人。AI Coding 一旦进入真实研发流，评价标准就从“会不会写”变成“出了错能不能收住”。

def deliverable_check(repo, patch):
    if not compile_ok(repo, patch):
        return "reject: compile_failed"
    if not run_unit_tests(repo, patch):
        return "reject: tests_failed"
    if high_risk_api_touched(patch):
        return "need_human_review"
    return "accept"

3. 你怎么理解大模型在工程侧最致命的短板，不要泛泛说幻觉

真正致命的短板不是它会答错，而是它经常在“证据不足、状态不完整、工具失败”时依然给出流畅答案。工程上最怕这种错，因为它不像报错那么显眼，反而容易被误用。另一个短板是上下文敏感且不稳定，同一问题换个顺序、换段历史、换次检索结果，行为可能就漂移。再往深一点，大模型天然缺少严格状态机意识，所以一旦任务需要前置条件、权限校验和不可逆动作控制，它必须被外部系统框住，而不能裸奔。

4. 公司内部上下文通常很杂，你会怎么做上下文治理

企业内部上下文不能混成一个大字符串喂给模型。更合理的做法是把它拆成会话态、知识态、实时态和工具态。会话态保留用户当前任务的显式目标，知识态来自文档和规程，实时态来自监控、订单、配置和日志，工具态则是当前可调用能力及权限。这样做的本质是防止模型把历史聊天、静态文档和实时事实混为一谈。上下文治理越往后做，问题越难查，因为最后你根本不知道模型是被哪一类信息带偏的。

5. 详细讲一下 Oncall 机器人，RAG 到底在用什么做向量化，不是所有东西都该直接 embedding 吧

当然不是。Oncall 场景里可向量化的对象通常不是“整段日志”，而是经过抽象后的故障单元，比如告警模板、Runbook 片段、错误码解释、依赖关系说明、历史处置摘要和服务画像。原始日志更适合先做结构提取，再把异常模式、调用链片段和聚合后的诊断线索送进检索层。否则直接 embedding 海量日志，既贵又脏，还会把时间性极强的噪声引进来。Oncall RAG 真正难的是把“语义知识”和“实时证据”拼成一个可执行排障上下文，而不是单纯做向量检索。

6. 发散提问很多的时候，系统怎么把问题收敛到可执行路径

发散提问本身不是坏事，坏的是一直发散却没有状态收敛。比较稳的做法是先把用户问题映射到任务槽位，比如服务名、环境、时间范围、异常现象、影响范围和最近变更。只要这些关键槽位没补齐，系统就不应该开始生成执行方案。很多系统看起来“会聊天”，但实际上一直在无效探索，因为每轮对话都没有让状态变得更确定。真正能落地的系统，必须把每轮交互转成结构化增量，而不是只累积自然语言。

{
  "task": "incident_triage",
  "slots": {
    "service": "payment-core",
    "env": "prod",
    "symptom": "p99_latency_spike",
    "time_range": "2026-04-15T00:10~00:25",
    "recent_change": null
  }
}

7. 模型经常会给出“听起来对，但根本不可执行”的回答，这类问题怎么治

这类问题往往不是知识缺失，而是执行语义没有被约束。解决思路通常有两层：第一层是把输出格式化，强制它写明前置条件、依赖对象、执行命令、风险级别和回退方式；第二层是把“建议”和“动作”彻底分开，建议可以自然语言生成，动作必须走工具校验。只要没有前置条件校验，模型就很容易给出跨环境、越权限、错版本的建议。听起来有道理，不等于线上可操作。

8. 如果让你从 0 学一个新技术或新框架，你的学习路径是什么

我不会先大面积刷教程，而是先确定这个技术在真实系统里承担什么角色，再围绕最小闭环去学。比如先跑一个最小可运行 demo，知道它的核心对象、生命周期、数据流和失败模式；然后看一遍官方文档和源码入口，搞清扩展点和默认行为；最后把它放进一个真实问题里，验证性能边界和异常路径。真正学会一个工具，不是“会用 API”，而是知道它在什么情况下会失效，以及失效后怎么补救。

9. 模糊度很高的一个任务，你会怎么拆，不让系统和人都陷入反复返工

高模糊任务最怕一开始就直接做方案。更好的做法是先定义问题边界、约束条件、验收口径和不能碰的红线，再拆出可以独立验证的小阶段。AI 系统尤其如此，因为如果目标定义本身是糊的，后面无论模型、RAG、Agent 怎么调，都会出现“看起来做了很多，但没人能判断是不是完成”的情况。真正有效的拆解一定会先产出结构化任务定义，而不是直接产出结果。

10. 超卖和假库存是两个问题，你会怎么一起治理

超卖通常是扣减时序和并发控制问题，假库存更偏数据同步和视图延迟问题。前者要解决的是高并发下库存原子扣减、订单回滚补偿和幂等重复扣减；后者要解决的是多仓、多渠道、多状态库存口径不一致。工程上不能只靠“加锁”处理，因为锁只能解决瞬时竞争，解决不了异步回流、消息延迟和状态对账。比较稳的方式是主库存收口、预占库存独立建模、异步回补加审计，再配合定时对账把脏数据捞出来。

-- 原子校验并扣减库存
local stock = tonumber(redis.call('GET', KEYS[1]) or '-1')
local need = tonumber(ARGV[1])
if stock < 0 then
    return -2
end
if st