# Six Layer Architect

> 六层架构全栈开发技能，支持从任意层级发起贯穿式修改，自动协调UI层/前端服务层/前端API层/后端API层/后端服务层/数据层六层配合，实现跨层一致性代码生成与重构，适用于Vue3+FastAPI+PostgreSQL技术栈

- Skill: `morning-start/six-layer-architect` (Agent Skill, multi-file: 11 files)
- Install (CLI): `npx skillmds@latest add morning-start/six-layer-architect`
- Raw SKILL.md: https://api.skillmd.com/api/skills/morning-start/six-layer-architect/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Integrations & APIs
- Author: morning-start (https://skillmd.com/u/morning-start)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/morning-start/six-layer-architect

---


# 六层架构全栈生成器

## 任务目标

**核心能力**
- 本 Skill 用于：根据用户提供的功能意图或修改需求，自动生成或修改符合六层架构规范的完整实现方案
- 能力包含：
  - **贯穿式修改**：从任意层级发起修改，自动推导并协调其他五层配合
  - **需求解析与领域识别**：分析用户意图，识别涉及的业务领域和数据实体
  - **逐层代码生成/修改**：按数据流顺序生成或修改每一层的代码
  - **跨层一致性校验**：确保字段名、类型、错误处理在各层间保持一致
- 触发条件：
  - 用户提出新功能需求（如"添加用户评论功能"）
  - 用户提出修改需求（如"把用户名字段从可选改为必填"）
  - 用户从特定层级提出修改（如"后端API需要增加一个字段"）

**可选能力**
- 类型同步校验（参考 code_patterns.md）
- 安全审查检查（参考 security_checklist.md）
- 数据库迁移脚本生成

## 六层架构概览

```
┌─────────────────────────────────────────────────────────────┐
│   ┌──────────┐    ┌──────────┐    ┌──────────┐             │
│   │  UI 层   │───▶│ 前端服务 │───▶│ 前端 API │              │
│   │(Vue3)    │    │(Pinia)   │    │(Axios)   │              │
│   └──────────┘    └──────────┘    └────┬─────┘             │
│                              HTTP Request                   │
│                                        ▼                    │
│   ┌──────────┐    ┌──────────┐    ┌──────────┐             │
│   │ 数据层   │◀───│ 后端服务 │◀───│ 后端 API │              │
│   │(SQLAlch) │    │(Service) │    │(FastAPI) │              │
│   └──────────┘    └──────────┘    └──────────┘             │
└─────────────────────────────────────────────────────────────┘
```

## 贯穿式修改工作流

### 阶段 1：识别修改入口层

| 用户描述关键词 | 识别为入口层 | 示例 |
|---------------|-------------|------|
| "界面显示..."、"页面上..." | **UI 层** | "用户详情页要显示注册时间" |
| "Store里..."、"状态管理..." | **前端服务层** | "登录状态需要在刷新后保持" |
| "前端调用..."、"API接口..." | **前端 API 层** | "前端需要调用获取订单列表接口" |
| "后端接口..."、"API返回..." | **后端 API 层** | "用户列表接口需要支持分页" |
| "业务逻辑..."、"数据处理..." | **后端服务层** | "订单创建时要检查库存" |
| "数据库..."、"表结构..."、"字段..." | **数据层** | "用户表需要添加手机号字段" |

### 阶段 2：推导跨层影响

**修改影响推导矩阵**

| 入口层 | 向前推导（→ UI） | 向后推导（→ DB） |
|--------|-----------------|-----------------|
| **UI 层** | 无 | UI → 前端服务 → 前端API → 后端API → 后端服务 → 数据层 |
| **前端服务层** | ← UI | → 前端API → 后端API → 后端服务 → 数据层 |
| **前端 API 层** | ← 前端服务 ← UI | → 后端API → 后端服务 → 数据层 |
| **后端 API 层** | ← 前端API ← 前端服务 ← UI | → 后端服务 → 数据层 |
| **后端服务层** | ← 后端API ← 前端API ← 前端服务 ← UI | → 数据层 |
| **数据层** | ← 后端服务 ← 后端API ← 前端API ← 前端服务 ← UI | 无 |

### 阶段 3：执行贯穿式修改

1. **修改入口层**：根据用户需求修改入口层代码
2. **向前推导修改**：从入口层向前（UI方向）逐层推导需要配合的修改
3. **向后推导修改**：从入口层向后（数据库方向）逐层推导需要配合的修改
4. **跨层一致性校验**：字段名、类型、接口契约检查

## 操作步骤

### 步骤 1：解析修改需求

1. **识别入口层**：分析用户描述，使用关键词映射表确定从哪一层开始修改
2. **分析修改类型**：新增功能 / 字段变更 / 逻辑变更 / 接口变更
3. **确定影响范围**：简单修改（2-3层）/ 复杂修改（六层全部）

### 步骤 2：执行贯穿式修改

根据入口层选择修改模式：

**模式 A：从 UI 层开始（向后推导）**
- UI 层 → 前端服务层 → 前端 API 层 → 后端 API 层 → 后端服务层 → 数据层
- 场景："页面上要显示用户的注册时间"

**模式 B：从数据层开始（向前推导）**
- 数据层 → 后端服务层 → 后端 API 层 → 前端 API 层 → 前端服务层 → UI 层
- 场景："用户表需要添加手机号字段"

**模式 C：从中间层开始（双向推导）**
- 向后：中间层 → 后端服务层 → 数据层
- 向前：中间层 ← 前端 API 层 ← 前端服务层 ← UI 层
- 场景："后端 API 需要增加搜索参数"

### 步骤 3：跨层一致性校验

**字段名一致性**

| 层级 | 命名风格 | 示例 |
|------|---------|------|
| UI 层 / 前端服务层 | 驼峰命名 | `registrationTime` |
| 前端 API 层 / 后端层 / 数据层 | 蛇形命名 | `registration_time` |

**类型匹配检查**

| TypeScript | Pydantic | SQLAlchemy |
|-----------|----------|------------|
| `string` | `str` | `String` |
| `number` | `int`/`float` | `Integer`/`Float` |
| `boolean` | `bool` | `Boolean` |
| `Date`/`string` | `datetime` | `DateTime` |
| `T \| null` | `Optional[T]` | `nullable=True` |

**接口契约检查**
- 前端 API 请求参数 ↔ 后端 API 接收参数
- 后端 API 响应格式 ↔ 前端 API 期望格式
- 前端服务层状态 ↔ UI 层显示绑定

### 步骤 4：输出修改方案

按照以下结构输出：

```markdown
## 修改方案：[功能名称]

### 修改入口
- **入口层**：[层级名称]
- **修改原因**：[用户原始需求]

### 逐层修改详情
#### 1. [层级1] 修改
**变更内容**：[具体修改点]
**代码变更**：[代码片段]

### 跨层一致性校验
- [ ] 字段名一致性
- [ ] 类型匹配
- [ ] 接口契约

### 数据库迁移（如需要）
```bash
alembic revision --autogenerate -m "描述"
```
```

## 资源索引

| 资源 | 路径 | 用途 |
|------|------|------|
| 贯穿式修改工作流 | [references/cross_layer_workflow.md](references/cross_layer_workflow.md) | 详细的跨层修改流程和示例 |
| 架构层说明 | [references/architecture_layers.md](references/architecture_layers.md) | 六层架构详细职责与约束 |
| 代码模式 | [references/code_patterns.md](references/code_patterns.md) | 常见代码模式、类型同步 |
| 安全检查清单 | [references/security_checklist.md](references/security_checklist.md) | 安全审查要点 |
| 代码模板 | [assets/templates/](assets/templates/) | 各层代码模板文件 |

## 注意事项

- **识别入口层是关键**：准确判断用户从哪一层发起修改，决定推导方向
- **双向推导**：中间层修改需要同时向前和向后推导影响
- **保持一致性**：字段命名、类型定义、接口契约必须在各层保持一致
- **数据库迁移**：数据层变更必须生成 Alembic 迁移脚本
- **充分利用智能体能力**：让智能体自动推导跨层影响，避免遗漏

## 使用示例

### 示例 1：从 UI 层发起的修改

**用户需求**："用户详情页要显示注册时间"

**入口层识别**：UI 层（关键词"页面显示"）

**推导过程**：UI 层需要显示 → 需要 Store 提供 → 需要 API 返回 → 后端需要查询 → 数据库需要字段

**修改方案**：
1. **数据层**：添加 `registration_time` 字段到 users 表
2. **后端服务层**：User 模型添加字段
3. **后端 API 层**：UserResponse 添加 `registration_time` 字段
4. **前端 API 层**：TypeScript User 接口添加字段
5. **前端服务层**：userStore 添加 `registrationTime` 状态
6. **UI 层**：UserProfile 组件添加注册时间显示

### 示例 2：从数据层发起的修改

**用户需求**："用户表需要添加手机号字段，用于短信通知"

**入口层识别**：数据层（关键词"表添加字段"）

**推导过程**：数据库有字段 → 后端可以存取 → API 可以传输 → 前端可以调用 → Store 可以管理 → UI 可以输入/显示

**修改方案**：
1. **数据层**：添加 `phone_number` 字段到 users 表
2. **后端服务层**：UserService 添加手机号验证逻辑
3. **后端 API 层**：添加手机号参数验证
4. **前端 API 层**：更新 User 接口
5. **前端服务层**：userStore 添加手机号状态
6. **UI 层**：用户资料编辑页添加手机号输入框

### 示例 3：从中间层发起的修改

**用户需求**："后端 API 需要增加按状态筛选订单的功能"

**入口层识别**：后端 API 层（关键词"API增加"）

**推导过程**：
- 向后：API 参数 → 服务层筛选逻辑 → 数据库查询条件
- 向前：API 参数 ← 前端调用 ← Store 方法 ← UI 组件

**修改方案**：
1. **后端 API 层**：`GET /orders` 添加 `status` 查询参数
2. **后端服务层**：OrderService 添加按状态筛选逻辑
3. **数据层**：确保 orders 表有 `status` 字段索引
4. **前端 API 层**：`getOrders()` 添加 `status` 参数
5. **前端服务层**：orderStore 添加筛选状态
6. **UI 层**：订单列表页添加状态筛选下拉框