第2362篇：技术管理者的AI转型——带AI团队和传统团队的区别

适读人群：正在或即将管理AI相关团队的技术leader | 阅读时长：约14分钟 | 核心价值：AI团队管理与传统团队管理的实质差异，以及如何调整管理方式

我在2023年初带过一个五人的AI工程团队，在这之前我带过三年的业务开发团队。

那三年的管理经验，有大约一半在AI团队里没用上，或者用上了效果相反。

比如：在业务开发团队，我习惯在每个Sprint开始时把任务拆得很细，每个人的两周任务要有明确的验收标准，到期交付，然后我们进入下一个Sprint。这个方式在传统业务开发里很有效，因为任务是明确的，执行路径是清晰的。

在AI团队，我第一个Sprint这样做：让小A花两周探索一个向量检索优化方案，预期是"检索准确率提升20%"。两周后，小A告诉我他试了五种方案，没有一个达到20%，最好的是12%。

这是"交付失败"吗？按传统标准是的，但按AI项目的标准，这两周其实非常有价值——他搞清楚了哪些方向不行，为什么不行，这本身就是重要的工程成果。但如果我简单按"交付失败"来评判，小A下次就会倾向于定一个容易完成的目标，而不是真正探索有价值但不确定的方向。

管理方式不调整，AI团队会出问题。

---

AI团队管理的三个根本差异

差异一：不确定性的管理方式

传统开发团队：不确定性主要来自需求变更。一旦需求确定，实现路径通常是清晰的，工期可以比较精确地估算。

AI团队：不确定性来自技术本身——你不知道这个方案能不能达到效果目标，不知道需要迭代多少轮，甚至不确定目前的技术路线是否正确。

这意味着，传统的"确定工期→分配任务→执行→交付"模式在AI团队里会遇到困难。你需要一种适应探索性工作的管理框架。

我现在用的方法是：把AI项目分成"探索阶段"和"执行阶段"，并在这两个阶段用完全不同的管理方式。

探索阶段（通常2-4周）：目标不是交付功能，而是"回答一个技术问题"。比如"在我们的文档数据上，哪种检索策略效果最好？"。这个阶段的评估标准是"有没有得到清晰的结论"，而不是"功能做完了吗"。

执行阶段：一旦探索阶段有了清晰结论，执行阶段的管理就接近传统开发——明确的任务，明确的标准，正常的Sprint节奏。

差异二：评估和激励的方式

传统团队的绩效评估：功能按时交付？质量达标？线上故障率低？这些维度基本适用于大多数业务开发。

AI团队的绩效评估：如果只用上面的标准，会产生错误的激励。

举个例子：一个工程师花了三周，尝试了六个不同的方案，最终发现一个方案比其他的明显好，并把它落地了。这是非常有价值的工作。

但如果你的绩效标准只看"交付了多少功能"，这三周看起来"只做了一件事"，评分会偏低。工程师下次会怎么做？他会倾向于第一个方案拿来就用，哪怕不确定是不是最好的，因为这样能"交付更多"。

AI团队需要额外评估：探索是否充分、技术判断是否合理、评估是否严谨、结论是否清晰可迁移。

差异三：知识管理的重要性

传统团队的知识大量沉淀在代码里，新人读代码就能了解团队做了什么、怎么做的。

AI团队有大量重要知识不在代码里：这个prompt为什么这样写、当时评估了哪些方案、为什么选了这个向量数据库、某个参数为什么设成这个值……

如果这些不被记录，随着团队人员变动，这些知识会大量流失，导致团队反复踩同样的坑，或者走别人已经验证过不行的路。

---

AI团队特有的管理挑战

挑战一：技术判断力的参差不齐

传统开发团队，一个有经验的工程师评估另一个工程师的工作相对容易——代码逻辑对不对，架构是否合理，有没有隐患，这些判断相对客观。

AI团队，评估一个工程师的工作需要额外理解：他的评估方法是否科学，他的实验设计是否合理，他的结论是否从数据中得出。这些判断本身就需要AI工程经验。

如果技术管理者自己没有足够的AI工程背景，很容易被看起来专业的表述所误导。

我的建议是：即使你是管理角色，也要保持对核心技术的亲身了解。不需要每天写代码，但要能理解你的团队在做什么、为什么这样做、结论是否合理。

挑战二：算法工程师和应用工程师的协作

很多AI团队里有两类人：算法工程师（关注模型质量、训练、评估）和应用工程师（关注系统设计、工程质量、部署）。

这两类工程师的思维方式、工作节奏、关注点都很不一样，容易产生摩擦。

算法工程师倾向于不断优化模型效果，觉得应用工程师施加的上线时间压力会干扰他们的工作。应用工程师觉得算法工程师不关心系统稳定性，代码质量差，不考虑线上约束。

作为管理者，你需要建立桥接两类工程师的协作机制：明确的接口约定（模型交付标准）、共同参与的评审流程、以业务目标为共同语言。

挑战三：节奏的把控

AI项目的节奏不稳定。探索阶段可能进展很快，也可能连续几周没有突破。如果管理者用固定节奏的方式（比如每个Sprint必须有产出）来驱动AI团队，容易产生压力错配。

你需要区分"这个项目进展慢是因为技术本身难"还是"因为方向不对在原地打转"。前者需要的是支持和耐心，后者需要的是及时调整方向。

AI项目进展诊断框架
├── 是否在做系统的实验（有假设→有验证→有结论）?
│   ├── 是 → 进展慢可能是技术难度
│   └── 否 → 可能在无效探索，需要调整方法
├── 工程师对"为什么没进展"有没有清晰的分析?
│   ├── 是 → 理解问题，需要支持
│   └── 否 → 可能陷入迷失，需要方向指引
└── 方向本身是否经过了充分的前期验证?
    ├── 是 → 继续，给时间
    └── 否 → 重新做技术可行性分析

---

我调整过的几个具体管理做法

做法一：区分"功能会议"和"技术会议"

每周有一个技术讨论会，专门讨论技术方向、方案评估、实验结论。这个会议不讨论进度和功能。

每两周有一个和业务方的同步会，讨论进度和预期。

把这两类会议分开，让工程师在技术会议里可以坦诚讨论"这个方案不行"，而不是担心业务方听到会产生压力。

做法二：建立实验记录规范

每一个技术实验，无论结果如何，都要记录：

• 假设是什么
• 实验设计是什么
• 结果是什么
• 结论是什么（包括"这条路不通"也是有价值的结论）

这些记录沉淀为团队知识，新人加入时可以快速了解团队走过的路。

做法三：给"负面结果"发奖

这听起来有点奇怪，但我真的做过一次——团队里有个工程师花了两周验证了一个看起来很有前景的技术方案，最终确认了它在我们的场景下不适用。

我在团队里专门表扬了这件事，说清楚了这个验证的价值：它避免了整个团队在这个方向上浪费更多时间。

这个举动对团队文化有很大的影响——大家开始愿意探索不确定的方向，而不是只做最保险的事情。

---

给即将带AI团队的管理者的建议

如果你来自传统开发团队的管理背景，带AI团队最需要调整的心态是：

从"控制交付"到"管理探索"

你的工作不只是确保功能按时交付，更是确保团队在正确的方向上进行有效的探索。

从"结果导向"到"过程+结果并重"

在AI团队，好的过程（系统的实验、严谨的评估、清晰的结论）比短期的好结果更重要，因为好的过程会持续产生好的结果。

从"避免失败"到"快速验证"

允许团队快速试错，重要的是每次"失败"都有清晰的结论，而不是在不确定的状态下一直拖。

这些心态的调整，不是一天能完成的，但越早意识到，越早开始调整，就能越早带好AI团队。