---
name: 部门协作章程
description: 定义 8 大部门的职责边界、协作流程、接口规范和决策权限，是项目运行的根本制度。
emoji: 📐
color: blue
group: 管理组
---

# 部门协作章程

## 一、部门总览

| # | 部门 | 人数 | 核心职责 | 汇报对象 |
|---|------|------|---------|---------|
| 👔 | 管理组 | 10 | 战略决策、资源调配、需求拆解、质量终审 | 用户 |
| 📦 | 产品部 | 7 | 需求管理、产品路线图、市场研究、PRD 输出 | 产品总监→管理组 |
| 🎨 | 设计部 | 10 | UI/UX 设计、Tailwind 设计系统、视觉规范 | 项目经理→管理组 |
| 🏗️ | 工程部 | 47 | 后端开发、数据库、API、前端实现 | CTO→管理组 |
| 🧪 | 测试部 | 35 | 测试方案、质量验收、缺陷追踪、回归验证 | 质量总监→管理组 |
| 🔧 | JC组 | 11 | 运维部署、灾备、日志、缓存、Nginx/SSH | CTO→管理组 |
| 🛡️ | ECC组 | 14 | 安全审计、编码规范、文档、深度研究、TDD | CTO→管理组 |
| 🤖 | AG组 | 58 | API 设计、AI 工具、代码审查、外部情报投喂 | CTO→管理组 |

---

## 二、协作流程

### 2.1 全流程图

```
                              ┌─────────────────────────────────────────┐
                              │                                         │
用户 ──▶ 项目经理（唯一入口）     │          AG 组（横向独立支撑）            │
                              │   外部情报投喂 · AI 工具 · 代码审查 · 性能优化  │
═══════════════════════════════════════════════════════════════════════ │
▼                                                                       │
管理组（拆解分派 · 资源调配）                                              │
  │                                                                     │
  ▼                                                                     │
┌──────────────────────────┐                                             │
│ 阶段 1 · 立项 · 产品部主导  │                                             │
├──────────────────────────┤                                             │
│ 产品经理       → PRD 输出       │                                        │
│ Sprint 排序师   → 优先级列表    │                                        │
│ 趋势研究员      → 竞品分析      │                                        │
│ 产品能力评估    → 实现契约      │                                        │
│                              │                                         │
│ 产品总监 → 审批 ──┐            │                                        │
└──────────────────│───────────┘                                         │
                   ▼                                                     │
┌──────────────────────────┐                                             │
│ 阶段 2 · 设计 · 设计部主导  │                                             │
├──────────────────────────┤                                             │
│ 趋势研究员      → 设计趋势报告  │                                        │
│ 灵感分析器      → 色彩/字体分析 │                                        │
│ 情绪板创作者    → 视觉方向     │                                         │
│ 配色策展人      → OKLCH 色板   │                                        │
│ 字体选择器      → 字体配对     │                                         │
│ UX 架构师       → CSS 布局框架  │                                        │
│ UI 设计师       → 组件库 + 令牌 │                                        │
│ 前端设计师      → Tailwind 落地 │                                        │
│ 设计向导        → 一站式编排(可选)│                                       │
└──────────────────────────┘                                             │
                   ▼                                                     │
┌──────────────────────────┐                                             │
│ 阶段 3 · 开发 · 工程部主导  │◀──── AG 组代码审查 ──── 贯穿全流程 ────▶    │
├──────────────────────────┤                                             │
│ 软件架构师      → 技术方案    │                                          │
│ 后端架构师      → 路由+数据模型│                                          │
│ FastAPI 开发    → API 实现   │                                          │
│ 数据库专家      → Schema+迁移 │                                          │
│ 前端开发者      → Tailwind 页面│                                         │
│ 代码审查员      → 审查报告    │                                          │
└──────────────────────────┘                                             │
                   ▼                                                     │
┌──────────────────────────┐                                             │
│ ECC 组 · 安全 / 编码规范   │◀───────────────────────────────────────── │
├──────────────────────────┤                                             │
│ 安全审查 → 安全审计报告     │                                             │
│ 编码规范 → 规范合规检查     │                                             │
└──────────────────────────┘                                             │
                   ▼                                                     │
┌──────────────────────────┐                                             │
│ 阶段 4 · 测试 · 测试部主导  │                                             │
├──────────────────────────┤                                             │
│ 测试结果分析师  → 测试方案  │                                            │
│ API 测试员      → API 测试报告│                                          │
│ 性能基准师      → 性能基准数据│                                          │
│ E2E 测试        → E2E 报告  │                                           │
│ 安全测试        → 安全测试报告│                                          │
│ Senior QA       → 综合质量评估│                                         │
│ Bug Fix Brief   → 修复优先级 │                                          │
│                              │                                         │
│ 质量总监 → 放行/驳回 ──┐      │                                         │
└──────────────────────│─────┘                                           │
                       ▼                                                 │
┌──────────────────────────┐                                             │
│ JC 组 · 部署             │                                              │
├──────────────────────────┤                                             │
│ 灾备规划 → 回滚方案       │                                             │
│ 运维自动化 → Docker/CI/CD │                                             │
└──────────────────────────┘                                             │
                       ▼                                                 │
┌──────────────────────────┐                                             │
│ 阶段 5 · 发布 · 管理组终审  │                                             │
├──────────────────────────┤                                             │
│ 运维总监 → 发布许可        │                                             │
│ 项目经理 → 最终放行 ✅     │                                             │
└──────────────────────────┘                                             │
                              │                                         │
                              └─────────────────────────────────────────┘
```

### 2.2 各阶段详细说明

#### 阶段 1：立项（产品部主导）

| 步骤 | 执行者 | 输入 | 输出 |
|------|--------|------|------|
| 1.1 | 管理组 | 用户需求 | 项目章程、资源分配 |
| 1.2 | 产品部·产品经理 | 项目章程 | 产品需求文档（PRD） |
| 1.3 | 产品部·Sprint 排序师 | PRD | Sprint 优先级列表 |
| 1.4 | 产品部·趋势研究员 | 市场数据 | 竞品分析报告 |
| 1.5 | 产品部·产品能力评估 | PRD | 实现契约（接口/约束/未决项） |
| 1.6 | 管理组·产品总监 | PRD + Sprint | 最终审批 |

#### 阶段 2：设计（设计部主导）

| 步骤 | 执行者 | 输入 | 输出 |
|------|--------|------|------|
| 2.1 | 设计部·趋势研究员 | PRD | 设计趋势报告 |
| 2.2 | 设计部·灵感分析器 | 参考网站/组件库 | 色彩/字体/布局分析 |
| 2.3 | 设计部·情绪板创作者 | 趋势+灵感 | 视觉方向提案 |
| 2.4 | 设计部·配色策展人 | 情绪板 | 配色方案（OKLCH 色板） |
| 2.5 | 设计部·字体选择器 | 情绪板 | 字体配对方案 |
| 2.6 | 设计部·UX 架构师 | 配色+字体 | CSS 架构 + 布局框架 |
| 2.7 | 设计部·UI 设计师 | UX 架构 | 组件库 + 设计令牌 |
| 2.8 | 设计部·前端设计师 | 组件库 | Tailwind 代码落地 |
| 2.9 | 设计部·设计向导 | PRD | 一站式设计编排（可选流程） |

#### 阶段 3：开发（工程部主导）

| 步骤 | 执行者 | 输入 | 输出 |
|------|--------|------|------|
| 3.1 | 工程部·软件架构师 | PRD + 设计系统 | 技术方案文档 |
| 3.2 | 工程部·后端架构师 | 技术方案 | FastAPI 路由 + 数据模型 |
| 3.3 | 工程部·FastAPI/Python 开发 | 数据模型 | API 端点实现 |
| 3.4 | 工程部·数据库专家 | 数据模型 | Schema + 迁移 + 索引 |
| 3.5 | 工程部·前端开发者 | API + 设计系统 | Tailwind 页面实现 |
| 3.6 | 工程部·代码审查员 | 代码 | 审查报告 |

> **AG 组**（外部情报投喂 · AI 工具 · 代码审查 · 性能优化 · API 设计）—— 不参与流水线排队。当各部门有问题时，AG 组到外部搜索、调研、获取情报，然后投喂给对应部门。横向独立支撑贯穿全流程。

#### ECC 组 · 安全 / 编码规范

| 步骤 | 执行者 | 输入 | 输出 |
|------|--------|------|------|
| E1 | ECC组·安全审查 | 代码 | 安全审计报告 |
| E2 | ECC组·编码规范 | 代码 | 规范合规检查 |

#### 阶段 4：测试（测试部主导）

| 步骤 | 执行者 | 输入 | 输出 |
|------|--------|------|------|
| 4.1 | 测试部·测试结果分析师 | 技术方案 | 测试方案文档 |
| 4.2 | 测试部·API 测试员 | API 端点 | API 测试报告 |
| 4.3 | 测试部·性能基准师 | 系统 | 性能基准数据 |
| 4.4 | 测试部·E2E 测试 | 完整功能 | E2E 测试报告 |
| 4.5 | 测试部·安全测试 | 系统 | 安全测试报告 |
| 4.6 | 测试部·Senior QA | 全部报告 | 综合质量评估 |
| 4.7 | 测试部·Bug Fix Brief | 缺陷列表 | 修复优先级 |
| 4.8 | 管理组·质量总监 | 综合报告 | 放行/驳回决策 |

#### JC 组 · 部署

| 步骤 | 执行者 | 输入 | 输出 |
|------|--------|------|------|
| J1 | JC组·灾备规划 | 系统 | 回滚方案 |
| J2 | JC组·运维自动化 | 代码 | Docker/CI/CD 配置 |

#### 阶段 5：发布（管理组终审）

| 步骤 | 执行者 | 输入 | 输出 |
|------|--------|------|------|
| 5.1 | 管理组·运维总监 | 测试报告+回滚方案 | 发布许可 |
| 5.2 | 管理组·项目经理 | 全部交付物 | 最终放行 |

---

## 三、部门接口规范

### 3.1 产品部 → 设计部

```
产品部交付：
  - PRD（产品需求文档）
  - 用户画像 + 场景描述
  - 功能优先级列表
  
设计部接收后启动：
  - 设计趋势研究 → 情绪板 → 配色/字体 → UX 架构 → UI 组件
```

### 3.2 设计部 → 工程部

```
设计部交付：
  - Tailwind CSS v4 @theme 配置（颜色/字体/间距/圆角/阴影）
  - 组件库（HTML + Tailwind 类名）
  - 布局框架（Stacked/Sidebar/Multi-Column）
  - 响应式断点规格 + 暗色模式策略
  - 设计令牌文档

工程部接收后启动：
  - 技术方案设计 → 数据建模 → API 开发 → 前端实现
```

### 3.3 工程部 → 测试部

```
工程部交付：
  - 可部署的代码包（含 CI/CD 配置）
  - API 文档（Swagger/OpenAPI）
  - 数据库迁移脚本
  - 部署说明 + 环境变量清单

测试部接收后启动：
  - 制定测试方案 → 功能测试 → 性能测试 → 安全测试 → 验收
```

### 3.4 横向组支撑

```
ECC组提供：安全审计、代码规范检查、TDD 工作流、技术文档
JC组提供：CI/CD 流水线、Docker 配置、Nginx 路由、灾备方案、回滚方案、缓存层
AG组提供：外部情报投喂、API 设计审查、性能剖析、代码审查、AI 工具（横向独立贯穿全流程）
```

### 3.5 测试部 → 管理组

```
测试部交付：
  - 测试报告（通过率、缺陷数、严重程度）
  - 性能基准对比（vs 上一版本）
  - 安全扫描结果
  - 验收结论（通过/有条件通过/驳回）

管理组决策：
  - 通过 → 发布
  - 有条件通过 → 指定必须修复项，限期完成
  - 驳回 → 返回工程部，附测试部缺陷清单
```

---

## 四、决策权限矩阵

| 决策类型 | AG组 | JC组 | ECC组 | 工程部 | 测试部 | 设计部 | 产品部 | 管理组 |
|---------|------|------|------|--------|--------|--------|--------|--------|
| 技术选型 | 建议 | 建议 | 建议 | **决定** | - | - | - | 审批 |
| 部署发布 | - | 执行 | - | 准备 | - | - | - | **批准** |
| 回滚 | - | **执行** | - | 配合 | - | - | - | 通知 |
| 架构变更 | 审查 | - | 审查 | 提案 | - | - | - | **批准** |
| 安全策略 | - | - | **制定** | 执行 | 验证 | - | - | 审批 |
| 编码规范 | 建议 | - | **制定** | 执行 | - | - | - | - |
| 设计系统 | - | - | - | 实现 | - | **制定** | - | 审批 |
| PRD/路线图 | - | - | - | - | - | - | **制定** | 审批 |
| 测试标准 | - | - | - | - | **制定** | - | - | 审批 |
| 质量放行 | - | - | - | - | 建议 | - | - | **决定** |
| 资源调配 | - | - | - | - | - | - | - | **决定** |

---

## 五、沟通规则

### 5.1 用户交互原则（最高优先级）

**核心原则：用户只需要和项目经理对话。除非用户明确指定某个部门，否则所有内部调度由管理组自行完成。**

```
用户
  │
  │  「我要做一个 XX 功能」         ← 用户只需描述需求，无需关心哪个部门执行
  │  「设计部直接出个方案看看」
  │  「让 ECC 组审计一下安全」
  │
  ▼
项目经理（用户唯一联系人）
  │
  │  项目经理理解需求后，在管理组内部协调：
  │  - 需要 PRD → 通知产品总监安排产品部
  │  - 需要设计 → 通知项目经理（设计）安排设计部
  │  - 需要开发 → 通知 CTO 安排工程部 + 横向组
  │  - 需要测试 → 通知质量总监安排测试部
  │
  ▼
管理组 ──内部分派──▶ 各执行部门
```

**两种情况：**

| 场景 | 用户怎么做 | 管理组怎么做 |
|------|-----------|-------------|
| 用户**未指定**部门 | 只描述需求，发给项目经理 | 管理组自行判断需要哪些部门参与，内部调度 |
| 用户**明确指定**了部门 | 如「让设计部直接出方案」 | 管理组直接路由到指定部门，无需判断 |

### 5.2 指令流向

```
用户 ←──→ 项目经理（双向唯一通道）
              │
              │ 项目经理在管理组内部协调
              ▼
         管理组（集体决策）
              │
              │ 按章程分派任务
              ▼
    产品部 / 设计部 / 工程部 / 测试部
              │
              │ 横向支撑
              ▼
    JC组 / ECC组 / AG组
```

**关键约束：**
- 用户不需要知道哪个部门在执行——项目经理负责翻译用户需求为部门任务
- 项目经理是管理组成员，直接参与管理组决策，无需额外转述
- 各部门之间不直接接收用户指令（除非用户明确点名）
- 所有跨部门协调由管理组内部消化，不暴露给用户

### 5.3 冲突升级

1. **同级协商**：部门间直接沟通解决
2. **CTO 仲裁**：技术争议由 CTO 裁定
3. **产品总监 仲裁**：需求/设计争议由产品总监裁定
4. **项目经理 终裁**：无法达成共识时，项目经理最终决定

### 5.4 信息同步

- 跨部门决策必须书面记录（PR 评论 / 文档 / issue）
- 接口变更（API / Schema / 设计令牌）必须通知所有下游部门
- 阻塞项必须在管理组周会中提出

---

## 六、附则

- 本章程由管理组制定和维护
- 部门职责边界以 `docs/skills/` 中各文件的 `group:` 标记为准
- 成员变动需同步更新 `docs/team/` 对应部门文件
- 本章程每季度评审一次
