前言
前面八篇文章解决了"个人怎么用 AI"的问题——写 PRD、做设计、写 Prompt、选工具、避坑。
但个人用得好不等于团队用得好。你可能已经体验到了 AI 的效率提升，但回头看团队：有人还没开始用，有人用了但方法不对，有人担心代码质量，有人质疑安全合规。
这篇文章解决"怎么让整个团队用起来"的问题。面向 Tech Lead、工程经理和任何需要推动 AI 落地的人。
一、团队落地的三个阶段
阶段一：试点 阶段二：规范化 阶段三：规模化
1-2 人试用 → 建立流程和规范 → 全团队推广
2-4 周 4-8 周 持续迭代
大多数团队失败在直接跳到阶段三——买了工具、发了通知、然后发现没人用。正确的路径是从小处开始，积累经验，再逐步扩展。
二、阶段一：找到 Champion 并试点
选对第一批人
不要强制全员使用。找 1-2 个满足以下条件的人：
- 对 AI 有兴趣：主动尝试过 ChatGPT 或 Copilot
- 有影响力：团队里其他人会参考他的做法
- 愿意分享：会把经验写下来或在团队会上讲
这些人就是你的 Champion。他们的成功案例是后续推广的最好素材。
选对试点场景
不要从最复杂的场景开始。推荐的试点顺序：
- 代码补全（Copilot）：最低门槛，不改变工作流，立刻见效
- 单元测试生成：效果明显，风险低（测试代码不上生产）
- 文档生成（PRD、技术方案）：节省时间最多的环节
- 代码生成（新功能）：效果最大，但需要更多经验
记录数据
从试点第一天就开始记录：
| 任务 | 传统耗时 | AI 辅助耗时 | 节省时间 | 质量评估 |
|------|---------|-----------|---------|---------|
| 写单元测试（UserService） | 2 小时 | 30 分钟 | 75% | 覆盖率相当，补充了 3 个边界用例 |
| PRD 初稿（通知模块） | 1 天 | 2 小时 | 75% | 需要 1 小时人工修改 |
| 新增 API 接口（5 个） | 3 天 | 1 天 | 67% | 代码质量需要 review 调整 |
这些数据是说服管理层和团队的关键。
三、阶段二：建立规范
试点成功后，在推广之前先建立规范。没有规范的推广会导致混乱。
1. Prompt 模板库
为什么需要：每个人自己摸索 Prompt 效率太低。好的 Prompt 应该像代码一样被复用。
怎么建：
项目根目录/
├── .prompts/ # Prompt 模板库
│ ├── README.md # 使用说明
│ ├── code-review.md # 代码审查模板
│ ├── unit-test.md # 单元测试生成模板
│ ├── api-doc.md # API 文档模板
│ ├── tech-spec.md # 技术方案模板
│ └── bug-analysis.md # Bug 分析模板
├── CLAUDE.md # Claude Code 项目规范
└── .cursorrules # Cursor 项目规范
模板示例（代码审查）：
# 代码审查 Prompt
## 使用方法
将以下 Prompt 和待审查的代码一起发送给 AI。
## Prompt
你是一位高级 [语言] 工程师。请审查以下代码变更：
### 必查项
- 逻辑正确性
- 错误处理
- 安全性（注入、XSS、权限）
### 输出格式
- 🔴 必须修复：[问题 + 修复建议]
- 🟡 建议修复：[问题 + 修复建议]
- 🟢 可选优化：[建议]
## 注意事项
- 此模板适用于业务代码审查，不适用于基础设施代码
- AI 的审查不能替代人工 review，作为补充使用管理方式：
- 放在代码仓库中，用 Git 管理版本
- 指定 1-2 个人负责维护
- 每月 review 一次，删除没人用的、优化效果不好的
- 鼓励团队成员提交新模板（像提交代码一样 PR）
2. AI 代码的 Review 流程
AI 生成的代码和人写的代码一样需要 review，但关注点不同。
AI 代码 Review 检查清单：
□ 安全性
- 是否有 SQL 注入、XSS 风险
- 密钥是否硬编码
- 权限检查是否完整
□ 一致性
- 是否遵循项目代码规范（命名、模块系统、格式）
- 是否与现有架构一致（ORM、错误处理模式、日志格式）
- import 的包是否都在 package.json 中
□ 正确性
- 业务逻辑是否正确（不只是"能跑"）
- 边界情况是否处理
- 错误处理是否合理
□ 可维护性
- 代码是否可读（不是 AI 风格的过度抽象）
- 是否有不必要的复杂度
- 后续修改是否方便
□ 测试
- 测试是否覆盖业务行为（不只是实现细节）
- 边界用例是否覆盖
流程建议：
开发者用 AI 生成代码
↓
开发者自己先 review（用上面的检查清单）
↓
提交 PR，标注哪些代码是 AI 生成的
↓
Reviewer 重点关注 AI 生成的部分
↓
合并
关键原则：提交 AI 生成代码的人对代码质量负责，不是 AI 负责。
3. CLAUDE.md / .cursorrules 规范
这是团队 AI 使用的"宪法"——定义了 AI 在这个项目中应该遵循的规则。
CLAUDE.md 模板：
# 项目规范
## 技术栈
- 语言：TypeScript 5.x
- 框架：Next.js 16（App Router）
- 数据库：PostgreSQL + Prisma ORM
- 测试：Vitest + Testing Library
## 代码规范
- 使用 ESM（import/export），不使用 CommonJS
- 命名：变量和函数用 camelCase，类型用 PascalCase
- 文件命名：kebab-case
- 每个函数不超过 50 行
## 安全要求
- 所有数据库查询使用 Prisma（自动参数化）
- 密钥从环境变量读取，不硬编码
- 每个 API 接口必须有权限检查
- 用户输入必须验证（使用 zod）
## 测试要求
- 新功能必须有单元测试
- 测试覆盖业务行为，不测试实现细节
- Mock 外部依赖，不 mock 内部模块
## 禁止事项
- 不要引入新的依赖库（需要时先讨论）
- 不要修改数据库 migration 文件
- 不要在代码中添加 TODO 注释（用 issue 跟踪）把这个文件提交到代码仓库，所有使用 Claude Code 的团队成员都会自动遵循这些规范。
4. 安全和合规规范
数据安全：
✅ 可以发送给 AI 的：
- 开源代码
- 公开的技术文档
- 脱敏后的数据
- 通用的业务逻辑描述
❌ 不能发送给 AI 的：
- 用户个人信息（姓名、手机号、身份证）
- 数据库连接字符串、API 密钥
- 未公开的商业数据（营收、用户量）
- 客户的机密信息
合规建议：
- 确认你使用的 AI 工具的数据处理政策（是否用你的数据训练模型）
- Claude API 和 ChatGPT API 默认不使用用户数据训练——但网页版可能不同
- 如果公司有严格的数据合规要求，考虑使用 API 而非网页版
- 建立团队的 AI 使用政策文档，让每个人签字确认
知识产权：
- AI 生成的代码的版权归属目前法律上还不完全明确
- 务实的做法：把 AI 生成的代码当作"参考实现"，经过人工修改和 review 后纳入项目
- 不要直接复制 AI 生成的大段文本作为产品文档（可能有版权风险）
四、阶段三：全团队推广
推广策略
不要：发一封邮件说"从今天开始大家都用 AI"。
要：
- 内部分享会：让 Champion 分享试点经验，展示真实案例和数据
- Pair Programming：Champion 和新手结对，手把手带一个任务
- 渐进式推广：先推代码补全（最低门槛），再推测试生成，最后推代码生成
- 建立支持渠道：Slack/飞书群，遇到问题随时问
处理阻力
团队中总会有人不想用 AI。常见的阻力和应对：
"AI 写的代码质量不行"
回应：展示试点数据。强调 AI 生成的代码必须经过 review，和人写的代码一样。AI 不是替代 review，而是加速初稿生成。
"我用 AI 反而更慢"
回应：正常。学习曲线大约 1-2 周。提供 Prompt 模板库降低上手门槛。安排 Champion 结对帮助。
"担心被 AI 替代"
回应：AI 替代的是重复性工作，不是工程师。会用 AI 的工程师替代不会用的——这是技能升级，不是淘汰。强调 AI 让你有更多时间做有创造性的工作。
"数据安全有风险"
回应：展示安全合规规范。说明 API 版本不使用数据训练。如果公司有特殊要求，可以使用私有部署方案。
衡量效果
推广后需要持续衡量效果，用数据说话。
量化指标：
| 指标 | 衡量方式 | 目标 |
|---|---|---|
| 开发速度 | 功能交付周期（从开始到合并） | 缩短 20-30% |
| 代码质量 | PR review 中的问题数 | 不增加 |
| 测试覆盖率 | 自动化测试覆盖率 | 提升 10-20% |
| 开发者满意度 | 季度调研 | 正面评价 > 70% |
| 工具使用率 | 活跃用户数 / 总人数 | > 80% |
定性反馈：
- 每月收集一次团队反馈
- 记录最有价值的使用场景和最大的痛点
- 根据反馈调整规范和模板
持续优化
团队落地不是一次性的事情，需要持续迭代：
每周：Champion 收集问题和反馈
每月：更新 Prompt 模板库，优化 CLAUDE.md
每季度：评估 ROI，调整工具选型，分享最佳实践
五、常见问题
Q：应该统一工具还是让大家自由选择？
建议：核心工具统一，辅助工具自由。
- 统一：CLAUDE.md / .cursorrules（项目规范必须统一）、Prompt 模板库
- 自由：具体用 Claude Code 还是 Cursor，用 ChatGPT 还是 Claude——让开发者选自己顺手的
Q：AI 生成的代码需要在 commit message 中标注吗？
建议：不需要逐行标注，但在 PR 描述中说明"本 PR 中 XX 模块使用了 AI 辅助生成"。这有助于 reviewer 知道重点关注哪些部分。
Q：怎么说服管理层投入预算？
用试点数据算 ROI：
假设：
- 团队 10 人，平均月薪 3 万
- AI 工具成本：10 人 × $30/月 ≈ ¥2,200/月
- 效率提升 25%（保守估计）
- 等效节省：10 × 3 万 × 25% = 7.5 万/月
ROI = (7.5 万 - 0.22 万) / 0.22 万 ≈ 33 倍
当然，这是理论计算。用试点阶段的真实数据会更有说服力。
Q：小团队（3-5 人）需要这么正式的流程吗？
不需要完整流程，但需要：
- 一份 CLAUDE.md（10 分钟就能写好）
- 3-5 个常用的 Prompt 模板
- 一个简单的约定：AI 生成的代码必须自己 review 过再提交
小团队的优势是沟通成本低，口头约定就够了。
Q：远程团队怎么推广？
- 录制 Champion 的使用演示视频（比文档更直观）
- 建立异步的 Prompt 分享频道（每周分享一个好用的 Prompt）
- 定期的线上 Pair Programming session
六、一份可执行的 30 天落地计划
第 1 周：准备
├── 选定 1-2 个 Champion
├── 确定试点场景（推荐：单元测试生成）
├── 购买工具订阅
└── 写 CLAUDE.md 初版
第 2 周：试点
├── Champion 开始使用
├── 每天记录使用数据
├── 收集问题和反馈
└── 开始积累 Prompt 模板
第 3 周：规范化
├── 整理试点数据和案例
├── 建立 Prompt 模板库（至少 5 个模板）
├── 制定 AI 代码 Review 检查清单
├── 写安全合规规范
└── Champion 做第一次内部分享
第 4 周：小范围推广
├── 扩展到 3-5 人
├── Pair Programming 帮助新手上手
├── 收集反馈，优化规范
└── 准备全团队推广计划
七、总结
团队 AI 落地的核心不是工具，而是流程和文化。
三个关键：
- 从小处开始。找到 Champion，选对试点场景，用数据证明价值。不要一上来就全员推广
- 规范先行。CLAUDE.md、Prompt 模板库、Review 检查清单、安全规范——这些基础设施决定了团队使用 AI 的质量下限
- 持续迭代。团队落地不是一次性项目，而是持续优化的过程。每月更新规范，每季度评估效果
推荐阅读
- AI Prompt 工程实战手册 — 建立 Prompt 模板库的基础
- AI 辅助开发踩坑指南 — 团队需要避免的常见错误
- AI 工具选型指南 — 帮团队选对工具
- AI 辅助产品开发全链路指南 — 了解 AI 在每个环节的角色