祝融说。

34.1 四阶段导入：试点期 → 规范期 → 推广期 → 优化期

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

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

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

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

34.2 每个阶段的目标、做法与验收标准

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

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

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

做法：

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

试点期的关键任务：

验收标准：

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

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

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

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

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

做法：

1. 复盘试点经验：哪些方法有效？哪些需要调整？遇到了哪些问题？如何解决？哪些规范可以标准化？
2. 制定规范文档：AI 编码使用规范（什么场景用、什么场景不用）、蓝图模板（CONTEXT.md 的标准结构）、验收清单（功能/架构/安全三维度）、代码提交规范（commit message 格式）；
3. 工具链配置：配置 AI 编码工具的团队级设置、建立蓝图和验收模板的共享库、配置 git hooks（可选）。

规范文档示例：

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

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

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

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

管理者做什么：组织复盘会议；审核规范文档；确保规范是"可执行的"而不是"贴在墙上的"。

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

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

推广期需要全员培训、结对实践与效果评估；分层对象、听做比例、材料和环境、跟进节奏及评估方法以第 35 章的团队培训方案为准。本章只负责把这些安排纳入第 4—6 周的导入节奏。

常见问题与应对：

管理者做什么：组织培训；监控推广进度；处理抵触情绪；评估效果。

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

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

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

1. 定期审计：每月一次代码质量审计，检查架构偏移率、规范遵守情况；
2. 复盘会议：每月一次项目复盘，讨论"哪些做得好？哪些需要改进？"，更新规范文档；
3. 知识库建设：收集最佳实践案例、建立常见问题 FAQ、定期分享会；
4. Field Notes 频道：建立按客户授权与内容敏感程度分权的共享空间，成员及时记录可分享的事实、场景和证据链接；指定轮值维护者聚合同类笔记，安排试用验证后再纳入知识库；
5. bootcamp 式训练营：建议以季度为起点，把近期复盘、验证过的实践和新工具用法组织成半天到一天的实操；由负责人安排主题、环境和演练验收。上述频次与时长是本书的导入建议，具体运营见第 35 章 35.5 节。

优化期把运行责任落到人：每份工具、playbook 和模板登记 owner、版本与最近验证日期，每季度复查，相关环境变更时提前复验；失效项标记停用或归档。一次循环的可见产物至少包括一条经试用验证的资产更新及其反馈记录，不能只统计发帖量或训练出勤率。

衡量指标：

管理者做什么：建立审计机制；主持复盘会议；推动持续改进；维护 Field Notes 频道与 bootcamp 节奏，让知识循环从个人习惯变成团队机制（这两个机制的"为什么"与 FDE 个人的职责，见第 29 章）。

34.3 导入的关键成功因素

为什么很多方法论导入会失败？以下五个因素回答了这个问题——它们是最关键的成功因素，缺一不可：

1. 高层支持：如果管理者本人不理解方法论的价值，团队就不会认真对待。管理者的一句话"这个流程很重要"比任何培训都有效；
2. 试点先行：直接全员推广的风险太高，试点能用最小的成本验证方法论的有效性；
3. 规范可执行：很多规范之所以失败，是因为规范太"理想"了——"每个里程碑必须 100% 通过验收才能提交"在现实中可能做不到。规范应该是"当前能做到的"，而不是"理想状态"；
4. 培训到位：不要假设团队成员能自己学会。培训不是"发一份文档让大家自己看"，而是"带着做一遍"；
5. 持续改进：方法论不是一成不变的，需要不断调整。一个季度前有效的流程，现在可能已经不适合了。

34.4 常见问题与应对（抵触情绪、验收走过场等）

问题一：抵触情绪。团队成员担心 AI 会替代自己的工作。应对：强调 AI 是工具不是替代品；展示 AI 编码如何减轻重复劳动、让人专注更有价值的工作；让抵触者加入试点，看到实际效果比任何说服都有力。

问题二：验收走过场。验收变成"勾选框"——为了完成流程而验收，而不是真正检查代码。应对：提供验收模板降低门槛；抽查验收记录的真实质量；把验收结果与代码质量数据关联，让"走过场"的团队看到自己低的验收通过率和高昂的返工成本。

问题三：规范执行打折扣。规范写在文档里，但执行时走样。应对：管理者以身作则，自己先遵守规范；在代码审查和例会上检查规范的执行情况；把规范执行纳入绩效评估。

问题四：两极分化。少数人用得很好，多数人还在观望。应对：让"用得好的"成为内部布道者，公开分享成功案例；把他们的实践沉淀为团队模板；让试点成员在推广期承担"带教"职责。

问题五：工具瓶颈。工具配置不统一、账号权限问题阻碍使用。应对：在试点期就把工具链问题全部解决；建立团队级工具配置规范；指定专人负责工具维护。