你安排了培训，但发现"培训了等于没培训"——学员回去后还是按老习惯做事。好的培训不是"讲一遍"，而是"让学员真正改变行为"。
你组织了培训。你准备了教材、安排了讲师、发了通知。培训当天，大家听得很认真，问了很多问题。你心想："这次培训效果不错。"
但一周后，你发现：学员还是按老习惯做事——直接让 AI 写代码，不验收、不建蓝图。培训的内容，似乎被遗忘了。
这不是你的培训没做好，而是"培训"这件事本身就有一个天然的局限：培训只能解决"知道"的问题，解决不了"做到"的问题。 学员可以理解六步工作法的每一步，但真正上手时还是会走样。所以，培训方案的设计必须围绕一个核心目标：让学员在培训中就开始"做"，而不仅仅是"听"。
不同角色需要不同的培训内容和时长。为什么？因为初级开发者、高级开发者、技术负责人、管理者——他们使用 AI 编码的方式完全不同。
初级开发者需要的是"怎么操作"——怎么装工具、怎么下指令、怎么验收。高级开发者需要的是"为什么这样操作"——为什么需要蓝图、为什么需要验收、为什么重建比修复更重要。技术负责人需要的是"怎么管理"——怎么保证质量、怎么安排多个功能。管理者需要的是"怎么决策"——怎么判断方法是否有效、怎么控制风险。
如果用同样的培训内容和方式教所有人，结果是：初级开发者觉得"太难了"（听不懂架构设计），高级开发者觉得"太简单了"（六步工作法早就会了）。所以需要分层设计。
| 角色 | 培训内容 | 时长 |
|---|---|---|
| 初级开发者 | 第一册全部内容 + 工具使用 | 2 天 |
| 高级开发者 | 第二册全部内容 + 实践 | 3 天 |
| 技术负责人 | 第二册 + 第三册第四章 | 2 天 |
| 管理者 | 第三册全部内容 | 1 天 |
| 形式 | 适用内容 | 优点 |
|---|---|---|
| 自学（阅读教程） | 基础知识 | 灵活，可反复阅读 |
| 工作坊（动手实践） | 技能实操 | 动手印象深刻 |
| 结对编程（带教） | 流程习惯 | 言传身教 |
| 复盘会（经验分享） | 最佳实践 | 互相学习 |
培训内容的核心设计原则是："听"和"做"的比例至少 1:1。 每讲一个小时的理论，就要安排一个小时的实操。因为"知道"和"做到"之间的差距，只能通过动手来弥合。
第一天：理论基础
上午（3 小时）：
下午（3 小时）：
第二天：实践巩固
上午（3 小时）：
下午（3 小时）：
第一天：方法论全景
上午（3 小时）：
下午（3 小时）：
第二天：自动化工作流
上午（3 小时）：
下午（3 小时）：
第三天：项目实战
上午（3 小时）：
下午（3 小时）：
全天（6 小时）：
培训材料不只是"教材"，还包括示例项目、模板、检查清单。这些材料的作用是降低学员的上手门槛——学员不需要从零开始，只需要在准备好的材料上实践。
培训不是一次性活动，而是持续的过程。为什么培训后需要跟进？ 因为习惯的改变需要时间——一个学员在培训中学会了六步工作法，但回到日常工作中，面对紧急的任务、熟悉的习惯，他很容易回到"直接让 AI 写代码"的老路上。培训后的跟进，就是帮助学员"巩固新习惯、防止回到旧习惯"。
"六步工作法不就是先想再做吗？这谁不知道？"
这个问题背后反映了一个常见的误区：知道"是什么"不等于能做到"怎么做"。 大多数人在理论上理解六步工作法，但实际执行时——面对紧急的任务、模糊的需求、复杂的代码——很容易走样。
应对：
"这么多技能，我记不住。"
这个问题说明学员被"14 个技能"吓到了，但其实他们不需要全部掌握。
应对：
培训后过了一周，学员又回到了"直接让 AI 写代码"的习惯。
这是最常见也最难解决的问题。习惯的改变需要时间和外部约束。
应对：
培训方案设计的核心原则是"听和做的比例至少 1:1"——培训只能解决"知道"的问题，只有动手才能解决"做到"的问题。分层培训确保不同角色获得适合的内容和深度。培训后的跟进比培训本身更重要——习惯的改变需要时间和外部约束。从反应、学习、行为、结果四个层面评估培训效果，确保培训不只是"走过场"。
# 团队 AI 编码技能评估
## 学员信息
姓名：________ 角色：________ 日期：________
## 技能掌握度自评（1-5 分）
1. 六步工作法的理解：____
2. 六步工作法的执行：____
3. 蓝图的编写能力：____
4. 验收的执行能力：____
5. 工具操作熟练度：____
## 实操考核
功能完成度：____ / 10
流程完整性：____ / 10
代码质量：____ / 10
## 改进建议
________________________________
________________________________
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。