如何打造一支 AI 原生团队：5-7 人小团队的四步搭建指南

如何打造一支 AI 原生团队：5-7 人小团队的四步搭建指南

最近三个月，被不同的人问了同一组问题，频率高到让我决定写这篇：

• "你们说的 AI 原生，到底是个啥？是不是给大家配个 Cursor 就算了？"
• "你认为真正的 AI 原生团队长什么样子？"
• "我们也想搞一个 AI 原生团队，怎么搭？要招些什么人？"

问的人里有创业公司 CTO，有大厂事业部老大，也有刚组队的 Tech Lead。共同的困惑是——AI 工具人人都在用，但"团队"这一层还卡在传统结构里：照旧的招聘 JD、照旧的 OKR、照旧的周会节奏，只是每个人电脑里多了个 AI 助手。这种形态最多是"AI 加强版的传统团队"，不是 AI 原生。

先把结论摆出来：5-7 个人能 cover 过去 15 个人才能 cover 的活，不是吹牛，是 AI 原生组织的常态。但 5-7 人不是关键——关键是这个团队里没有 prompt engineer、没有 AI 算法、没有专职 PM。如果这三个岗位你都还在招人，那不管用了多少 AI 工具，你都还不是 AI 原生。

当个体生产力被 AI 放大十倍，组织如果还按"每人一个工位 + 周报 + 季度 OKR"那一套来，结果是：团队的速度还是被卡在最慢那个人那里。

AI 原生团队指的是把 AI 当水和空气、组织本身按 AI 杠杆重做过的小团队——做什么产品不重要，可以是电商、SaaS、金融系统、内部数据中台，也可以是 Agent 平台或 AI 编辑器。关键不在产品载体，在组织结构本身被 AI 改写过。AI 原生 ≠ 做 AI 产品——这是这篇文章最核心的一个澄清。

TL;DR：这是一份打造指南，不是观察笔记。四步走完，你会有一支真能跑出 3 倍人效的小团队：

1. 第 1 步：搭骨架 —— 位置图 + "没有谁"清单 + 招到三类对的人，怎么 30 分钟面出来
2. 第 2 步：立基线 —— 第一个月四周必须落地的五件事，错过就还债
3. 第 3 步：立规矩 —— 把 AI 写进每一环工作方式：vibe coding、三道闸 review、AI 辅助测试
4. 第 4 步：做验证 —— 四个判定信号 + 三个度量指标，验证团队真的起来了

        TL;DR     →   第 1 步       →   第 2 步       →   第 3 步       →   第 4 步
       看路径          搭骨架            立基线            立规矩            做验证
          │              │                 │                 │                 │
          ▼              ▼                 ▼                 ▼                 ▼
       为什么是        位置图 +         前四周五件事       三条工作方式      四个判定信号
       5-7 人          没有谁 +         + 四周节奏        规矩 + 抗熵增     + 三个度量指标
                       三类人 +
                       30 分钟面试

---

为什么是 5-7 人、为什么砍这三个岗位

进入打造步骤前，先把这两件事的因果讲清楚——否则后面每一步你都会想"我能不能稍微通融一下"。

为什么是 5-7 人不是 15 人？ AI 把"一个工程师能 cover 的工作量"放大了 3-5 倍——同样的功能、同样的客户场景、同样的代码库维护，传统团队靠人海堆出来的中间层（写样板代码、跑测试、查文档、做重复 review），AI 已经默默接管了。5-7 人不是上限的妥协，是 AI 杠杆下的最优规模：再多人，沟通成本反而吃掉杠杆收益（Brooks 那条老规律 AI 时代变本加厉）。

为什么砍 prompt engineer / AI 算法 / 专职 PM？ 不是这些角色"没价值"，是这些角色会让团队结构倒退回传统形态：

• 专设 prompt engineer → 团队产生 "prompt 是某个人的事"的幻觉，其他人不练这个基本功
• 招 AI 算法 → 应用层团队会自动把"模型不行"当兜底借口，而真问题往往在 eval、RAG、上下文工程
• 留专职 PM → 信息要在 PM ↔ 工程师之间多转一手，AI 让工程师直接读客户场景已经成为可能，多一层转译就多一层失真

砍掉这三个岗位，省下来的预算用来招更资深的全栈工程师——这才是 5-7 人能 cover 15 人活的关键。

理由讲完，进入第 1 步。

---

第 1 步：搭骨架——位置图、没有谁、招到三类对的人

骨架包含三件事：位置图（每个人坐在哪里）、没有谁清单（先划掉传统岗位）、三类人怎么招（怎么 30 分钟面出来）。这一步做完，你的 headcount 表和 JD 就定型了。

位置图：一个 player-coach + 三条工程线 + AI 助理矩阵

AI 原生小团队的位置图，长这样：

                  ┌──────────────────┐
                  │  Tech Lead       │
                  │  player-coach    │
                  └────────┬─────────┘
                           │
        ┌──────────────────┼──────────────────┐
        ▼                  ▼                  ▼
   Core Engineering    Platform / SRE     Product Eng
   (2 人)              (1 人)             (1-2 人)
   - 核心业务逻辑       - Observability    - 客户场景
   - 关键抽象           - CI/CD            - 评测集
   - AI 集成（如需）     - Cost / Quota     - 业务对接

                  ┌──────────────────┐
                  │  AI 助理矩阵       │
                  │ (每人 2-3 个 skill)│
                  └──────────────────┘

Core Engineering 这条线随产品形态伸缩：产品重 AI（Agent 平台、RAG 应用），它偏向 prompt / RAG / 模型集成；产品不重 AI（电商后台、SaaS 仪表盘），它就是普通核心业务工程。变的是产品，不变的是团队的工作方式。

Tech Lead 必须是 player-coach——自己亲手写关键路径（核心业务模块、关键抽象、和 AI 协作的姿态示范），同时 review 团队代码。只会管理、不会写代码的 Lead 在这种结构里会很快失去判断力。

比"有谁"更重要的是"没有谁"

这部分最能区分 AI 原生团队和"传统团队 + AI"，也是你招聘启动前必须先想清楚的——否则 JD 一发出来就回到传统配置：

1. 没有专门的"prompt engineer"——这个角色在 2026 年快速贬值。Prompt 不是某个人的专长，是每个工程师的基本功，就像写 SQL 一样。专设这个岗位会让团队产生"prompt 是某个人的事"的幻觉
2. 没有专门的"AI 算法"——即使产品里有 AI 模块，应用层也不需要训模型的人。需要的是会读论文、会设计 eval、会做 prompt + RAG 优化的全栈工程师；产品里完全没 AI 模块，更不用说
3. 没有专职的项目经理——PM 工作分散在 Tech Lead 和 Product Eng 身上。传递信息的人越少，决策越快。Product Eng 是工程师身份的产品脑，能直接和客户聊、能从场景反推架构

把上面这三个岗位从 headcount 里划掉、把省下的预算用来招更资深的全栈，是打造的第一步。砍掉这三个岗位，才有 5-7 人 cover 15 人活的空间。

招到对的人：三类要的，一类不要的

骨架的 headcount 表定型后，下一件事是把人填进去。AI 原生团队的招聘和传统团队最大的差异：不按头衔分，按思维方式和工作姿态分。

要的三类人

A 类：AI 原生工程师（团队主力，3-4 人）

• 已经有自己的 .claude/ 或 .cursor/ 配置，用 AI 是日常而非技能点
• 和 AI 的协作姿态稳定——知道什么时候让 AI 主导、什么时候自己接管
• 角色：承担核心业务模块、关键抽象、产品里 AI 模块的集成（如有）

B 类：经验型工程师，团队"压舱石"（1-2 人）

• 工程纪律深、AI 用得不多但不抗拒
• 价值在"沉淀"——把团队里漂着的隐性纪律写成 skill 文档、review checklist、CONTEXT.md
• 角色：基线建设、Platform / SRE、评审兜底——防止团队"被 AI 跑歪"的那道闸

C 类：跨界产品脑工程师（Product Eng，1 人，To B 团队必备）

• 能直接和客户聊、能从场景反推架构
• 拿到模糊需求第一反应不是"我会做"，而是"我会先问这三个问题"
• 角色：客户场景、评测集、业务对接——连接"代码"和"真实业务"

3-4 个 A 类 + 1-2 个 B 类 + 1 个 C 类 + player-coach 的 Tech Lead，5-7 人骨架就齐了。

怎么 30 分钟面出来：三个动作

面试 AI 原生团队最容易踩的坑——问"你用过哪些 AI 工具"。这种问题任何人都能背答案。真正的辨别方法是让候选人当面打开他的工作环境：

候选人类别	动作	通过的信号
A 类	让他打开自己的 .claude/ 或 .cursor/ 目录，讲讲为什么这样配	能说出 2-3 个 skill / 规则文件的设计理由；能举出"上次我让 AI 改这个，它写歪了，我后来怎么修的"具体例子
B 类	让他聊一段他写过的 review checklist 或团队规范	不是套话，能讲清楚"为什么是这条规则、它解决了什么具体的坑"
C 类	给他一个一句话的模糊需求（例如"客户想要更智能的推荐"），让他展开	第一反应是反问而不是给方案；能拆出 3-5 个待澄清的问题

简历看 GitHub / .claude 目录，比看"AI 经验 X 年"靠谱十倍。

不要的一类人

自称 "prompt expert" 但写不出生产级代码的人——能讲一堆 prompt 技巧，但你让他写一个带重试、限流、trace 的 LLM 调用封装，他写不出来。这种角色在 2026 年是负资产，会让团队产生"AI 是魔法"的错觉，破坏工程纪律。

面试 30 分钟内就能识别：让他打开 IDE 现场写一个最简单的、带错误处理的 LLM 调用——能不能写出来，一目了然。

收拢一句：AI 原生团队要的是有真实工程纪律的人，AI 是给他们装上的杠杆——不是反过来。

---

第 2 步：立住第一个月基线——前四周必须落地的五件事

新团队的前两周做不对，后面三个月都在还债。基线的最小集——这五件事必须在前两周完成：

项	必须有的东西	谁来做
代码仓库	AGENTS.md + CONTEXT.md + docs/ 骨架	Lead 亲自写
工作流	单一 AI 工具 + 统一 skill 集 + 定期 sync 节奏	Lead 拍板
Review 标准	code review checklist + AI 生成代码额外检查项	Lead + 1 senior
测试基线	通用：单元/集成测试 + CI；产品含模型调用再加：黄金测试集 + eval CI	Platform Eng
观测	通用：metrics + log + dashboard；含模型调用再加：trace + cost dashboard	Platform Eng

把它们展开成一个月的节奏：

Week 1 搭骨架

• 写三份核心文档（AGENTS.md / CONTEXT.md / docs/）——这是 AI 助手的"工作上下文"，没有这套，全员的 AI 输出会到处漂
• 统一 AI 工具——不讨论"哪个工具好"，是定下来"我们用哪个"，给所有人 30 天适应期
• 搭起最小可用的观测——通用团队是 metrics + log + dashboard；如果产品本身含模型调用（Agent / RAG / Copilot），再加一层 trace + cost——没有这套别动核心 AI 模块

Week 2 建纪律

• 引入 5 个核心 skill：tdd / diagnose / code-review / to-prd / improve-codebase-architecture
• 如果产品里有 AI 模块：写第一份 prompt-libraries.md——所有面向用户的 prompt 集中管理、版本化、有测试；定 evals——核心场景 ≥30 条黄金 case，CI 跑
• 如果产品里没 AI 模块：把这一项换成"AI 辅助开发的 review checklist"——管的是"AI 写的代码怎么进库"，不是"模型输出怎么测"

Week 3 跑闭环

• 选一个真实客户场景，端到端跑通——从需求拆解 → 架构 → 编码 → 评测 → 部署
• 这一周的目标不是"做完功能"，是把流程跑通一次，让团队建立肌肉记忆
• 跑完一次之后，每个人才真正理解上面那些文档为什么存在

Week 4 复盘 + 节奏化

• 第一次"AI 原生回顾"——这一个月哪些环节 AI 帮上了忙、哪些反而拖后腿
• 定下后面三个月的研发节奏：双周 sprint、每周一次 zoom-out、每月一次 build vs. buy 复审

四周下来积累的是一套"和底层 AI 能力升级正交"的复利资产——无论你换 IDE / 换模型 / 换 Agent 框架，下面这些资产都不失效：

   Week 1            Week 2             Week 3              Week 4
  搭骨架            建纪律             跑闭环              复盘节奏化
     │                │                  │                    │
     ▼                ▼                  ▼                    ▼
┌─────────┐    ┌─────────────┐    ┌─────────────┐    ┌─────────────┐
│AGENTS.md│    │ 5 个核心    │    │ 端到端真实  │    │ AI 原生回顾  │
│CONTEXT  │    │ skill       │    │ 客户场景    │    │ + 三月节奏   │
│docs/    │    │ review ck   │    │ 跑通一次    │    │              │
│metrics  │    │ *prompt lib │    │             │    │              │
│ + log   │    │ *evals(30+) │    │             │    │              │
└────┬────┘    └──────┬──────┘    └──────┬──────┘    └──────┬──────┘
     │                │                  │                    │
     └────────────────┴──────────┬───────┴────────────────────┘
                                 ▼
                  ┌────────────────────────────────────┐
                  │  正交资产池（和工具/模型升级无关）  │
                  │  ├─ skill 文档                      │
                  │  ├─ review checklist                │
                  │  ├─ metrics + log + dashboard       │
                  │  └─ * 产品含模型时再加：            │
                  │       prompt 库 / eval 集 /         │
                  │       trace / cost 观测             │
                  └────────────────┬───────────────────┘
                                   │ 工具/模型升级时
                                   ▼
                  ┌──────────────────────────────┐
                  │  资产不失效，反而因为底层变强  │
                  │  而放大效用 ⇒ 复利            │
                  └──────────────────────────────┘

后面任何"我们先把功能做出来再补文档"的提议都要直接拒绝——基线立不住，技术债复利会吃掉团队。这张图的核心是右下角那个箭头：底层 AI 能力每升级一次（无论是你用的 AI 编码工具更聪明了，还是你产品里调用的模型更强了），前面四周积累的资产价值不降反升。这是 AI 原生团队最不容易看见、却最值钱的红利。

---

第 3 步：把 AI 写进每一环工作方式——三条必须立下的规矩

骨架搭好、基线立住之后，团队会进入"会用 AI、但用法不一致"的阶段——每个人有自己的 vibe，code review 标准飘，AI 辅助测试要么没有要么混乱。这一步要做的是把"AI 默认参与每一环"从口号变成可执行的规矩。

三条规矩，每条对应工作流上的一个关键环节。注意：这一节是给打造期的"立法者"看的——细节怎么实现可以去看延伸阅读里那两篇专题；这里只列必须立下的规矩本身。

规矩 1：Vibe coding 的边界——能用在哪、不能用在哪

Vibe coding 是 Andrej Karpathy 2025 年初推火的姿态——脑子里有目标，把约束讲给 AI，只审查行为不审查每行代码。它在脚本、原型、explore 代码上能让生产力上 10 倍。

但打造团队的时候，必须明确写在工程规范里的是"不能用在哪"：

• 核心架构层（关键抽象、流程编排、权限控制）
• 安全敏感路径
• 数据库 schema 变更
• 任何"改错了不知道怎么改回来"的场景

新人最容易踩的坑就是用 vibe coding 的姿态去写核心架构——三个月后没人能维护。这条规矩不立，团队的 AI 速度会被技术债反噬。

规矩 2：AI code review 三道闸——AI 处理 80% 机械活，人专注 20% 判断

"让 AI review PR"听起来简单，做对很难。打造期就要把三道闸的位置定下来：

1. Pre-commit hook：AI 标出 obvious smell（命名、复杂度、magic number）。让 AI 处理 80% 的机械问题，不再让 senior 在 PR 里指出"这里命名不好"
2. CI 流水线 ai-review job：影响范围分析 + 反熵增视角（有没有违反 boundaries.md）+ 测试覆盖建议。这一道是 AI 真正发挥价值的地方，因为它能看到整个 codebase 的状态，而人很难
3. 人工 review：只看设计和边界——这个抽象对吗、和现有模块关系是否清晰、三个月后会怎么改

特别要立一条针对 AI 生成代码的反向 review 规矩——AI 写得太流畅，问题不在"写错了"，在"过度设计"和"幻觉"：接口的复杂度是否真有这么复杂的需求？引入的库 / API 是否真存在？错误处理是否在解决真问题？

再加一条防熵增的硬性规矩：每两周一次"反熵增日"——专门做小重构，不写新功能。

规矩 3：AI 系统测试——三种信号叠加，单一信号不可靠

这条规矩只在产品本身包含模型调用（Agent、RAG、AI Copilot）时适用。如果你做的是纯电商、SaaS、传统业务系统，跳过这条直接看第 4 步。

带模型的系统输出是非确定的。同一输入可能给三个不同输出，都"对"也都"不太对"。打造期间要立下的规矩是 eval 必须三种信号叠加：

• 规则检查——格式、必含字段、安全约束（确定的）
• LLM-as-judge——用另一个更强的模型当评判，绝不能让同一个模型自己评自己（会有自我偏好偏差）
• 嵌入相似度——和参考答案的语义距离

只用 LLM-as-judge 的团队会被自我偏好偏差坑；只用规则检查的团队会漏掉语义错误；只用 embedding 的团队会被"看起来很像但其实是错的"骗过去。三种叠加，加权打分，配 5% 的人工抽检校准——这是打造期就必须写进 CI 的规矩，否则后面补特别痛。

---

第 4 步：验证团队真的起来了——一份自检清单

打造完一个月之后，最容易出现的状态是"自我感觉良好"——大家都在用 AI，貌似比之前快，但究竟是不是真的 AI 原生说不清楚。这一步给一份能拿走用的自检工具。

真信 vs. 假信：先做定性判断

最值钱的一句话：vibe coding、AI code review、AI 辅助测试不是工具，是工作方式。

• 假信：我们公司给大家配了 Cursor，所以我们是 AI 原生
• 真信：PR 流程、需求文档、测试编写、bug 排查、code review——每一环都默认有 AI 参与，没有 AI 这一环跑不通

四个判定信号：自检对照

⏬ 30 天后用这份清单自检——只要少一条，团队就不算真起来。

打造期满 30 天，对照下面四条。全部命中才能说团队真的起来了，少一条都是"AI 加强版传统团队"：

• 没有 AI，团队当天的产出会至少减半——不是"会慢一点"，是直接腰斩
• 团队的 code review、文档、测试、调试 SOP 都是和 AI 协作的产物（不是某人手写的传统 SOP）
• skills 仓库每月都在更新，过期的 skill 会被显式标记 deprecated
• 每个工程师都能拿出自己的 .claude/ 或 .cursor/ 目录，并讲清楚为什么这么配

三个度量指标：定量验证

传统指标全部失效——代码行数（AI 可以无限刷）、PR 数量（一个 vibe coding 下午能开 20 个）、工时（AI 让 1 小时干完 8 小时的活）都没意义。

打造期满后跟踪这三个指标：

1. 单工程师月活跃需求数——一个人本月真正"端到端做完并交付"了多少需求。AI 原生团队里这个数应该是传统团队的 3-5 倍
2. 缺陷逃逸率——线上发现的 bug / 总 bug 数。AI 原生团队的缺陷应该更多在开发期被 AI 辅助测试和 AI review 拦下，逃逸率应低于行业平均
3. 客户场景到上线的 lead time——从客户提需求到上线的总时间。这是最综合的指标，反映团队的端到端能力

三个月内三项都没起来——回到第 2 步，基线一定有地方没立住。

常见反问：怎么避免大家变得依赖 AI？

这个问题本身就是过时的提问。你不会问"为什么要避免依赖 IDE / 编译器 / Git"。AI 是工程师的新一层基础设施，不是要"避免依赖"的东西。打造 AI 原生团队的目标恰恰是让团队"离了 AI 跑不动"——那才证明你把 AI 真的写进了工作方式里。

---

写在最后：四步打造，三句话收拢

四步走完一遍，你手上会有一支这样的团队：骨架砍掉了三个传统岗位、三类人到位、前四周基线立住、三条规矩跑起来、四个判定信号全部命中。

三句话收拢：

结构——AI 原生团队的标志不是"用了什么 AI 工具"，是"砍掉了哪些岗位"。AI 不是给老岗位装杠杆，是让一些岗位消失。

纪律——第一个月的基线必须立住，skill 文档 / review checklist / 观测（产品含模型时再加 prompt 库 / eval 集），缺一不可。它们是工程纪律的杠杆，会随着 AI 工具和模型的升级而复利。

水和空气——vibe coding / AI code review / AI 辅助测试是日常工作方式，而不是"我们也在用 AI"的勋章。

5-7 个人 cover 一摊原本要 15 个人才能 cover 的活，不是因为他们是天才，是因为他们让 AI 默默承担了那个本来需要一倍人手才能做的中间层。这种团队和"传统团队 + AI 工具"的差距，不是 1.5 倍生产力，是结构性的代差。

---

延伸阅读

• 《AI 写代码比你快 10 倍，你还剩什么？——读 mattpocock/skills》——本文反复引用的"工程纪律的杠杆"和 L0-L5 五级模型来源
• 《多 Agent 平台怎么搭才不翻车——从砍东西开始的六步骨架》——一个具体载体的架构骨架，可以搭配本文看"团队怎么对应到代码结构"
• The Mythical Man-Month by Frederick Brooks——AI 时代再读一次，"加人会让晚期项目更晚"那句话变本加厉
• The Manager's Path by Camille Fournier——技术管理的进阶路径，player-coach 一节值得反复看
• Amazon "two-pizza team" 原则——团队规模上限来自沟通成本，AI 让沟通成本进一步压缩

---

关注公众号「coft」，获取更多 AI 时代的深度思考。