跳至主要內容

AI 工程团队建设——从 0 到 10 人，我踩过的那些坑

老张2026/4/30大约 9 分钟

AI 工程团队建设——从 0 到 10 人，我踩过的那些坑

适读人群：AI 技术负责人、工程团队管理者 | 阅读时长：约 15 分钟 | 核心价值：AI 工程团队从 0 开始建设的真实经验，包含团队结构、规范建设、知识沉淀

两年前我接手一个 AI 工程团队，从 0 开始。

那时候团队只有我一个人，我既是架构师又是程序员又是产品经理。后来陆续招了人，到现在稳定在 9 个人左右。

这两年踩了不少坑。有的坑很贵，一个技术决策失误，返工了几个月。有的坑很难看，一个核心成员离职，有一块业务几乎垮掉了，因为他走的时候带走了只存在他脑子里的知识。

这篇文章不是管理理论，是我踩过的坑和从坑里爬出来之后的总结。

招什么样的人

先说招人，这是一切的基础。招错了人，后面全乱。

AI 工程团队不需要全是 AI 专家。

我见过很多人把这个搞反了——觉得 AI 团队里应该都是懂模型、会训练的人。这是误解。

AI 工程团队要解决的是工程问题，不是研究问题。绝大多数 AI 应用公司，核心工作是：

  • 把 LLM API 整合到业务系统里
  • 做 RAG、Agent 这类应用层架构
  • 保证 AI 服务的稳定性、可观测性、成本可控

这些工作，需要的是扎实的工程能力，不是 AI 研究能力。

我现在的团队构成：

  • 2 个有 AI 应用开发经验的工程师（做核心 AI 功能）
  • 3 个扎实的后端工程师（有 Java 或 Python 经验，零 AI 基础也行）
  • 1 个前端工程师
  • 1 个测试工程师
  • 1 个数据工程师
  • 1 个运维工程师

没有算法工程师，没有 ML 工程师。因为我们不训练模型，我们调用模型。

招 AI 工程师，我看的具体能力：

不是"会用 ChatGPT"，是：

  • 能把 AI 的不确定性做成可测试的行为（会写 AI 功能的测试）
  • 理解 Prompt 工程的工程化方式（Prompt 版本管理、A/B 测试）
  • 知道 AI 应用的失败模式（幻觉、上下文窗口、Token 成本）
  • 有过生产环境 AI 应用的经历（不只是 Demo）

面试的时候我会让候选人设计一个简单的 RAG 系统并描述它的失败场景。不会设计系统的人一问就露馅，因为他们只说"AI 会自动搞定"，没有工程意识。

招普通后端工程师，我看的是学习能力，不是 AI 经验。

一个有 5 年 Java 经验、学习能力强的工程师，三个月后能成为团队里很重要的 AI 工程师。但一个 AI 基础知识丰富、工程能力差的人，可能永远是麻烦制造者。

前三个月：不要急着建规范

很多人一组建团队就急着建各种规范：代码规范、PR 规范、文档规范……这是个错误。

前三个月，唯一重要的事情是：出活，并且在出活的过程中发现真正的问题。

规范要从真实的痛点里提炼，不是凭空制定。在你实际遇到问题之前制定的规范，很可能约束了有用的东西，但没约束到真正需要约束的。

我前三个月做的事情：

  • 建一个基础的代码仓库结构（目录规范、Linter 配置）
  • 写第一版 README（让别人能把项目跑起来）
  • 建 CI/CD 流水线（代码合并自动测试、自动部署）

就这三件事，其他的等三个月后再说。

最重要的规范：AI 功能的测试规范

等到第三个月之后，我开始建规范，但重点放在一个地方：AI 功能怎么测试。

这是 AI 工程团队最核心的工程挑战，也是和普通后端团队最不一样的地方。

AI 功能的特点：输出不确定，你没办法用 assertEqual 来测试。但"没法精确测试"不等于"不用测试"。

我们建立的 AI 测试分层：

Level 1：确定性测试
  - 格式测试：AI 输出的 JSON 格式是否符合 Schema
  - 边界测试：输入为空/超长/乱码时不崩溃
  - 路由测试：不同类型的输入是否路由到正确的处理逻辑
  
Level 2：统计性测试
  - 准确率测试：对于一批固定测试用例，准确率是否超过阈值（如 85%）
  - 用来做版本回归，Prompt 更新后准确率不能下降超过 5%

Level 3：人工评估
  - 对于无法自动化的质量评估，建立人工评估流程
  - 每次大的 Prompt 变更或模型版本升级前执行

代码结构：

# tests/ai/test_intent_recognition.py

import pytest
from src.ai.intent import IntentRecognizer

# Level 1：确定性测试
class TestIntentRecognizerFormat:
    def test_output_format(self, recognizer):
        result = recognizer.recognize("我要退款")
        assert "intent" in result
        assert "confidence" in result
        assert isinstance(result["confidence"], float)
        assert 0 <= result["confidence"] <= 1

    def test_empty_input_returns_other(self, recognizer):
        result = recognizer.recognize("")
        assert result["intent"] == "other"

    def test_very_long_input_does_not_crash(self, recognizer):
        long_input = "a" * 10000
        result = recognizer.recognize(long_input)
        assert result is not None

# Level 2：统计性测试
class TestIntentRecognizerAccuracy:
    TEST_CASES = [
        ("我的订单到哪里了", "order_tracking"),
        ("我要退款", "refund"),
        ("产品坏了", "complaint"),
        # ... 共 100 个测试用例
    ]

    def test_accuracy_above_threshold(self, recognizer):
        correct = sum(
            1 for input_text, expected in self.TEST_CASES
            if recognizer.recognize(input_text)["intent"] == expected
        )
        accuracy = correct / len(self.TEST_CASES)
        # 准确率低于 85% 则测试失败
        assert accuracy >= 0.85, f"Accuracy {accuracy:.1%} below threshold 85%"

这套测试体系，让我们能在每次 Prompt 变更或模型版本升级时，快速知道效果是否退化。

最大的坑：知识孤岛

这是让我损失最惨的一个坑。

有一个团队成员，他一个人负责了 RAG 系统的核心逻辑——向量化策略、检索参数、重排序逻辑。这些东西运行了一年多，效果不错，但文档几乎为零，逻辑全在他脑子里。

他离职的时候，我们花了将近两个月时间，才大概搞清楚这个系统是怎么工作的。这两个月里，这个系统基本上处于"能运行但不敢动"的状态。

解决知识孤岛的方法，我后来用了几个：

方法一：ADR（Architecture Decision Record，架构决策记录）

每一个重要的技术决策，必须有一个 ADR 文件记录。格式很简单：

# ADR-012：向量检索使用 MMR 而不是纯相似度排序

## 状态：已采纳（2024-06-15）

## 背景
我们发现纯余弦相似度检索返回的文档经常高度重复
（同一个文档的不同 chunk），导致 LLM 生成的回答缺乏多样性。

## 决策
使用 Maximum Marginal Relevance (MMR) 算法，
在相关性和多样性之间做平衡。

参数：lambda=0.5，top_k=20 候选中取 5 个结果。

## 理由
对比实验（见 notebooks/experiments/mmr_vs_cosine_eval.ipynb）
显示 MMR 在我们的测试集上 RAGAS 分数提升了 12%。

## 权衡
MMR 计算成本比纯相似度高约 30%，但考虑到质量提升，可以接受。

## 后续
如果未来向量库切换为 Milvus，需要确认 Milvus 的 MMR 实现是否兼容。

ADR 不需要写得很长，一两页就够。关键是记录"为什么"，而不只是"是什么"。

方法二：强制结对

AI 系统的核心模块，不允许只有一个人了解。强制结对工作或者定期代码 walk-through。

方法三：Runbook

每一个生产环境的 AI 服务，必须有一个 Runbook：这个服务是干什么的、怎么启动、怎么重启、常见故障怎么排查、监控看哪些指标。

不是让人写完整的技术文档，是让接手的人在半小时内能搞清楚"这是什么、挂了怎么办"。

AI 功能的工程规范

除了测试和文档，还有几条规范是血泪教训：

规范一：Prompt 必须版本化

Prompt 改了，效果变了，要能回滚。我们把 Prompt 存在数据库里，有版本号，有 A/B 测试记录。

# Prompt 不能硬编码在代码里
# 错误方式：
PROMPT = "你是一个客服助手..."

# 正确方式：从配置/数据库读取，支持热更新
prompt = prompt_store.get("customer_service_v3.2")

规范二：所有 AI 调用必须有超时和降级

# 所有 AI 调用必须设置超时
with timeout(seconds=30):
    result = llm_client.call(prompt)

# 必须有降级策略
if result is None:
    result = fallback_handler.handle(user_input)

规范三：Token 消耗必须可见

每次 AI 调用消耗了多少 Token，必须记录下来，能按业务、按用户维度统计。不可见的成本，是失控成本的开始。

团队文化：对 AI 的不确定性保持诚实

AI 系统有一个普通系统没有的特质：输出不确定。这个不确定性如果团队内部不坦诚面对，会出很大问题。

我见过一些 AI 团队，为了让 Demo 好看，在 Prompt 里加了各种 "magic"，让演示用例跑得很完美，但生产环境里遇到真实用户的各种输入，就完全不一样了。

我在团队里明确说的一条原则是：对 AI 功能的效果，要诚实汇报，不要美化。

演示失败的用例比展示成功的用例更有价值，因为它说明了系统的边界。如果你只给老板看成功用例，你会发现 Demo 很完美，但上线之后被用户骂。

10 人以内不需要复杂的组织结构

最后说一个常见的错误：团队还没到 10 人，就开始搞复杂的小组划分、汇报层级。

10 人以内，扁平就好。我现在的团队：直接汇报给我，周会同步进展，有问题直接沟通。没有中间层，没有"小组负责人"这种虚设的角色。

等团队到 15-20 人，再考虑分组。

说到底，AI 工程团队建设和普通工程团队没有本质区别，核心都是：招对的人、建对的规范、留住关键知识、让团队可持续运转。

AI 带来的额外挑战是：功能不确定、技术迭代快、基础设施不成熟。但这些都是工程问题，不是管理魔法能解决的，还是得一件一件做扎实。

编辑此页
最近更新:
贡献者: xiaozhangge