AI人才管理实践笔记

简历写得很漂亮，一聊项目才发现只调过几个 Hugging Face 模型。

开场白

“千里马常有，而伯乐不常有。” 这句话放到AI人才市场上，应该改成：“AI工程师常有，但能长期留得住的很少。”

2023年刚开始搭AI团队时，我以为招人就是把JD写漂亮点，面试问几个算法题，然后给个有竞争力的薪资就完事了。半年后发现，团队里走的人比招进来的多，而且留下来的人也没几个能真正扛起项目。

这篇文章主要梳理一件事：在AI人才这个特殊的赛道上，从招聘到留人，到底哪些做法真的有用，哪些只是听起来对。

招聘：JD和简历都是骗人的

刚开始写AI工程师JD时，我把"精通深度学习"、“熟悉Transformer架构”、“有顶会论文优先"都写上了。后来发现，这种JD筛出来的要么是应届生背书，要么是海投刷题的。

真实场景是这样的：

• 有人简历上写"精通PyTorch和TensorFlow”，面试一问才知道只是调过几个现成模型
• 有人声称"熟悉RLHF"，但没实际跑过RL循环，只看过几篇论文
• 有人写着"有大模型训练经验"，实际上只是用过的API调用过GPT

后来我改了个做法：JD里不写"精通"和"熟悉"，而是写具体要干的活：

- 能从零开始训练一个百万参数的transformer模型
- 能自己实现LoRA/QLoRA微调，不是只会调库
- 能处理真实数据的清洗、预处理和标注工作
- 能独立排查CUDA OOM、梯度爆炸等训练问题

这样筛下来的简历质量反而高了很多。至少对方知道这份工作不是调调API就完事的。

面试：别只问算法题

刚开始面试时，我准备了一堆算法题和手写代码。面试了十几个人后发现，能刷题的不一定能干活。

有一次面试一个刷题很厉害的候选人，LeetCode 2000+题，现场手写反向传播也很溜。但当我让他聊一聊自己做的项目时，他说最多就是调过几个Hugging Face模型，没处理过真实业务数据。

算法题该问还得问，但光靠刷题量判断不了对方能不能在真实环境里扛住 AI 项目的复杂性。

现在的面试流程我这样设计：

1. 第一轮聊项目经历，重点问：

   • 你之前做的项目里，最难的技术问题是什么？
   • 你是怎么解决的？中间遇到什么坑？
   • 如果重来一次，你会怎么优化？

2. 第二轮给一个实际任务，比如：

   • 这是一个不平衡的分类数据集，数据量50万，你打算怎么处理？
   • 这是一个电商评论数据，要做情感分析，你怎么设计baseline？
   • 模型训练时总是OOM，你怀疑是哪里的问题？

3. 第三轮聊聊学习方式和团队协作：

   • 你最近在看什么技术方向？
   • 之前项目里遇到过什么团队冲突，你怎么解决的？
   • 你怎么看AI技术发展的？

这样的面试，筛掉了很多只会刷题的，但也错过了一些能干但不善言辞的。这是个取舍。

团队建设：不要强行技术对齐

刚组建团队时，我觉得应该有个统一的技术栈。于是规定所有人用PyTorch，推理统一用ONNX，部署统一用Kubernetes。

结果踩了好几个坑：

• 有个工程师擅长TensorFlow，强行转PyTorch后效率大跌
• ONNX导出对于某些自定义算子支持很差，浪费了很多时间
• Kubernetes部署对于小团队来说太重，运维成本比写代码还高

后来我改了思路：

• 框架不强制统一，但API层面要统一
• 推理方案按场景选，小模型就用PyTorch原生推理，大模型才上TensorRT
• 部署方案从简单开始，先Docker，有必要再上K8s

团队技术氛围比统一技术栈更重要。每周一次技术分享，鼓励大家讲自己最近踩的坑和学到的东西。这种分享比强制统一更有价值。

人才培养：光给培训没用

刚开始时，我给团队买了很多课程、组织了很多培训。但半年后发现，学过的技术要么没机会用，要么用了但没形成沉淀。

有个工程师学过RLHF，但项目里一直没用上，等真要用时已经忘得差不多了。

后来我改了个做法：

• 培训和项目直接挂钩，学完马上用上
• 鼓励大家写技术博客，把学到的沉淀下来
• 每个项目结束后复盘，把经验教训整理成文档

最有价值的是最后一个。比如有一次项目里遇到了模型精度下降的问题，复盘后我们整理了一个"模型精度检查清单"，之后项目里避免了类似问题。

培训本身不是目的，学到东西能用到项目里才是。

留人：薪资不是唯一因素

团队里有个核心工程师离职，跳槽去了竞对。聊了聊才知道，薪资不是主因——主要是在我们团队觉得技术成长慢了。

这点让我反思了很多。

AI工程师这类人才，技术成长路径大致清楚：熟悉框架 → 独立做端到端项目 → 设计方案和架构 → 带队攻坚 → 定技术方向。卡在某个阶段，人就容易想走。

我在留人上踩过的坑：

• 只给升职不给技术挑战
• 把人当工具人，不给机会主导项目
• 技术债务堆积，天天修bug没机会做新东西

后来调整了思路：

• 给每个人明确的技术成长路径，定期聊进度
• 鼓励主导项目，即使失败了也允许复盘
• 技术债务要控制在可接受范围内，不能天天修bug

薪资当然重要，但不是唯一因素。很多时候，技术成长和挑战更重要。

实踩过的坑

坑1：招了太多"全能选手"

刚开始觉得招到全才最好，算法、工程、产品都懂。结果发现这种人要么很难招，要么要价很高，要么什么都懂一点但什么都不精。

后来改了思路：团队里要有明确的分工，有人专注算法，有人专注工程，有人专注产品。当然有全才很好，但不能指望所有人都是全才。

坑2：过度依赖外部专家

有个阶段，我总想着找个行业专家来指导团队。请了几次外部专家讲课后发现，效果并不理想。

原因是：外部专家讲的内容要么太泛，要么不适合我们团队的实际情况。最后还是得自己摸索。

外部专家可以请，但别指望靠几次讲课替代自己在项目里踩坑爬出来。

坑3：技术调研时间过长

有段时间，团队花了太多时间做技术调研，模型、框架、工具都要试个遍。结果项目进度很慢，团队士气也受影响。

后来定了规矩：技术调研不能超过两周，两周后要么选方案推进，要么砍掉需求。哪怕选的方案不是最优，也比一直调研强。

一些有用的做法

做法1：给每个人"专属领域"

团队里每个人都有自己的"专属领域"，比如有人负责大模型微调，有人负责推理优化，有人负责数据处理。这个领域不是固定的，可以根据项目和个人兴趣调整。

好处是：

• 每个人都有不可替代性
• 技术深度更容易沉淀
• 团队协作效率更高

做法2：定期搞"技术对齐"

每周一次技术对齐，不讲 PPT，每个人分享这周做了什么、卡在哪、怎么解的、有什么教训。这种对齐比正式 Review 更真实、更及时。

做法3：允许"可控的失败"

团队里不是所有项目都要成功。有些探索性的项目，失败了也允许。关键是：

• 失败前要有风险评估
• 失败后要有复盘总结
• 把经验教训沉淀下来

这种"可控的失败"比按部就班做项目更有价值，因为能学到更多。

结语

AI 人才管理更像手艺，不是标准答案。每个团队情况不同，这篇只能当参考。

管理 AI 团队，技术当然重要，但理解人的需求、成长路径和职业规划往往更难——也更有价值。

版权声明: 本文首发于 指尖魔法屋-AI人才管理实践笔记（https://blog.thinkmoon.cn/post/192-ai-talent-management-recruitment-retention/） 转载或引用必须申明原指尖魔法屋来源及源地址！