蚂蚁 AI应用开发二面

1. 实习拷打

2. AI Coding 的笔试如果只是人工造 case 去测，你觉得它离生产可交付还差什么

人工造 case 只能验证“在已知分布上能不能过样例”，离生产可交付还差三层。第一层是任务边界，要明确输入约束、输出格式、失败语义和回滚策略，不然模型生成的内容没法进入真实工作流。第二层是稳定性，要知道不同仓库规模、不同语言、不同依赖环境下性能会不会抖。第三层是验收能力，必须补静态检查、单测、sandbox 执行、diff 审核和回归评估。没有这些，AI Coding 最多是演示能力，不是工程能力。

def validate_patch(patch, repo_path):
    if not syntax_check(patch):
        return {"ok": False, "reason": "syntax_error"}
    if not unit_test(repo_path, patch):
        return {"ok": False, "reason": "unit_test_failed"}
    if not lint_check(repo_path, patch):
        return {"ok": False, "reason": "lint_failed"}
    return {"ok": True}

3. Oncall 机器人回答准确率怎么定义，为什么“用户感觉还行”不够

Oncall 机器人不是聊天机器人，准确率不能只看主观满意度。更合理的定义通常要拆成意图识别准确率、证据命中率、操作建议正确率、升级转人工正确率和最终处置成功率。因为有些回答语言很流畅，但引用证据错了；有些判断本身没错，但升级条件漏掉了，线上风险反而更大。真正可用的 oncall 机器人必须以“减少错误操作”和“缩短故障恢复时间”为目标，而不是把回复写得像人工。

4. 如何提高 Oncall 机器人的回答准确率，而不是一味堆更强的模型

提高准确率，通常不是先换模型，而是先收紧问题空间。先把告警类型、日志模式、服务依赖图、常见剧本和历史处置动作结构化，再让模型在受限证据里推理。其次要做分层回答，像“解释告警”“建议排查路径”“允许执行动作”不能混在一起。再往上要做证据引用、工具白名单和高风险操作确认。真正稳定的 oncall 系统，往往是规则、检索、工具和模型一起配合，而不是全靠大模型自由发挥。

5. 回答用户问题时，怎么保证不是只把对应文档找出来，而是真的完成了任务

“找到文档”只是检索成功，不代表任务完成。任务完成通常意味着模型不仅要找到证据，还要完成参数抽取、条件判断、上下文补全和结果落地。比如用户问“某类故障怎么恢复”，如果只是甩一段文档给他，实际上仍然需要他自己判断版本、环境和执行顺序。真正的任务型系统一般会把流程拆成检索、判定、执行建议、风险校验和结果确认几步，而不是把文档当答案本身。

6. RAG 在文档比较少的情况下，和全文检索的边界到底在哪

文档少的时候，RAG 不一定天然优于全文检索。因为当知识规模还小、文档结构很清晰、关键词稳定时，全文检索往往更直接、可解释性也更强。RAG 的价值更多体现在语义表达多样、同义改写多、跨段证据整合和答案生成这些场景。真正选型时不能只看“是不是 AI 应用”，而要看问题是不是需要语义泛化、跨文档组合和自然语言归纳。如果只是定位一条配置项或错误码，全文检索经常更稳。

7. 机器人和用户交互效果一般看哪些指标，为什么轮次数多不一定代表体验差

交互效果至少要看首轮命中率、平均轮次、任务完成率、转人工率、用户放弃率和高风险误导率。轮次数多不一定差，因为有些任务本来就需要澄清信息，比如版本、区域、权限和资源对象。真正差的是无效轮次多，也就是系统一直在重复问已经知道的信息，或者在错误路径上打转。评估交互质量不能只盯平均轮数，还要看每一轮是不是在有效收缩问题空间。

8. 评估机制收集到的反馈数据应该怎么用，才能形成真正有价值的闭环

反馈数据如果只是做满意度统计，价值很有限。更有效的做法是把反馈分层：用户显式评分、是否采纳建议、是否转人工、最终工单结果、执行后是否恢复，以及人工修正内容。然后用这些反馈去做 bad case 归因，区分是检索问题、提示词问题、工具调用问题还是知识过期问题。闭环真正的关键不是“收集了很多反馈”，而是反馈能不能反向驱动知识更新、case 增补和策略调整。

9. Agent 项目里是怎么通过 MCP 实现工具调用的，为什么不是直接本地函数调用

MCP 的价值不是“能调用工具”这么简单，而是把工具能力协议化、可发现化、跨进程化。直接本地函数调用当然也能跑，但一旦工具分布在不同服务、不同语言、不同权限域里，本地调用很快就会把 Agent 和底层系统耦死。MCP 更像一个受控工具总线，模型只看统一的工具描述、参数 schema 和返回结构，底层具体是本地服务、远程服务还是受限执行环境，对上层来说可以统一抽象。这样工具治理、权限控制和审计才更容易做。

{
  "name": "query_alert_detail",
  "description": "查询告警详情及最近30分钟异常指标",
  "inputSchema": {
    "type": "object",
    "properties": {
      "alertId": { "type": "string" }
    },
    "required": ["alertId"]
  }
}

10. 展开讲一下 MCP 和 Skill 的关系，它们为什么经常被混着说

Skill 更像任务语义层面的能力单元，强调“完成什么事”；MCP 更像工具接入和调用协议层，强调“怎么把能力安全暴露出来”。一个 Skill 可能会调用多个 MCP 工具，也可能一个 MCP 工具被多个 Skill 复用。两者混着说，通常是因为在简单 demo 里它们都表现为“模型能调一个东西”。但工程里差异很明显，Skill 要考虑任务边界、输入输出契约、失败回退和效果评估；MCP 更关注工具注册、发现、鉴权、参数校验和执行审计。