> 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/roles.md).

# 团队角色模型

AI 驱动团队的角色不再按"执行任务"划分，而是按**判断权归属**划分。AI 承担大量执行工作，人类的核心价值是判断、编排与验证。

***

## 三层框架

| 层       | 职能               | 对应传统岗位           |
| ------- | ---------------- | ---------------- |
| **判断层** | 决定做什么、结构是否正确     | 产品经理、架构师         |
| **编排层** | 把意图转化为 AI 可执行的任务 | 工程师、PM、项目经理      |
| **验证层** | 确认 AI 输出是否达到质量要求 | Tech Lead、QA、审查员 |

> 一个人可以同时属于多个层。例如：技术负责人在编排层写提示，也在验证层审查输出；架构师在判断层定架构，也在验证层把关 AI 生成的设计。

***

## 判断层

判断层的人对**决策本身**负责，AI 只能提供选项和草案，不能替代最终判断。

***

### 产品判断者

**对应传统岗位**：产品经理（Product Manager）

|       | 传统工作              | AI 时代变化     |
| ----- | ----------------- | ----------- |
| AI 接管 | 整理需求文档、竞品分析、用例编写  | AI 生成初稿，人审阅 |
| 人必须拥有 | 用户价值判断、优先级决策、验收标准 | 不变，权重更高     |

**核心职责**

* 定义"做什么"与"为什么做"，输出可被 AI 执行的结构化需求
* 使用 AI 生成 PRD 草稿、用户故事、FAQ，但对内容负责
* 验收 AI 生成的产出是否符合业务意图

**AI 角色**：AI 协调员（需求侧）

***

### 架构判断者

**对应传统岗位**：架构师（Architect）

|       | 传统工作                 | AI 时代变化      |
| ----- | -------------------- | ------------ |
| AI 接管 | 生成架构草图、技术选型对比、ADR 初稿 | AI 给选项，人做决定  |
| 人必须拥有 | 约束判断、风险接受、长期演进决策     | 不变，AI 无法承担后果 |

**核心职责**

* 定义跨服务边界、非功能性需求（性能/安全/可扩展）
* 审查 AI 生成的设计方案是否违反架构约束
* 输出架构决策记录（ADR），说明为何接受或拒绝 AI 方案

**AI 角色**：系统设计师

> 小团队中由技术负责人兼任。

***

## 编排层

编排层的人负责**把意图转化为 AI 能执行的任务**。编排质量直接决定 AI 输出质量——这不是低技能工作，需要深厚的领域理解。

***

### 工程编排者

**对应传统岗位**：后端工程师 / 前端工程师 / 全栈工程师

|       | 传统工作                  | AI 时代变化     |
| ----- | --------------------- | ----------- |
| AI 接管 | 样板代码、数据模型、SQL、组件、类型定义 | AI 生成，人审查修改 |
| 人必须拥有 | 业务逻辑正确性判断、提示设计能力      | 提示能力是新核心技能  |

**核心职责**

* 将功能需求分解为 AI 可执行的提示任务
* 审查 AI 生成的代码，确认逻辑、安全、边界情况
* 上报 AI 在当前业务场景中的失败模式，反馈提示库

**AI 角色**：AI 协调员 + AI 审查员（自审）

***

### 交付编排者

**对应传统岗位**：项目经理（Project Manager）

|       | 传统工作              | AI 时代变化   |
| ----- | ----------------- | --------- |
| AI 接管 | 状态周报、会议纪要、风险列表生成  | AI 草拟，人确认 |
| 人必须拥有 | 人际协调、优先级裁决、交付节奏把控 | 不变        |

**核心职责**

* 维护交付计划，识别跨人员/跨团队依赖
* 使用 AI 生成项目摘要、风险分析、里程碑报告
* 在小团队中此角色通常由产品经理或技术负责人兼任

**AI 角色**：AI 协调员（项目侧）

> AI 时代项目经理的执行负担大幅减轻，但协调与决策判断无法替代。5 人以下团队不需要独立此岗位。

***

## 验证层

验证层的人是 **AI 输出的最后一道关**。没有验证，AI 生成的错误会直接流入生产。

***

### 技术验证者

**对应传统岗位**：技术负责人（Tech Lead）/ 高级工程师

|       | 传统工作               | AI 时代变化            |
| ----- | ------------------ | ------------------ |
| AI 接管 | 代码格式检查、静态分析、重复模式识别 | AI 做初筛             |
| 人必须拥有 | 架构一致性、业务正确性、风险裁决   | 审查密度提高，因为 AI 提交量更大 |

**核心职责**

* 制定 AI 输出的审查标准和 checklist
* 对 AI 生成代码做最终技术裁决
* 将审查中发现的问题反馈到提示库

**AI 角色**：AI 审查员（技术裁决）

***

### 质量验证者

**对应传统岗位**：测试 / QA 工程师

|       | 传统工作                 | AI 时代变化       |
| ----- | -------------------- | ------------- |
| AI 接管 | 生成测试用例、接口测试脚本、回归用例草稿 | AI 提高覆盖广度     |
| 人必须拥有 | 覆盖盲区识别、业务场景验证、质量门禁判断 | 更聚焦于 AI 遗漏的边界 |

**核心职责**

* 使用 AI 生成测试用例，人工验证覆盖盲区
* 系统性审查 AI 生成代码的边界情况和异常路径
* 将发现的失败模式整理反馈到提示库

**AI 角色**：AI 审查员（质量专职）

***

### 工具守护者

**对应传统岗位**：平台 / DevOps 工程师

|       | 传统工作                        | AI 时代变化      |
| ----- | --------------------------- | ------------ |
| AI 接管 | 配置文件生成、CI 脚本草稿、changelog 生成 | AI 辅助生成      |
| 人必须拥有 | AI 工具链集成、成本监控、可靠性保障         | 新增 AI 工具运维职责 |

**核心职责**

* 将 AI 工具集成到 CI/CD（自动 review、生成测试、changelog）
* 监控 AI 调用的延迟、成本和失败率
* 维护团队 AI 工具版本和访问配置

**AI 角色**：工具工程师

***

## 兼任矩阵

### 3 人团队

| 人员 | AI 时代角色               | 对应传统岗位         |
| -- | --------------------- | -------------- |
| A  | 架构判断者 + 技术验证者         | 技术负责人兼架构师      |
| B  | 工程编排者 + 工具守护者         | 全栈 + DevOps    |
| C  | 产品判断者 + 质量验证者 + 交付编排者 | PM + QA + 项目经理 |

***

### 5 人团队

| 人员 | AI 时代角色       | 对应传统岗位      |
| -- | ------------- | ----------- |
| A  | 架构判断者 + 技术验证者 | 技术负责人兼架构师   |
| B  | 工程编排者         | 后端工程师       |
| C  | 工程编排者         | 前端工程师       |
| D  | 产品判断者 + 交付编排者 | 产品经理兼项目经理   |
| E  | 质量验证者 + 工具守护者 | QA + DevOps |

***

### 8 人团队

| 人员  | AI 时代角色       | 对应传统岗位      |
| --- | ------------- | ----------- |
| A   | 架构判断者         | 架构师         |
| B   | 技术验证者         | 技术负责人       |
| C/D | 工程编排者         | 后端工程师 × 2   |
| E   | 工程编排者         | 前端工程师       |
| F   | 产品判断者         | 产品经理        |
| G   | 交付编排者         | 项目经理        |
| H   | 质量验证者 + 工具守护者 | QA + DevOps |

***

## 兼任原则

1. **判断层不能降级**：架构决策和产品决策必须由人类做出，AI 只能提供选项，不能承担后果。
2. **验证层不能省略**：无论团队多小，AI 输出必须经过独立验证，生成者不能是最终审查人。
3. **编排能力是新核心技能**：写出高质量提示的能力，等同于传统工程师的编码能力，需要培养和考核。
4. **项目经理可以最晚独立**：5 人以下团队无需独立此岗位，由产品判断者兼任；8 人以上才考虑拆分。
5. **工具守护者不可缺席**：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/roles.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.