六层架构全栈生成器
任务目标
核心能力
- 本 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：执行贯穿式修改
- 修改入口层：根据用户需求修改入口层代码
- 向前推导修改：从入口层向前（UI方向）逐层推导需要配合的修改
- 向后推导修改：从入口层向后（数据库方向）逐层推导需要配合的修改
- 跨层一致性校验：字段名、类型、接口契约检查
操作步骤
步骤 1：解析修改需求
- 识别入口层：分析用户描述，使用关键词映射表确定从哪一层开始修改
- 分析修改类型：新增功能 / 字段变更 / 逻辑变更 / 接口变更
- 确定影响范围：简单修改（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] 修改
**变更内容**：[具体修改点]
**代码变更**：[代码片段]
### 跨层一致性校验
- [ ] 字段名一致性
- [ ] 类型匹配
- [ ] 接口契约
### 数据库迁移（如需要）alembic revision --autogenerate -m "描述"
资源索引
| 资源 | 路径 | 用途 |
|---|---|---|
| 贯穿式修改工作流 | references/cross_layer_workflow.md | 详细的跨层修改流程和示例 |
| 架构层说明 | references/architecture_layers.md | 六层架构详细职责与约束 |
| 代码模式 | references/code_patterns.md | 常见代码模式、类型同步 |
| 安全检查清单 | references/security_checklist.md | 安全审查要点 |
| 代码模板 | assets/templates/ | 各层代码模板文件 |
注意事项
- 识别入口层是关键：准确判断用户从哪一层发起修改，决定推导方向
- 双向推导：中间层修改需要同时向前和向后推导影响
- 保持一致性：字段命名、类型定义、接口契约必须在各层保持一致
- 数据库迁移：数据层变更必须生成 Alembic 迁移脚本
- 充分利用智能体能力：让智能体自动推导跨层影响，避免遗漏
使用示例
示例 1：从 UI 层发起的修改
用户需求："用户详情页要显示注册时间"
入口层识别：UI 层（关键词"页面显示"）
推导过程：UI 层需要显示 → 需要 Store 提供 → 需要 API 返回 → 后端需要查询 → 数据库需要字段
修改方案：
- 数据层：添加
registration_time字段到 users 表 - 后端服务层：User 模型添加字段
- 后端 API 层：UserResponse 添加
registration_time字段 - 前端 API 层：TypeScript User 接口添加字段
- 前端服务层：userStore 添加
registrationTime状态 - UI 层：UserProfile 组件添加注册时间显示
示例 2：从数据层发起的修改
用户需求："用户表需要添加手机号字段，用于短信通知"
入口层识别：数据层（关键词"表添加字段"）
推导过程：数据库有字段 → 后端可以存取 → API 可以传输 → 前端可以调用 → Store 可以管理 → UI 可以输入/显示
修改方案：
- 数据层：添加
phone_number字段到 users 表 - 后端服务层：UserService 添加手机号验证逻辑
- 后端 API 层：添加手机号参数验证
- 前端 API 层：更新 User 接口
- 前端服务层：userStore 添加手机号状态
- UI 层：用户资料编辑页添加手机号输入框
示例 3：从中间层发起的修改
用户需求："后端 API 需要增加按状态筛选订单的功能"
入口层识别：后端 API 层（关键词"API增加"）
推导过程：
- 向后：API 参数 → 服务层筛选逻辑 → 数据库查询条件
- 向前：API 参数 ← 前端调用 ← Store 方法 ← UI 组件
修改方案：
- 后端 API 层：
GET /orders添加status查询参数 - 后端服务层：OrderService 添加按状态筛选逻辑
- 数据层：确保 orders 表有
status字段索引 - 前端 API 层：
getOrders()添加status参数 - 前端服务层：orderStore 添加筛选状态
- UI 层：订单列表页添加状态筛选下拉框