1. 从一份岗位说明书说起为什么传统JD在AI团队里越来越不够用我做了十多年技术管理带过算法团队、数据团队也帮不少公司做过技术岗位的招聘和人才盘点。这几年最直观的感受就是传统岗位说明书JD在AI相关岗位上几乎处于半失效状态。你写“熟悉机器学习、有NLP经验、掌握Python”投进来的简历五花八门面完发现真正能干活的和纸面描述之间差了十万八千里。问题的根源在于AI岗位的能力维度太立体了。一个“AI应用工程师”他可能需要同时具备大模型基础理论的理解力、提示词工程的实操手感、Agent搭建的工程能力、以及把业务需求翻译成技术方案的产品思维。这些维度用一段JD文字根本描述不清楚更别说用来做招聘筛选、绩效评估和人才培养了。所以这两年我一直在琢磨一件事能不能把一份模糊的岗位说明书变成一张结构化的胜任力图谱这张图谱要能回答几个核心问题——这个岗位到底需要哪些能力项每个能力项分几个等级等级之间的行为差异是什么怎么用这张图去评估一个人当前处在什么位置这就是“AI岗位能力建模”要解决的事。它不是HR那种泛泛的素质模型而是针对AI岗位特有的技术栈和能力结构做一次系统性的拆解和量化。适合谁来参考技术管理者、HRBP、想转型AI方向的开发者、以及正在搭建AI团队的一号位。不管你之前有没有做过能力模型这套技术路线都能让你从一份JD出发一步步推导出一张可落地的胜任力图谱。2. 整体设计思路从文本到图谱的四层拆解逻辑2.1 为什么不能直接拿JD改一改就用很多人第一反应是我把JD里的要求逐条列出来每条打个分不就成了能力模型了吗我试过走不通。原因有三个。第一JD是面向招聘场景写的不是面向能力评估写的。JD的语言是“要求”“熟悉”“优先”这些词在评估场景下没有可操作性。“熟悉大模型”到底是什么水平能调API算熟悉还是能微调算熟悉还是能从零预训练算熟悉差距太大了。第二JD是扁平的能力是有层级的。JD把所有要求并列排在一起但实际工作中有些能力是基础门槛有些是进阶加分有些是区分高潜和普通的关键项。不做层级区分评估就没有区分度。第三JD是静态的AI岗位的能力要求是快速演化的。去年还要求“了解RAG”今年已经变成“能独立搭建多路召回重排序的RAG系统”了。能力模型必须有一个可扩展的结构方便后续迭代。2.2 四层拆解从岗位到能力项到等级到行为锚点我最终采用的路线是四层结构从抽象到具体依次是岗位角色层 → 能力域层 → 能力项层 → 行为锚点层。岗位角色层解决“这个岗位在团队里承担什么职责”的问题。比如“AI应用工程师”这个角色核心职责是把大模型能力落地到具体业务场景中那他的能力域就和“AI研究员”完全不同。能力域层是把岗位所需能力做聚类。我一般会分成技术硬能力、工程实践能力、业务理解能力、协作与表达能力四大域。每个域下面再拆能力项。能力项层是最关键的一层也是需要最多专业判断的一层。比如“工程实践能力”下面可以拆出“提示词工程”“Agent搭建”“模型部署与推理优化”“数据管道搭建”等能力项。每个能力项要给出明确的定义和边界避免和其他能力项重叠。行为锚点层是让能力模型真正可用的关键。每个能力项分3到5个等级每个等级用具体的行为描述来锚定。比如“提示词工程”的L1是“能照着模板改提示词”L3是“能针对复杂任务设计多轮提示词策略并做A/B测试”L5是“能建立团队级的提示词规范和评估体系”。2.3 技术路线全景从JD文本到图谱的五个步骤整个技术路线我梳理成五个步骤后面会逐一展开讲实操细节。第一步是JD文本解析与能力关键词提取。把原始JD输入进去用规则大模型辅助的方式把里面隐含的能力要求全部抽出来。这一步的关键是不要漏宁可多抽一些后面再合并。第二步是能力项聚类与去重。抽出来的关键词往往是零散的、有重叠的需要做聚类归并形成结构化的能力项列表。第三步是能力等级定义与行为锚点撰写。这是最耗专业判断的一步需要结合团队实际的技术栈和业务场景来写。第四步是权重分配与评估量表设计。不同能力项对岗位的重要性不同需要分配权重并设计出可操作的评估量表。第五步是图谱可视化与落地应用。把最终结果做成一张可交互的图谱用于招聘、评估、培养等场景。3. 核心细节解析能力项拆解与等级定义的实操要点3.1 JD文本解析怎么把“熟悉大模型”翻译成可评估的能力项拿到一份JD第一步不是直接开始拆而是先做一轮关键词提取。我的做法是分三遍读。第一遍读技术栈关键词。把所有提到的技术名词圈出来比如“PyTorch”“LangChain”“向量数据库”“Prompt Engineering”“Fine-tuning”“RAG”“Agent”等。这些是显性的能力线索。第二遍读动作动词。JD里会写“负责”“参与”“主导”“优化”“搭建”等动词这些动词隐含了能力等级。比如“参与RAG系统开发”和“主导RAG系统架构设计”对应的能力等级完全不同。第三遍读业务场景关键词。比如“智能客服”“知识问答”“内容生成”“代码辅助”等这些场景决定了能力项需要结合哪些业务知识。三遍读完你会得到一张零散的关键词表。我拿一份真实的“AI应用工程师”JD做过测试原始JD大概400字三遍读下来抽出了37个关键词。这37个里面有很多是重叠的比如“大模型应用开发”和“LLM应用落地”其实是一回事。注意这一步不要急着合并先把所有关键词都列出来用表格记录每个关键词的来源句子和出现频次。频次高的关键词大概率是核心能力项。3.2 能力项聚类从37个关键词到12个能力项的归并逻辑37个关键词直接拿去做模型太碎了需要做聚类归并。我的归并逻辑是按“能力输出的可交付物”来聚类。举个例子“提示词设计”“Prompt优化”“提示词模板管理”“多轮对话设计”这四个关键词它们的可交付物都是“提示词方案”所以归并成一个能力项叫“提示词工程”。再比如“RAG搭建”“向量库选型”“检索策略优化”“知识库构建”这四个可交付物都是“检索增强生成系统”归并成“RAG系统开发”。按这个逻辑37个关键词最终归并成了12个能力项分布在四个能力域下面能力域能力项来源关键词举例技术硬能力大模型基础理论大模型原理、Transformer、注意力机制技术硬能力提示词工程Prompt设计、提示词优化、多轮对话技术硬能力RAG系统开发向量库、检索策略、知识库构建技术硬能力Agent搭建工具调用、任务规划、多Agent协作技术硬能力模型微调Fine-tuning、LoRA、数据标注工程实践能力模型部署与推理优化推理加速、量化、服务化部署工程实践能力数据管道搭建数据清洗、数据标注、数据版本管理工程实践能力AI测试与评估效果评估、A/B测试、Bad Case分析业务理解能力场景需求分析业务调研、需求拆解、方案设计业务理解能力成本与效率权衡Token成本、推理延迟、ROI分析协作与表达能力技术方案表达方案文档、技术分享、跨团队沟通协作与表达能力项目推进与协作项目管理、敏捷协作、风险把控这张表就是能力模型的骨架。12个能力项不算多也不算少覆盖了一个AI应用工程师的核心能力要求同时每个能力项都有明确的边界。3.3 等级定义每个能力项分几级、怎么描述才不空洞能力项定下来之后下一步是给每个能力项分等级。我一般用5级制但实际评估时只重点区分L1到L4L5是专家级用来做天花板参照。等级定义最容易犯的错是写成“了解/熟悉/精通/专家”这种空洞的形容词。这种描述在评估时完全没有区分度两个人都是“熟悉”实际水平可能差三倍。我的做法是用行为锚点来定义等级。每个等级描述的是“在这个等级的人在真实工作场景中会表现出什么行为”。行为锚点要满足三个条件可观察、可验证、有区分度。拿“提示词工程”这个能力项举例等级行为锚点描述L1能照着团队已有的提示词模板替换任务描述和示例完成简单的信息抽取或文本分类任务L2能针对新任务独立设计提示词包括角色设定、任务拆解、输出格式约束能通过2-3轮迭代达到可用效果L3能针对复杂多步任务设计多轮提示词策略引入思维链、Few-shot示例选择、输出校验等技巧能建立提示词版本管理和A/B测试流程L4能建立团队级的提示词规范和评估体系能针对不同模型特性做提示词迁移和适配能指导他人提升提示词设计能力L5能提出新的提示词方法论在业界形成影响力能解决提示词工程中的开放性问题这样定义的好处是评估的时候直接对照行为锚点看被评估人实际做过什么、能做到什么程度而不是凭感觉打分。实操心得写行为锚点的时候尽量用“能独立完成”“能指导他人”“能建立体系”这类动词来区分等级。L1是“能照着做”L2是“能独立做”L3是“能优化流程”L4是“能建体系”L5是“能定标准”。这个递进关系很清晰。3.4 权重分配为什么不能所有能力项平均用力12个能力项如果平均分配权重每个占8.3%那评估结果就没有重点了。实际岗位中不同能力项的重要性差异很大。我的权重分配方法是基于岗位职责做重要性排序。具体操作是先确定这个岗位最核心的3个能力项给它们分配60%左右的权重然后确定5个重要能力项分配30%权重剩下4个基础能力项分配10%权重。还是拿AI应用工程师举例核心能力项是“提示词工程”“RAG系统开发”“场景需求分析”这三个直接决定了他能不能独立交付一个AI应用。重要能力项是“Agent搭建”“模型部署与推理优化”“AI测试与评估”“技术方案表达”“项目推进与协作”。基础能力项是“大模型基础理论”“模型微调”“数据管道搭建”“成本与效率权衡”。权重分配不是拍脑袋而是基于一个判断如果这个能力项缺失岗位的核心职责还能不能完成如果不能就是核心项如果会打折扣但还能做就是重要项如果影响不大就是基础项。4. 实操过程从零搭建一张胜任力图谱的完整步骤4.1 第一步准备原始素材不止是JD很多人以为做能力建模只需要一份JD就够了。我一开始也这么想后来发现远远不够。JD只是起点还需要补充三类素材。第一类是团队内部的实际工作记录。比如代码仓库的提交记录、技术方案文档、项目复盘报告。这些能反映真实工作中需要什么能力而不是JD上写了什么。第二类是高绩效员工的访谈记录。找团队里表现最好的2-3个人问他们“你每天实际在做的事情中哪些能力用得最多”“你觉得新人最容易卡在什么地方”。这些信息能帮你校准能力项的权重和等级定义。第三类是行业对标资料。看看同类型公司在招AI岗位时要求什么但不要照搬而是用来查漏补缺。我一般会看5-10份同类JD把里面反复出现但自己团队JD里没写的关键词记下来判断是否需要补充。注意素材准备阶段不要贪多3-5份JD、2-3份工作记录、2-3个访谈就够了。素材太多反而会干扰判断导致能力项越拆越碎。4.2 第二步关键词提取与初步归类素材准备好之后开始做关键词提取。我习惯用表格法建一个三列的表格关键词、来源、初步归类。关键词这一列把三遍读法抽出来的所有词都列进去。来源这一列标注这个词是从JD、工作记录还是访谈里来的。初步归类这一列先凭直觉把关键词分到四个能力域下面。这一步不需要太精确先粗分后面再调整。关键是不要漏掉任何关键词哪怕你觉得不太重要也先列上。我见过太多人因为提前过滤导致最后能力模型有盲区。提取完之后做一轮频次统计。出现频次高的关键词大概率是核心能力项。频次低但来自高绩效员工访谈的关键词也要重点关注可能是隐性关键能力。4.3 第三步能力项定义与边界划分关键词归类之后每个能力域下面会有一堆关键词。这时候需要把它们归并成能力项并给每个能力项写一个清晰的定义。定义能力项的时候我遵循一个原则一个能力项只描述一种可交付的能力输出。如果一个能力项下面有两种不同的输出就拆成两个。比如“RAG系统开发”和“知识库构建”虽然相关但前者输出的是检索增强生成系统后者输出的是结构化的知识库。如果放在一个能力项里评估的时候会混淆。所以我一般会拆开或者把“知识库构建”作为“RAG系统开发”下面的一个子项。边界划分还有一个技巧用反例来检验。写完一个能力项的定义后问自己“什么行为不属于这个能力项”。如果能清晰地说出不属于的行为说明边界是清楚的。如果说不清楚说明定义太模糊需要重新写。4.4 第四步等级行为锚点撰写这是最耗时间的一步也是决定能力模型质量的关键。我的做法是先写L3再写L1和L5最后补L2和L4。为什么先写L3因为L3是“能独立完成复杂任务”的等级是岗位的主力水平。把L3写清楚了L1就是“在指导下能完成简单任务”L5就是“能定义标准”两头的锚点就出来了。L2和L4是中间过渡相对好补。写行为锚点的时候我要求自己做到三个具体具体场景、具体动作、具体产出。比如不要写“能熟练使用向量数据库”而要写“能根据业务场景选择合适的向量数据库完成索引构建、检索调优和性能测试产出可上线的检索服务”。实操心得写行为锚点的时候可以找团队里对应等级的人聊一聊问他们“你最近做的一件能体现这个能力的事是什么”。把他们的真实案例提炼成行为锚点比凭空写要准确得多。4.5 第五步权重分配与评估量表设计能力项和等级都定好之后开始做权重分配。我一般用AHP层次分析法的简化版先让3-5个评委独立给每个能力项的重要性打分1-5分然后取平均值再做归一化处理。归一化之后每个能力项的权重就出来了。核心能力项权重在15%-25%之间重要能力项在5%-10%之间基础能力项在2%-5%之间。评估量表的设计我习惯用行为频率量表。每个能力项的每个等级对应一个行为频率描述。比如L1是“在指导下偶尔能做到”L2是“在指导下经常能做到”L3是“能独立稳定做到”L4是“能指导他人做到”L5是“能建立标准并持续优化”。评估的时候评估者只需要判断被评估人的行为频率落在哪个区间就能对应到等级。这样比直接打1-5分要客观得多。4.6 第六步图谱可视化与落地应用最后一步是把结果可视化。我一般用雷达图热力图的组合。雷达图展示被评估人在12个能力项上的得分分布一眼能看出强项和弱项。热力图展示团队整体的能力分布用于人才盘点和培养规划。落地应用主要有三个场景。招聘场景用能力模型做面试评估表每个能力项设计对应的面试题和行为追问。绩效场景用能力模型做季度评估对照行为锚点看成长。培养场景根据能力短板设计培养计划缺什么补什么。5. 常见问题与排查技巧实录5.1 能力项拆得太细或太粗怎么办这是最常见的问题。拆得太细12个能力项变成30个评估的时候根本评不过来。拆得太粗3个能力项评估结果没有区分度。我的经验值是8-15个能力项比较合适。如果超过15个说明你把子能力也拆出来了需要合并。如果少于8个说明你拆得不够需要继续往下分。判断标准是每个能力项是否对应一个独立的可交付物。如果两个能力项的可交付物是同一个东西的不同侧面就合并。如果两个能力项的可交付物完全不同就保留。5.2 行为锚点写不出来怎么办写行为锚点卡住的时候我一般用访谈法。找团队里对应等级的人问三个问题你最近做的一件能体现这个能力的事是什么这件事里你具体做了什么如果让一个新人来做他会在哪里卡住把这三个问题的答案整理一下就是很好的行为锚点素材。比如新人卡在“不知道选哪个向量库”那L1的锚点就可以写“能在指导下完成向量库的选型和基础配置”。5.3 权重分配争议大怎么处理权重分配有争议很正常因为每个人对岗位的理解不同。我的处理方法是先对齐岗位职责再谈权重。具体操作是让所有评委先独立写一段“这个岗位最核心的职责是什么”然后对比大家的答案。如果对职责的理解都不一致那权重分配肯定谈不拢。先把职责对齐了权重分配就是自然推导的结果。如果职责对齐了还有争议就用投票法。每个评委给每个能力项的重要性打分取平均值。少数服从多数但保留异议记录后续迭代时再调整。5.4 能力模型落地时没人用怎么办能力模型做出来没人用通常是因为太复杂或者和实际工作脱节。太复杂的问题解决办法是做减法。先只保留核心能力项和重要能力项基础能力项暂时不纳入评估。等大家用习惯了再逐步补充。脱节的问题解决办法是和现有流程绑定。比如把能力模型嵌入到季度绩效评估表里嵌入到面试评估表里嵌入到晋升答辩的评审标准里。用着用着就习惯了。5.5 常见问题速查表问题现象可能原因排查思路解决建议能力项太多评估耗时拆解过细子能力混入检查每个能力项是否有独立可交付物合并可交付物相同的能力项评估结果区分度低等级定义太模糊检查行为锚点是否具体可观察重写行为锚点用具体场景和动作权重分配争议大岗位职责理解不一致先对齐岗位核心职责用投票法分配权重保留异议记录模型落地没人用太复杂或与流程脱节检查是否嵌入现有流程做减法先推核心能力项能力项覆盖不全关键词提取有遗漏回查原始素材补充遗漏关键词增加行业对标资料查漏补缺避坑技巧能力模型不是做一次就完事的建议每半年做一次迭代。迭代的时候重点看两个东西一是业务变化带来的新能力要求二是评估过程中发现的不合理锚点。小步快跑持续优化。6. 工具选型与效率提升让建模过程少掉头发6.1 文本解析阶段规则大模型辅助关键词提取如果纯靠人工读一份JD要读半小时效率太低。我的做法是先用规则做初筛再用大模型做补充。规则初筛很简单建一个技术关键词库把常见的AI技术名词、动作动词、业务场景词都放进去用脚本跑一遍把命中的词标出来。这一步能覆盖70%左右的关键词。剩下30%的隐性关键词用大模型来补。把JD输入进去让模型回答“这份JD里隐含了哪些没有直接写出来的能力要求”。模型给出的结果不一定全对但能帮你查漏补缺。注意大模型辅助的结果一定要人工复核不能直接拿来用。我遇到过模型把“熟悉Linux”解读成“能搭建Linux内核”的情况明显过度解读了。6.2 能力项管理用表格工具就够了能力项的管理不需要复杂的系统一个结构化的表格就够了。我一般用在线表格工具建四个Sheet能力项列表、等级定义、权重分配、评估记录。能力项列表Sheet包含能力域、能力项名称、定义、来源关键词。等级定义Sheet包含能力项、等级、行为锚点。权重分配Sheet包含能力项、权重、分配依据。评估记录Sheet包含被评估人、各能力项等级、总分、评估日期。这样管理的好处是所有信息在一个文件里方便版本管理和协作。每次迭代只需要更新对应的Sheet历史版本可以存档对比。6.3 图谱可视化雷达图热力图的组合可视化工具我用过不少最后发现雷达图热力图的组合最实用。雷达图用于个人评估热力图用于团队盘点。雷达图的画法很简单12个能力项作为12个轴每个轴的刻度是1-5级。把被评估人的得分标上去连成线就能看出能力分布的形状。如果某个方向明显凹陷就是能力短板。热力图的画法是横轴是能力项纵轴是团队成员每个格子的颜色深浅代表等级高低。一眼就能看出团队整体的能力分布哪些能力项是团队短板哪些人需要重点培养。6.4 评估流程从自评到他评到校准评估流程我一般设计成三步自评→他评→校准会。自评是被评估人对照行为锚点给自己打分这一步的目的是让被评估人理解能力模型的标准。他评是直属上级和协作同事分别打分取平均值。校准会是所有评估者一起讨论分歧大的能力项达成一致。校准会是最关键的一步。没有校准会不同评估者的标准不一致评估结果就没有可比性。校准会上重点讨论两类情况自评和他评差异大的不同他评者之间差异大的。实操心得校准会不要开太长控制在1-2小时。提前把分歧大的能力项筛出来只讨论这些。讨论的时候聚焦行为锚点不要跑偏到主观印象上。7. 这套路线还能怎么扩展这套从JD到胜任力图谱的技术路线最初是为AI应用工程师岗位设计的但实际用下来它的适用范围比我想的要广。扩展到其他AI岗位把能力项和等级定义替换一下就能用于AI产品经理、AI数据标注师、AI测试工程师等岗位。核心逻辑是一样的只是能力项不同。扩展到非AI岗位我帮一个做传统后端开发的团队用这套方法做过能力建模把能力项换成“高并发系统设计”“数据库优化”“微服务治理”等效果也很好。说明这套方法论不局限于AI领域。扩展到团队能力盘点把每个人的评估结果汇总到热力图里就能看出团队整体的能力分布。哪些能力项是团队短板需要招聘补充哪些人是高潜可以重点培养哪些能力项之间有关联可以设计轮岗计划。扩展到学习路径设计根据能力模型的等级定义可以设计出从L1到L4的学习路径。每个等级需要学什么、练什么、产出什么都对应到具体的行为锚点。这样学习目标就很清晰不再是泛泛的“提升AI能力”。扩展到面试题库建设每个能力项的每个等级都可以设计对应的面试题和行为追问。面试官拿着题库对照行为锚点打分面试评估的客观性会大幅提升。我个人在实际操作中的体会是能力建模这件事最难的不是技术而是专业判断。工具和流程都是辅助真正决定模型质量的是你对岗位的理解深度。所以我的建议是不要追求一次做到完美先做一个粗糙版本用起来在用的过程中持续迭代。用着用着你对岗位的理解会越来越深模型也会越来越准。最后再分享一个小技巧做能力建模的时候找一个你团队里最懂业务的人一起做。技术能力你可以判断但业务理解能力和场景需求分析能力需要业务方来校准。两个人一起做比一个人闷头搞要快得多也准得多。
阅读完成 · 觉得有帮助?