脉脉

爱摸鱼的技术负责人

07-03 · 金账卫士

转行投大模型岗，简历上的运维知识库RAG项目写满技术栈直接被秒筛？我是摸鱼CTO老汪，趁今天故障复盘会临时推迟的间隙，摸鱼唠点实打实的简历干货。我当年从运维转大模型，第一版简历投了二十多份只拿到一个面试，后来托HR朋友打听才知道，我的项目写得跟开源Demo模板一模一样，招聘方扫三秒就归到练手项目档了。很多转行的朋友写大模型项目简历，总觉得技术名词堆得越多、功能写得越全，越显得能力强。但站在招聘方视角，这种模板化的写法一天能见几十份，全是教程标配的内容，不用细看就知道没接触过真实生产环境。核心真相是：简历上的大模型项目，写得越全面越像教程复刻，越容易被一眼看穿是练手作品。分享三个改写思路，不用改项目不用补技术，换个表述真实感直接拉满。别只列技术栈不写业务价值。很多人项目描述全是“基于LangChain搭建RAG系统，接入向量数据库与开源嵌入模型，实现语义检索与生成回答”，通篇技术名词像学习笔记，面试官看不到实际价值，自然默认是Demo作品。把技术绑定业务结果才有用，你可以改成“搭建运维故障排查知识库RAG系统，覆盖800+份历史故障文档与解决方案，将新人排查常见故障的平均耗时从25分钟压缩到6分钟”，我当初改完这类表述，投递回复率立刻高了不少。别写全场景覆盖的智能系统。不少人喜欢写支持多格式解析、多轮对话、自动生成排查方案，功能拉得满满当当。但真实生产里根本不会一上来做全功能，都是先跑通核心场景再迭代，这么写反而暴露没做过真实落地。写清迭代节奏和场景边界才可信，比如：“一期先落地单故障点问答验证效果，二期新增日志关键词关联检索，目前覆盖70%的常见运维故障场景”，有递进感才像真实迭代的项目。别只写优势不写落地局限。很多人把项目写得准确率超高、零差错，完美得像官方示例，反而显得很假。做过生产项目的都知道，永远有局限和妥协，适当写折中方案更显真实。比如补充：“针对非结构化原始日志解析准确率不足的问题，暂时采用人工上传标准化故障记录兜底，后续规划接入日志结构化解析模块优化”。其实简历被一眼看穿，从来不是你能力不行，只是没摸透招聘方的筛选逻辑，换成业务视角加真实落地细节，真实感立刻就上来了。我整理了大模型项目简历改写模板和避坑清单，都是当年改了十几版攒下来的干货。祝大家投递都有回应，转岗顺利。