> For the complete documentation index, see [llms.txt](https://zhouhao4221.gitbook.io/haiqing-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://zhouhao4221.gitbook.io/haiqing-docs/06-team.md).

# 06 · 团队

AI 驱动工程的团队结构、角色与协作实践。

***

## 目的

AI 改变了团队分工的逻辑，但大多数团队仍在用旧的角色框架套新的工作方式。本章节解释 AI 时代团队角色应该如何重新划分，帮助你回答：

* 谁对哪类决策有最终权？
* 哪些工作可以交给 AI，哪些不能？
* 小团队如何合理兼任多个层的职责？

→ 各层的 AI 原生岗位定义、与传统岗位的详细对照、兼任矩阵见 [roles.md](/haiqing-docs/06-team/roles.md)\
→ 用产品思维诊断和设计团队的具体操作方法见 [team-design-practice.md](/haiqing-docs/06-team/team-design-practice.md)

***

## 核心思想：三层角色框架

传统团队按**执行任务**划分角色（谁写代码、谁写文档、谁测试）。AI 介入后，大量执行任务可以外包给 AI，**人的角色应该按判断权归属来划分**。

| 层       | 核心问题       | 职能              | 对应传统岗位           |
| ------- | ---------- | --------------- | ---------------- |
| **判断层** | 做什么？结构对吗？  | 决策、定义约束、承担后果    | 产品经理、架构师         |
| **编排层** | 怎么让 AI 做好？ | 结构化意图、设计提示、拆解任务 | 工程师、PM、项目经理      |
| **验证层** | AI 做对了吗？   | 审查输出、识别盲区、反馈提示库 | Tech Lead、QA、审查员 |

**三个推论：**

1. 判断层不能委托给 AI — AI 可以给选项，但无法承担决策后果
2. 编排层是新核心技能 — 写出高质量提示等同于传统的编码能力
3. 验证层不能省略 — 没有验证，AI 的错误会直接流入生产

***

## 协作原则

* 每件 AI 生成的成果都有指定的人类负责人，对其质量负责
* 判断层的决策不因 AI 建议而自动成立，需要人类显式确认
* 验证层独立于编排层 — AI 输出的生成者不能是该输出的最终审查人
* 角色是指导原则，小团队中一个人可以同时属于多个层

***

## 团队仪式调整

**站会**：新增"AI 使用情况"一项 — 昨天哪些任务用了 AI？遇到什么失败模式？\
**需求评审**：评审前要求需求已结构化（填完结构化模板），未结构化的需求退回重写。\
**复盘**：新增"提示库更新"议题 — 哪些提示本周有改进？哪些失效了？

***

## 知识共享机制

大多数团队提升能力的方式是**培训人**——招更强的人、要求个人学习。这有一个根本缺陷：人是流动的，能力不留存。强的人走了，能力也带走了，团队回到原点。

真正能积累的方式是**能力外化**：把原本存在个人脑子里的判断力、经验和方法，沉淀到系统中：

* 有效的提示 → 提交到 `04-prompt/`，附带说明
* AI 失败案例 → 记录到对应章节的"失败模式"
* 工具使用心得 → 更新 `07-tooling/` 中的工具文档
* 角色经验 → 通过 `roles.md` 中的能力定义积累

知识只有落入仓库才算共享，否则只是个人经验。

**避免文档陷阱**：知识沉淀很容易退化为"建文档"——写完没人用，也没人更新。有效的方式是让改进嵌入日常工作，而不是作为额外负担：

* 提示词在用的时候迭代，不是专门开会讨论
* 流程在执行时发现问题就修，不是等季度复盘
* 失败案例在踩坑时立刻记录，不是事后整理

这个循环建起来，团队能力才是真的在积累。

***

## AI 优先团队的招聘信号

在筛选候选人时，寻找：

* 能清晰描述"我让 AI 做了什么、我自己做了什么"的人
* 对 AI 输出持批判态度，而非无条件接受
* 习惯结构化输入，而非依赖模糊对话

不看重：每天用了多少次 AI 工具（数量不等于质量）。


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://zhouhao4221.gitbook.io/haiqing-docs/06-team.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.