祝融说。

你决定在团队中推行 AI 编码方法论。但你知道，这不是"今天宣布、明天执行"的事情——错误的导入方式可能比不导入更糟糕。

3.1 导入总览

在团队中推行 AI 编码方法论，不是一个"今天宣布、明天执行"的事情。因为这种方法论改变的不是"用什么工具"，而是"怎么工作"。改变工作方式是最难的——它需要新习惯、新流程、新思维方式。如果一上来就全员推广，结果可能是：团队抵触、执行走样、效果打折，然后得出结论"这个方法不行"。

所以需要分阶段推进。每个阶段有明确的目标和验收标准，前一阶段达标了才能进入下一阶段。

第 1 周          第 2-3 周        第 4-6 周         第 7 周起
┌────────┐      ┌────────┐      ┌────────┐        ┌────────┐
│ 试点期 │ ───→ │ 规范期 │ ───→ │ 推广期 │ ────→  │ 优化期 │
└────────┘      └────────┘      └────────┘        └────────┘
  1-2 人          建立规范        全员推广          持续改进
  1 个项目        试点验证        效果评估          流程优化

3.2 第一阶段：试点期（第 1 周）

目标

在小范围内验证方法论的有效性，积累经验，发现初期问题。

为什么从小范围开始？ 因为新的方法论一定有"理想"和"现实"之间的差距。你想象中的操作流程，在实际执行中可能会遇到各种意外——工具配置问题、团队理解偏差、流程中的盲点。如果一上来就全员推广，这些意外会被放大。在小范围内先跑一遍，发现问题、修正流程，然后再推广，风险可控得多。

做法

1. 选择试点人员：选 1-2 名对 AI 编码有热情、技术能力较强的开发者
2. 选择试点项目：选一个中等复杂度、非关键业务的项目（风险可控）
3. 导入核心方法：
   • 六步工作法
   • 三大纪律（蓝图、验收、重建）
4. 工具配置：
   • 配置 AI 编码工具
   • 建立项目目录规范
   • 建立 git 使用规范

试点期的关键任务

验收标准

• 试点人员能独立走完六步工作法
• 试点项目产出了蓝图（CONTEXT.md）
• 每个里程碑都有验收记录
• 收集了至少 5 个实践中的问题

管理者做什么

• 每周与试点人员 1:1 沟通，了解进展和问题
• 关注试点项目的代码质量变化
• 不急于推广，先在小范围内打磨

3.3 第二阶段：规范期（第 2-3 周）

目标

基于试点经验，建立团队统一的 AI 编码规范。

为什么先建规范再推广？ 很多管理者犯的错误是：让团队先用起来，等发现问题再建立规范。但一旦团队养成了"自由使用"的习惯，再建立规范就会遇到阻力——"我们之前一直这么用，为什么要改？"先建立规范再推广，虽然看起来慢，但实际上避免了后续的"改习惯"成本。

做法

1. 复盘试点经验：

   • 哪些方法有效？哪些需要调整？
   • 遇到了哪些问题？如何解决？
   • 哪些规范可以标准化？

2. 制定规范文档：

   • AI 编码使用规范（什么场景用、什么场景不用）
   • 蓝图模板（CONTEXT.md 的标准结构）
   • 验收清单（功能/架构/安全三维度）
   • 代码提交规范（commit message 格式）

3. 工具链配置：

   • 配置 AI 编码工具的团队级设置
   • 建立蓝图和验收模板的共享库
   • 配置 git hooks（可选）

规范文档示例

# 团队 AI 编码规范（草案）

## 使用范围
- ✅ 常规 CRUD 功能
- ✅ 单元测试编写
- ✅ 代码迁移和重构
- ❌ 核心业务逻辑（需人工编写后再由 AI 优化）
- ❌ 安全敏感代码（认证、加密、支付）
- ❌ 架构决策

## 编码前
- 必须产出 CONTEXT.md 蓝图
- 蓝图必须包含：技术栈、数据模型、API 契约、里程碑
- 蓝图需经过至少一位同事评审

## 编码后
- 每个里程碑完成后必须验收
- 验收必须覆盖功能、架构、安全三个维度
- 验收未通过的代码不得提交

管理者做什么

• 组织复盘会议
• 审核规范文档
• 确保规范是"可执行的"而不是"贴在墙上的"

3.4 第三阶段：推广期（第 4-6 周）

目标

将方法论推广到整个团队，确保大部分成员能正确使用。

为什么需要结对实践？ 培训只能解决"知道"的问题，解决不了"做到"的问题。一个开发者听了六步工作法的培训，理解了每一步做什么，但真正上手时可能还是会走样。结对实践——让试点人员带着团队成员做一遍——能有效弥合"知道"和"做到"之间的差距。

做法

1. 全员培训：

   • 第一册内容：六步工作法、三大纪律
   • 工具使用培训：AI 编码工具的基本操作
   • 规范解读：团队规范的逐条说明

2. 结对实践：

   • 试点人员与团队成员结对，带教实践
   • 每个结对完成一个小功能

3. 效果评估：

   • 对比使用 AI 编码前后的开发效率
   • 收集代码质量数据（测试覆盖率、bug 率）
   • 团队成员满意度调查

常见问题

问题：团队有抵触情绪

• 原因：担心 AI 会替代自己的工作
• 应对：强调 AI 是工具不是替代品，展示 AI 编码如何减轻重复劳动

问题：不知道从哪里开始

• 原因：方法论的步骤太多，不知道当前该做什么
• 应对：提供决策树或 checklist，帮助快速定位

问题：验收走过场

• 原因：验收太麻烦，或者不知道验收什么
• 应对：提供验收模板，让验收变得简单

管理者做什么

• 组织培训
• 监控推广进度
• 处理抵触情绪
• 评估效果

3.5 第四阶段：优化期（第 7 周起）

目标

建立持续改进机制，让方法论在团队中不断进化。

为什么持续改进是必要的？ 方法论不是"一次性设计出来的"，而是"在持续使用中逐步优化的"。你的团队、你的项目、你的技术栈都在变化，方法论也需要跟着变化。一个季度前有效的方法，现在可能已经不适合了。所以需要建立"审计-复盘-改进"的循环。

1. 定期审计：

   • 每月一次代码质量审计
   • 检查架构偏移率
   • 检查规范遵守情况

2. 复盘会议：

   • 每月一次项目复盘
   • 讨论：哪些做得好？哪些需要改进？
   • 更新规范文档

3. 知识库建设：

   • 收集最佳实践案例
   • 建立常见问题 FAQ
   • 定期分享会

衡量指标

管理者做什么

• 建立审计机制
• 主持复盘会议
• 推动持续改进

3.6 导入的关键成功因素

为什么这五个因素最重要？因为它们回答了一个根本问题："为什么很多方法论导入会失败？"

高层支持——如果管理者本人不理解方法论的价值，团队就不会认真对待。管理者的一句话"这个流程很重要"比任何培训都有效。

试点先行——直接全员推广的风险太高，试点能用最小的成本验证方法论的有效性。

规范可执行——很多规范之所以失败，是因为规范太"理想"了——"每个里程碑必须 100% 通过验收才能提交"——在现实中可能做不到。规范应该是"当前能做到的"，而不是"理想状态"。

培训到位——不要假设团队成员能自己学会。培训不是"发一份文档让大家自己看"，而是"带着做一遍"。

持续改进——方法论不是一成不变的，需要不断调整。一个季度前有效的流程，现在可能已经不适合了。

本章小结

团队导入分四阶段——试点、规范、推广、优化——每个阶段解决一个核心问题：试点验证"这个方法行不行"，规范解决"怎么统一做"，推广解决"怎么让所有人做"，优化解决"怎么越做越好"。每个阶段都有"为什么"支撑：试点是因为新方法论一定有理想和现实的差距，规范是因为先建规范再推广比先推广再建规范成本更低，结对实践是因为"知道"和"做到"之间有很大差距，持续改进是因为方法论需要随着团队和项目的变化而调整。下一章，我们学习质量治理——如何建立 AI 编码的红线与门禁。