六层架构全栈生成器

任务目标

核心能力

• 本 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：输出修改方案

按照以下结构输出：

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

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

### 逐层修改详情
#### 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 层**：订单列表页添加状态筛选下拉框