脉脉

爱摸鱼的技术负责人

07-04 · 神州

转行面大模型岗，讲工具调用项目总被面试官追着问露馅？我是摸鱼CTO老汪，上班摸鱼攒了不少Agent项目经验，当年从后端转大模型应用开发，第一次面工具调用项目就栽在这，被追着问生产问题直接卡壳，场面一度尴尬。面过七八十个转行的候选人，八九成都栽在同一个问题上：项目讲得像标准demo，半点儿生产质感都没有。很多人讲工具调用，上来就列调用了多少工具、套了什么开源框架，说得越全越像培训班练手货。站在面试官视角根本不关心你用了哪几款工具，关心的是你有没有处理过真实线上场景的问题。真相是：工具调用项目，功能堆得越满，越容易被判定注水。分享三个调整表达的思路，不用改项目，换个说法就能拉满真实感：- 别只讲工具列表不讲异常兜底。很多人上来就报搜索、计算器、数据库一堆工具名，在面试官眼里和应届生写的demo没区别。不如重点讲工具失效时的处理逻辑，比如“第三方天气工具超时率8%，我加了两级降级，先重试再切本地缓存，最后返回兜底话术，把调用成功率从91%拉到99.2%”，真实感立刻就有了。- 别脱离业务讲参数配置。别掰扯function call的参数格式、用了什么框架封装，纯调API的工作没有竞争力。要绑定业务场景讲设计取舍，比如“做内部工单Agent时，一开始把所有字段都当入参，大模型参数混淆误调用率15%，后来只留3个核心必填参数，剩下的走后置补全，误调用率直接降到2%以内”。- 别回避多工具协同的坑。别只说单工具调用有多丝滑，越完美越像没碰过真实链路。主动讲多工具串行的问题，比如“做数据查询Agent时，一开始查库+生成报表两步串行，经常查库数据没返回就触发报表生成，我加了状态机做调用校验，每步结果做格式校验再进下一环，链路报错率降了七成”。还有个最容易忽略的前置坑：别为了显得项目复杂硬堆工具数量。判断标准很简单：如果一个工具的调用场景，你说不出对应的业务收益和踩过的坑，那就是凑数的。面试官判断项目真实性，从来不是看技术复杂度，是看你有没有解决过真实的生产问题，凑数的工具一深问就露馅。其实转行面试拼的从来不是项目有多高大上，是能不能把做过的事讲出真实的生产质感。不是你能力不行，只是之前没人告诉你面试官真正想听什么。我整理了大模型应用岗面试高频题和生产级项目表达参考，都是自己踩坑攒出来的干货。祝大家转岗顺利，都能拿到心仪的offer。