six-layer-architect

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

六层架构全栈生成器

Six-Layer Architecture Full-Stack Generator

任务目标

Task Objectives

核心能力

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

可选能力

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

Core Capabilities

This Skill is used to: automatically generate or modify complete implementation plans that comply with the six-layer architecture specifications based on user-provided functional intentions or modification requirements
Capabilities include:
- Cross-layer Modification: Initiate modifications from any layer, automatically deduce and coordinate the collaboration of the other five layers
- Requirement Parsing and Domain Identification: Analyze user intentions, identify involved business domains and data entities
- Layer-by-layer Code Generation/Modification: Generate or modify code for each layer in the order of data flow
- Cross-layer Consistency Check: Ensure field names, types, and error handling remain consistent across all layers
Trigger Conditions:
- User proposes new functional requirements (e.g., "Add user comment function")
- User proposes modification requirements (e.g., "Change the user name field from optional to required")
- User proposes modifications from a specific layer (e.g., "Backend API needs to add a field")

Optional Capabilities

Type synchronization check (refer to code_patterns.md)
Security review check (refer to security_checklist.md)
Database migration script generation

六层架构概览

Overview of Six-Layer Architecture

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

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

贯穿式修改工作流

Cross-layer Modification Workflow

阶段 1：识别修改入口层

Phase 1: Identify the Modification Entry Layer

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

User Description Keywords	Identified as Entry Layer	Example
"UI display...", "page..."	UI Layer	"User detail page needs to display registration time"
"Store...", "state management..."	Frontend Service Layer	"Login state needs to persist after refresh"
"Frontend call...", "API interface..."	Frontend API Layer	"Frontend needs to call the order list interface"
"Backend interface...", "API returns..."	Backend API Layer	"User list interface needs to support pagination"
"Business logic...", "data processing..."	Backend Service Layer	"Check inventory when creating an order"
"Database...", "table structure...", "field..."	Data Layer	"User table needs to add a phone number field"

阶段 2：推导跨层影响

Phase 2: Deduce Cross-layer Impacts

修改影响推导矩阵

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

Modification Impact Deduction Matrix

Entry Layer	Forward Deduction (→ UI)	Backward Deduction (→ DB)
UI Layer	None	UI → Frontend Service → Frontend API → Backend API → Backend Service → Data Layer
Frontend Service Layer	← UI	→ Frontend API → Backend API → Backend Service → Data Layer
Frontend API Layer	← Frontend Service ← UI	→ Backend API → Backend Service → Data Layer
Backend API Layer	← Frontend API ← Frontend Service ← UI	→ Backend Service → Data Layer
Backend Service Layer	← Backend API ← Frontend API ← Frontend Service ← UI	→ Data Layer
Data Layer	← Backend Service ← Backend API ← Frontend API ← Frontend Service ← UI	None

阶段 3：执行贯穿式修改

Phase 3: Execute Cross-layer Modification

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

Modify Entry Layer: Modify the entry layer code according to user requirements
Forward Deduction Modification: Deduce required collaborative modifications layer by layer from the entry layer towards the UI direction
Backward Deduction Modification: Deduce required collaborative modifications layer by layer from the entry layer towards the database direction
Cross-layer Consistency Check: Check field names, types, and interface contracts

操作步骤

Operation Steps

步骤 1：解析修改需求

Step 1: Parse Modification Requirements

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

Identify Entry Layer: Analyze user description, use the keyword mapping table to determine which layer to start modification from
Analyze Modification Type: New feature addition / Field change / Logic change / Interface change
Determine Impact Scope: Simple modification (2-3 layers) / Complex modification (all six layers)

步骤 2：执行贯穿式修改

Step 2: Execute Cross-layer Modification

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

模式 A：从 UI 层开始（向后推导）

UI 层 → 前端服务层 → 前端 API 层 → 后端 API 层 → 后端服务层 → 数据层
场景："页面上要显示用户的注册时间"

模式 B：从数据层开始（向前推导）

数据层 → 后端服务层 → 后端 API 层 → 前端 API 层 → 前端服务层 → UI 层
场景："用户表需要添加手机号字段"

模式 C：从中间层开始（双向推导）

向后：中间层 → 后端服务层 → 数据层
向前：中间层 ← 前端 API 层 ← 前端服务层 ← UI 层
场景："后端 API 需要增加搜索参数"

Select modification mode based on the entry layer:

Mode A: Start from UI Layer (Backward Deduction)

UI Layer → Frontend Service Layer → Frontend API Layer → Backend API Layer → Backend Service Layer → Data Layer
Scenario: "User detail page needs to display registration time"

Mode B: Start from Data Layer (Forward Deduction)

Data Layer → Backend Service Layer → Backend API Layer → Frontend API Layer → Frontend Service Layer → UI Layer
Scenario: "User table needs to add a phone number field"

Mode C: Start from Middle Layer (Bidirectional Deduction)

Backward: Middle Layer → Backend Service Layer → Data Layer
Forward: Middle Layer ← Frontend API Layer ← Frontend Service Layer ← UI Layer
Scenario: "Backend API needs to add search parameters"

步骤 3：跨层一致性校验

Step 3: Cross-layer Consistency Check

字段名一致性

层级	命名风格	示例
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 层显示绑定

Field Name Consistency

Layer	Naming Convention	Example
UI Layer / Frontend Service Layer	camelCase	`registrationTime`
Frontend API Layer / Backend Layers / Data Layer	snake_case	`registration_time`

Type Matching Check

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

Interface Contract Check

Frontend API request parameters ↔ Backend API received parameters
Backend API response format ↔ Frontend API expected format
Frontend Service Layer state ↔ UI Layer display binding

步骤 4：输出修改方案

Step 4: Output Modification Plan

按照以下结构输出：

markdown

undefined

Output in the following structure:

markdown

undefined

修改方案：[功能名称]

Modification Plan: [Feature Name]

修改入口

Modification Entry

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

Entry Layer: [Layer Name]
Modification Reason: [Original User Requirement]

逐层修改详情

Layer-by-layer Modification Details

1. [层级1] 修改

1. [Layer 1] Modification

变更内容：[具体修改点] 代码变更：[代码片段]

Change Content: [Specific Modification Points] Code Changes: [Code Snippets]

跨层一致性校验

Cross-layer Consistency Check

数据库迁移（如需要）

Database Migration (if needed)

bash

alembic revision --autogenerate -m "描述"

undefined

bash

alembic revision --autogenerate -m "description"

undefined

资源索引

Resource Index

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

Resource	Path	Purpose
Cross-layer Modification Workflow	references/cross_layer_workflow.md	Detailed cross-layer modification workflow and examples
Architecture Layer Description	references/architecture_layers.md	Detailed responsibilities and constraints of six-layer architecture
Code Patterns	references/code_patterns.md	Common code patterns, type synchronization
Security Checklist	references/security_checklist.md	Security review key points
Code Templates	assets/templates/	Code template files for each layer

注意事项

Notes

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

Identifying the entry layer is crucial: Accurately determining which layer the user initiates modification from determines the deduction direction
Bidirectional deduction: Modifications in middle layers require both forward and backward impact deduction
Maintain consistency: Field naming, type definitions, and interface contracts must remain consistent across all layers
Database migration: Data layer changes must generate Alembic migration scripts
Make full use of agent capabilities: Let the agent automatically deduce cross-layer impacts to avoid omissions

使用示例

Usage Examples

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

Example 1: Modification Initiated from UI Layer

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

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

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

修改方案：

数据层：添加
```
registration_time
```
字段到 users 表
后端服务层：User 模型添加字段
后端 API 层：UserResponse 添加
```
registration_time
```
字段
前端 API 层：TypeScript User 接口添加字段
前端服务层：userStore 添加
```
registrationTime
```
状态
UI 层：UserProfile 组件添加注册时间显示

User Requirement: "User detail page needs to display registration time"

Entry Layer Identification: UI Layer (keyword "page display")

Deduction Process: UI layer needs to display → requires Store to provide → requires API to return → backend needs to query → database needs the field

Modification Plan:

Data Layer: Add
```
registration_time
```
field to users table
Backend Service Layer: Add field to User model
Backend API Layer: Add
```
registration_time
```
field to UserResponse
Frontend API Layer: Add field to TypeScript User interface
Frontend Service Layer: Add
```
registrationTime
```
state to userStore
UI Layer: Add registration time display to UserProfile component

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

Example 2: Modification Initiated from Data Layer

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

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

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

修改方案：

数据层：添加
```
phone_number
```
字段到 users 表
后端服务层：UserService 添加手机号验证逻辑
后端 API 层：添加手机号参数验证
前端 API 层：更新 User 接口
前端服务层：userStore 添加手机号状态
UI 层：用户资料编辑页添加手机号输入框

User Requirement: "User table needs to add a phone number field for SMS notifications"

Entry Layer Identification: Data Layer (keyword "table add field")

Deduction Process: Database has the field → backend can access and store → API can transmit → frontend can call → Store can manage → UI can input/display

Modification Plan:

Data Layer: Add
```
phone_number
```
field to users table
Backend Service Layer: Add phone number verification logic to UserService
Backend API Layer: Add phone number parameter validation
Frontend API Layer: Update User interface
Frontend Service Layer: Add phone number state to userStore
UI Layer: Add phone number input box to user profile edit page

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

Example 3: Modification Initiated from Middle Layer

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

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

推导过程：

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

修改方案：

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

User Requirement: "Backend API needs to add order filtering by status"

Entry Layer Identification: Backend API Layer (keyword "API add")

Deduction Process:

Backward: API parameters → Service layer filtering logic → Database query conditions
Forward: API parameters ← Frontend call ← Store method ← UI component

Modification Plan:

Backend API Layer: Add
```
status
```
query parameter to
```
GET /orders
```
Backend Service Layer: Add status-based filtering logic to OrderService
Data Layer: Ensure orders table has index for
```
status
```
field
Frontend API Layer: Add
```
status
```
parameter to
```
getOrders()
```
Frontend Service Layer: Add filter status to orderStore
UI Layer: Add status filter dropdown to order list page