团队怎么用 AI 编程？2026 协作规范落地指南

一个人用 Claude Code、Cursor 写代码，提效是立竿见影的。但同一套工具搬进 5 个人以上的团队，往往变成另一回事：PR 一次几千行没人看得动、每个人的 AI 规则文件各写各的、线上事故反而变多、月底账单没人说得清花在哪。AI 编程的团队协作问题，本质上不是工具问题，而是流程没跟着改。 这篇不讲「哪个工具好用」（那类横评满地都是），只讲团队要改哪六件事才不翻车：规范放哪、review 怎么改、提交怎么切、密钥怎么管、钱怎么算、效果怎么量。

先认清一件事：个人提效 ≠ 团队提效

这不是主观感受。Google 的 DORA 研究连续两年得出同一个略显尴尬的结论：AI 的采用确实提升了个人产出、心流体验和交付吞吐（不同口径下约 2%–18% 的吞吐提升），但同时拉低了交付稳定性——变更失败率上升、技术债增长更快。也就是说，代码写得更快了，出问题的概率也更高了，而团队规模会把这个副作用放大。

为什么放大？因为 AI 打破了几个传统研发流程默认成立的前提：

• 写代码的成本塌了，读代码的成本没变。 过去 500 行 PR 意味着作者花了两天，现在可能是 20 分钟生成的。审查侧的人力瞬间成了瓶颈。
• 「作者理解自己的代码」这个假设失效了。 AI 生成的代码作者本人也未必逐行读过，出事时排查链条比手写代码更长。
• 规范散落在每个人的本机。 张三的 .cursor/rules、李四的 CLAUDE.md、王五什么都没配，同一个仓库产出三种风格。
• 上下文不共享。 AI 只看得到当前仓库里写下来的东西，看不到你们在群里、在会上达成的口头约定。

第一步：把 AI 规范写进仓库，别写在群里

团队落地 AI 编程的第一件事，是让规范变成版本控制里的文件，而不是口头约定。主流工具现在都读仓库根目录的约定文件：AGENTS.md 是跨工具的通用格式（Codex、Cursor、Copilot、Qwen Code 等都支持），CLAUDE.md 是 Claude Code 的原生格式，Cursor 还额外支持 .cursor/rules/*.mdc。实践上最省事的做法是：主内容写在 AGENTS.md，其他工具的配置文件软链接或简短引用过去，避免一份规范维护三遍。

关键在于这个文件必须提交进仓库、跟着代码走，新人 clone 下来就自动拥有和老员工一样的 AI 行为基线。一份能用的团队规范文件大概长这样：

# AGENTS.md

## 技术栈
- Next.js 15 App Router + TypeScript strict + Tailwind v4
- 数据库 PostgreSQL / Prisma，禁止手写裸 SQL

## 命令
- 开发：`npm run dev`
- 类型检查：`npm run typecheck`（提交前必跑，比 build 快得多）
- 测试：`npm test -- --run`

## 硬性约束
- 不要新增依赖，需要新库先在 PR 描述里说明理由
- 不要修改 `prisma/migrations/` 下的历史迁移文件
- 不要碰 `src/generated/`（自动生成目录）
- 任何写操作接口必须先做鉴权校验，参考 `src/lib/auth.ts`

## 代码风格
- 组件用具名导出，不用 default export
- 错误处理不要吞异常，统一抛 `AppError`
- 注释密度对齐周边代码，不要给显而易见的代码加注释

## 提交
- 单个 PR 控制在 400 行改动以内
- AI 大幅参与的提交，在 commit message 里带上 `Assisted-by:` 标记

• 写「不要做什么」比写「要做什么」更有效。 模型的默认行为已经够好了，规范的价值在于兜住那些它猜不到的团队禁忌。
• 把命令写全。 类型检查、测试、lint 的确切命令写进去，AI 才会自己跑自检，而不是把没编译过的代码丢给你。
• 控制长度。 超过两三百行的规范文件，模型的遵守率会明显下降，且每次对话都在烧 token。把细节留给代码里的注释和示例。
• 当成代码来维护。 规范失效时改文件、走 PR，而不是在群里补一句「以后别这么写」。

第二步：改造 code review——AI 先审，人终审

既然写代码变快了、读代码没变快，review 就是必须重点改造的环节。2026 年比较成熟的做法是分层审查：机器负责「量」，人负责「险」。

1. 1第一层——静态规则兜底。 lint、类型检查、密钥扫描、依赖漏洞扫描全部塞进 CI，不通过不给人看。这层零成本、零争议，先做满。
2. 2第二层——AI 自动审查。 让 AI reviewer 在 PR 上留行内评论，专门抓空指针、边界条件、错误吞掉、并发问题这类机械性缺陷。
3. 3第三层——人类终审。 人只看 AI 和 CI 过不了的部分，以及机器根本判断不了的东西：这个抽象合不合理、这个改动会不会影响别的团队、这个方案是不是过度设计。

第二层的工具目前竞争很激烈，按噪音/精度取舍大致是这样（价格按 2026 年公开信息，均为每人每月）：

选型建议别一步到位：先挑一个在 1–2 个仓库上试跑一个月，统计一下「AI 提的意见里有多少真的被采纳」。低于三成就说明要么工具不对，要么你们的规范没喂给它。另外一个反直觉但重要的经验——不要让 AI 审查有阻断权。让它只留评论、不卡合并，否则误报会直接变成团队的怨气来源。

第三步：小批量提交，让 AI 产出可追溯

DORA 的另一半结论是：在 AI 时代，小批量交付和完善的测试这些老掉牙的基本功，反而变得更加关键。它们正是抵消 AI 带来的稳定性下滑的解药。具体到团队约定，有三条值得写死：

• 单个 PR 控制在 400 行改动以内，超了就拆。AI 让你能一次生成 3000 行，不代表应该一次合并 3000 行。
• AI 大范围参与的提交要打标记，出事时能快速定位模式。
• 生成代码必须配套测试，且测试要人过目——AI 很擅长写出「跟着实现走」的测试，实现错了测试也跟着错。

打标记不用搞复杂系统，git 的 trailer 就够了，还能直接统计：

# 提交时带上标记
git commit -m "feat: 增加导出 CSV 接口" -m "Assisted-by: Claude Code"

# 统计近三个月 AI 参与的提交占比
total=$(git log --since="3 months ago" --oneline | wc -l)
ai=$(git log --since="3 months ago" --grep="Assisted-by" --oneline | wc -l)
echo "AI 参与提交：$ai / $total"

# 出线上事故时，看这个文件里哪些改动是 AI 写的
git log --grep="Assisted-by" --oneline -- src/lib/payment.ts

第四步：划清密钥与数据边界

个人开发时把 .env 甩给 AI 看一眼没什么心理负担，团队场景下这是合规事故。落地时至少要卡住这几条：

• 配置忽略文件。 在 .gitignore 之外，给 AI 工具单独配忽略规则（Claude Code 的 permissions.deny、Cursor 的 .cursorignore），把 .env*、密钥目录、客户数据样本全部排除。
• 用企业版而不是个人版接入公司代码。 主流厂商的团队/企业档位才提供「不用于模型训练」的合同承诺，个人订阅的条款通常不一样。这条要让法务而不是工程师去确认。
• 自建网关收口。 让所有 AI 请求走公司统一网关，既能统计成本、也能在出站前做一层敏感信息脱敏，还避免每个人拿自己的私人 key 接公司仓库。
• 默认权限收紧。 别全员开自动执行模式。写文件、跑命令、发网络请求这几类权限分开配，高危命令走白名单。

第五步：算清楚席位成本这笔账

AI 编程的账单结构和传统 SaaS 不一样：既有固定席位费，又有随用量浮动的部分，很容易失控。先看主流团队方案的量级（2026 年公开定价，实际以官网为准）：

一个 10 人团队，如果编程工具 + 审查工具都上高档位，一年 10 万人民币级别的支出是很正常的。几条实测有效的降本思路：分档发席位（重度开发者上高档，偶尔用的人给基础档）；混合模型路由（日常补全、写测试、改文案这类任务切到便宜模型，只有复杂重构才用最贵的模型）；接国产模型做主力——具体配法可以看我们写过的 Claude Code 接入国产模型教程，或者干脆用 免费的国产平替 CLI 覆盖一部分人的日常需求。工具怎么选可以参考 Codex 和 Claude Code 的对比。

第六步：用对指标衡量，别数代码行数

「AI 到底有没有提效」是每个引入 AI 编程的团队都要回答的问题，而最容易踩的坑是拿代码行数、提交数、AI 生成占比当 KPI。这几个指标在 AI 时代全部失真——生成行数越多，很可能只是重复代码和技术债越多。该看的是这些：

建议在全员铺开之前先采集两周的基线数据，否则事后无法证明任何事情。另外，别只看数字——每月花二十分钟问团队三个问题：这周 AI 帮你省时间最多的是哪件事、最坑的是哪件事、你有没有因为它偷懒跳过了本该做的检查。第三个问题的答案通常最有价值。

一份可以照抄的 30 天落地清单

• 第 1 周：采集基线数据（PR 时长、变更失败率、事故恢复时长），选定 1–2 个试点仓库。
• 第 1 周：起草 AGENTS.md 并提交进试点仓库，先写 20 行就够，重点是「不要做什么」。
• 第 2 周：把 lint / 类型检查 / 密钥扫描全部接进 CI，作为第一层兜底。
• 第 2 周：在试点仓库接入一个 AI 审查工具，设为只评论不阻断。
• 第 3 周：约定 PR 400 行上限和 Assisted-by: 提交标记，开始统计采纳率。
• 第 3 周：确认企业版数据条款，配好 AI 工具的忽略规则和权限白名单。
• 第 4 周：复盘——AI 审查意见采纳率、基线指标变化、团队主观反馈。
• 第 4 周：按复盘结果调整规范文件和席位档位，再决定要不要向全团队铺开。

把这六步走完，AI 在团队里的角色才从「每个人的私人玩具」变成「团队的生产力基础设施」。真正拉开差距的从来不是谁用了更贵的模型，而是谁把规范、审查、度量这套工程习惯先建立起来了。如果你想系统性地掌握 AI 编程从写代码到交付上线的完整方法论，欢迎来 IMAI 看看我们的体系化实战课程。