尧图网站建设 
1. 为什么“找AI技能”突然成了团队的头号难题1.1 这个标题背后藏着的真实场景最近一段时间“How are you finding and managing AI skills?”这句话经常出现在技术圈的各种讨论里不管是技术负责人、HRBP还是在一线写代码的工程师多多少少都绕不开这个问题。表面上看它是在问“你怎么找到会AI的人”和“你怎么管理这些AI技能”但实际上这句话问的是团队在AI转型过程中最扎心的两件事第一团队里到底谁真正会AI而不是嘴上说会第二当大家都会一点AI之后怎么把这些零散的能力变成团队可复用的资产而不是各玩各的。我自己的观察是很多团队在2022年底大模型刚火起来那阵都特别兴奋OpenAI、Claude、开源模型轮番刷屏老板们的第一反应是“我们也要有AI能力”。但真正落地的时候问题就全出来了有人用AI写周报有人用AI生成图片有人用Cursor写代码还有人在摸鱼的时候跟AI聊天。这些场景五花八门唯一的共同点是——没有人知道这些尝试到底产生了多少价值也没有人能回答“如果我们想认真做一个AI项目谁来做核心开发”这个问题。1.2 现在团队里的AI技能分布比想象中更混乱说句实在话现在的AI技能分布是非常不均匀的而且在大多数团队里属于“隐性技能”。什么意思就是你知道某个人可能在用AI但你不清楚他到底会到什么程度。我见过太多类似的例子一个后端工程师在GitHub上偷偷用Copilot写了小半年代码代码质量还意外地好一个测试同学用AI自动生成了一堆边界用例效率翻了三四倍但如果你去做一次技能普查问“谁会AI”这些人大概率不会主动站出来因为AI技能不在他们的岗位JD里说出来既不算业绩又怕被认为是“不务正业”。这就导致了一个很尴尬的局面公司想凑一个AI项目组翻遍整个团队找不到人但真做起来之后发现身边的人其实都会点AI只是每个人会的点完全不一样。有人擅长提示词有人擅长用Agent框架有人擅长微调有人擅长部署推理服务但大家的技能是割裂的没有一套机制把它们识别出来更谈不上统一管理。所以这篇文章我想好好聊聊“找”和“管”这两个动作结合我自己在团队里折腾AI工程实践的经验尽量把它讲透。2. 先搞清楚你找的到底是“技能”还是“场景”2.1 技能和场景很多团队把它们混为一谈了我发现一个特别常见的误区很多团队在盘点AI技能的时候把“技能”和“场景”混在一起。比如有人会写“会用AI写周报”有人写“会用Midjourney画图”还有人写“了解大模型原理”。这些东西严格来说都不是技能而是场景、工具或知识它们无法用来评估一个人能不能干活。什么叫技能技能是你面对一类问题时能稳定、可复用、可衡量的解决能力。比如“能在一个星期内把一个开源模型部署成内部API服务”这是技能“能在Prompt里设计复杂的思维链让模型输出稳定格式”这是技能“能定位AI生成代码里的隐蔽错误并修复”这也是技能。但“会用AI写周报”不算技能因为它太浅了只代表你接触过不代表你能解决复杂问题。所以团队在“找”AI技能的时候第一个动作不是做普查而是先把“我们要解决什么问题”给定义清楚。你是想提高软件开发效率想做一个内部知识库问答机器人还是想给现有产品加上AI能力不同的目标决定了你需要的技能组合是完全不同的。如果目标是提效你需要的核心技能是AI编程、测试设计、Prompt优化以及把这些能力嵌入现有工作流的能力。如果目标是做新产品/新功能你需要的是AI应用开发、Agent框架、模型微调、RAG检索增强生成等端到端能力。如果目标是产品化/规模化你还需要AI Infra相关的技能比如模型部署、推理优化、监控、成本控制。2.2 从场景倒推需要的技能地图长什么样我比较推荐的做法是先画一张简单的“AI技能地图”把团队可能需要的技能分门别类列出来再让大家去认领。分类不需要太复杂分成五类就够了技能类别典型能力对应角色提示工程与对话设计Prompt编写、Few-shot设计、输出格式约束、上下文管理产品经理、运营、技术支持AI编程与开发用AI辅助写代码、Code Review、AI Coding工具深度使用前端/后端/全栈工程师Agent与应用框架LangChain、Spring AI、自研Agent框架、工具调用应用开发工程师模型工程微调、RAG、评估集构建、模型选型算法工程师、AI工程化人员AI基础设施部署、GPU资源管理、推理加速、成本优化运维/SRE、AI Infra工程师这张地图的好处是它让每个成员都能快速定位自己“在哪个格子”。更重要的是它把AI技能从“玄学”变成了可讨论的工程能力。我记得我们团队第一次做这个地图的时候好几个人都发现自己其实已经具备了不止一格的技能只是之前从来没被定义过。2.3 找到技能之后马上做“可信度验证”有了技能地图下一步不是急着安排工作而是做“可信度验证”。因为自评这个东西很容易出现“觉得自己会”和“实际会”之间的巨大落差。我见过好几个工程师自称精通AI编程结果一上手连Context窗口爆掉的问题都搞不清楚。所以我建议在“找”的阶段就别怕麻烦把人放到一个小而真实的项目里去验证。具体操作可以是这样选一个内部的小需求比如“把每周的发布日志自动总结成一条结构化公告”让候选人自己决定怎么用AI实现限定两天时间。做完之后重点不看结果看过程——他有没有选对工具有没有做效果评估有没有处理AI输出不稳定这个核心问题如果他连“这次输出好、下次输出差”这件事都觉得无所谓那这个技能基本就是假的。反过来如果他能主动跟你聊“我加了温度参数”“我做了输出校验”那这个人大概率是真会。3. 管理AI技能本质上是管理生产和消费两条线3.1 把人员分成生产者和消费者管理策略完全不同找到人之后“管理”就是下一个大问题。很多管理者的第一反应是建一个技能清单记录谁会用AI然后定期更新。这个思路没错但太静态了。AI技能更新迭代极快今天会用某个工具明天工具就升级了今天的最佳实践下个月可能就过时了。所以管理AI技能的核心不是“登记”而是“让技能流动起来”。我比较喜欢把AI技能相关人员分成两类生产者和消费者。生产者是能搭建AI应用、写AI相关代码、调模型、部署服务的人他们创造AI能力消费者是能在自己的工作流里使用AI工具、提升效率的人他们使用AI能力。两者的管理方式完全不同。对生产者要管理他们的产出物比如代码库、Prompt模板、内部Agent、评估脚本确保这些东西是可复用的、可维护的。对消费者要管理他们的使用水平比如有没有把AI用对地方、有没有形成新的工作习惯、效率提升能否被量化。3.2 提示词和AI代码也应该像代码资产一样入库说到管理我最想强调的一个点是Prompt不是写给自己看的AI生成的代码也不是“跑通了就完事”。如果把AI技能管理当成一个工程问题来对待那Prompt和AI辅助产出的代码都应该纳入资产管理体系。具体怎么做我们在内部建了一个“AI技能库”里面分门别类存放几类东西Prompt模板比如“代码评审Prompt”“需求拆解Prompt”“测试用例生成Prompt”。每个模板都包含版本号、适用场景、参数说明、实测效果截图。AI Coding实践笔记记录某个复杂的AI编程问题是怎么解决的。比如“当生成代码出现幻觉调用不存在的API时通过添加Fake API定义让代码生成更稳定”这类经验。可复用脚本比如批量清洗数据、自动跑评估集的脚本全部放到统一的Git仓库里。踩坑记录比如“某个模型在长文本场景下会漏掉中间内容需要改成滑动窗口分段调用”。这个技能库的作用是让个人经验变成组织资产。哪怕当初写这个Prompt的人离职了后来者翻一下历史记录也能快速上手。这也是“管理AI技能”和“统计谁会AI”之间最大的区别——前者沉淀资产后者只是做台账。3.3 用“技能矩阵项目实践”双维度做动态评估当然光有资产库还不够还得有动态评估机制。很多团队喜欢半年做一次技能评估但我觉得AI领域的节奏半年太久了一个季度一次比较合理。评估维度也不建议只看“你会不会某个工具”而应该结合项目实践来打。这里分享一个我们用过的评估方式叫做“技能矩阵项目实践”双维度打分。技能矩阵就是前面提到的技能地图按熟练度分四级了解、会用、熟练、精通。项目实践则是看这个人在真实项目里用AI产出了什么、解决了什么问题、有没有沉淀出可复用的资产。评分的时候每个维度各占50%。举个例子一个人能滔滔不绝讲RAG原理可以打“熟练”但如果他项目实践中连一个正经的RAG demo都没做过那项目实践分就是0。反过来一个人可能说不清楚太多理论但他把一个内部知识库问答系统真正部署上线了那后者显然更有价值。这套评估方式不一定适合所有团队但它提供了一个思路管理AI技能不能停留在“知道”必须落到“做到”。4. 从个人技能到团队能力关键在于工程化沉淀4.1 为什么个人会用AI不等于团队有AI能力聊完了“找”和“管”第三个问题自然跳出来了就算团队里每个人都用AI这个团队就算有AI能力了吗我的答案是不算。因为个人技能如果没有变成团队可以复用的流程、工具、规范那它在组织层面就是隐性的一遇到人员变动就会断档。这也是为什么很多大厂在提AI工程实践、AI Infra这些概念——它们的重心不是“让人学会AI”而是“把AI能力变成基础设施”。举个很简单的例子。一个工程师可以用Cursor在一天内写好一个数据清洗脚本效率确实高但如果没有沉淀出“如何安全地让AI生成数据处理代码”的规范下一次另一个工程师又得从零摸索甚至在AI生成代码时踩中数据泄露的坑。所以个人用AI提效是好事但如果它不能沉淀为团队的规范、流程和可复用资产那团队的整体AI能力依然是很脆弱的。4.2 AI编程、Agent、模型部署怎么沉淀成团队能力从我的实践经验来看工程化沉淀有几个关键抓手对应到大家一起用的AI工具上尤其重要。第一个抓手是AI编程规范化。团队统一选择1-2个AI编程工具我们尝试过Copilot、Cursor、通义灵码等定义清楚哪些场景适合让AI写代码、哪些场景必须人工写并且要求AI生成的代码必须经过代码评审、必须有测试覆盖。这个规范听起来简单但能做到的团队真不多。很多时候工程师在用AI生成了代码之后自己都不仔细看就提交了这种代码入库短期看不出问题长期就是技术债。第二个抓手是Agent框架的统一。现在做AI应用开发绕不开Agent市面上的框架种类繁多有LangChain、Spring AI也有团队自研。我建议不要在项目里随意引入多种框架而是选定一个并在团队内形成最佳实践。我们团队在Java栈里用的比较多的是Spring AI Alibaba它在与现有微服务体系的整合上做得比较顺尤其适合有大量已有Spring Boot服务的团队。框架统一之后才能把工具调用、上下文管理、记忆机制这些经验沉淀成可复用的模块。第三个抓手是模型部署的标准化。做AI应用的人通常不会只调用云厂商API很多时候需要私有化部署开源模型。这时候就涉及模型部署的技术选型——用vLLM还是TGI用GPU还是CPU怎么做量化模型服务如何与现有监控体系打通如果每个人部署一次模型都从零开始效率会很低。更好的做法是把部署流程脚本化、模板化做成一个内部工具让使用者填几个参数就能拉起一个模型服务。这三个抓手对应了从开发到上线再到维护的全流程。只有在这几个环节都沉淀出团队标准AI技能才算真正“被管理起来”而不是停留在“某某很会用AI”的嘴上评价。4.3 提示词和评估集管理AI技能时最容易忽略的一环最后说一个容易被忽略的管理对象提示词和评估集。在很多团队里提示词散落在每个人的聊天记录里评估集则根本不存在。但如果你做一个AI应用没有评估集你根本不知道模型某次升级后效果是变好了还是变差了。Prompt管理也一样同一个Prompt经手多人修改后可能早就面目全非但没有人知道哪个版本效果最好。所以我强烈建议把Prompt和评估集纳入版本管理。Prompt可以放到类似Git的仓库里每次修改都走提交记录方便回溯。评估集至少要包含几十条真实场景的问题以及对应的期望答案或评分标准。每次替换模型、修改Prompt、调整参数都要跑一遍评估集用数据说话。这套机制看着麻烦但一旦跑起来你会发现团队对AI效果的讨论终于有依据了不再是“我觉得”“我试了一下”。5. 怎么搭一个AI技能管理体系的实操框架5.1 从零开始五个步骤把框架搭起来如果你准备在团队里推行AI技能管理我建议从这五个步骤开始不用一上来就做很大很全先让体系转起来再逐步完善。第一步建立AI技能地图。按我们前面提到的五类技能提示工程、AI编程、Agent与应用框架、模型工程、AI基础设施做一张表让每个成员自己勾选当前能力和目标能力。第二步定义关键角色。每个技能类别找1-2个人作为“技能Owner”他们负责梳理该领域的最佳实践、答疑解惑、维护资产文档。第三步建立资产沉淀机制。要有明确的“提交物”定义比如每个AI项目结束之后必须产出可复用的Prompt、脚本或部署模板放进技能库。第四步设定评估与反馈循环。每个季度做一次技能矩阵更新结合项目实践来调整每个人的技能评级让评估结果反过来指导培训和学习方向。第五步建立透明展示面板。把技能地图、资产库、进行中的项目放在一个团队都能看到的地方让大家知道“谁在做什么”“哪些资产可以复用”。5.2 一次技能盘点会议的实操过程可能有朋友会问“你说的这套东西实际操作起来是什么感觉”我拿我们团队做过的一次技能盘点会议来举例。那一次会议我们花了大概三个小时分四个环节。第一个环节是每个成员花20分钟在技能地图上标注自己的技能熟练度和项目实践案例同时把自己常用的AI工具、常用Prompt、使用心得提前填到技能库里。第二个环节是分组展示每组5个人左右每个人花5分钟讲自己最近做的一个和AI相关的任务重点讲思路、工具、踩坑。第三个环节是交叉提问其他人可以随意提问比如“你做RAG的时候chunk_size怎么设的”“你评估过这个方法的效果吗”“如果换一个模型你的方案还能跑吗”问题越具体越能看出这个人是真懂还是假懂。第四个环节是汇总形成行动项比如发现缺“模型量化”技能就安排一个内部学习小组发现某个Prompt模板特别好用就提入技能库作为团队标准。这场会议最大的价值不是“盘清了家底”而是让团队第一次意识到原来自己身边有这么多AI技能可以调用。以前大家是在各自的角落里摸索现在可以互相借力了。5.3 常犯的五个错误基本上每个团队都会踩框架搭起来之后实际操作中还是会踩不少坑。我总结了五个最常见的错误你对照看看大概率中招。把所有希望押在招聘上忽略内部挖潜。觉得“团队没人会AI招个AI专家就好了”。实际上外部招聘成本高而且外部专家不了解你的业务。更好的策略是“内部挖潜针对性培训”双管齐下往往那个平时喜欢折腾脚本的同事就是最好的AI种子选手。把AI技能等同于会聊大模型。有人觉得“能说出来Transformer三个核心机制”就是AI人才。真到了项目里方案设计能力、工程落地能力、排查问题的能力比背概念重要得多。只激励尖端人才忽略大众化普及。团队里最会用AI的永远是少数人如果只奖励这些人其他人会觉得AI跟自己无关。正确的做法是设置“普及者”角色鼓励那些愿意分享、愿意带人的人。管理和考核脱节评估完就完事。技能盘点出来之后没有后续动作大家填完表就忘了那这套体系就没有生命力。一定要把评估结果和项目分配、培训资源挂钩才能形成闭环。照搬网上的“最佳实践”。每个团队的场景、技术栈、人才结构完全不一样别人的AI技能管理方案只可参考不可照搬一定要根据自己团队的实际情况裁剪。6. 常见问题与排查技巧实录6.1 技能图谱画得挺好但团队成员不配合怎么办这个问题几乎百分之百会出现。员工不配合的原因通常不是“不愿意”而是“觉得这又是HR搞的形式主义”。破解方法有三个。第一让技能盘点直接关联实际利益。比如盘点结果可以用在项目分配上技能评级高的人可以优先选择感兴趣的项目或者在绩效评估时加分。第二降低填写成本。表格不要设计得太复杂尽量用选择题、多选框、下拉菜单别让人填一堆开放性文字。第三先做试点再全面推广。先选一个积极配合的小组跑一遍把成果案例展示出来让别人看到“填这个东西确实有用”再推广就容易多了。6.2 明明有人精通AI但项目需要时他不愿意接这也是很现实的问题。一个人AI能力强但主动参与AI项目的意愿低可能是因为当前岗位职责里没有这一项干了算额外劳动也可能是因为AI项目风险高、不确定性大容易背锅。我建议在管理机制上做一些调整在项目目标里把AI探索或AI应用单独列为一项OKR或KPI在晋升标准里明确把“AI应用能力”作为加分项对于参与AI项目的同事在时间安排上给予一定弹性避免让大家觉得“AI是额外负担”。说到底AI技能管理如果不能让有能力的人受益那这个体系本身就不可持续。6.3 技能评估结果明显失真怎么办评估失真的情况很常见尤其是自学能力强、表达能力好但不擅长干活的人容易高估而埋头苦干但话少的人容易被低估。应对方式是引入“作品评审”和“同行互评”不看自评看项目产出。如果你发现评估结果和平时观察有明显出入不要急着改分数而是去找反例和正例把评估标准细化用事实说话。比如有人自评“精通RAG”但你问他“检索到垃圾内容时怎么减轻对生成的影响”他答不上来那这个“精通”就要打问号。技能评估最忌讳的就是只看自评必须结合实操、作品、互评三方面交叉验证。6.4 工具买了、平台搭了团队就是不用怎么破AI工具落地难是个老问题。很多时候不是工具不好而是推广方式有问题。我们试过比较有效的做法是“场景化试点意见领袖带动”。先选一个高频场景比如代码评审、测试用例生成、周报汇总找两三个愿意尝鲜的人做试点把效果量化出来再在团队里分享。这里的关键是一定要让团队看到“看得见摸得着”的效率提升。比如你说“用AI写测试用例效率提升50%”不如直接放一张对比图左边是以前写测试用例的时间右边是AI辅助后的时间。人都是趋利避害的只要工具确实好用传播速度比你想的快得多。如果工具推了一段时间还是没人用那大概率不是“人不行”而是工具本身不适合或者推广场景没找准这时候要及时回头复盘而不是硬推。6.5 几个实用技巧越早知道越好最后分享几个我在实操中总结的小技巧可能对你有帮助。每季度做一次技能地图更新。AI技能迭代太快半年不更新基本就失真了。建立AI技能库时给每个Prompt和脚本都写清楚“适用边界”。不写使用条件的模板过了三个月就没人敢用了。开会时让人演示实操而不是只看PPT。现场让同事用AI解决一个临时问题比任何自评都更能反映真实水平。保留失败案例。AI项目里失败的尝试同样有价值多记录“为什么这条路走不通”比单纯的成功经验更有参考意义。7. 这条路的下一站让AI技能管理变成团队的一种习惯7.1 从一次技能普查到一套需要持续的机制说了这么多回到原点。AI技能管理这件事最难的不是开始而是持续。我自己见过太多团队刚开始搞AI技能盘点时热情满满拉表格、开会、做评估一套流程走完感觉特别充实。但过了两三个月表格吃灰了技能库没人更新了新来的同事也没人告诉他怎么使用这些资产。这就是典型的“一次性运动”。要避免这个问题最有效的办法是让AI技能管理嵌入日常工作的流程里而不是独立出来单独搞。比如项目复盘的时候加一项“这个项目里我们用到了哪些AI技能是否可沉淀”周会的时候花五分钟让一个同事分享一个AI使用技巧新人入职培训的时候把技能库和Prompt模板作为必读资料。当AI技能的分享、沉淀、复用变成一种习惯的时候你才真正完成了从“个人会用AI”到“团队长出了AI能力”的转变。7.2 缺少专职人员时怎么让这件事跑起来很多中小团队会说“我们也想搞AI技能管理但没有专职的人来做。”这个顾虑可以理解但说实话AI技能管理本身并不需要一个专职团队才能启动。我更推荐“兼职Owner轮值机制”让对AI感兴趣的同学兼任技能库管理员每季度轮换让团队里最活跃的AI用户做内部布道者不占编制、不用专门考核只要给一点激励他们就会非常乐意做。这个机制跑起来之后你会发现一个很有意思的现象真正推动AI技能管理的人不一定是你想象中那个“最懂AI的人”而常常是那个最愿意分享、懂得带动氛围的人。AI技能管理这件事本质上是知识管理在AI时代的新形态。技术会更新换代工具会不停变化但只要团队形成了“发现技能、沉淀资产、分享经验”的循环那不管AI怎么发展团队都能踩在浪头上前进。7.3 未来方向从管人到管场景、管Agent、管流程现在再回头看“How are you finding and managing AI skills?”这个问题我越来越觉得未来的答案可能跟现在不太一样。过去我们管理的是“人的技能”未来我们可能还需要管理“Agent的技能”——当每个团队里都有多个AI Agent承担不同的任务时我们怎么去评估一个Agent的表现怎么更新Agent的提示词和工具配置怎么保证Agent之间的协作不失控这些都是AI技能管理的新课题。所以我的建议是现在搭体系的时候尽量留出扩展空间别把规则定得太死。比如技能地图里预留“Agent配置与编排”这一类让团队里已经有人在用AI Agent的同事能把经验放进去。这样做的好处是当Agent的普及率进一步提升时你不需要推翻重来只需要在现有体系上做增量。在我自己看来AI技能管理的终点不是一个精美的表格也不是一套复杂的流程而是让团队里的每一个人都清楚AI工具只是杠杆真正的价值在于那些会利用杠杆解决问题的人以及把个体能力沉淀成组织能力的那套机制。 AI技能管理实战：从识别到沉淀，打造团队AI能力
1. 为什么“找AI技能”突然成了团队的头号难题1.1 这个标题背后藏着的真实场景最近一段时间“How are you finding and managing AI skills?”这句话经常出现在技术圈的各种讨论里不管是技术负责人、HRBP还是在一线写代码的工程师多多少少都绕不开这个问题。表面上看它是在问“你怎么找到会AI的人”和“你怎么管理这些AI技能”但实际上这句话问的是团队在AI转型过程中最扎心的两件事第一团队里到底谁真正会AI而不是嘴上说会第二当大家都会一点AI之后怎么把这些零散的能力变成团队可复用的资产而不是各玩各的。我自己的观察是很多团队在2022年底大模型刚火起来那阵都特别兴奋OpenAI、Claude、开源模型轮番刷屏老板们的第一反应是“我们也要有AI能力”。但真正落地的时候问题就全出来了有人用AI写周报有人用AI生成图片有人用Cursor写代码还有人在摸鱼的时候跟AI聊天。这些场景五花八门唯一的共同点是——没有人知道这些尝试到底产生了多少价值也没有人能回答“如果我们想认真做一个AI项目谁来做核心开发”这个问题。1.2 现在团队里的AI技能分布比想象中更混乱说句实在话现在的AI技能分布是非常不均匀的而且在大多数团队里属于“隐性技能”。什么意思就是你知道某个人可能在用AI但你不清楚他到底会到什么程度。我见过太多类似的例子一个后端工程师在GitHub上偷偷用Copilot写了小半年代码代码质量还意外地好一个测试同学用AI自动生成了一堆边界用例效率翻了三四倍但如果你去做一次技能普查问“谁会AI”这些人大概率不会主动站出来因为AI技能不在他们的岗位JD里说出来既不算业绩又怕被认为是“不务正业”。这就导致了一个很尴尬的局面公司想凑一个AI项目组翻遍整个团队找不到人但真做起来之后发现身边的人其实都会点AI只是每个人会的点完全不一样。有人擅长提示词有人擅长用Agent框架有人擅长微调有人擅长部署推理服务但大家的技能是割裂的没有一套机制把它们识别出来更谈不上统一管理。所以这篇文章我想好好聊聊“找”和“管”这两个动作结合我自己在团队里折腾AI工程实践的经验尽量把它讲透。2. 先搞清楚你找的到底是“技能”还是“场景”2.1 技能和场景很多团队把它们混为一谈了我发现一个特别常见的误区很多团队在盘点AI技能的时候把“技能”和“场景”混在一起。比如有人会写“会用AI写周报”有人写“会用Midjourney画图”还有人写“了解大模型原理”。这些东西严格来说都不是技能而是场景、工具或知识它们无法用来评估一个人能不能干活。什么叫技能技能是你面对一类问题时能稳定、可复用、可衡量的解决能力。比如“能在一个星期内把一个开源模型部署成内部API服务”这是技能“能在Prompt里设计复杂的思维链让模型输出稳定格式”这是技能“能定位AI生成代码里的隐蔽错误并修复”这也是技能。但“会用AI写周报”不算技能因为它太浅了只代表你接触过不代表你能解决复杂问题。所以团队在“找”AI技能的时候第一个动作不是做普查而是先把“我们要解决什么问题”给定义清楚。你是想提高软件开发效率想做一个内部知识库问答机器人还是想给现有产品加上AI能力不同的目标决定了你需要的技能组合是完全不同的。如果目标是提效你需要的核心技能是AI编程、测试设计、Prompt优化以及把这些能力嵌入现有工作流的能力。如果目标是做新产品/新功能你需要的是AI应用开发、Agent框架、模型微调、RAG检索增强生成等端到端能力。如果目标是产品化/规模化你还需要AI Infra相关的技能比如模型部署、推理优化、监控、成本控制。2.2 从场景倒推需要的技能地图长什么样我比较推荐的做法是先画一张简单的“AI技能地图”把团队可能需要的技能分门别类列出来再让大家去认领。分类不需要太复杂分成五类就够了技能类别典型能力对应角色提示工程与对话设计Prompt编写、Few-shot设计、输出格式约束、上下文管理产品经理、运营、技术支持AI编程与开发用AI辅助写代码、Code Review、AI Coding工具深度使用前端/后端/全栈工程师Agent与应用框架LangChain、Spring AI、自研Agent框架、工具调用应用开发工程师模型工程微调、RAG、评估集构建、模型选型算法工程师、AI工程化人员AI基础设施部署、GPU资源管理、推理加速、成本优化运维/SRE、AI Infra工程师这张地图的好处是它让每个成员都能快速定位自己“在哪个格子”。更重要的是它把AI技能从“玄学”变成了可讨论的工程能力。我记得我们团队第一次做这个地图的时候好几个人都发现自己其实已经具备了不止一格的技能只是之前从来没被定义过。2.3 找到技能之后马上做“可信度验证”有了技能地图下一步不是急着安排工作而是做“可信度验证”。因为自评这个东西很容易出现“觉得自己会”和“实际会”之间的巨大落差。我见过好几个工程师自称精通AI编程结果一上手连Context窗口爆掉的问题都搞不清楚。所以我建议在“找”的阶段就别怕麻烦把人放到一个小而真实的项目里去验证。具体操作可以是这样选一个内部的小需求比如“把每周的发布日志自动总结成一条结构化公告”让候选人自己决定怎么用AI实现限定两天时间。做完之后重点不看结果看过程——他有没有选对工具有没有做效果评估有没有处理AI输出不稳定这个核心问题如果他连“这次输出好、下次输出差”这件事都觉得无所谓那这个技能基本就是假的。反过来如果他能主动跟你聊“我加了温度参数”“我做了输出校验”那这个人大概率是真会。3. 管理AI技能本质上是管理生产和消费两条线3.1 把人员分成生产者和消费者管理策略完全不同找到人之后“管理”就是下一个大问题。很多管理者的第一反应是建一个技能清单记录谁会用AI然后定期更新。这个思路没错但太静态了。AI技能更新迭代极快今天会用某个工具明天工具就升级了今天的最佳实践下个月可能就过时了。所以管理AI技能的核心不是“登记”而是“让技能流动起来”。我比较喜欢把AI技能相关人员分成两类生产者和消费者。生产者是能搭建AI应用、写AI相关代码、调模型、部署服务的人他们创造AI能力消费者是能在自己的工作流里使用AI工具、提升效率的人他们使用AI能力。两者的管理方式完全不同。对生产者要管理他们的产出物比如代码库、Prompt模板、内部Agent、评估脚本确保这些东西是可复用的、可维护的。对消费者要管理他们的使用水平比如有没有把AI用对地方、有没有形成新的工作习惯、效率提升能否被量化。3.2 提示词和AI代码也应该像代码资产一样入库说到管理我最想强调的一个点是Prompt不是写给自己看的AI生成的代码也不是“跑通了就完事”。如果把AI技能管理当成一个工程问题来对待那Prompt和AI辅助产出的代码都应该纳入资产管理体系。具体怎么做我们在内部建了一个“AI技能库”里面分门别类存放几类东西Prompt模板比如“代码评审Prompt”“需求拆解Prompt”“测试用例生成Prompt”。每个模板都包含版本号、适用场景、参数说明、实测效果截图。AI Coding实践笔记记录某个复杂的AI编程问题是怎么解决的。比如“当生成代码出现幻觉调用不存在的API时通过添加Fake API定义让代码生成更稳定”这类经验。可复用脚本比如批量清洗数据、自动跑评估集的脚本全部放到统一的Git仓库里。踩坑记录比如“某个模型在长文本场景下会漏掉中间内容需要改成滑动窗口分段调用”。这个技能库的作用是让个人经验变成组织资产。哪怕当初写这个Prompt的人离职了后来者翻一下历史记录也能快速上手。这也是“管理AI技能”和“统计谁会AI”之间最大的区别——前者沉淀资产后者只是做台账。3.3 用“技能矩阵项目实践”双维度做动态评估当然光有资产库还不够还得有动态评估机制。很多团队喜欢半年做一次技能评估但我觉得AI领域的节奏半年太久了一个季度一次比较合理。评估维度也不建议只看“你会不会某个工具”而应该结合项目实践来打。这里分享一个我们用过的评估方式叫做“技能矩阵项目实践”双维度打分。技能矩阵就是前面提到的技能地图按熟练度分四级了解、会用、熟练、精通。项目实践则是看这个人在真实项目里用AI产出了什么、解决了什么问题、有没有沉淀出可复用的资产。评分的时候每个维度各占50%。举个例子一个人能滔滔不绝讲RAG原理可以打“熟练”但如果他项目实践中连一个正经的RAG demo都没做过那项目实践分就是0。反过来一个人可能说不清楚太多理论但他把一个内部知识库问答系统真正部署上线了那后者显然更有价值。这套评估方式不一定适合所有团队但它提供了一个思路管理AI技能不能停留在“知道”必须落到“做到”。4. 从个人技能到团队能力关键在于工程化沉淀4.1 为什么个人会用AI不等于团队有AI能力聊完了“找”和“管”第三个问题自然跳出来了就算团队里每个人都用AI这个团队就算有AI能力了吗我的答案是不算。因为个人技能如果没有变成团队可以复用的流程、工具、规范那它在组织层面就是隐性的一遇到人员变动就会断档。这也是为什么很多大厂在提AI工程实践、AI Infra这些概念——它们的重心不是“让人学会AI”而是“把AI能力变成基础设施”。举个很简单的例子。一个工程师可以用Cursor在一天内写好一个数据清洗脚本效率确实高但如果没有沉淀出“如何安全地让AI生成数据处理代码”的规范下一次另一个工程师又得从零摸索甚至在AI生成代码时踩中数据泄露的坑。所以个人用AI提效是好事但如果它不能沉淀为团队的规范、流程和可复用资产那团队的整体AI能力依然是很脆弱的。4.2 AI编程、Agent、模型部署怎么沉淀成团队能力从我的实践经验来看工程化沉淀有几个关键抓手对应到大家一起用的AI工具上尤其重要。第一个抓手是AI编程规范化。团队统一选择1-2个AI编程工具我们尝试过Copilot、Cursor、通义灵码等定义清楚哪些场景适合让AI写代码、哪些场景必须人工写并且要求AI生成的代码必须经过代码评审、必须有测试覆盖。这个规范听起来简单但能做到的团队真不多。很多时候工程师在用AI生成了代码之后自己都不仔细看就提交了这种代码入库短期看不出问题长期就是技术债。第二个抓手是Agent框架的统一。现在做AI应用开发绕不开Agent市面上的框架种类繁多有LangChain、Spring AI也有团队自研。我建议不要在项目里随意引入多种框架而是选定一个并在团队内形成最佳实践。我们团队在Java栈里用的比较多的是Spring AI Alibaba它在与现有微服务体系的整合上做得比较顺尤其适合有大量已有Spring Boot服务的团队。框架统一之后才能把工具调用、上下文管理、记忆机制这些经验沉淀成可复用的模块。第三个抓手是模型部署的标准化。做AI应用的人通常不会只调用云厂商API很多时候需要私有化部署开源模型。这时候就涉及模型部署的技术选型——用vLLM还是TGI用GPU还是CPU怎么做量化模型服务如何与现有监控体系打通如果每个人部署一次模型都从零开始效率会很低。更好的做法是把部署流程脚本化、模板化做成一个内部工具让使用者填几个参数就能拉起一个模型服务。这三个抓手对应了从开发到上线再到维护的全流程。只有在这几个环节都沉淀出团队标准AI技能才算真正“被管理起来”而不是停留在“某某很会用AI”的嘴上评价。4.3 提示词和评估集管理AI技能时最容易忽略的一环最后说一个容易被忽略的管理对象提示词和评估集。在很多团队里提示词散落在每个人的聊天记录里评估集则根本不存在。但如果你做一个AI应用没有评估集你根本不知道模型某次升级后效果是变好了还是变差了。Prompt管理也一样同一个Prompt经手多人修改后可能早就面目全非但没有人知道哪个版本效果最好。所以我强烈建议把Prompt和评估集纳入版本管理。Prompt可以放到类似Git的仓库里每次修改都走提交记录方便回溯。评估集至少要包含几十条真实场景的问题以及对应的期望答案或评分标准。每次替换模型、修改Prompt、调整参数都要跑一遍评估集用数据说话。这套机制看着麻烦但一旦跑起来你会发现团队对AI效果的讨论终于有依据了不再是“我觉得”“我试了一下”。5. 怎么搭一个AI技能管理体系的实操框架5.1 从零开始五个步骤把框架搭起来如果你准备在团队里推行AI技能管理我建议从这五个步骤开始不用一上来就做很大很全先让体系转起来再逐步完善。第一步建立AI技能地图。按我们前面提到的五类技能提示工程、AI编程、Agent与应用框架、模型工程、AI基础设施做一张表让每个成员自己勾选当前能力和目标能力。第二步定义关键角色。每个技能类别找1-2个人作为“技能Owner”他们负责梳理该领域的最佳实践、答疑解惑、维护资产文档。第三步建立资产沉淀机制。要有明确的“提交物”定义比如每个AI项目结束之后必须产出可复用的Prompt、脚本或部署模板放进技能库。第四步设定评估与反馈循环。每个季度做一次技能矩阵更新结合项目实践来调整每个人的技能评级让评估结果反过来指导培训和学习方向。第五步建立透明展示面板。把技能地图、资产库、进行中的项目放在一个团队都能看到的地方让大家知道“谁在做什么”“哪些资产可以复用”。5.2 一次技能盘点会议的实操过程可能有朋友会问“你说的这套东西实际操作起来是什么感觉”我拿我们团队做过的一次技能盘点会议来举例。那一次会议我们花了大概三个小时分四个环节。第一个环节是每个成员花20分钟在技能地图上标注自己的技能熟练度和项目实践案例同时把自己常用的AI工具、常用Prompt、使用心得提前填到技能库里。第二个环节是分组展示每组5个人左右每个人花5分钟讲自己最近做的一个和AI相关的任务重点讲思路、工具、踩坑。第三个环节是交叉提问其他人可以随意提问比如“你做RAG的时候chunk_size怎么设的”“你评估过这个方法的效果吗”“如果换一个模型你的方案还能跑吗”问题越具体越能看出这个人是真懂还是假懂。第四个环节是汇总形成行动项比如发现缺“模型量化”技能就安排一个内部学习小组发现某个Prompt模板特别好用就提入技能库作为团队标准。这场会议最大的价值不是“盘清了家底”而是让团队第一次意识到原来自己身边有这么多AI技能可以调用。以前大家是在各自的角落里摸索现在可以互相借力了。5.3 常犯的五个错误基本上每个团队都会踩框架搭起来之后实际操作中还是会踩不少坑。我总结了五个最常见的错误你对照看看大概率中招。把所有希望押在招聘上忽略内部挖潜。觉得“团队没人会AI招个AI专家就好了”。实际上外部招聘成本高而且外部专家不了解你的业务。更好的策略是“内部挖潜针对性培训”双管齐下往往那个平时喜欢折腾脚本的同事就是最好的AI种子选手。把AI技能等同于会聊大模型。有人觉得“能说出来Transformer三个核心机制”就是AI人才。真到了项目里方案设计能力、工程落地能力、排查问题的能力比背概念重要得多。只激励尖端人才忽略大众化普及。团队里最会用AI的永远是少数人如果只奖励这些人其他人会觉得AI跟自己无关。正确的做法是设置“普及者”角色鼓励那些愿意分享、愿意带人的人。管理和考核脱节评估完就完事。技能盘点出来之后没有后续动作大家填完表就忘了那这套体系就没有生命力。一定要把评估结果和项目分配、培训资源挂钩才能形成闭环。照搬网上的“最佳实践”。每个团队的场景、技术栈、人才结构完全不一样别人的AI技能管理方案只可参考不可照搬一定要根据自己团队的实际情况裁剪。6. 常见问题与排查技巧实录6.1 技能图谱画得挺好但团队成员不配合怎么办这个问题几乎百分之百会出现。员工不配合的原因通常不是“不愿意”而是“觉得这又是HR搞的形式主义”。破解方法有三个。第一让技能盘点直接关联实际利益。比如盘点结果可以用在项目分配上技能评级高的人可以优先选择感兴趣的项目或者在绩效评估时加分。第二降低填写成本。表格不要设计得太复杂尽量用选择题、多选框、下拉菜单别让人填一堆开放性文字。第三先做试点再全面推广。先选一个积极配合的小组跑一遍把成果案例展示出来让别人看到“填这个东西确实有用”再推广就容易多了。6.2 明明有人精通AI但项目需要时他不愿意接这也是很现实的问题。一个人AI能力强但主动参与AI项目的意愿低可能是因为当前岗位职责里没有这一项干了算额外劳动也可能是因为AI项目风险高、不确定性大容易背锅。我建议在管理机制上做一些调整在项目目标里把AI探索或AI应用单独列为一项OKR或KPI在晋升标准里明确把“AI应用能力”作为加分项对于参与AI项目的同事在时间安排上给予一定弹性避免让大家觉得“AI是额外负担”。说到底AI技能管理如果不能让有能力的人受益那这个体系本身就不可持续。6.3 技能评估结果明显失真怎么办评估失真的情况很常见尤其是自学能力强、表达能力好但不擅长干活的人容易高估而埋头苦干但话少的人容易被低估。应对方式是引入“作品评审”和“同行互评”不看自评看项目产出。如果你发现评估结果和平时观察有明显出入不要急着改分数而是去找反例和正例把评估标准细化用事实说话。比如有人自评“精通RAG”但你问他“检索到垃圾内容时怎么减轻对生成的影响”他答不上来那这个“精通”就要打问号。技能评估最忌讳的就是只看自评必须结合实操、作品、互评三方面交叉验证。6.4 工具买了、平台搭了团队就是不用怎么破AI工具落地难是个老问题。很多时候不是工具不好而是推广方式有问题。我们试过比较有效的做法是“场景化试点意见领袖带动”。先选一个高频场景比如代码评审、测试用例生成、周报汇总找两三个愿意尝鲜的人做试点把效果量化出来再在团队里分享。这里的关键是一定要让团队看到“看得见摸得着”的效率提升。比如你说“用AI写测试用例效率提升50%”不如直接放一张对比图左边是以前写测试用例的时间右边是AI辅助后的时间。人都是趋利避害的只要工具确实好用传播速度比你想的快得多。如果工具推了一段时间还是没人用那大概率不是“人不行”而是工具本身不适合或者推广场景没找准这时候要及时回头复盘而不是硬推。6.5 几个实用技巧越早知道越好最后分享几个我在实操中总结的小技巧可能对你有帮助。每季度做一次技能地图更新。AI技能迭代太快半年不更新基本就失真了。建立AI技能库时给每个Prompt和脚本都写清楚“适用边界”。不写使用条件的模板过了三个月就没人敢用了。开会时让人演示实操而不是只看PPT。现场让同事用AI解决一个临时问题比任何自评都更能反映真实水平。保留失败案例。AI项目里失败的尝试同样有价值多记录“为什么这条路走不通”比单纯的成功经验更有参考意义。7. 这条路的下一站让AI技能管理变成团队的一种习惯7.1 从一次技能普查到一套需要持续的机制说了这么多回到原点。AI技能管理这件事最难的不是开始而是持续。我自己见过太多团队刚开始搞AI技能盘点时热情满满拉表格、开会、做评估一套流程走完感觉特别充实。但过了两三个月表格吃灰了技能库没人更新了新来的同事也没人告诉他怎么使用这些资产。这就是典型的“一次性运动”。要避免这个问题最有效的办法是让AI技能管理嵌入日常工作的流程里而不是独立出来单独搞。比如项目复盘的时候加一项“这个项目里我们用到了哪些AI技能是否可沉淀”周会的时候花五分钟让一个同事分享一个AI使用技巧新人入职培训的时候把技能库和Prompt模板作为必读资料。当AI技能的分享、沉淀、复用变成一种习惯的时候你才真正完成了从“个人会用AI”到“团队长出了AI能力”的转变。7.2 缺少专职人员时怎么让这件事跑起来很多中小团队会说“我们也想搞AI技能管理但没有专职的人来做。”这个顾虑可以理解但说实话AI技能管理本身并不需要一个专职团队才能启动。我更推荐“兼职Owner轮值机制”让对AI感兴趣的同学兼任技能库管理员每季度轮换让团队里最活跃的AI用户做内部布道者不占编制、不用专门考核只要给一点激励他们就会非常乐意做。这个机制跑起来之后你会发现一个很有意思的现象真正推动AI技能管理的人不一定是你想象中那个“最懂AI的人”而常常是那个最愿意分享、懂得带动氛围的人。AI技能管理这件事本质上是知识管理在AI时代的新形态。技术会更新换代工具会不停变化但只要团队形成了“发现技能、沉淀资产、分享经验”的循环那不管AI怎么发展团队都能踩在浪头上前进。7.3 未来方向从管人到管场景、管Agent、管流程现在再回头看“How are you finding and managing AI skills?”这个问题我越来越觉得未来的答案可能跟现在不太一样。过去我们管理的是“人的技能”未来我们可能还需要管理“Agent的技能”——当每个团队里都有多个AI Agent承担不同的任务时我们怎么去评估一个Agent的表现怎么更新Agent的提示词和工具配置怎么保证Agent之间的协作不失控这些都是AI技能管理的新课题。所以我的建议是现在搭体系的时候尽量留出扩展空间别把规则定得太死。比如技能地图里预留“Agent配置与编排”这一类让团队里已经有人在用AI Agent的同事能把经验放进去。这样做的好处是当Agent的普及率进一步提升时你不需要推翻重来只需要在现有体系上做增量。在我自己看来AI技能管理的终点不是一个精美的表格也不是一套复杂的流程而是让团队里的每一个人都清楚AI工具只是杠杆真正的价值在于那些会利用杠杆解决问题的人以及把个体能力沉淀成组织能力的那套机制。