1. 从一份岗位说明书说起为什么传统JD撑不起AI团队的能力管理我做过一段时间AI团队的招聘和技术管理最头疼的事情不是招不到人而是招进来之后发现“岗位说明书”和“实际要干的活”完全是两码事。一份典型的AI岗位JD大概长这样熟悉机器学习算法、掌握Python、有深度学习项目经验、了解大模型相关技术。你拿这份JD去招人来的人五花八门有做CV的、有做NLP的、有做推荐系统的还有纯调参侠。面试的时候感觉都还行进来之后发现团队里缺的是能把模型部署到生产环境的人而不是再找一个在Jupyter Notebook里刷准确率的人。这就是问题的起点传统岗位说明书是“职责描述”不是“能力描述”。它告诉你这个人要干什么但没告诉你干好这件事需要哪些具体能力、这些能力之间是什么关系、每个能力应该达到什么水平。对于AI岗位来说这个问题尤其严重因为AI领域的技术栈更新极快岗位边界模糊一个人可能同时涉及数据处理、模型训练、推理优化、工程部署、业务理解等多个维度。我后来开始尝试用“能力建模”的思路来重构这件事。简单说就是把一份模糊的岗位说明书拆解成一张结构化的胜任力图谱。这张图谱不是简单的技能列表而是一个有层级、有依赖关系、有熟练度标准的能力网络。它要能回答几个核心问题这个岗位到底需要哪些能力哪些是基础能力哪些是进阶能力能力之间的依赖关系是什么每个能力怎么评估不同级别的人应该达到什么水平这件事的技术含量在于它不是拍脑袋写出来的而是需要一套可复现的技术路线。从原始JD的语义解析到能力项的抽取和归类再到能力关系的建模和熟练度分级最后到图谱的可视化和评估体系设计每一步都有具体的方法和工具可以落地。我在这篇文章里会把整条路线拆开讲清楚包括我实际踩过的坑和验证过的做法。注意能力建模不是HR的绩效考核工具它的第一服务对象是技术管理者。你要用它来指导招聘、培养、项目排期和团队能力盘点而不是拿来给成员打分排名。这个定位如果搞错了后面所有工作都会变形。2. 能力建模到底建的是什么核心概念和边界定义2.1 能力项、能力域、熟练度、依赖关系在动手之前先把几个核心概念定义清楚不然后面会越做越乱。能力项是图谱的最小单元比如“PyTorch框架使用”“Transformer架构理解”“模型量化与剪枝”“Prompt工程”“数据清洗与标注管理”。每个能力项必须是可观察、可评估的不能是“有责任心”这种没法量化的东西。能力域是能力项的归类容器比如“算法与模型”“工程与部署”“数据与特征”“业务与产品”“协作与沟通”。一个AI岗位通常涉及3到5个能力域不同岗位的差异主要体现在各能力域的权重和深度要求上。熟练度我一般分五级L1了解概念、L2能跟着做、L3能独立完成、L4能设计和优化、L5能制定标准和带人。这个分级不是拍脑袋定的后面会讲怎么用行为锚定法来校准。依赖关系是能力项之间的前置关系。比如“模型量化与剪枝”依赖“模型推理基础”和“PyTorch框架使用”“Prompt工程”依赖“大模型基础理论”和“业务场景理解”。依赖关系决定了学习路径和培养优先级。2.2 能力建模和岗位说明书、技能矩阵的区别很多人会把能力建模和技能矩阵搞混。技能矩阵通常是一个二维表行是人列是技能格子里打勾或者打分。它解决的是“谁会什么”的问题但不解决“这个能力到底意味着什么”“能力之间怎么组合”“不同级别差在哪里”的问题。岗位说明书解决的是“这个岗位要做什么”能力建模解决的是“做好这个岗位需要具备什么”。前者是任务导向后者是能力导向。两者互补但不能互相替代。能力建模和胜任力模型也不完全一样。经典的胜任力模型往往包含动机、特质、自我概念等深层要素偏HR心理学范式。我这里讲的能力建模更偏技术和工程视角聚焦在可培养、可评估的专业能力上不涉及性格和动机层面的东西。2.3 为什么AI岗位特别需要能力建模AI岗位有三个特点让传统JD特别不好用。第一是技术栈跨度大一个“AI工程师”可能从数据清洗一直做到服务上线中间涉及十几个技术环节。第二是更新速度快去年还在用BERT做微调今年就要搞RAG和Agent能力项需要持续迭代。第三是岗位边界模糊算法工程师和AI应用工程师的职责经常重叠但能力侧重点完全不同。没有能力建模你在招聘时只能靠关键词匹配在培养时只能靠“多跟着项目练”在评估时只能靠主观印象。有了能力图谱你至少能把讨论拉到一个共同的框架里来。3. 从JD文本到能力项抽取、清洗与归类的完整链路3.1 原始语料的收集和预处理第一步不是直接拿一份JD就开始抽而是要收集足够多的语料。我的做法是同一个岗位收集至少20到30份来自不同公司、不同行业的JD文本。为什么要这么多因为单份JD的表述偏差很大有的写得很细有的很粗有的夹杂大量公司特定术语。只有多份语料放在一起才能通过共现频率识别出真正核心的能力项。收集完之后做预处理去掉公司介绍、福利待遇、投递方式这些无关段落只保留岗位职责和任职要求两部分。然后把文本按句子或短段落切分方便后续逐条分析。这一步可以用简单的脚本做不需要上大模型正则加关键词过滤就够了。提示如果你所在的公司有内部岗位文档优先用内部文档。外部JD往往有美化成分内部文档更真实地反映了实际工作内容。3.2 用LLM做能力项抽取的提示词设计预处理完之后我用的方法是用大模型做能力项抽取。这里的关键是提示词设计。我试过很多版本最后稳定下来的提示词结构是这样的你是一名AI领域的技术能力分析专家。请从以下岗位描述文本中抽取具体的能力项。 要求 1. 每个能力项必须是一个可评估的具体技能不能是“有责任心”“学习能力强”这类通用素质。 2. 能力项粒度控制在“一个技术点或一个明确的工作能力”级别不要过于宽泛如“机器学习”也不要过于细碎如“会用pandas.read_csv”。 3. 对每个能力项标注它所属的能力域从以下选项中选择算法与模型、工程与部署、数据与特征、业务与产品、协作与沟通。 4. 输出格式为JSON数组每个元素包含能力项名称、能力域、原文依据。 岗位描述文本 {text}这个提示词我迭代了大概七八版主要调整的是粒度控制和能力域分类的稳定性。早期版本抽出来的能力项要么太粗要么太细后来加了“粒度控制在技术点级别”这个约束之后好很多。3.3 多轮抽取结果的合并与去重单次抽取肯定有遗漏和重复我的做法是跑三轮第一轮用原始提示词第二轮在提示词里加入“请特别注意工程部署和业务理解相关的能力”第三轮加入“请特别注意数据质量和模型评估相关的能力”。三轮结果合并之后做去重。去重不是简单的字符串匹配因为同一个能力可能有不同表述比如“PyTorch使用”“PyTorch框架”“PyTorch开发经验”其实是同一个能力项。我用的方法是先做向量化然后用余弦相似度做聚类相似度阈值设在0.85左右。聚类之后每个簇选一个最具代表性的表述作为标准能力项名称。3.4 能力域归类的校验和修正自动归类之后一定要人工校验。我遇到过几个典型问题一是“模型部署”有时候被归到“算法与模型”有时候被归到“工程与部署”需要统一二是“A/B测试设计”有时候被归到“数据与特征”有时候被归到“业务与产品”这个取决于岗位侧重点需要根据具体岗位来定三是有些能力项跨多个域比如“特征工程”既涉及数据也涉及算法我一般归到“数据与特征”但在依赖关系里标注它和算法域的关联。校验的时候我会拉一个表格每行是一个能力项列包括能力项名称、自动归类结果、人工修正结果、修正理由。这个表格后面做依赖关系建模的时候还要用。4. 能力关系建模依赖图、权重分配与分级标准4.1 用有向图表达能力依赖关系能力项抽出来之后它们不是孤立的。我用有向无环图来表达依赖关系如果掌握能力B之前必须先掌握能力A就从A到B连一条有向边。比如“模型量化与剪枝”依赖“模型推理基础”“模型推理基础”依赖“深度学习框架使用”“深度学习框架使用”依赖“Python编程”。构建依赖图的方法有两种。一种是专家法找几个资深工程师坐在一起画优点是准确缺点是慢且主观。另一种是数据驱动法从学习路径数据、课程先修关系、技术文档的引用关系中自动抽取。我实际用的是混合法先用数据驱动法生成初始图然后专家评审修正。数据驱动法的具体做法是收集一批AI学习路径数据比如课程大纲、技术书籍目录、开源项目贡献指南用LLM抽取其中的“先修-后继”关系然后和JD中能力项的共现关系做交叉验证。如果两个能力项在大量JD中总是同时出现且在学习路径中总是有先后关系那它们之间很可能存在依赖。4.2 权重分配不同岗位的能力侧重差异同一个能力域在不同岗位中的权重完全不同。比如“工程与部署”在AI应用工程师岗位中权重很高在算法研究员岗位中权重较低。“业务与产品”在AI产品经理岗位中权重很高在底层框架开发岗位中权重较低。权重的确定我用的方法是对每个岗位统计该岗位所有JD中各个能力域被提及的频率归一化之后作为初始权重然后根据团队实际需求做调整。比如我们团队当时急需提升推理优化能力就把“工程与部署”域的权重从0.25调到了0.35。权重的作用主要体现在两个地方一是培养优先级排序权重高的域优先投入资源二是评估时的加权计算不同能力域的得分按权重汇总。4.3 熟练度分级的行为锚定法熟练度分级最怕的是拍脑袋。L3和L4的区别到底是什么如果不定义清楚评估的时候就会吵架。我用的是行为锚定法对每个能力项用具体的行为描述来定义每个级别。以“Prompt工程”为例级别行为锚定描述L1了解Prompt的基本概念能使用简单的指令完成问答L2能编写多轮对话Prompt理解Few-shot和CoT的基本用法L3能针对具体业务场景设计稳定的Prompt模板能处理常见的输出格式问题L4能设计Prompt评估体系能通过Prompt优化显著提升业务指标能总结Prompt设计模式L5能制定团队Prompt工程规范能培训他人能跟踪前沿方法并转化为团队实践行为锚定描述必须具体到“能做什么”而不是“了解什么”。L1和L2的区别在于“跟着做”和“独立做”L3和L4的区别在于“做好”和“设计好”L4和L5的区别在于“自己好”和“让别人也好”。4.4 能力图谱的数据结构设计整张图谱最终要落到一个数据结构上。我用的是JSON格式核心字段包括{ capability_id: cap_001, name: Prompt工程, domain: 算法与模型, dependencies: [cap_010, cap_015], levels: { L1: 了解Prompt的基本概念..., L2: 能编写多轮对话Prompt..., L3: 能针对具体业务场景设计..., L4: 能设计Prompt评估体系..., L5: 能制定团队Prompt工程规范... }, weight: 0.15, assessment_methods: [项目评审, 代码审查, 场景测试] }这个结构的好处是可扩展。后面如果要加“学习资源”“评估题库”“典型项目案例”直接加字段就行不影响已有数据。5. 图谱落地可视化、评估体系与持续迭代5.1 用雷达图和力导向图做能力盘点图谱建好之后要让人能看懂。我常用的两种可视化方式是雷达图和力导向图。雷达图适合看个人或团队的能力分布。把能力域作为轴熟练度作为刻度一个人或一个团队在每个域上的平均熟练度画出来一眼就能看出短板在哪里。比如我们团队当时雷达图显示“工程与部署”域明显凹陷后来就针对性地安排了推理优化的专项培养。力导向图适合看能力之间的依赖关系。节点是能力项边是依赖关系节点大小表示权重颜色表示能力域。这种图能帮你识别出关键路径上的瓶颈能力。比如如果“模型推理基础”这个节点很大且有很多出边说明它是很多进阶能力的前置培养优先级应该最高。5.2 评估方式的选择项目评审、代码审查、场景测试能力评估不能只靠考试。我用的组合是项目评审看实际产出代码审查看工程规范场景测试看临场解决问题的能力。项目评审主要评估L3以上的能力看候选人在真实项目中是否独立完成了相关任务产出质量如何。代码审查主要评估工程与部署域的能力看代码结构、注释、测试覆盖、异常处理这些细节。场景测试主要评估业务与产品域和部分算法域的能力给一个模拟的业务问题看候选人怎么分析、怎么选型、怎么权衡。每种评估方式都要有评分标准评分标准要和熟练度分级的行为锚定描述对应起来。比如代码审查中如果候选人能写出清晰的模块划分和完整的单元测试对应L3如果能设计出可复用的组件和自动化测试流程对应L4。5.3 图谱的版本管理和迭代节奏AI领域变化快能力图谱不能建完就不管了。我的做法是每季度做一次小迭代每年做一次大迭代。小迭代主要是补充新出现的能力项和调整权重大迭代会重新审视能力域划分和依赖关系。版本管理用Git每次迭代打一个tag变更记录写清楚。这样当有人问“为什么这个能力项的权重变了”的时候可以追溯到具体的决策记录。迭代的触发条件有三个一是团队业务方向发生重大变化比如从做CV转向做大模型应用二是新技术成为主流比如Agent框架从实验阶段进入生产阶段三是评估数据积累到一定程度发现某些能力项的评估结果和实际绩效相关性很低需要调整定义或评估方式。注意迭代不是越频繁越好。能力图谱如果天天变团队会无所适从。季度小迭代、年度大迭代这个节奏是我试过比较稳的。6. 实操中踩过的坑和验证有效的经验6.1 能力项粒度过粗或过细的典型症状粒度太粗的典型症状是评估的时候发现大家都“会”但实际水平差距很大。比如“机器学习”作为一个能力项L3的定义是“能独立完成机器学习项目”但有人做的是调包有人做的是从零实现有人做的是优化生产环境性能这些差距完全体现不出来。粒度太细的典型症状是图谱节点爆炸维护成本极高而且很多细粒度能力项之间高度相关实际上可以合并。比如“会用pandas读取CSV”“会用pandas做groupby”“会用pandas做merge”这三个如果都作为独立能力项图谱会变得极其臃肿。我的经验是一个能力项应该对应“一个可以在项目中独立承担的技术职责”。比如“数据清洗与标注管理”是一个合适的能力项“会用pandas”太细“数据处理”太粗。6.2 依赖关系建错的排查方法依赖关系建错有两种情况一种是漏了依赖导致学习路径不完整另一种是多了依赖导致不必要的先修要求。排查漏依赖的方法是找几个实际做过该能力项相关项目的工程师问他们“在做这件事之前你必须要先会什么”。如果多个工程师都提到同一个前置能力而图谱里没有这条边那就是漏了。排查多依赖的方法是看是否存在“跳过某个前置能力直接学后继能力也成功了”的案例。如果有那这条依赖可能不是必须的可以降级为“推荐先修”而不是“必须前修”。6.3 让团队接受能力图谱的沟通策略能力图谱最大的阻力往往不是技术问题而是人的问题。大家会担心“这是不是要拿来考核我”“是不是要给我贴标签”。我的做法是第一明确图谱的用途是培养和项目匹配不是绩效考核。第二让团队成员参与图谱的建设和迭代而不是自上而下强推。第三先在小范围试点用实际效果说话。比如我们用图谱做了一次项目人员匹配把合适的人放到合适的位置上项目交付质量明显提升大家就自然接受了。6.4 从图谱到培养计划的转化路径图谱建好之后怎么变成具体的培养计划我的做法是三步第一步做个人能力盘点找出每个人当前水平和目标岗位要求之间的差距。第二步根据依赖关系确定学习顺序先补前置能力再补进阶能力。第三步匹配学习资源包括内部项目机会、外部课程、导师带教等。这里的关键是培养计划要具体到“下一个季度重点提升哪两个能力项”而不是笼统地说“提升工程能力”。越具体越容易执行和验证。7. 一个简化版落地示例从JD到图谱的完整走一遍7.1 输入一份AI应用工程师JD假设我们有一份AI应用工程师的JD核心职责是负责大模型应用的设计和开发包括Prompt设计、RAG系统搭建、Agent流程编排、模型服务部署和性能优化。任职要求是熟悉Python了解大模型基本原理有LangChain或类似框架使用经验了解向量数据库有后端服务开发经验。7.2 抽取出的能力项和依赖关系经过抽取和归类得到以下能力项能力项能力域依赖Python编程工程与部署无大模型基础理论算法与模型无Prompt工程算法与模型大模型基础理论RAG系统设计算法与模型Prompt工程、向量数据库向量数据库使用数据与特征无Agent流程编排算法与模型Prompt工程、Python编程模型服务部署工程与部署Python编程推理性能优化工程与部署模型服务部署业务场景理解业务与产品无7.3 权重分配和分级标准对这个岗位权重分配如下算法与模型0.35工程与部署0.30数据与特征0.15业务与产品0.15协作与沟通0.05。以“RAG系统设计”为例分级标准是L1了解RAG基本概念L2能跟着教程搭建简单RAGL3能独立设计RAG流程并处理常见问题L4能优化检索策略和生成质量能评估RAG效果L5能制定RAG设计规范并培训他人。7.4 图谱输出和培养建议最终输出的图谱可以直接用于招聘时按能力项设计面试题培养时按依赖关系安排学习路径项目匹配时按能力权重选择人员。比如一个新入职的工程师Python和向量数据库是L3Prompt工程是L2RAG系统设计是L1那培养重点就很明确先补Prompt工程到L3再补RAG系统设计到L3同时通过实际项目积累Agent流程编排经验。这套方法我在两个团队里实际跑过从零到一建图谱大概需要两到三周的全职投入后续维护每季度大概两三天。投入不算小但比起招聘错人、培养方向跑偏、项目匹配靠感觉的代价这个投入是值得的。
1. 从一份岗位说明书说起为什么传统JD撑不起AI团队的能力管理我做过一段时间AI团队的招聘和技术管理最头疼的事情不是招不到人而是招进来之后发现“岗位说明书”和“实际要干的活”完全是两码事。一份典型的AI岗位JD大概长这样熟悉机器学习算法、掌握Python、有深度学习项目经验、了解大模型相关技术。你拿这份JD去招人来的人五花八门有做CV的、有做NLP的、有做推荐系统的还有纯调参侠。面试的时候感觉都还行进来之后发现团队里缺的是能把模型部署到生产环境的人而不是再找一个在Jupyter Notebook里刷准确率的人。这就是问题的起点传统岗位说明书是“职责描述”不是“能力描述”。它告诉你这个人要干什么但没告诉你干好这件事需要哪些具体能力、这些能力之间是什么关系、每个能力应该达到什么水平。对于AI岗位来说这个问题尤其严重因为AI领域的技术栈更新极快岗位边界模糊一个人可能同时涉及数据处理、模型训练、推理优化、工程部署、业务理解等多个维度。我后来开始尝试用“能力建模”的思路来重构这件事。简单说就是把一份模糊的岗位说明书拆解成一张结构化的胜任力图谱。这张图谱不是简单的技能列表而是一个有层级、有依赖关系、有熟练度标准的能力网络。它要能回答几个核心问题这个岗位到底需要哪些能力哪些是基础能力哪些是进阶能力能力之间的依赖关系是什么每个能力怎么评估不同级别的人应该达到什么水平这件事的技术含量在于它不是拍脑袋写出来的而是需要一套可复现的技术路线。从原始JD的语义解析到能力项的抽取和归类再到能力关系的建模和熟练度分级最后到图谱的可视化和评估体系设计每一步都有具体的方法和工具可以落地。我在这篇文章里会把整条路线拆开讲清楚包括我实际踩过的坑和验证过的做法。注意能力建模不是HR的绩效考核工具它的第一服务对象是技术管理者。你要用它来指导招聘、培养、项目排期和团队能力盘点而不是拿来给成员打分排名。这个定位如果搞错了后面所有工作都会变形。2. 能力建模到底建的是什么核心概念和边界定义2.1 能力项、能力域、熟练度、依赖关系在动手之前先把几个核心概念定义清楚不然后面会越做越乱。能力项是图谱的最小单元比如“PyTorch框架使用”“Transformer架构理解”“模型量化与剪枝”“Prompt工程”“数据清洗与标注管理”。每个能力项必须是可观察、可评估的不能是“有责任心”这种没法量化的东西。能力域是能力项的归类容器比如“算法与模型”“工程与部署”“数据与特征”“业务与产品”“协作与沟通”。一个AI岗位通常涉及3到5个能力域不同岗位的差异主要体现在各能力域的权重和深度要求上。熟练度我一般分五级L1了解概念、L2能跟着做、L3能独立完成、L4能设计和优化、L5能制定标准和带人。这个分级不是拍脑袋定的后面会讲怎么用行为锚定法来校准。依赖关系是能力项之间的前置关系。比如“模型量化与剪枝”依赖“模型推理基础”和“PyTorch框架使用”“Prompt工程”依赖“大模型基础理论”和“业务场景理解”。依赖关系决定了学习路径和培养优先级。2.2 能力建模和岗位说明书、技能矩阵的区别很多人会把能力建模和技能矩阵搞混。技能矩阵通常是一个二维表行是人列是技能格子里打勾或者打分。它解决的是“谁会什么”的问题但不解决“这个能力到底意味着什么”“能力之间怎么组合”“不同级别差在哪里”的问题。岗位说明书解决的是“这个岗位要做什么”能力建模解决的是“做好这个岗位需要具备什么”。前者是任务导向后者是能力导向。两者互补但不能互相替代。能力建模和胜任力模型也不完全一样。经典的胜任力模型往往包含动机、特质、自我概念等深层要素偏HR心理学范式。我这里讲的能力建模更偏技术和工程视角聚焦在可培养、可评估的专业能力上不涉及性格和动机层面的东西。2.3 为什么AI岗位特别需要能力建模AI岗位有三个特点让传统JD特别不好用。第一是技术栈跨度大一个“AI工程师”可能从数据清洗一直做到服务上线中间涉及十几个技术环节。第二是更新速度快去年还在用BERT做微调今年就要搞RAG和Agent能力项需要持续迭代。第三是岗位边界模糊算法工程师和AI应用工程师的职责经常重叠但能力侧重点完全不同。没有能力建模你在招聘时只能靠关键词匹配在培养时只能靠“多跟着项目练”在评估时只能靠主观印象。有了能力图谱你至少能把讨论拉到一个共同的框架里来。3. 从JD文本到能力项抽取、清洗与归类的完整链路3.1 原始语料的收集和预处理第一步不是直接拿一份JD就开始抽而是要收集足够多的语料。我的做法是同一个岗位收集至少20到30份来自不同公司、不同行业的JD文本。为什么要这么多因为单份JD的表述偏差很大有的写得很细有的很粗有的夹杂大量公司特定术语。只有多份语料放在一起才能通过共现频率识别出真正核心的能力项。收集完之后做预处理去掉公司介绍、福利待遇、投递方式这些无关段落只保留岗位职责和任职要求两部分。然后把文本按句子或短段落切分方便后续逐条分析。这一步可以用简单的脚本做不需要上大模型正则加关键词过滤就够了。提示如果你所在的公司有内部岗位文档优先用内部文档。外部JD往往有美化成分内部文档更真实地反映了实际工作内容。3.2 用LLM做能力项抽取的提示词设计预处理完之后我用的方法是用大模型做能力项抽取。这里的关键是提示词设计。我试过很多版本最后稳定下来的提示词结构是这样的你是一名AI领域的技术能力分析专家。请从以下岗位描述文本中抽取具体的能力项。 要求 1. 每个能力项必须是一个可评估的具体技能不能是“有责任心”“学习能力强”这类通用素质。 2. 能力项粒度控制在“一个技术点或一个明确的工作能力”级别不要过于宽泛如“机器学习”也不要过于细碎如“会用pandas.read_csv”。 3. 对每个能力项标注它所属的能力域从以下选项中选择算法与模型、工程与部署、数据与特征、业务与产品、协作与沟通。 4. 输出格式为JSON数组每个元素包含能力项名称、能力域、原文依据。 岗位描述文本 {text}这个提示词我迭代了大概七八版主要调整的是粒度控制和能力域分类的稳定性。早期版本抽出来的能力项要么太粗要么太细后来加了“粒度控制在技术点级别”这个约束之后好很多。3.3 多轮抽取结果的合并与去重单次抽取肯定有遗漏和重复我的做法是跑三轮第一轮用原始提示词第二轮在提示词里加入“请特别注意工程部署和业务理解相关的能力”第三轮加入“请特别注意数据质量和模型评估相关的能力”。三轮结果合并之后做去重。去重不是简单的字符串匹配因为同一个能力可能有不同表述比如“PyTorch使用”“PyTorch框架”“PyTorch开发经验”其实是同一个能力项。我用的方法是先做向量化然后用余弦相似度做聚类相似度阈值设在0.85左右。聚类之后每个簇选一个最具代表性的表述作为标准能力项名称。3.4 能力域归类的校验和修正自动归类之后一定要人工校验。我遇到过几个典型问题一是“模型部署”有时候被归到“算法与模型”有时候被归到“工程与部署”需要统一二是“A/B测试设计”有时候被归到“数据与特征”有时候被归到“业务与产品”这个取决于岗位侧重点需要根据具体岗位来定三是有些能力项跨多个域比如“特征工程”既涉及数据也涉及算法我一般归到“数据与特征”但在依赖关系里标注它和算法域的关联。校验的时候我会拉一个表格每行是一个能力项列包括能力项名称、自动归类结果、人工修正结果、修正理由。这个表格后面做依赖关系建模的时候还要用。4. 能力关系建模依赖图、权重分配与分级标准4.1 用有向图表达能力依赖关系能力项抽出来之后它们不是孤立的。我用有向无环图来表达依赖关系如果掌握能力B之前必须先掌握能力A就从A到B连一条有向边。比如“模型量化与剪枝”依赖“模型推理基础”“模型推理基础”依赖“深度学习框架使用”“深度学习框架使用”依赖“Python编程”。构建依赖图的方法有两种。一种是专家法找几个资深工程师坐在一起画优点是准确缺点是慢且主观。另一种是数据驱动法从学习路径数据、课程先修关系、技术文档的引用关系中自动抽取。我实际用的是混合法先用数据驱动法生成初始图然后专家评审修正。数据驱动法的具体做法是收集一批AI学习路径数据比如课程大纲、技术书籍目录、开源项目贡献指南用LLM抽取其中的“先修-后继”关系然后和JD中能力项的共现关系做交叉验证。如果两个能力项在大量JD中总是同时出现且在学习路径中总是有先后关系那它们之间很可能存在依赖。4.2 权重分配不同岗位的能力侧重差异同一个能力域在不同岗位中的权重完全不同。比如“工程与部署”在AI应用工程师岗位中权重很高在算法研究员岗位中权重较低。“业务与产品”在AI产品经理岗位中权重很高在底层框架开发岗位中权重较低。权重的确定我用的方法是对每个岗位统计该岗位所有JD中各个能力域被提及的频率归一化之后作为初始权重然后根据团队实际需求做调整。比如我们团队当时急需提升推理优化能力就把“工程与部署”域的权重从0.25调到了0.35。权重的作用主要体现在两个地方一是培养优先级排序权重高的域优先投入资源二是评估时的加权计算不同能力域的得分按权重汇总。4.3 熟练度分级的行为锚定法熟练度分级最怕的是拍脑袋。L3和L4的区别到底是什么如果不定义清楚评估的时候就会吵架。我用的是行为锚定法对每个能力项用具体的行为描述来定义每个级别。以“Prompt工程”为例级别行为锚定描述L1了解Prompt的基本概念能使用简单的指令完成问答L2能编写多轮对话Prompt理解Few-shot和CoT的基本用法L3能针对具体业务场景设计稳定的Prompt模板能处理常见的输出格式问题L4能设计Prompt评估体系能通过Prompt优化显著提升业务指标能总结Prompt设计模式L5能制定团队Prompt工程规范能培训他人能跟踪前沿方法并转化为团队实践行为锚定描述必须具体到“能做什么”而不是“了解什么”。L1和L2的区别在于“跟着做”和“独立做”L3和L4的区别在于“做好”和“设计好”L4和L5的区别在于“自己好”和“让别人也好”。4.4 能力图谱的数据结构设计整张图谱最终要落到一个数据结构上。我用的是JSON格式核心字段包括{ capability_id: cap_001, name: Prompt工程, domain: 算法与模型, dependencies: [cap_010, cap_015], levels: { L1: 了解Prompt的基本概念..., L2: 能编写多轮对话Prompt..., L3: 能针对具体业务场景设计..., L4: 能设计Prompt评估体系..., L5: 能制定团队Prompt工程规范... }, weight: 0.15, assessment_methods: [项目评审, 代码审查, 场景测试] }这个结构的好处是可扩展。后面如果要加“学习资源”“评估题库”“典型项目案例”直接加字段就行不影响已有数据。5. 图谱落地可视化、评估体系与持续迭代5.1 用雷达图和力导向图做能力盘点图谱建好之后要让人能看懂。我常用的两种可视化方式是雷达图和力导向图。雷达图适合看个人或团队的能力分布。把能力域作为轴熟练度作为刻度一个人或一个团队在每个域上的平均熟练度画出来一眼就能看出短板在哪里。比如我们团队当时雷达图显示“工程与部署”域明显凹陷后来就针对性地安排了推理优化的专项培养。力导向图适合看能力之间的依赖关系。节点是能力项边是依赖关系节点大小表示权重颜色表示能力域。这种图能帮你识别出关键路径上的瓶颈能力。比如如果“模型推理基础”这个节点很大且有很多出边说明它是很多进阶能力的前置培养优先级应该最高。5.2 评估方式的选择项目评审、代码审查、场景测试能力评估不能只靠考试。我用的组合是项目评审看实际产出代码审查看工程规范场景测试看临场解决问题的能力。项目评审主要评估L3以上的能力看候选人在真实项目中是否独立完成了相关任务产出质量如何。代码审查主要评估工程与部署域的能力看代码结构、注释、测试覆盖、异常处理这些细节。场景测试主要评估业务与产品域和部分算法域的能力给一个模拟的业务问题看候选人怎么分析、怎么选型、怎么权衡。每种评估方式都要有评分标准评分标准要和熟练度分级的行为锚定描述对应起来。比如代码审查中如果候选人能写出清晰的模块划分和完整的单元测试对应L3如果能设计出可复用的组件和自动化测试流程对应L4。5.3 图谱的版本管理和迭代节奏AI领域变化快能力图谱不能建完就不管了。我的做法是每季度做一次小迭代每年做一次大迭代。小迭代主要是补充新出现的能力项和调整权重大迭代会重新审视能力域划分和依赖关系。版本管理用Git每次迭代打一个tag变更记录写清楚。这样当有人问“为什么这个能力项的权重变了”的时候可以追溯到具体的决策记录。迭代的触发条件有三个一是团队业务方向发生重大变化比如从做CV转向做大模型应用二是新技术成为主流比如Agent框架从实验阶段进入生产阶段三是评估数据积累到一定程度发现某些能力项的评估结果和实际绩效相关性很低需要调整定义或评估方式。注意迭代不是越频繁越好。能力图谱如果天天变团队会无所适从。季度小迭代、年度大迭代这个节奏是我试过比较稳的。6. 实操中踩过的坑和验证有效的经验6.1 能力项粒度过粗或过细的典型症状粒度太粗的典型症状是评估的时候发现大家都“会”但实际水平差距很大。比如“机器学习”作为一个能力项L3的定义是“能独立完成机器学习项目”但有人做的是调包有人做的是从零实现有人做的是优化生产环境性能这些差距完全体现不出来。粒度太细的典型症状是图谱节点爆炸维护成本极高而且很多细粒度能力项之间高度相关实际上可以合并。比如“会用pandas读取CSV”“会用pandas做groupby”“会用pandas做merge”这三个如果都作为独立能力项图谱会变得极其臃肿。我的经验是一个能力项应该对应“一个可以在项目中独立承担的技术职责”。比如“数据清洗与标注管理”是一个合适的能力项“会用pandas”太细“数据处理”太粗。6.2 依赖关系建错的排查方法依赖关系建错有两种情况一种是漏了依赖导致学习路径不完整另一种是多了依赖导致不必要的先修要求。排查漏依赖的方法是找几个实际做过该能力项相关项目的工程师问他们“在做这件事之前你必须要先会什么”。如果多个工程师都提到同一个前置能力而图谱里没有这条边那就是漏了。排查多依赖的方法是看是否存在“跳过某个前置能力直接学后继能力也成功了”的案例。如果有那这条依赖可能不是必须的可以降级为“推荐先修”而不是“必须前修”。6.3 让团队接受能力图谱的沟通策略能力图谱最大的阻力往往不是技术问题而是人的问题。大家会担心“这是不是要拿来考核我”“是不是要给我贴标签”。我的做法是第一明确图谱的用途是培养和项目匹配不是绩效考核。第二让团队成员参与图谱的建设和迭代而不是自上而下强推。第三先在小范围试点用实际效果说话。比如我们用图谱做了一次项目人员匹配把合适的人放到合适的位置上项目交付质量明显提升大家就自然接受了。6.4 从图谱到培养计划的转化路径图谱建好之后怎么变成具体的培养计划我的做法是三步第一步做个人能力盘点找出每个人当前水平和目标岗位要求之间的差距。第二步根据依赖关系确定学习顺序先补前置能力再补进阶能力。第三步匹配学习资源包括内部项目机会、外部课程、导师带教等。这里的关键是培养计划要具体到“下一个季度重点提升哪两个能力项”而不是笼统地说“提升工程能力”。越具体越容易执行和验证。7. 一个简化版落地示例从JD到图谱的完整走一遍7.1 输入一份AI应用工程师JD假设我们有一份AI应用工程师的JD核心职责是负责大模型应用的设计和开发包括Prompt设计、RAG系统搭建、Agent流程编排、模型服务部署和性能优化。任职要求是熟悉Python了解大模型基本原理有LangChain或类似框架使用经验了解向量数据库有后端服务开发经验。7.2 抽取出的能力项和依赖关系经过抽取和归类得到以下能力项能力项能力域依赖Python编程工程与部署无大模型基础理论算法与模型无Prompt工程算法与模型大模型基础理论RAG系统设计算法与模型Prompt工程、向量数据库向量数据库使用数据与特征无Agent流程编排算法与模型Prompt工程、Python编程模型服务部署工程与部署Python编程推理性能优化工程与部署模型服务部署业务场景理解业务与产品无7.3 权重分配和分级标准对这个岗位权重分配如下算法与模型0.35工程与部署0.30数据与特征0.15业务与产品0.15协作与沟通0.05。以“RAG系统设计”为例分级标准是L1了解RAG基本概念L2能跟着教程搭建简单RAGL3能独立设计RAG流程并处理常见问题L4能优化检索策略和生成质量能评估RAG效果L5能制定RAG设计规范并培训他人。7.4 图谱输出和培养建议最终输出的图谱可以直接用于招聘时按能力项设计面试题培养时按依赖关系安排学习路径项目匹配时按能力权重选择人员。比如一个新入职的工程师Python和向量数据库是L3Prompt工程是L2RAG系统设计是L1那培养重点就很明确先补Prompt工程到L3再补RAG系统设计到L3同时通过实际项目积累Agent流程编排经验。这套方法我在两个团队里实际跑过从零到一建图谱大概需要两到三周的全职投入后续维护每季度大概两三天。投入不算小但比起招聘错人、培养方向跑偏、项目匹配靠感觉的代价这个投入是值得的。
