做AI猎头这些年，有一个现象反复出现：企业HR在主流招聘平台上把关键词换了一轮又一轮，搜出来的简历翻来覆去就那么几份，好不容易约面，聊十五分钟就发现根本不是要找的人。HR通常会归因于“渠道不够”“平台数据库太小”。但拆开看，大量“搜不到人”的困局，根源不在渠道，在JD本身——它没有被“翻译”成人才市场能识别、能搜索、能自我对号入座的语言。

大模型人才的市场，信息不对称的方向已经变了。不是候选人不看机会，而是JD发出的信号太模糊，他们不知道“这个岗位跟我有什么关系”。有猎头同行说得直接：AI招聘做不对，不是不会写JD，而是一开始理解就偏了。HR在这里真正要做的，不是列筛选条件，而是把业务语言翻译成可以被市场理解的人才需求。

一、最常见的“翻译事故”：把两种人塞进同一个JD

最典型的一种情况：岗位标题写“大模型工程师”，正文里既要求“熟悉LoRA/QLoRA微调”，又要求“有RAG系统落地经验”，还加一句“了解Agent编排”。HR以为这是在扩大覆盖面，实际效果恰恰相反。

在模型层做微调的人，和在应用层搭RAG的人，是两个几乎没有交集的人才池。一个每天跟vLLM、TensorRT-LLM、量化格式（GGUF/AWQ/GPTQ）打交道的工程师，不会对向量库的chunking策略有强烈观点；反过来，一个用LangChain调用API搭了两年RAG管线的人，被问到“上次QLoRA微调的rank和alpha怎么选的”，大概率答不上来。当一份JD把两类画像混在一起，两个池子里的人都会觉得“这不是我要找的岗位”，滑过去。HR搜不到人，是因为JD先把人推走了。

翻译的第一步，不是写技能清单，是定层。业务要解决的是“API-hosted模型太贵、太慢、不懂我们的领域” ，那要的是模型层的人，关键词应该落在LoRA/QLoRA、vLLM、量化、评测harness；业务要解决的是“让产品基于我们的知识库回答问题” ，那要的是应用层的人，关键词落在RAG链路、检索策略、Agent编排。定层之后，JD的搜索命中率才会从“两个池子都漏”变成“一个池子打穿”。

二、把“精通”翻译成候选人认得出的动作

大模型JD里泛滥的“精通”“熟悉”“了解”，在候选人眼里几乎是噪声。“熟悉大模型训练原理”写在应用岗JD里，候选人翻译过来的信号是“这家公司可能自己也不知道要招什么人”；而真正做微调的人看到“熟悉vLLM推理部署”和“有QLoRA实际调参经验”，才会停下来判断自己够不够格。

有效的翻译，是把抽象层级降到候选人可以自我核对的颗粒度。与其写“熟悉大模型微调”，不如写清楚：是在Qwen/Llama/DeepSeek上做过LoRA/QLoRA微调，还是只需要理解“何时微调、何时RAG”的判断逻辑。前者吸引的是模型层工程师，后者吸引的是应用层工程师，信号一旦分开，搜索和投递的精准度同时上升。有经验的做法是：必须项只留3—5条，把加分项明确标成加分项，而不是把整份JD写成一张许愿清单。JD不是准入门槛，是信号发射器；信号越具体，能接住的人越对。

三、JD里要有“业务坐标”，不能只有技术栈

大模型人才，尤其是中高端人才，看JD的第一反应不是“我能不能干”，而是“这件事值不值得干”。一份只列技术名词的JD，在候选人眼里缺乏最基本的决策信息：这个岗位在解决什么业务问题，入职90天要交付什么，技术栈的真实边界在哪里。

把业务坐标写进去，本身就是最高效的翻译。比如“降低线上推理成本30%”“将RAG回答的引用准确率从X提到Y”“在给定延迟目标下完成开源模型的量化部署”——这类表述比十行“精通”更能让对的人对号入座。诚实列出真实的技术栈环境（用的哪家模型、什么推理框架、数据规模大概什么量级），也会过滤掉大量错配的投递，让真正匹配的人愿意花时间研究你的岗位。大厂JD的关键词已经从“会调API”迁移到工程化落地能力，HR的翻译如果还停留在概念层，搜到的自然是已经被市场淘汰的画像。

四、翻译之后，动作要快

JD翻译对了，搜索和触达的效率会显著变化。但大模型人才的流动窗口很短，顶尖工程师手上通常同时有三四个流程，决策周期以周计。一份对路的JD加上一个清晰的业务坐标，能在第一次触达时就建立信任；但如果流程拖到四五周，候选人早已在其他地方走完终面。JD翻译是起点，速度才是兑现。

慧猎猎头深耕人工智能行业中高端人才寻访，我们每天都在做同一件事：把企业的业务需求翻译成市场上听得懂的语言，再把市场上真正对的人翻译回企业的决策桌上。如果你正在为一个大模型岗位反复搜索却找不到对的人，不妨先放下渠道焦虑，从JD的“翻译”开始重写。 慧猎猎头 15730249807（同微信） ，我们可以从一份JD的诊断开始聊。