最近三个月，被不同的人问了同一组问题，频率高到让我决定写这篇：
问的人里有创业公司 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 倍人效的小团队：
TL;DR → 第 1 步 → 第 2 步 → 第 3 步 → 第 4 步
看路径 搭骨架 立基线 立规矩 做验证
│ │ │ │ │
▼ ▼ ▼ ▼ ▼
为什么是 位置图 + 前四周五件事 三条工作方式 四个判定信号
5-7 人 没有谁 + + 四周节奏 规矩 + 抗熵增 + 三个度量指标
三类人 +
30 分钟面试
进入打造步骤前，先把这两件事的因果讲清楚——否则后面每一步你都会想"我能不能稍微通融一下"。
为什么是 5-7 人不是 15 人？ AI 把"一个工程师能 cover 的工作量"放大了 3-5 倍——同样的功能、同样的客户场景、同样的代码库维护，传统团队靠人海堆出来的中间层（写样板代码、跑测试、查文档、做重复 review），AI 已经默默接管了。5-7 人不是上限的妥协，是 AI 杠杆下的最优规模：再多人，沟通成本反而吃掉杠杆收益（Brooks 那条老规律 AI 时代变本加厉）。
为什么砍 prompt engineer / AI 算法 / 专职 PM？ 不是这些角色"没价值"，是这些角色会让团队结构倒退回传统形态：
砍掉这三个岗位，省下来的预算用来招更资深的全栈工程师——这才是 5-7 人能 cover 15 人活的关键。
理由讲完，进入第 1 步。
骨架包含三件事：位置图（每个人坐在哪里）、没有谁清单（先划掉传统岗位）、三类人怎么招（怎么 30 分钟面出来）。这一步做完，你的 headcount 表和 JD 就定型了。
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 一发出来就回到传统配置：
把上面这三个岗位从 headcount 里划掉、把省下的预算用来招更资深的全栈，是打造的第一步。砍掉这三个岗位，才有 5-7 人 cover 15 人活的空间。
骨架的 headcount 表定型后，下一件事是把人填进去。AI 原生团队的招聘和传统团队最大的差异：不按头衔分，按思维方式和工作姿态分。
A 类：AI 原生工程师（团队主力，3-4 人）
.claude/ 或 .cursor/ 配置，用 AI 是日常而非技能点B 类：经验型工程师，团队"压舱石"（1-2 人）
CONTEXT.mdC 类：跨界产品脑工程师（Product Eng，1 人，To B 团队必备）
3-4 个 A 类 + 1-2 个 B 类 + 1 个 C 类 + player-coach 的 Tech Lead，5-7 人骨架就齐了。
面试 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 是给他们装上的杠杆——不是反过来。
新团队的前两周做不对，后面三个月都在还债。基线的最小集——这五件事必须在前两周完成：
| 项 | 必须有的东西 | 谁来做 |
|---|---|---|
| 代码仓库 | 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 输出会到处漂Week 2 建纪律
tdd / diagnose / code-review / to-prd / improve-codebase-architectureprompt-libraries.md——所有面向用户的 prompt 集中管理、版本化、有测试；定 evals——核心场景 ≥30 条黄金 case，CI 跑Week 3 跑闭环
Week 4 复盘 + 节奏化
四周下来积累的是一套"和底层 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 原生团队最不容易看见、却最值钱的红利。
骨架搭好、基线立住之后，团队会进入"会用 AI、但用法不一致"的阶段——每个人有自己的 vibe，code review 标准飘，AI 辅助测试要么没有要么混乱。这一步要做的是把"AI 默认参与每一环"从口号变成可执行的规矩。
三条规矩，每条对应工作流上的一个关键环节。注意：这一节是给打造期的"立法者"看的——细节怎么实现可以去看延伸阅读里那两篇专题；这里只列必须立下的规矩本身。
Vibe coding 是 Andrej Karpathy 2025 年初推火的姿态——脑子里有目标，把约束讲给 AI，只审查行为不审查每行代码。它在脚本、原型、explore 代码上能让生产力上 10 倍。
但打造团队的时候，必须明确写在工程规范里的是"不能用在哪"：
新人最容易踩的坑就是用 vibe coding 的姿态去写核心架构——三个月后没人能维护。这条规矩不立，团队的 AI 速度会被技术债反噬。
"让 AI review PR"听起来简单，做对很难。打造期就要把三道闸的位置定下来：
ai-review job：影响范围分析 + 反熵增视角（有没有违反 boundaries.md）+ 测试覆盖建议。这一道是 AI 真正发挥价值的地方，因为它能看到整个 codebase 的状态，而人很难特别要立一条针对 AI 生成代码的反向 review 规矩——AI 写得太流畅，问题不在"写错了"，在"过度设计"和"幻觉"：接口的复杂度是否真有这么复杂的需求？引入的库 / API 是否真存在？错误处理是否在解决真问题？
再加一条防熵增的硬性规矩：每两周一次"反熵增日"——专门做小重构，不写新功能。
这条规矩只在产品本身包含模型调用（Agent、RAG、AI Copilot）时适用。如果你做的是纯电商、SaaS、传统业务系统，跳过这条直接看第 4 步。
带模型的系统输出是非确定的。同一输入可能给三个不同输出，都"对"也都"不太对"。打造期间要立下的规矩是 eval 必须三种信号叠加：
只用 LLM-as-judge 的团队会被自我偏好偏差坑；只用规则检查的团队会漏掉语义错误；只用 embedding 的团队会被"看起来很像但其实是错的"骗过去。三种叠加，加权打分，配 5% 的人工抽检校准——这是打造期就必须写进 CI 的规矩，否则后面补特别痛。
打造完一个月之后，最容易出现的状态是"自我感觉良好"——大家都在用 AI，貌似比之前快，但究竟是不是真的 AI 原生说不清楚。这一步给一份能拿走用的自检工具。
最值钱的一句话：vibe coding、AI code review、AI 辅助测试不是工具，是工作方式。
⏬ 30 天后用这份清单自检——只要少一条，团队就不算真起来。
打造期满 30 天，对照下面四条。全部命中才能说团队真的起来了，少一条都是"AI 加强版传统团队"：
传统指标全部失效——代码行数（AI 可以无限刷）、PR 数量（一个 vibe coding 下午能开 20 个）、工时（AI 让 1 小时干完 8 小时的活）都没意义。
打造期满后跟踪这三个指标：
三个月内三项都没起来——回到第 2 步，基线一定有地方没立住。
这个问题本身就是过时的提问。你不会问"为什么要避免依赖 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 倍生产力，是结构性的代差。
关注公众号「coft」，获取更多 AI 时代的深度思考。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。