我用 AI 快了十倍，项目还是照样延期。

前面 36 篇讲的全是你一个人怎么用 AI。你确实变快了。

然后你回到团队里，发现：

• 你两小时写完的功能，等对方接口等了两天
• 你交上去的代码，Review 排队排了三天
• 新同事接手你的模块，问了你 20 个问题
• 同一个需求，产品说的、你听的、后端理解的，是三个东西

你把自己那一段跑成了高铁，可整条线还是绿皮车。

这一篇讲：AI 怎么从”个人加速器”变成”团队加速器”。

不需要你是团队负责人，一个普通成员也能从今天开始用。

一、团队为什么慢？

新手以为写代码慢是打字慢、想得慢。真到了团队里你会发现，一天八小时，真正敲代码可能只有两小时，剩下六小时花在：

AI 在”敲代码”这一段帮你省了 30%，可这一段本来就只占两小时。

想让团队真的变快，得把 AI 用到 “等、对、猜、返” 这四个字上。

个人用 AI 是提速，团队用 AI 是减少摩擦。

二、五个落脚点：接、传、审、齐、留

【接】接手别人的活

你被安排去改一个不是你写的模块。以前：翻代码 → 看不懂 → 找原作者 → 他在忙 → 明天再说。

现在：把文件整个丢给 AI，按顺序问三个问题，别一上来就问细节：

1. 这段代码整体是干什么的？用大白话，别用术语
2. 入口在哪？数据从哪进来，最后流到哪去？
3. 有哪些地方是”为了处理某个特殊情况”专门加的？

第三问是精髓。代码里那些奇怪的 if 判断，往往藏着历史坑（第74篇讲过）。

从”我看不懂能给我讲讲吗”，变成”这三处特判是为了什么”——对方回答只要 5 分钟，还觉得你靠谱。

【传】需求传递

团队最贵的错误，是理解错了方向，写完全废。源头通常是：需求是口头说的、群里零散发的、会上顺嘴提的。

开完会/聊完天，把所有零散信息扔给 AI，让它整理成一张”确认清单”，发回群里让对方确认。

四块内容，四块清单：

• 要做什么（一句话）
• 具体规则（逐条，含边界）
• 不做什么（划出范围外）
• 我不确定的点（列成问题）

最后那块是核武器。它把”我以为”提前变成了”你确认”——原本测试阶段才暴露的偏差，开完会 10 分钟就暴露了。

这一招不需要任何技术，产品、测试、运营都能用。

【审】Code Review

第80篇讲过怎么用 AI 做 Review。放到团队里，它有个新价值：

提交给同事之前，自己先让 AI 过一遍。

把低级问题（命名、边界、错误捕获、风格）在自己这一关干掉。同事拿到的是”干净的代码”，注意力就能放在真正值得讨论的地方。

Review 从 40 分钟变 10 分钟，来回打回从 3 次变 1 次——你省的是别人的时间。

用 Review 五关：正、安、错、洁、快，让 AI 分三档输出（必须改 / 建议改 / 可以不改），自己先改掉”必须改”的。

【齐】统一规范

这是团队用 AI 最大的杠杆，也是 90% 的团队没做的事。

团队里五个人都在用 AI，张三的提示词写得很好，李四一句”帮我写个登录”——合到一起五种风格，谁也看不懂谁的。

AI 让每个人都变快了，也让代码变得更不统一了。

解法很朴素：建一个团队共享的提示词库，一个共享文档就行：

【场景】写后端接口
【提示词】（可直接复制的完整内容）
【什么时候用】新增任何一个 REST 接口时
【谁维护】张三
【上次更新】2026-08

关键在于把规范”焊进”提示词里：

• 接口统一返回 {code, message, data}
• 时间格式统一
• 错误码四位数

别靠开会宣讲，写进提示词模板。

第82篇的铁律：靠自觉的规范 = 没有规范。 写进提示词的规范，复制粘贴时就自动执行了。

【留】沉淀

团队里最容易蒸发的是“为什么”：为什么用这个技术不用那个？为什么这个字段允许为空？半年后所有人都忘了，包括当初拍板的那个人。

用 AI 把”讨论”变成”记录”，成本几乎为零： 把聊天记录、会议要点丢给 AI，输出决策记录四要素：

• 选了啥
• 为什么
• 弃了啥
• 何时重评

跟代码放一起。

同理还有交接手册：把你负责的模块丢给 AI 生成”接手指南”，你再补上 AI 猜不出来的三样：

• 业务含义
• 边界规则
• 历史坑

这三样是你脑子里的，AI 打死也编不出来。

三、三条团队纪律

纪律一：保密红线白纸黑字定下来

公司代码、客户数据、内部文档，能不能贴给 AI？不同公司答案完全不同，先确认三件事：

• 公司有没有明确规定？（先去问，别自己猜）
• 有没有提供内部部署的 AI？（有的话优先用它）
• 只能用公网 AI 的话，哪些内容必须脱敏？

通用做法：把真实业务信息替换成假的，只保留结构。 “某某银行客户手机号”换成”用户联系方式”，真实数据换成 13800000000。代码逻辑 AI 照样能看懂，敏感信息一个字没出去。

回顾第20篇红线：密钥、密码、真实用户数据、未公开的商业信息——一律不贴。

纪律二：AI 写的代码，责任是提交者的

团队里迟早会出现这句话：“这段是 AI 写的，我也不知道为啥。” 必须从一开始就禁掉。

你提交的代码，就是你的代码。AI 是工具，不是同事，它不背锅。

这不是苛刻，是保护你自己。你只提交自己看懂了的代码，出问题时你能改。配套第84篇那条：AI 说”没问题”不算数，得自己验一遍。

纪律三：别让 AI 当”传话筒”

用 AI 把一句话扩写成一封长邮件发给同事，同事再用 AI 缩回一句话——中间那一大段纯属浪费两个人的时间，还可能被加进原本没有的意思。

原则：AI 用来”整理和澄清”，不用来”注水”。

四、一个五人小团队的一周

注意看：AI 出现在每一个”接缝处”，而不只是”写代码”那一格。 这就是团队用法和个人用法的分水岭。

五、新手最容易犯的三个错

错一：以为团队用 AI 是”老大的事”。 不是。你今天就能做的三件事：

• 自己先 Review 一遍再提交
• 开完会整理一份确认清单发群里
• 把自己调好的提示词分享出来

一个人做，整条线就顺一点。

错二：把 AI 当成”不用沟通”的理由。 恰恰相反——AI 帮你搞定”能自己搞定的部分”，是为了让你把沟通时间用在真正需要人的地方：意图、权衡、历史原因。这三样，只有人知道。

错三：提示词库建了但没人维护。 就一条：每个模板必须有”谁维护”和”上次更新”。 没人认领的模板说明没人用，直接删掉。

提示词模板盒子

模板一：接手陌生代码（快速上手）

你是一位擅长带新人的资深工程师。

下面是我刚接手的一个模块的代码，我完全没参与过它的开发。

【代码】
（把完整文件粘贴在这里，多个文件就都贴上）

请按顺序回答三个问题，全部用大白话，不要用专业术语：

1. 这段代码整体是干什么的？用一段话讲清楚它的业务作用。
2. 它的入口在哪？数据从哪里进来，中间经过哪几步，最后流到哪里去？
   请画一个简单的文字流程图。
3. 有哪些地方看起来是"为了处理某个特殊情况"专门加的？
   逐条列出，标明在哪一行，并推测可能是为了应对什么问题。
   这一条最重要，请尽量找全。

最后额外给我一份"该去问原作者的问题清单"，
只列你从代码里确实推断不出来的部分，控制在 5 条以内。

模板二：会议/需求 → 确认清单

你是一位严谨的项目协调人。

下面是我们刚讨论一个需求的零散记录（可能顺序乱、有口语、有重复）：

【原始记录】
（把会议要点、群聊记录、口头转述原样粘贴，别自己先整理）

请整理成一份可以直接发回群里让对方确认的清单，包含四个部分：

一、要做什么：一句话概括，不超过 30 字。
二、具体规则：逐条列出，每条一句话，包括所有边界情况和特殊处理。
三、明确不做什么：把范围之外的事写清楚，防止后面加需求。
四、我需要确认的点：把记录里没说清、有歧义、或你推断出来但没被明说的地方，
    整理成问题，每条都要能用"是/否"或一句话回答。

要求：
- 语气客观，不要加我没说过的判断
- 第四部分尤其重要，宁可多问，不要漏问
- 用 Markdown 格式，方便我直接复制

模板三：团队提示词模板（把规范焊进去）

你是一位资深后端工程师，正在为我们团队写代码。

请严格遵守以下团队规范，优先级高于你的默认习惯：

【团队规范】
1. 接口返回统一格式：{ "code": 数字, "message": 字符串, "data": 对象或 null }
2. 成功 code 为 0，参数错误 4001，无权限 4003，资源不存在 4004，系统异常 5000
3. 时间字段统一用字符串格式 "YYYY-MM-DD HH:mm:ss"
4. 命名：变量和函数小驼峰，常量全大写下划线，文件名全小写中划线
5. 所有对外接口必须做参数校验，校验失败返回 4001 并说明是哪个参数
6. 所有可能失败的操作必须有错误处理，禁止空的 catch
7. 注释只写"为什么这么做"，不写"这行代码做了什么"

【本次任务】
（描述你要做的功能，建议按第68篇五段式：背景/目标/输入输出/约束/交付形式）

【交付要求】
- 给我完整文件，从第一行到最后一行，不要用"其余省略"
- 多个文件逐个给，每个标清楚文件名和存放路径
- 最后单独说明：我要怎么验证这段代码是对的

模板四：交接手册 / 决策记录

你是一位擅长写交接文档的技术负责人。

【场景】我要把下面这个模块交接给同事，他没参与过这块的开发。

【代码】
（粘贴模块的主要文件）

【我补充的背景】（AI 猜不出来，必须我自己写）
- 业务含义：这个模块在业务上解决什么问题、给谁用的
- 边界规则：有哪些业务上的硬性规定（比如"超过30天的订单不能退"）
- 历史坑：踩过什么坑、为什么某些地方要特殊处理、哪里改动风险最大

请生成一份接手指南，包含：
1. 模块是干什么的（一段话）
2. 代码结构：每个文件负责什么
3. 主要流程：数据怎么流转（文字流程图）
4. 对外接口清单：地址、入参、返回、错误码
5. 配置项说明：有哪些配置、分别改什么
6. 高风险区域：哪几处改动前必须找我确认，为什么
7. 常见问题：新人接手最可能踩的 3 个坑

用 Markdown，语气面向"完全没接触过这块的同事"。

下篇预告

#92《开发提效篇总复盘 + 进阶预告》

从第 55 篇的 Cursor 安装到这一篇的团队协作，模块四”开发提效专场”整整 38 篇，到下一篇收官。

我们把这 38 篇重新拼成一张图：开发九步全景图（AI 在哪一步帮你、对应哪一篇）、一套母版（为什么提示词都收敛成”五段式”）、一页铁律、一张自检表（三档水平，你现在站哪格）。

如果你前面漏看了几篇，下一篇是最好的补课索引。