簡介獵聘大數(shù)據(jù)研究院發(fā)布的《2025 AI技術(shù)人才供需洞察報告》是一份聚焦AI技術(shù)崗位供需格局的行業(yè)調(diào)查研究報告面向企業(yè)HR、行業(yè)分析師、AI從業(yè)者與求職者提供近一年人才需求、薪資分布、行業(yè)區(qū)域趨勢等關(guān)鍵洞察。報告基于2024年2月至2025年1月招聘大數(shù)據(jù)顯示AI技術(shù)崗明顯高學(xué)歷、高薪化碩博需求占比近47%明顯高于整體崗位的4.47%50萬以上年薪職位超三成而整體職位不足一成。細(xì)分職能中算法工程師需求占比最高達(dá)67.17%深度學(xué)習(xí)、機(jī)器學(xué)習(xí)人才需求排名上升且超50萬年薪職位占比均超38%。行業(yè)方面互聯(lián)網(wǎng)、電子半導(dǎo)體、計算機(jī)軟件需求居前家電行業(yè)同比增長最快達(dá)93.75%區(qū)域上長三角需求最旺盛北京、上海、深圳位居城市前三。資源為1個PDF文件大小1.19MB報告結(jié)構(gòu)清晰包含需求分析、人才畫像、城市群分布及細(xì)分學(xué)歷要求等圖示與數(shù)據(jù)便于讀者快速定位所需信息。已有491人學(xué)習(xí)適合需要把握AI人才市場動向、支撐招聘或求職決策的讀者閱讀。1. 獵聘2025研報里的AI技術(shù)人才供需洞察先看結(jié)構(gòu)再看數(shù)字獵聘這份《2025 AI技術(shù)人才供需洞察報告》發(fā)布時大家第一反應(yīng)是看薪水和崗位增量但真正值得IT從業(yè)者反復(fù)讀的是供需結(jié)構(gòu)錯位。報告不會直接告訴你“該學(xué)什么”但會把崗位JD里的技能詞、行業(yè)分布、經(jīng)驗?zāi)晗拮兂煽闪炕男盘枴€在做傳統(tǒng)后端、前端的工程師來說這份研報更像一張地圖AI技術(shù)人才的需求已經(jīng)從算法崗擴(kuò)散到應(yīng)用層、基礎(chǔ)設(shè)施層甚至每個業(yè)務(wù)團(tuán)隊都能碰到與此同時供給端的簡歷大量集中在提示詞和輕調(diào)用上系統(tǒng)設(shè)計、模型調(diào)優(yōu)、評測工程這類硬能力依然稀缺。具體數(shù)字以獵聘官方報告為準(zhǔn)我這里只順著供需兩頭講清楚怎么把研報語言翻譯成可落地的招聘參數(shù)、技能評估和職業(yè)決策。2. 需求側(cè)拆解從AI技術(shù)人才崗位畫像里提取量化參數(shù)需求側(cè)不是一條“崗位變多變少”的曲線而是一組可以被程序讀取的技能組合。工程師看獵聘這類研報時最容易犯的錯是把注意力放在城市薪資排行上然后得出結(jié)論“AI崗位又漲了”。真正有用的是把崗位JD文本拆開看每個崗位背后的工具棧、經(jīng)驗?zāi)晗藓凸ぷ髀氊?zé)否則需求側(cè)的結(jié)論永遠(yuǎn)是“多”“快”“難”這類沒有操作性的描述。2.1 看AI技術(shù)人才需求先分清“算法崗”和“應(yīng)用崗”2025年的AI技術(shù)人才需求里算法崗和應(yīng)用崗已經(jīng)明顯分成兩條線。算法崗?fù)ǔＲ竽Ｐ陀?xùn)練、調(diào)優(yōu)、數(shù)據(jù)集構(gòu)建技能詞集中在“預(yù)訓(xùn)練”“SFT”“RLHF”“推理優(yōu)化”應(yīng)用崗則要求理解業(yè)務(wù)流程能把大模型接到產(chǎn)品里技能詞集中在“RAG”“Agent”“提示詞”“向量數(shù)據(jù)庫”“模型部署”。獵聘研報在討論供需錯位時通常會把這兩類崗分開統(tǒng)計否則會出現(xiàn)“算法崗競爭激烈、應(yīng)用崗招不到人”的假象。怎么快速區(qū)分崗位屬性我一般看JD里是否出現(xiàn)“業(yè)務(wù)”“系統(tǒng)集成”“全鏈路”這類詞。應(yīng)用崗強(qiáng)調(diào)端到端落地算法崗強(qiáng)調(diào)模型指標(biāo)提升。兩者的薪資帶寬也有差異算法崗高薪集中度更高但崗位數(shù)量不如應(yīng)用崗應(yīng)用崗門檻相對低但技能要求更雜。這個差異決定了你讀研報時的關(guān)注點做技術(shù)選型的人看應(yīng)用崗做模型研究的人看算法崗不能混著用。2.2 需求側(cè)三個量化參數(shù)崗位發(fā)布量、技能詞、薪資帶寬讀需求側(cè)不必做復(fù)雜建模抓三個參數(shù)就夠崗位發(fā)布量、技能關(guān)鍵詞、薪資帶寬。崗位發(fā)布量回答“哪個方向在擴(kuò)張”技能關(guān)鍵詞回答“擴(kuò)張時優(yōu)先要什么人”薪資帶寬回答“什么技能最難補(bǔ)”。把這三組數(shù)放進(jìn)一個表里研報就從結(jié)論變成數(shù)據(jù)源。維度典型字段用途崗位發(fā)布量城市、行業(yè)、發(fā)布時間判斷AI技術(shù)人才的需求重心在哪里技能關(guān)鍵詞大模型、RAG、Agent、微調(diào)、提示詞建立JD篩選和簡歷搜索的標(biāo)簽庫薪資帶寬P50、P75、P90、經(jīng)驗?zāi)晗夼袛嗉寄芟∪背潭确赐乒┙o缺口這個表是招聘系統(tǒng)中人才庫標(biāo)簽體系的雛形。比如“RAG”這個詞在崗位發(fā)布量里高頻出現(xiàn)那就在人才庫里建一個“RAG經(jīng)驗”標(biāo)簽如果帶“RAGAgent”組合關(guān)鍵詞的崗位薪資帶寬明顯高于單一關(guān)鍵詞說明組合型需求更稀缺。研報正文不一定有現(xiàn)成的組合表但按這個表自己從JD里拉數(shù)據(jù)能得出同樣的結(jié)論。2.3 用Python做JD技能詞頻統(tǒng)計最小腳本和參數(shù)說明前面說的技能關(guān)鍵詞最好用腳本統(tǒng)計不要靠肉眼掃JD。下面是一段可以直接跑的Python腳本用jieba把JD文本切成詞再按自定義技能詞典統(tǒng)計頻率import jieba from collections import Counter # 技能詞典隨研報周期調(diào)整 skill_words [ 大模型, RAG, Agent, 微調(diào), 提示詞, 向量數(shù)據(jù)庫, 模型部署, AI應(yīng)用開發(fā), 模型評測, 多模態(tài), LangChain, 本地部署, 推理優(yōu)化, LoRA, SFT, Agent編排 ] for w in skill_words: jieba.add_word(w) def extract_skills(text_path): with open(text_path, r, encodingutf-8) as f: content f.read() # 清掉JD模板里的通用詞避免占頻次 noise [崗位職責(zé), 任職要求, 崗位描述, 職位描述, 工作職責(zé)] for n in noise: content content.replace(n, ) words jieba.lcut(content) counter Counter(w for w in words if w in skill_words) return counter.most_common() if __name__ __main__: for skill, count in extract_skills(jd_corpus.txt): print(f{skill}\t{count})代碼邏輯第一步把JD模板中的通用詞刪掉因為這些詞每個崗位都會出現(xiàn)不刪會污染統(tǒng)計結(jié)果第二步用jieba分詞并且只保留skill_words里出現(xiàn)過的詞第三步按頻率排序輸出。重點在于自定義詞典因為jieba默認(rèn)會把“AI應(yīng)用開發(fā)”切分成“AI”“應(yīng)用”“開發(fā)”所以先add_word確保“AI應(yīng)用開發(fā)”作為一個整體出現(xiàn)。參數(shù)說明jd_corpus.txt可以是幾十份JD拼接后的文件也可以每份一個文件如果按城市或行業(yè)分組建議在統(tǒng)計前先按分組字段過濾這樣能看到不同行業(yè)的技能差異。使用這個腳本時還有兩個小習(xí)慣一是每季度更新一次skill_words淘汰“元宇宙”這類過氣詞二是把輸出結(jié)果和研報里的供需描述對照如果腳本結(jié)果與報告結(jié)論偏差大大概率是你收集的JD樣本不夠而不是報告錯了。3. 供給側(cè)透視AI大模型與Agent經(jīng)驗如何改變?nèi)瞬旁u估邏輯需求側(cè)看崗位供給側(cè)看人。獵聘研報的供給側(cè)數(shù)據(jù)大多來自簡歷庫和求職者調(diào)研常見字段包括學(xué)歷、工作年限、技能標(biāo)簽、期望城市。對IT從業(yè)者來說比“簡歷總量”更重要的是經(jīng)驗的分布方式有多少簡歷停留在AI使用層又有多少簡歷具備工程落地能力。這個分布直接決定了招聘策略和個人技能提升方向。3.1 供給側(cè)的關(guān)鍵不是人數(shù)而是“有效經(jīng)驗”很多團(tuán)隊招不到人不是簡歷少而是“有效簡歷”少。2025年的AI技術(shù)人才供給里大量簡歷會把“熟悉ChatGPT”“會寫Prompt”“用過AI編程工具”寫進(jìn)技能標(biāo)簽但這些能力本質(zhì)上是用大模型而不是做AI技術(shù)開發(fā)。反觀JD里的高薪崗位幾乎都要求候選人能解決模型幻覺、控制推理成本、做Agent規(guī)劃與工具調(diào)用這些經(jīng)驗光靠聊天很難積累。研報如果只統(tǒng)計“簡歷含AI關(guān)鍵詞”會高估供給如果只統(tǒng)計“AI崗位相關(guān)經(jīng)驗”又會低估正在從傳統(tǒng)后端轉(zhuǎn)崗的潛在候選人。我的判斷方法是看簡歷里有沒有三樣?xùn)|西可量化的項目結(jié)果比如“檢索準(zhǔn)確率提升到92%”“接口吞吐提升了3倍”明確的工具鏈比如“用LangChain寫過多輪Agent”“對模型做過LoRA微調(diào)”以及問題邊界描述比如“負(fù)責(zé)過RAG知識庫中的切片策略”。這些細(xì)節(jié)比“熟悉AI”有用得多也是招聘系統(tǒng)里做技能評估的核心依據(jù)。3.2 用AI提示詞模板把簡歷和JD匹配度做成結(jié)構(gòu)化分?jǐn)?shù)既然人工篩簡歷耗時我常常用大模型做第一輪篩選。關(guān)鍵不是讓模型直接給“通過/不通過”而是要求輸出結(jié)構(gòu)化匹配結(jié)果。下面是一份可以直接復(fù)用的提示詞模板里面刻意寫明了評分維度和輸出格式你是AI技術(shù)崗位的招聘助手。請根據(jù)崗位JD評估候選人簡歷只輸出JSON。 崗位JD {jd_text} 候選人簡歷 {resume_text} 評分維度 1. 硬技能RAG、Agent、大模型、微調(diào)、向量數(shù)據(jù)庫、模型部署 2. AI經(jīng)驗?zāi)晗藓蜻x人從事AI相關(guān)工作的時間 3. 工程證據(jù)是否有可量化的延遲、吞吐、評測準(zhǔn)確率 4. 稀缺技能是否包含微調(diào)、推理優(yōu)化、本地部署等關(guān)鍵詞 輸出字段 { overall_score: 0-100, skill_match: [命中技能], experience_match: 年限評估, project_evidence: 項目證據(jù), missing_keywords: [缺失技能], suggestion: 一句招聘建議 } 注意候選人寫“熟悉AI”不算證據(jù)必須找到具體技能或項目描述。使用這份模板時我用Python把JD和簡歷的文本替換到{jd_text}和{resume_text}位置再調(diào)用大模型接口。一個關(guān)鍵參數(shù)是temperature匹配評分場景通常設(shè)成0.1到0.2因為溫度太高會讓同樣一份簡歷在不同輪次得到不同分?jǐn)?shù)招聘流程不認(rèn)可。輸出JSON后我會把missing_keywords字段直接寫入候選人標(biāo)簽表作為后續(xù)人才池篩選的依據(jù)。這套提示詞在為AI應(yīng)用開發(fā)崗和AI產(chǎn)品經(jīng)理崗做初篩時表現(xiàn)不錯但用于算法崗還要再補(bǔ)充模型訓(xùn)練相關(guān)維度。3.3 本地部署AI處理簡歷數(shù)據(jù)模型選型和關(guān)鍵參數(shù)如果公司不允許簡歷數(shù)據(jù)傳到外部服務(wù)常見做法是把開源模型部署在內(nèi)部服務(wù)器上。個人經(jīng)驗是7B到14B的量化模型已經(jīng)能完成關(guān)鍵詞提取、匹配度打分這類任務(wù)不需要追求70B大模型。Ollama是本地部署最省事的選擇下面是一個調(diào)用本地模型的Python示例import requests url http://localhost:11434/api/generate payload { model: qwen2.5:14b, prompt: 請從簡歷中提取AI技術(shù)關(guān)鍵詞、工作年限和項目中的量化結(jié)果用JSON返回。簡歷內(nèi)容..., stream: False, options: { temperature: 0.1, num_predict: 512, top_p: 0.7 } } resp requests.post(url, jsonpayload) print(resp.json().get(response, ))代碼說明Ollama的api/generate接口執(zhí)行一次完整推理stream設(shè)為False表示拿到完整結(jié)果再返回適合批處理場景。options里的三個參數(shù)很關(guān)鍵具體推薦范圍如下參數(shù)推薦值用途temperature0.1~0.2讓相同簡歷得到一致評分num_predict256~512限制輸出長度避免無效展開top_p0.7~0.9控制候選采樣范圍配合temperature使用提示14B模型在純CPU環(huán)境跑一條簡歷大約要十幾秒如果一天處理幾千份最好先用規(guī)則把簡歷壓縮只給模型傳“經(jīng)驗描述”和“技能標(biāo)簽”兩個字段如果簡歷文本較長num_predict可以調(diào)到1024但超過后內(nèi)容會被截斷建議保持精簡。4. 把供需洞察變成行動招聘側(cè)建技能雷達(dá)求職側(cè)補(bǔ)缺口研報讀完不落地就只是談資。落到招聘側(cè)要建一套能被技能詞驅(qū)動的篩選機(jī)制落到求職側(cè)要把需求側(cè)的技能詞頻當(dāng)成檢查清單。下面分別說兩套做法。4.1 招聘側(cè)落地從研報熱詞到人才雷達(dá)的四步操作團(tuán)隊要做人才雷達(dá)不需要先買系統(tǒng)按四步走第一步從研報和頭部公司JD里提取高頻技能詞按“基礎(chǔ)技能”“進(jìn)階技能”“稀缺技能”分級第二步把分級技能詞維護(hù)進(jìn)人才庫的標(biāo)簽字段鼓勵候選人和推薦人補(bǔ)充標(biāo)簽第三步用技能組合查詢定期掃描活躍簡歷第四步把查詢命中的人拉進(jìn)私庫按供需熱度安排觸達(dá)。整個過程里研報的作用是給分級提供權(quán)重。比如2025年“本地部署”“模型評測”“AI應(yīng)用開發(fā)”如果出現(xiàn)在多份研報的供需缺口段落那它們就應(yīng)該被歸入稀缺技能。這個分級不是一次性工作而是每季度跟著報告更新一次否則去年“提示詞”很稀缺今年它可能已經(jīng)變成“基礎(chǔ)技能”再拿它當(dāng)高門檻篩選條件只會誤殺候選人。4.2 求職側(cè)落地用技能頻次反查缺口排學(xué)習(xí)優(yōu)先級求職側(cè)更容易操作。收集二十份目標(biāo)崗位的JD用第2章的腳本統(tǒng)計技能詞頻再逐項對比自己的簡歷。高頻出現(xiàn)但自己沒寫過的技能就是需要補(bǔ)的口子中頻但幾乎每份JD都要求的技能是可以提升的加分項低頻但薪資帶寬很高的技能是差異化方向。下面是我常用的自評表格差距類型示例建議動作公共詞缺失RAG、向量數(shù)據(jù)庫用兩周做一個RAG知識庫demo并記錄效果經(jīng)驗詞缺失微調(diào)、LoRA在開源模型上跑一次領(lǐng)域微調(diào)記錄顯存和訓(xùn)練時長工程指標(biāo)缺失推理延遲、吞吐給已有項目補(bǔ)壓測輸出一份性能報告稀缺詞缺失模型部署、推理優(yōu)化按官方教程部署一次vLLM或Ollama記錄排錯過程這個表格的要點是把“學(xué)習(xí)AI”還原成“解決具體問題”。比如研報提到AI應(yīng)用開發(fā)崗需求增長快那就優(yōu)先做RAG和Agent編排如果研報顯示模型部署人才難招那就用Ollama本地部署一個模型再試著用它做一次簡歷篩選這比背概念更能寫進(jìn)簡歷。4.3 用SQL維護(hù)人才庫技能標(biāo)簽的查詢寫法招聘系統(tǒng)里的人才庫如果以JSON數(shù)組存技能標(biāo)簽SQL查詢可以寫得非常干凈。下面是一個同時要求RAG和Agent并至少帶一項模型微調(diào)能力的查詢SELECT candidate_id, name, skill_tags, years_of_experience FROM candidate_warehouse WHERE JSON_CONTAINS(skill_tags, RAG) AND JSON_CONTAINS(skill_tags, Agent) AND ( JSON_CONTAINS(skill_tags, 微調(diào)) OR JSON_CONTAINS(skill_tags, LoRA) ) AND updated_at 2025-01-01 ORDER BY years_of_experience DESC LIMIT 100;代碼邏輯JSON_CONTAINS用來判斷skill_tags這個JSON數(shù)組是否包含某個字符串比LIKE %RAG%更準(zhǔn)確因為LIKE會把“RAGenerator”這種無關(guān)詞也命中。最后的updated_at字段用于提高數(shù)據(jù)新鮮度避免觸達(dá)幾個月前已經(jīng)找到工作的候選人。參數(shù)說明如果技能標(biāo)簽是中文MySQL的JSON_CONTAINS需要寫雙引號包裹的中文串注意別寫成單引號。實際使用中我會把第2章統(tǒng)計出來的高頻組合直接拼進(jìn)SQL條件比如“RAGAgent本地部署”這樣人才雷達(dá)的命中結(jié)果會明顯收窄但也更貼近真實需求。5. 自建“供需缺口指數(shù)”驗證研報結(jié)論而不是背數(shù)字研報每季度更新一次但招聘決策每天都在發(fā)生。與其等下一次報告不如用可控數(shù)據(jù)源算一個“供需缺口指數(shù)”把研報里“短缺”“緊張”這類形容詞變成可比較的數(shù)字。這個指數(shù)適合內(nèi)部復(fù)盤也適合幫團(tuán)隊做季度招聘預(yù)算分配。5.1 供需缺口指數(shù)的定義與計算我的定義很簡單把某技能詞在崗位JD中的出現(xiàn)占比除以該技能詞在簡歷庫中的出現(xiàn)占比得到供需缺口指數(shù)。指數(shù)大于1說明需求濃度高于供給濃度這個技能值得重點投入指數(shù)接近1說明基本平衡指數(shù)小于1說明供給相對過?？梢陨晕⒎啪徴衅浮Ｓ嬎惴绞饺缦耫ef supply_demand_index(demand_share, supply_share): if supply_share 0: return float(inf) return round(demand_share / supply_share, 2) # 示例數(shù)據(jù)假設(shè)從JD和簡歷中統(tǒng)計出的占比 skills { RAG: {demand: 0.20, supply: 0.06}, Agent: {demand: 0.15, supply: 0.04}, 微調(diào): {demand: 0.08, supply: 0.12}, } for skill, data in skills.items(): index supply_demand_index(data[demand], data[supply]) print(f{skill}: {index})代碼邏輯demand_share是某技能詞出現(xiàn)在JD中的次數(shù)除以全部JD數(shù)supply_share是出現(xiàn)在簡歷中的次數(shù)除以全部簡歷數(shù)。兩者的比值不受樣本量直接影響所以不同技能之間可以直接比較。比如RAG的需求占比20%供給占比6%指數(shù)就是3.33微調(diào)的需求占比8%供給占比12%指數(shù)0.67說明市面上會微調(diào)的人比崗位所需的多篩選時就要提高要求。提示樣本太少時指數(shù)會失真建議每個技能詞至少在JD和簡歷中各出現(xiàn)50次再計算。5.2 如何用指數(shù)復(fù)現(xiàn)研報結(jié)論同時避開兩個誤區(qū)用指數(shù)驗證研報結(jié)論時最容易踩兩個坑。第一個坑是拿全市場數(shù)據(jù)當(dāng)作自己公司數(shù)據(jù)研報反映的是行業(yè)整體而公司業(yè)務(wù)可能只集中在某個垂直領(lǐng)域比如金融客服場景下Agent需求一定高于研報平均指數(shù)要用自己崗位池的數(shù)據(jù)計算。第二個坑是忽略技能詞的時效性2025年“提示詞”已經(jīng)不是高稀缺詞如果詞典還停留在2023年指數(shù)會嚴(yán)重失真所以每次計算前都要重新從最新JD里提取技能詞。這個指數(shù)不一定要做成后臺系統(tǒng)我通常直接在季末跑一次腳本把結(jié)果和研報結(jié)論放一起對比。如果兩者方向一致說明招聘策略不用大調(diào)如果方向相反就檢查是樣本偏差還是研報統(tǒng)計口徑不同。最后還有一個小技巧把指數(shù)按“技能詞城市”分組計算比如“RAG在北京”和“RAG在成都”可能是兩個完全不同的供需市場用分組后的指數(shù)做招聘預(yù)算會比只看全國平均更接近真實情況。本文還有配套的精品資源點擊獲取