从JD到胜任力图谱：AI岗位能力建模实战指南

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个能力项，分布在四个能力域下面：

这张表就是能力模型的骨架。12个能力项不算多也不算少，覆盖了一个AI应用工程师的核心能力要求，同时每个能力项都有明确的边界。

3.3 等级定义：每个能力项分几级、怎么描述才不空洞

能力项定下来之后，下一步是给每个能力项分等级。我一般用5级制，但实际评估时只重点区分L1到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能力”。

扩展到面试题库建设：每个能力项的每个等级，都可以设计对应的面试题和行为追问。面试官拿着题库，对照行为锚点打分，面试评估的客观性会大幅提升。

我个人在实际操作中的体会是，能力建模这件事，最难的不是技术，而是专业判断。工具和流程都是辅助，真正决定模型质量的是你对岗位的理解深度。所以我的建议是，不要追求一次做到完美，先做一个粗糙版本用起来，在用的过程中持续迭代。用着用着，你对岗位的理解会越来越深，模型也会越来越准。

最后再分享一个小技巧：做能力建模的时候，找一个你团队里最懂业务的人一起做。技术能力你可以判断，但业务理解能力和场景需求分析能力，需要业务方来校准。两个人一起做，比一个人闷头搞要快得多，也准得多。