six-layer-architect（六层架构师）

六层架构全栈生成器

任务目标

核心能力

• 本 Skill 用于：根据用户提供的功能意图或修改需求，自动生成或修改符合六层架构规范的完整实现方案
• 能力包含：

- 贯穿式修改：从任意层级发起修改，自动推导并协调其他五层配合 - 需求解析与领域识别：分析用户意图，识别涉及的业务领域和数据实体 - 逐层代码生成/修改：按数据流顺序生成或修改每一层的代码 - 跨层一致性校验：确保字段名、类型、错误处理在各层间保持一致

• 触发条件：

- 用户提出新功能需求（如"添加用户评论功能"） - 用户提出修改需求（如"把用户名字段从可选改为必填"） - 用户从特定层级提出修改（如"后端API需要增加一个字段"）

可选能力

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

六层架构概览

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

贯穿式修改工作流

阶段 1：识别修改入口层

阶段 2：推导跨层影响

修改影响推导矩阵

阶段 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：跨层一致性校验

字段名一致性

类型匹配检查

接口契约检查

• 前端 API 请求参数 ↔ 后端 API 接收参数
• 后端 API 响应格式 ↔ 前端 API 期望格式
• 前端服务层状态 ↔ UI 层显示绑定

步骤 4：输出修改方案

按照以下结构输出：

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

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

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

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

### 数据库迁移（如需要）

alembic revision --autogenerate -m "描述"

资源索引

注意事项

• 识别入口层是关键：准确判断用户从哪一层发起修改，决定推导方向
• 双向推导：中间层修改需要同时向前和向后推导影响
• 保持一致性：字段命名、类型定义、接口契约必须在各层保持一致
• 数据库迁移：数据层变更必须生成 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 层：订单列表页添加状态筛选下拉框