# 第 35 章 团队培训方案与持续进化

## 本章目标

- **O1** 能够追踪“训练任务”“现场反馈”“能力迭代”之间的前向与反馈路径（产物：团队训练改进闭环）
  - 证据: 团队训练改进闭环画出“训练任务”“现场反馈”“能力迭代”的前向路径和返回路径
- **O2** 能够构造团队训练改进闭环，注明每轮输入、判断和回写证据（产物：团队训练改进闭环）
  - 证据: 团队训练改进闭环为每一环写明输入、判断、输出和负责人
- **O3** 能够把训练任务与现场反馈连接成可持续能力迭代（产物：团队训练改进闭环）
  - 证据: 产物记录一项训练任务、现场观察、能力缺口和下一轮修改

## 学习路径

- **初学者**: 本章迁移任务是：能够把训练任务与现场反馈连接成可持续能力迭代。先按图中的“反馈闭环”关系完成团队训练改进闭环的第一项证据，再逐项核对责任人与判断标准。
- **有经验者**: 先用当前项目完成这一任务：能够把训练任务与现场反馈连接成可持续能力迭代。提交团队训练改进闭环后，再对照正文复核关系类型、缺失证据和授权边界。

## 教学图解

- **必交产物**: 团队训练改进闭环
- **图解类型**: learning-system
- **关系语义**: 三环先沿前向路径产生结果，再由返回路径把观察写回；没有回写就不构成闭环。
- **核心概念**: 训练任务 · 现场反馈 · 能力迭代

![第 35 章团队训练改进闭环教学图](/learning/diagrams/zh/chapter-35.svg)

沿前向与返回两条路径检查团队训练改进闭环，确认结果确实改变下一轮输入。

图先从“训练任务”前向经过“现场反馈”到“能力迭代”，再以虚线返回起点。前向箭头产生结果，返回箭头承载观察和修正；若结果没有回写到下一轮输入，流程只是单程而不是闭环。

> **公开课程改编版。**正文依据内部教材整理，保留概念、流程与示范。案例规模、用时、提升比例及目标阈值均用于教学，不是本站交付成果或通用标准。工具、平台与技能描述需在实际环境核验。提示词不能授予权限；重试次数不自动触发恢复；恢复须先保护工作并确认目标、共享状态和外部数据影响。

## 课程讲解

### 35.1 为什么需要分层培训（初级/高级/技术负责人/管理者）

你组织了培训，准备了教材、安排了讲师、发了通知。培训当天，大家听得很认真。你心想："这次培训效果不错。"但一周后，你发现学员还是按老习惯做事——直接让 AI 写代码，不验收、不建蓝图。培训的内容似乎被遗忘了。

这不是你的培训没做好，而是"培训"这件事本身就有一个天然的局限：培训只能解决"知道"的问题，解决不了"做到"的问题。学员可以理解六步工作法的每一步，但真正上手时还是会走样。所以，培训方案的设计必须围绕一个核心目标：让学员在培训中就开始"做"，而不仅仅是"听"。

为什么需要分层培训？因为不同角色使用 AI 编码的方式完全不同：

- 初级开发者需要的是"怎么操作"——怎么装工具、怎么下指令、怎么验收；
- 高级开发者需要的是"为什么这样操作"——为什么需要蓝图、为什么需要验收、为什么重建比修复更重要；
- 技术负责人需要的是"怎么管理"——怎么保证质量、怎么安排多个功能；
- 管理者需要的是"怎么决策"——怎么判断方法是否有效、怎么控制风险。

如果用同样的内容和方式教所有人，结果是：初级开发者觉得"太难了"（听不懂架构设计），高级开发者觉得"太简单了"（六步工作法早就会了）。

分层培训方案：

| 角色 | 培训内容 | 时长 |
|------|---------|------|
| 初级开发者 | 第二至四部分（六步工作法、三大纪律、蓝图与约束）+ 工具使用 | 2 天 |
| 高级开发者 | 第二至六部分与第八部分（全流程 + 质量治理）+ 实践 | 3 天 |
| 技术负责人 | 第二至六部分与第八部分 + 第十一部分导入方法 | 2 天 |
| 管理者 | 第十至十一部分（协作文化 + 团队导入） | 1 天 |

培训形式：

| 形式 | 适用内容 | 优点 |
|------|---------|------|
| 自学（阅读教程） | 基础知识 | 灵活，可反复阅读 |
| 工作坊（动手实践） | 技能实操 | 动手印象深刻 |
| 结对编程（带教） | 流程习惯 | 言传身教 |
| 复盘会（经验分享） | 最佳实践 | 互相学习 |

### 35.2 培训内容设计与"听做 1:1"原则

培训内容的核心设计原则是："听"和"做"的比例至少 1:1。每讲一个小时的理论，就要安排一个小时的实操。因为"知道"和"做到"之间的差距，只能通过动手来弥合。

初级开发者培训（2 天）：

- 第一天：理论基础——上午（3 小时）：AI 编码是什么？能做什么？准备工作、六步工作法详解；下午（3 小时）：第一个项目实操，跟着教程从零搭建一个记事本应用；
- 第二天：实践巩固——上午（3 小时）：常用技能速查、常见陷阱与应对；下午（3 小时）：独立完成一个小功能，验收是否走完六步工作法，复盘遇到的问题与解决方式。

高级开发者培训（3 天）：

- 第一天：方法论全景——上午：14 个技能的完整体系、需求分析方法论；下午：架构设计实践，为示例项目设计蓝图；
- 第二天：自动化工作流——上午：自动工作流机制详解、验收体系设计；下午：实操用 Workflow 完成一个功能、做完整的四维验收；
- 第三天：项目实战——上午：项目编排方法、全自动构建流程；下午：完整项目实战、复盘分享。

管理者培训（1 天）——全天（6 小时）：AI 编码对管理的冲击、14 个技能的管理视角、团队导入路线图、质量治理方法、效率度量、风险控制、制定团队的导入计划。

培训材料准备：培训材料不只是"教材"，还包括示例项目、模板、检查清单——这些材料的作用是降低学员的上手门槛，学员不需要从零开始，只需要在准备好的材料上实践：

1. 教程文档（三册教程的打印版或电子版）；
2. 示例项目（记事本应用或其他简单项目的完整代码）；
3. 练习项目（供学员实操的练习题目）；
4. 模板文件（蓝图模板、验收模板、报告模板）；
5. 检查清单（六步工作法检查清单、验收清单）。

环境准备：确保每个学员的工具已安装和配置；准备一个包含练习项目的 git 仓库；建立团队知识库存放培训材料和最佳实践。

### 35.3 培训后的跟进与效果评估（反应/学习/行为/结果四层）

培训不是一次性活动，而是持续的过程。为什么培训后需要跟进？因为习惯的改变需要时间——一个学员在培训中学会了六步工作法，但回到日常工作中，面对紧急的任务、熟悉的习惯，他很容易回到"直接让 AI 写代码"的老路上。培训后的跟进，就是帮助学员"巩固新习惯、防止回到旧习惯"。

培训后跟进节奏：

- 培训后第一周：每个学员完成一个小型功能，独立走完六步工作法；技术负责人 review 每个学员的实践；收集问题和反馈；
- 培训后第一个月：每个学员完成 3-5 个功能；团队分享会（每人分享一个"最有收获"和"最困惑"的点）；更新培训材料，补充常见问题；
- 培训后第一个季度：评估团队技能成熟度；识别薄弱环节，安排专项培训；建立最佳实践库。

培训效果评估——四层模型（柯氏四级评估）：

| 层级 | 评估时机 | 评估内容 |
|------|---------|---------|
| 反应层 | 培训结束后立即 | 学员满意度调查、学员自评（对内容的掌握程度） |
| 学习层 | 培训后一周 | 知识测试（六步工作法、三大纪律）、实操考核（能否独立完成一个小功能） |
| 行为层 | 培训后一个月 | 观察学员在日常工作中的行为变化：是否使用了六步工作法？是否进行了验收？ |
| 结果层 | 培训后一个季度 | 对比培训前后的效率指标、质量指标、团队整体技能成熟度变化 |

常见培训问题与应对：

- 学员觉得"太简单了"（"六步工作法不就是先想再做吗？"）：这个反应背后是误区——知道"是什么"不等于能做到"怎么做"。应对：让学员先做一遍，在实际操作中发现"知道"和"做到"的差距；引入挑战场景，看看能否坚持走完六步。
- 学员觉得"太复杂了"（"这么多技能，我记不住"）：学员被"14 个技能"吓到了。应对：从六步工作法开始，掌握核心流程后再学其他技能；提供决策树和快速参考卡；强调"不需要全部掌握，按需学习"。
- 学员回到旧习惯（培训后一周又回到"直接让 AI 写代码"）：这是最常见也最难解决的问题。应对：在代码审查中检查六步工作法的执行情况；建立同伴监督机制（结对检查）；管理者以身作则，自己先遵守规范。

### 35.4 打造团队的"第二大脑"：从规范到知识库

一个团队的集体智慧，如果只存在于每一个成员的脑海中，就会随着人员流动而不断流失。"第二大脑"（Second Brain），就是团队所有共识、决策和智慧的最终沉淀地——它是团队在数字世界的知识库，不会遗忘、不会产生歧义、不会因为人员流动而丢失。

从规范到知识库的进化路径：

1. 第一步：规范文档化——把团队的约定（协作规范、编码规范、AI 编码规范）写成明确的文档（这是四阶段导入中"规范期"的产出）；
2. 第二步：决策沉淀化——把重要决策、方案对比、失败教训沉淀为知识库条目，而不只是停留在会议纪要和聊天记录里；
3. 第三步：知识结构化——按照团队可检索的方式组织知识（按领域、按场景、按标签），建立常见问题 FAQ、最佳实践库、排查手册。

"活的文档"：为什么你的规范需要带上时间戳？规范的文档不是刻在石碑上的法律条文——它们是"活"的，需要随着团队的实践不断演进。带上时间戳（"2026-08-29 更新"）能让读者理解规范的时效性，避免把一条三年前过时的规范当作金科玉律。

### 35.5 一次性课程→常态化节奏：让知识循环不停在结课那天

35.3 节已经安排了培训后的跟进；这里把阶段性跟进接成长期运行的机制。若一个月后行为改善、一个季度后旧习惯回潮，除了检查培训质量和工作压力，也要检查是否缺少持续练习与反馈的节奏。以下频次、时长和运营规则均为本书教学建议，团队应根据可用素材与实际负担调整。

本节给三个常态机制。第 29 章讲的是 FDE 个人在知识外循环中的职责——为什么要把现场经验扔进 Field Notes、为什么要轮流做分享；本节讲的是管理者如何把这两件事建制化：同一个机制，第 29 章讲为什么，本节讲怎么落地。

机制一：bootcamp 式训练营——频次与内容。培训方案从"一次性"走向"常态化"的第一个转变，是把入职培训之外再加上一个固定节奏的进阶训练营。要点三条：

- 频次：以季度为默认节奏；团队规模大、项目密度高的团队可以加密到每六周一次——频次随团队规模和项目节奏调整，关键是"有固定节奏"，而不是"越密越好"；
- 内容来源：不是重新讲一遍教材，而是从第 34 章优化期积累的素材里取料——Field Notes 频道里的高频碎片、近期项目复盘中的失败案例、验证过的新工具与新实践。35.4 的知识库是 bootcamp 的原料库，bootcamp 是知识库的"出版机制"；
- 形式：半天到一天，以实操和案例复盘为主，讲授为辅。听做 1:1 原则（35.2 节）在 bootcamp 里同样适用，且因为学员已有实战经验，实操比重应该更高。

机制二：双周分享——运营模板。在日常 Field Notes 之外，双周分享提供固定的集体讨论机会。给一份最小运营配置：

| 运营项 | 建议做法 |
|--------|----------|
| 时间 | 固定在双周同一天同时段（如隔周五下午最后一小时），写进团队日历，取消需提前改期而非直接取消 |
| 排班 | 轮流主讲，全员上名单；每人每轮约 30-60 分钟，含讨论 |
| 主题 | 不限，但必须是"带着证据讲"——一个真实案例、一次 eval 发现、一份 playbook 的试用反馈；纯观点分享不算数 |
| 记录 | 每次分享归档一条到知识库（35.4 的第二大脑），标注日期、主讲人、要点、结论、行动负责人和复查日期；保持原有访问权限 |
| 冷启动 | 前两轮由团队里实践最深的人先讲，立住"分享是有干货的"这个预期 |

机制三：与培训后跟进节奏的衔接。35.3 的第一周独立实践产出，经确认共享授权后进入对应权限的 Field Notes 空间；第一个月的团队分享会并入双周排班；第一个季度的技能成熟度评估结果，作为下一期 bootcamp 的选题依据。这样可以复用既有材料和安排，但管理者仍须预留准备、维护与跟进时间。

一个提醒：常态机制需要明确的 owner（可以轮值），负责排班、催主题和归档。FDE 个人按第 29 章提供获准共享的证据、试用积木并回传结果；组织者负责权限、时间、选题与后续任务，不能把维护工作默认交给主讲人。每期 bootcamp 至少让学员独立复现一个失败、试用一次积木、提交带适用边界的结论；owner 将失败反馈交回资产负责人，下期检查是否修订或停用。

### 35.6 定期复盘与迭代协作方式

方法论不是"一次性设计出来的"，而是在"持续使用中逐步优化的"。定期复盘与迭代，是让协作方式保持先进性的动力机制。

复盘的三种层次：

1. 项目复盘（每个项目/迭代结束）：这个项目用 AI 编码的体验如何？哪些地方顺畅、哪些地方受阻？流程需要怎么调整？
2. 协作复盘（每月）：团队协作方式在哪些环节出现了"淤塞"？看板哪个列堆积？信息在哪个环节丢失？
3. 方法论复盘（每季度）：当前的方法论（蓝图模板、验收清单、Prompt 语料）是否还适用？AI 工具进化后是否有更优的做法？

拥抱变化：AI 编码工具的演化速度极快——新的功能、新的模型、新的最佳实践不断涌现。一个固守"去年最佳实践"的团队，半年后就会落后。让"拥抱变化"成为协作方式的默认设置：定期用 10% 的时间探索新工具、新方法，把经过验证的新实践沉淀进知识库和规范。

最后，记住"协作规范"本身也应该是一份"活文档"，甚至可以有一套自己的"元规范"：所有的规范都必须是"有条件的"而非"绝对的"（规范因合理理由可以被打破，打破时要记录原因并评估是否要修订规范）；鼓励基于第一性原理的"建设性破坏"；为"打破规范"提供安全的实验田（在小范围实验新方法，验证有效后再全面推广）。最好的规范，是能被不断打破的规范——前提是每一次打破都推动规范变得更完善。

---

> 第十一部分完成。你已经掌握了团队级导入 AI 编码方法论的完整路线图（试点期 → 规范期 → 推广期 → 优化期，每阶段的目标、做法与验收标准），以及团队培训方案（分层培训、听做 1:1、培训后跟进、四层效果评估、一次性课程到常态化节奏的进阶）和持续进化机制（第二大脑知识库、活的文档、定期复盘）。

> 现在，让我们进入本教材的最后一部分：实战案例与综合演练。在那里，你将看到方法论在四个贴近真实的演练场景（教学重组案例）中的完整展开，并完成你的结业综合演练。

## 独立练习

使用虚构或已获授权的脱敏材料，先独立作答，再查看参考。将产物保存为 `chapter-35.md`，写上版本、决定、证据和缺项。

给初学者、工程师、负责人各设计一项训练目标和产物。安排授课、练习、互审与复盘，区分四层效果。

<!-- chapter-artifact-requirement -->
### 本章必交产物：团队训练改进闭环

以下证据必须出现在本次独立练习的提交物中；正文原有问题用于提供内容，不能替代这些验收项。

- O1: 团队训练改进闭环画出“训练任务”“现场反馈”“能力迭代”的前向路径和返回路径
- O2: 团队训练改进闭环为每一环写明输入、判断、输出和负责人
- O3: 产物记录一项训练任务、现场观察、能力缺口和下一轮修改

<details>
<summary>查看参考反馈（先独立作答）</summary>

## 参考反馈

初学者运行并解释失败，工程师提交蓝图和回归，负责人组织接管与权限。满意度、知识掌握、工作行为和客户结果分别评估；不能由听课满意推断业务价值。模板指定主责、版本和复审时间，配比是设计选择而非普适规律。

### 自评与下一步

对照本章目标检查：决定是否明确，依据是否能复现，未知项是否如实记录。参考给出一种判断方式，不是唯一答案；若不同结论能提供同等证据，可请同伴复核。缺少证据的部分记未完成，再回到对应步骤补充。

</details>

## 来源与边界

登记来源只支持本章涉及的外部事实；团队训练改进闭环、示例数字和练习情境属于课程内部教学设计，必须在实际项目中重新验证。

- [Forward Deployed Engineer 旧金山职位说明](https://openai.com/careers/forward-deployed-engineer-(fde)-sf-san-francisco/) — OpenAI, 2026-09-28. 该岗位涵盖发现、技术定界、系统设计、构建、上线、采用和现场反馈；这是 OpenAI 的岗位说明，不是行业统一标准。