AI 全栈开发实战手册
从全栈工程师视角,讲解如何用 AI 贯穿「前端 / 后端 / 数据库 / API / 测试 / 部署」六个技术层,核心命题是跨层一致性——全栈开发区别于"会用几个框架"的关键所在。
一、AI 全栈开发总览
1.1 什么是全栈开发
全栈开发(Full-Stack Development)指一个开发者能够独立完成一个应用从数据存储到用户界面的所有技术层。一个典型 Web 应用的完整链路:
用户界面(前端) → 业务逻辑(后端) → 数据存储(数据库) ↑ ↑ ↑ Vue/React Node/Java/PHP MySQL/Redis └────────────────┴────────────────────┘ 部署运维(Nginx/Docker/CI)全栈工程师的核心价值不在"每层都精通",而在能保证各层之间的衔接不出错——数据模型在前端、后端、数据库三处定义保持一致;API 契约前后端对齐;错误码统一。
1.2 AI 在全栈六层的角色
| 技术层 | AI 承担的角色 | 典型产出 |
|---|---|---|
| 前端层 | 组件、页面、状态管理、样式 | Vue/React 组件、请求封装 |
| 后端层 | 路由、服务、中间件、鉴权 | Controller/Service、JWT 中间件 |
| 数据库层 | 表结构、SQL、索引 | DDL、建表语句、慢查询优化 |
| API 层 | 接口设计、文档、联调 | RESTful 契约、OpenAPI 文档 |
| 测试层 | 用例设计、断言、Mock | 单测、接口测试、E2E |
| 部署层 | 配置、脚本、CI | Dockerfile、Nginx conf、部署脚本 |
AI 的价值上限取决于上下文质量。全栈开发的上下文天然比单层开发更复杂——你需要同时让 AI 理解前端、后端、数据库三套结构,以及它们之间的映射关系。
1.3 传统全栈 vs AI 全栈
| 维度 | 传统全栈 | AI 全栈 |
|---|---|---|
| 开发速度 | 靠个人熟练度 | 靠上下文质量与 Prompt 能力 |
| 知识广度 | 受限于个人学习时间 | AI 补齐短板层 |
| 跨层一致性 | 靠记忆与规范自觉 | 靠文档先行 + 契约驱动 |
| 主要瓶颈 | 某一层不熟拖慢整体 | 上下文失控、跨层不一致 |
| 产出物 | 代码 | 代码 + 设计文档 + Prompt 资产 |
结论:AI 并没有消除全栈开发的难度,而是把难度从"写代码"转移到了"管理上下文与跨层契约"。
二、AI 全栈开发核心原则
2.1 先文档后代码
不要上来就让 AI 写代码。全栈项目第一步永远是先产出设计文档:
- 数据模型(表结构 / 实体定义)
- API 契约(接口路径、参数、响应)
- 目录结构(前后端各层怎么组织)
文档是后续所有 AI 对话的"锚点"。没有文档,AI 每次生成都会漂移,跨层一致性无从谈起。
2.2 一次只做一层
一次对话只让 AI 处理一个技术层的一个模块。典型错误是让 AI"帮我写一个用户注册功能"——它会同时改前端、后端、数据库三处,产生大量不可控的改动。
正确的拆法:
第 1 轮:设计 users 表结构(数据库层)第 2 轮:生成注册/登录的 API 契约(API 层)第 3 轮:实现后端 controller + service(后端层)第 4 轮:实现前端页面 + 请求封装(前端层)第 5 轮:联调 + 测试(跨层验证)2.3 跨层一致性(全栈核心)
全栈开发最致命的问题不是"某层写错",而是三处定义不一致。一个字段在数据库叫 created_at,后端返回 createTime,前端又读 createdAt——这种漂移会制造大量隐蔽 bug。
解决之道:单一数据源(Single Source of Truth)。让数据模型在项目中只有一份权威定义,其他层从它派生。详见第十章。
2.4 上下文管理
每次对话开头,先喂给 AI 一份项目上下文(可沉淀为 CONTEXT.md):
# 项目上下文## 技术栈- 前端:Vue 3 + TypeScript + Vite + Pinia- 后端:Node.js + NestJS + TypeORM- 数据库:MySQL 8.0 + Redis## 目录结构- src/api/ 前端接口封装- src/components/ 前端组件- server/src/ 后端源码- server/src/entity/ 数据库实体## 约定- 时间字段统一 snake_case:created_at, updated_at- 响应格式:{ code, message, data }- 错误码:0 成功,非 0 失败2.5 审查不可跳过
AI 生成的代码必须人工审查,全栈项目尤其要检查跨层点:
- 前端调用的接口路径是否与后端一致
- 前端读取的字段名是否与后端响应一致
- 数据库字段与实体映射是否一致
三、前端层:AI 辅助开发
3.1 前端层 AI 能做什么
| 任务 | 是否适合交给 AI | 说明 |
|---|---|---|
| 组件代码生成 | ✅ 高 | 模板化强,AI 效率极高 |
| 页面布局 | ✅ 高 | 描述清楚即可 |
| 请求封装 | ✅ 高 | 有 API 契约就能生成 |
| 状态管理 | ⚠️ 中 | 需明确业务逻辑 |
| 样式调优 | ⚠️ 中 | 像素级调整需反复反馈 |
| 复杂动画 | ❌ 低 | 难以描述精确效果 |
3.2 组件生成 Prompt 模板
## 任务生成一个「用户列表」组件## 技术栈Vue 3 + TypeScript + <script setup> + Element Plus## API 契约(来自设计文档)GET /api/users?page=1&pageSize=10响应:{ code: 0, data: { list: User[], total: number } }User 字段:id, nickname, avatar, created_at## 要求1. 使用 useFetch 封装的请求方法2. 分页用 el-pagination3. 加载态用 el-skeleton4. 时间字段 created_at 用 dayjs 格式化为 YYYY-MM-DD5. 空数据展示 el-empty## 约束- 不引入新的依赖- 遵循项目现有命名规范3.3 Vue 3 示例:请求封装
给 AI 一个清晰的契约,它能产出规范统一的封装:
// src/api/request.tsimport axios from 'axios'export interface ApiResponse<T = any> { code: number message: string data: T}const request = axios.create({ baseURL: import.meta.env.VITE_API_BASE, timeout: 10000})// 统一拦截:剥离 code,抛出业务错误request.interceptors.response.use( (response) => { const res = response.data as ApiResponse if (res.code !== 0) { return Promise.reject(new Error(res.message)) } return res.data }, (error) => Promise.reject(error))export default request3.4 React 示例:Hook 封装
// src/hooks/useUsers.tsimport { useState, useEffect } from 'react'import request from '@/api/request'interface User { id: number nickname: string avatar: string created_at: string}export function useUsers(page: number) { const [list, setList] = useState<User[]>([]) const [total, setTotal] = useState(0) const [loading, setLoading] = useState(false) useEffect(() => { setLoading(true) request.get('/api/users', { params: { page, pageSize: 10 } }) .then((res) => { setList(res.list) setTotal(res.total) }) .finally(() => setLoading(false)) }, [page]) return { list, total, loading }}3.5 状态管理与 API 分层
让 AI 生成前端代码时,务必约束分层结构,避免页面里塞满请求逻辑:
src/├── api/ # 接口定义(与后端契约一一对应)│ ├── user.ts│ └── order.ts├── stores/ # 状态管理(Pinia / Zustand)├── components/ # 复用组件└── views/ # 页面(只负责编排)四、后端层:AI 辅助开发
4.1 后端层 AI 能做什么
后端是 AI 发挥最稳定的层——因为有明确的输入(API 契约、数据模型)和输出(Controller/Service/Mapper)。关键是先给契约再写代码。
4.2 三栈 Prompt 示例
通用模板:
## 任务实现用户注册接口## API 契约POST /api/auth/register请求体:{ username, password, nickname }响应:{ code: 0, message: 'ok', data: { token, user } }## 数据模型users 表:id, username(唯一), password(加密), nickname, created_at## 技术栈与框架[Node + NestJS / Java + Spring Boot / PHP + ThinkPHP]## 要求1. 密码用 bcrypt 加密存储2. username 查重,重复返回业务错误3. 成功签发 JWT4. 参数校验失败返回统一错误格式Node + NestJS 产出:
// auth.controller.ts@Post('register')async register(@Body() dto: RegisterDto) { return this.authService.register(dto)}// auth.service.tsasync register(dto: RegisterDto) { const exists = await this.userRepo.findOneBy({ username: dto.username }) if (exists) throw new BusinessException('用户名已存在') const hash = await bcrypt.hash(dto.password, 10) const user = await this.userRepo.save({ ...dto, password: hash }) const token = this.jwtService.sign({ sub: user.id }) return { token, user }}Java + Spring Boot 产出:
@PostMapping("/register")public Result<AuthVO> register(@Valid @RequestBody RegisterDTO dto) { if (userService.existsByUsername(dto.getUsername())) { throw new BusinessException("用户名已存在"); } User user = userService.register(dto); String token = jwtUtil.generateToken(user.getId()); return Result.ok(new AuthVO(token, user));}PHP + ThinkPHP 产出:
public function register(Request $request){ $data = $request->validate([ 'username' => 'require|unique:users', 'password' => 'require|min:6', ]); $data['password'] = password_hash($data['password'], PASSWORD_BCRYPT); $user = User::create($data); $token = Jwt::encode(['sub' => $user->id]); return json(['code' => 0, 'data' => ['token' => $token, 'user' => $user]]);}4.3 认证鉴权
让 AI 生成鉴权逻辑时,要明确鉴权方式和角色模型:
## 鉴权要求1. JWT 放在 Authorization: Bearer <token> 头2. 中间件统一解析 token,挂载当前用户到请求上下文3. 角色:admin / member,admin 可访问 /admin/* 路由4. token 过期返回 code=401,权限不足返回 code=4034.4 数据校验
校验规则必须与数据库约束、前端表单三处对齐,这是跨层一致性的典型场景:
## 校验规则(三端统一)- username:3-20 位,字母数字下划线- password:6-32 位,至少含字母和数字- nickname:1-30 位,任意字符五、数据库层:AI 辅助设计
5.1 表结构设计
数据库设计是全栈一致性的源头。让 AI 生成表结构时,要给出业务实体 + 关系,而不是直接让它自由发挥:
## 任务设计「旅游线路」相关的表结构## 业务实体与关系- 线路 line:一个线路属于一个分类 category(多对一)- 线路有多个行程日 itinerary(一对多)- 用户可收藏线路(多对多,通过收藏表)- 用户可下单 order(用户与线路多对多,通过订单表)## 要求1. 所有表统一含 id, created_at, updated_at2. 金额字段用 DECIMAL(10,2)3. 状态字段用 TINYINT + 注释枚举值4. 外键关系用索引保证,不强制物理外键5.2 SQL 生成
复杂查询交给 AI 前,先把业务口径讲清楚:
## 查询需求查询「本周热门线路 Top10」,口径:- 热门 = 订单数(已支付状态)- 时间范围 = 本周(周一 0 点至今)- 结果字段:线路名、封面、价格、订单数- 按订单数倒序,不足 10 条则全返回产出示例:
SELECT l.id, l.name, l.cover, l.price, COUNT(o.id) AS order_countFROM line lLEFT JOIN `order` o ON o.line_id = l.id AND o.status = 1 -- 已支付 AND o.paid_at >= DATE_FORMAT(CURDATE(), '%Y-%m-%d 00:00:00')GROUP BY l.id, l.name, l.cover, l.priceORDER BY order_count DESCLIMIT 105.3 索引优化
让 AI 分析慢查询时,提供 EXPLAIN 结果和执行计划:
## 慢查询SELECT * FROM `order` WHERE user_id = 123 AND status = 1ORDER BY created_at DESC LIMIT 20## EXPLAIN 结果type=ALL, rows=500000(全表扫描)## 请给出1. 建议的联合索引及原因2. 为什么 user_id 单列索引不够AI 应能给出:联合索引 (user_id, status, created_at) 覆盖过滤 + 排序,避免 filesort。
5.4 ORM 映射
实体定义是数据库与后端代码之间的桥,字段命名和类型必须严格对齐。这是跨层一致性的第一道防线:
// TypeORM 实体@Entity('users')export class User { @PrimaryGeneratedColumn() id: number @Column({ unique: true, length: 20 }) username: string @Column({ name: 'created_at' }) createdAt: Date // 显式映射 snake_case → camelCase}关键点:
@Column({ name: 'created_at' })这类显式映射,能让数据库的 snake_case 与代码的 camelCase 各司其职,避免混用。
六、API 层:契约先行
6.1 为什么 API 层是全栈最容易出问题的层
前后端是两个独立代码库,靠 HTTP 接口衔接。一旦契约没有固化,就会出现:
- 前端按 A 字段名读,后端返回 B 字段名
- 前端判断
code === 200,后端返回code === 0 - 时间格式前端按字符串处理,后端返回时间戳
解决之道:契约先行(Contract First)——在写任何代码前,先把接口定义成一份双方都认可的文档。
6.2 RESTful 设计规范
| 规则 | 示例 |
|---|---|
| 资源用名词复数 | /api/users 而非 /api/getUsers |
| 用 HTTP 方法表达动作 | GET 查 / POST 增 / PUT 改 / DELETE 删 |
| 层级关系用路径 | /api/lines/:id/itineraries |
| 过滤/分页用 query | /api/lines?category=1&page=1 |
| 统一前缀 | /api + 版本 /api/v1 |
6.3 统一响应格式
全栈项目必须先定死响应格式,这是跨层一致性的基石:
{ "code": 0, "message": "ok", "data": {}}约定:
| code | 含义 |
|---|---|
| 0 | 成功 |
| 400 | 参数错误 |
| 401 | 未登录 / token 失效 |
| 403 | 无权限 |
| 500 | 服务器错误 |
| 业务码 | 以 1 开头的自定义码,如 1001=用户名已存在 |
6.4 契约先行工作流
1. 让 AI 产出 API 契约文档(Markdown 或 OpenAPI)2. 前后端各自确认契约无误3. 后端按契约实现(可用 Mock 数据先跑通)4. 前端按契约开发(用 Mock 服务并行开发)5. 联调时只验证契约是否被遵守,而非重新协商6.5 API 文档生成
用 OpenAPI(Swagger)让文档与代码自动同步,避免文档漂移:
## 任务给后端代码加 Swagger 注解,自动生成 OpenAPI 文档## 要求1. 每个接口标注 @ApiOperation 中文说明2. DTO 字段用 @ApiProperty 标注说明与示例3. 分组按模块:auth / user / line / order七、测试层:AI 辅助测试
7.1 单元测试
给 AI 提供被测函数 + 边界条件,它生成测试的效率远超手写:
## 任务为 passwordStrength 函数写单元测试## 函数逻辑密码强度校验:6 位以下=弱,6-11 位=中,12 位以上且含数字+字母=强## 要求覆盖:空密码、6 位边界、12 位边界、纯数字、纯字母、特殊字符7.2 接口测试
接口测试是全栈项目性价比最高的测试——直接验证跨层契约:
## 任务为 /api/auth/register 写接口测试## 契约POST /api/auth/register请求:{ username, password, nickname }成功:code=0, data.token 非空重复用户名:code=1001缺少字段:code=400## 要求用 supertest / 或 Postman 集合,覆盖上述三种情况7.3 E2E 测试
端到端测试让 AI 生成时,给出用户操作路径:
## 任务为用户「注册→登录→下单→支付」写 E2E 测试## 操作路径1. 打开注册页 → 填表单 → 提交2. 跳转登录 → 输入凭证 → 登录成功3. 进入线路详情 → 点「立即预订」4. 提交订单 → 模拟支付成功5. 断言订单状态变为「已支付」## 工具Playwright八、部署运维层:AI 辅助
8.1 Dockerfile
给 AI 提供项目结构 + 构建命令,它能生成多阶段构建:
## 任务为前端项目写 Dockerfile(多阶段构建)## 信息- 构建:pnpm install && pnpm build,产物在 dist/- 运行:Nginx 托管静态文件,支持 history 路由- 基础镜像:node:20-alpine 构建,nginx:alpine 运行8.2 CI/CD
## 任务写 GitHub Actions 工作流## 要求1. push 到 master 触发2. 前端:pnpm build → 产物上传3. 后端:mvn package → 构建镜像4. 部署:SSH 到服务器执行部署脚本5. 失败时通知8.3 Nginx 配置
让 AI 生成 Nginx 配置时,明确前后端分离的代理规则:
## 任务写 Nginx 配置,实现前后端分离部署## 要求1. 静态文件 / 交给前端 build 产物2. /api/ 反向代理到后端 :80803. history 路由 fallback 到 index.html4. 上传文件 50MB 限制8.4 部署脚本
## 任务写后端一键部署脚本## 流程1. 停止旧服务2. 备份旧 jar3. 上传新 jar4. 启动服务5. 健康检查(最多重试 5 次)6. 失败自动回滚九、完整实战:全栈项目从 0 到 1
以「待办事项(Todo)」为例,演示 AI 贯穿六层的完整流程。Todo 虽小,但覆盖了全栈的每一个环节。
9.1 第一步:需求与数据模型
## 需求一个待办事项应用:用户注册登录,可增删改查自己的待办,支持标记完成、按状态筛选。## 请先产出1. 数据模型(表结构)2. API 契约3. 目录结构不要写任何代码。AI 产出数据模型:
CREATE TABLE users ( id INT AUTO_INCREMENT PRIMARY KEY, username VARCHAR(20) UNIQUE NOT NULL, password VARCHAR(100) NOT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP);CREATE TABLE todos ( id INT AUTO_INCREMENT PRIMARY KEY, user_id INT NOT NULL, title VARCHAR(200) NOT NULL, status TINYINT DEFAULT 0, -- 0未完成 1已完成 created_at DATETIME DEFAULT CURRENT_TIMESTAMP, INDEX idx_user_status (user_id, status));9.2 第二步:API 契约
| 方法 | 路径 | 说明 |
|---|---|---|
| POST | /api/auth/register | 注册 |
| POST | /api/auth/login | 登录 |
| GET | /api/todos?status=0 | 查询(按状态筛选) |
| POST | /api/todos | 新增 |
| PUT | /api/todos/:id | 更新(改标题/状态) |
| DELETE | /api/todos/:id | 删除 |
9.3 第三步:后端实现(一次一层)
先做 users 模块,再做 todos 模块,每个模块分别对话,避免上下文膨胀。
9.4 第四步:前端实现
按"请求封装 → 页面组件 → 状态管理"的顺序分轮生成。
9.5 第五步:联调验证
让 AI 生成接口测试,逐条验证契约是否被遵守。
9.6 第六步:部署
生成 Dockerfile + compose 配置,一键起 MySQL + 后端 + Nginx。
关键认知:全程没有一次让 AI"把整个 Todo 应用写出来"。每一层都是独立的一轮对话,层与层之间靠契约文档衔接。这才是 AI 全栈开发的正确姿势。
十、跨层一致性专题
10.1 类型定义共享
前后端分离项目中,类型定义是最容易漂移的部分。方案:单一数据源 + 派生。
| 方案 | 做法 | 适用 |
|---|---|---|
| OpenAPI 生成 | 后端 OpenAPI → 前端用工具生成 TS 类型 | 大型项目 |
| 共享类型包 | monorepo 里放一份 shared/types |
前后端同仓库 |
| 手动对齐 | 契约文档里写死字段,人工核对 | 小项目 |
10.2 统一错误码
错误码在项目启动时就全局定义一份,前后端共用:
// 统一错误码(前后端各存一份,内容一致)export const ErrorCode = { SUCCESS: 0, PARAM_ERROR: 400, UNAUTHORIZED: 401, FORBIDDEN: 403, NOT_FOUND: 404, SERVER_ERROR: 500, USER_EXISTS: 1001, TODO_NOT_FOUND: 2001,} as const10.3 环境变量管理
前端 VITE_*、后端环境变量、部署环境,三处的 key 要统一约定:
# 前端 .envVITE_API_BASE=/api# 后端 .envDB_HOST=localhostJWT_SECRET=xxx# 部署(compose)API_BASE_URL=http://localhost:808010.4 命名约定统一
全栈项目最难维护的隐性成本是命名漂移。在 CONTEXT.md 里写死:
| 层 | 约定 | 示例 |
|---|---|---|
| 数据库 | 字段 snake_case | created_at |
| 后端实体 | 属性 camelCase + 显式映射 | createdAt |
| API 响应 | 字段 camelCase | createdAt |
| 前端 | 与 API 响应一致 | createdAt |
一条铁律:API 响应字段的命名,是前端读取的唯一依据。前端不要自作主张改名,后端也不要随意改字段名。
十一、陷阱与最佳实践
11.1 十大陷阱
| # | 陷阱 | 后果 | 规避 |
|---|---|---|---|
| 1 | 让 AI 一次写整个功能 | 三处全改,不可控 | 一次一层 |
| 2 | 不写契约直接写代码 | 前后端漂移 | 契约先行 |
| 3 | 上下文没喂就提问 | AI 瞎猜 | 每次附 CONTEXT.md |
| 4 | 跳过代码审查 | 埋下隐蔽 bug | 跨层点必审 |
| 5 | 字段命名随意 | 联调大量报错 | 命名约定固化 |
| 6 | 响应格式不统一 | 前端到处判空 | 统一响应 + 拦截器 |
| 7 | 让 AI 猜业务口径 | 查询结果错误 | 口径讲清楚 |
| 8 | 依赖 AI 做安全审计 | 漏洞漏检 | 人工专项审计 |
| 9 | 无版本控制 | 改动无法回滚 | 每层完成即 commit |
| 10 | 工具换来换去 | 上下文断裂 | 锁定一套主工具 |
11.2 最佳实践 checklist
启动阶段
- 产出数据模型、API 契约、目录结构三份文档
- 固化统一响应格式、错误码、命名约定到 CONTEXT.md
开发阶段
- 每次对话开头附上下文
- 一次只做一层的一个模块
- 每层完成即 commit(可回滚)
联调阶段
- 用接口测试验证契约,而非肉眼联调
- 检查字段命名、类型、时间格式三处一致
上线阶段
- 部署脚本含健康检查 + 回滚
- 安全项人工专项审计(不依赖 AI)
11.3 AI 全栈开发工具生态
| 类别 | 工具 | 说明 |
|---|---|---|
| AI 编程 IDE | Cursor / Windsurf | 内置 Agent,上下文感知最强 |
| 编辑器插件 | GitHub Copilot / Codeium | 补全 + 对话 |
| CLI Agent | Claude Code / Aider | 终端内全自动编程 |
| 协作平台 | WorkBuddy | 多 Agent 协作 + 技能编排 |
| 上下文工具 | MCP / Skills | 把外部数据源接入 AI |
总结
AI 全栈开发的本质,是把"写代码"的难度转化为"管理上下文与跨层契约"的难度。掌握以下三条,即可高效驾驭:
- 先文档后代码——数据模型、API 契约是唯一权威,代码从它派生。
- 一次一层——层间靠契约衔接,绝不一次跨多层。
- 跨层一致性——字段命名、响应格式、错误码三处对齐,是全栈质量的命脉。
完