AI 驱动工程的团队结构、角色与协作实践。
目的
AI 改变了团队分工的逻辑，但大多数团队仍在用旧的角色框架套新的工作方式。本章节解释 AI 时代团队角色应该如何重新划分，帮助你回答：
– 谁对哪类决策有最终权？
– 哪些工作可以交给 AI，哪些不能？
– 小团队如何合理兼任多个层的职责？
→ 各层的 AI 原生岗位定义、与传统岗位的详细对照、兼任矩阵见 roles.md
→ 用产品思维诊断和设计团队的具体操作方法见 team-design-practice.md
核心思想：三层角色框架
传统团队按执行任务划分角色（谁写代码、谁写文档、谁测试）。AI 介入后，大量执行任务可以外包给 AI，人的角色应该按判断权归属来划分。
| 层 | 核心问题 | 职能 | 对应传统岗位 |
|---|---|---|---|
| 判断层 | 做什么？结构对吗？ | 决策、定义约束、承担后果 | 产品经理、架构师 |
| 编排层 | 怎么让 AI 做好？ | 结构化意图、设计提示、拆解任务 | 工程师、PM、项目经理 |
| 验证层 | AI 做对了吗？ | 审查输出、识别盲区、反馈提示库 | Tech Lead、QA、审查员 |
三个推论：
- 判断层不能委托给 AI — AI 可以给选项，但无法承担决策后果
- 编排层是新核心技能 — 写出高质量提示等同于传统的编码能力
- 验证层不能省略 — 没有验证，AI 的错误会直接流入生产
协作原则
- 每件 AI 生成的成果都有指定的人类负责人，对其质量负责
- 判断层的决策不因 AI 建议而自动成立，需要人类显式确认
- 验证层独立于编排层 — AI 输出的生成者不能是该输出的最终审查人
- 角色是指导原则，小团队中一个人可以同时属于多个层
团队仪式调整
站会：新增”AI 使用情况”一项 — 昨天哪些任务用了 AI？遇到什么失败模式？
需求评审：评审前要求需求已结构化（填完结构化模板），未结构化的需求退回重写。
复盘：新增”提示库更新”议题 — 哪些提示本周有改进？哪些失效了？
知识共享机制
大多数团队提升能力的方式是培训人——招更强的人、要求个人学习。这有一个根本缺陷：人是流动的，能力不留存。强的人走了，能力也带走了，团队回到原点。
真正能积累的方式是能力外化：把原本存在个人脑子里的判断力、经验和方法，沉淀到系统中：
- 有效的提示 → 提交到
04-prompt/，附带说明 - AI 失败案例 → 记录到对应章节的”失败模式”
- 工具使用心得 → 更新
07-tooling/中的工具文档 - 角色经验 → 通过
roles.md中的能力定义积累
知识只有落入仓库才算共享，否则只是个人经验。
避免文档陷阱：知识沉淀很容易退化为”建文档”——写完没人用，也没人更新。有效的方式是让改进嵌入日常工作，而不是作为额外负担：
- 提示词在用的时候迭代，不是专门开会讨论
- 流程在执行时发现问题就修，不是等季度复盘
- 失败案例在踩坑时立刻记录，不是事后整理
这个循环建起来，团队能力才是真的在积累。
AI 优先团队的招聘信号
在筛选候选人时，寻找：
– 能清晰描述”我让 AI 做了什么、我自己做了什么”的人
– 对 AI 输出持批判态度，而非无条件接受
– 习惯结构化输入，而非依赖模糊对话
不看重：每天用了多少次 AI 工具（数量不等于质量）。