AI 让“会写代码的人”变多了，但也让一个老问题更显眼：写得快并不等于做得稳。

• vibe coding 很爽，但在企业协作/长期迭代里，如果缺少统一规范与质量门禁，返工会非常昂贵
• 前后端分离的联调常常依赖 Apifox MCP 这类工具，但契约同步、环境对齐、反复调用依然麻烦，而且还会额外消耗 token
• 真正吸引人的方向是“全栈 + AI”：把重复劳动交给 AI，把关键决策交给工程化与契约，降低个人做全栈的门槛

这份项目模板 vben-nest 的核心思路很直接：在 vben 的工程化底座上新增 Nest 后端（apps/server），并让后端接口完全适配 vben 原本的 mock 契约。前端调用尽量不改，只替换“接口实现者”，从 mock 走向真实后端更平滑、更可演进。

1. 为什么不是“随便写接口”：全栈的关键是契约

一个判断是：随着 AI 能力增强，“前后端一个人搞”会越来越常见。原因并不神秘：很多业务难点不在 UI 或 API 的某一端，而在业务逻辑本身。

当 AI 能把样板代码写得更快时，决定交付质量的就变成了：

• 需求是否能被拆成稳定的接口契约
• 前后端是否能围绕同一套领域模型演进
• 多人协作与长期维护里，边界是否足够清晰、成本是否可控

社区里也常有人吐槽 vben“很重”。但把视角从“个人 demo”切换到“企业协作”，它更像是在提前支付必要成本：规范、质量门禁、脚手架、依赖治理，以及可观测的目录结构与约定。

2. vibe coding 的边界：快要配护栏

vibe coding 适合快速验证与个人实验；一旦进入团队协作或中长期迭代，劣势会迅速放大：风格不一致、边界不清晰、可测试性差、回归成本高。AI 越强，越容易把“写得像能跑”误当成“工程上可交付”。

更理想的组合是：

• AI 负责加速产出
• 工程化负责约束质量与一致性

3. 这个项目做了什么：用 Nest 复刻并升级 vben mock

vben 自带的后端 mock（见 apps/backend-mock）已经非常接近真实后端：它不是浏览器里的 mock.js，而是一套独立服务实现，因此能覆盖文件上传、复杂逻辑、鉴权流程等更真实的场景。

vben-nest 在此基础上新增了 Nest 后端（见 apps/server），并坚持一个核心原则：

前端不改接口调用方式，只替换“实现者”。

路径、方法、响应结构、鉴权方式尽量保持一致，从 mock 平滑迁移到真实后端；甚至可以做到“先跑起来，再逐步替换为真实业务”。

4. 兼容策略与实现要点：对齐调用习惯，也保留演进空间

4.1 接口层：兼容 vben 的响应约定

Nest 侧做了三件事，降低前端切换成本：

• 使用全局前缀 api，对齐 vben 的请求习惯（见 main.ts）
• 通过全局响应拦截器，统一包装为 { code, data, message, error }（见 ResponseInterceptor）
• 通过全局异常过滤器，统一输出错误结构（见 HttpExceptionFilter）

这样前端的请求层可以继续使用原有的 code/data 成功码约定（例如 playground 的请求拦截器依旧按 successCode: 0 解析，见 request.ts）。

4.2 鉴权层：从"能用"到"更像生产"

很多 mock 方案只做"伪登录"，但真实项目通常会有 refresh token、cookie 策略、过期处理等细节。Nest 侧采用：

• 全局 AuthGuard + @Public() 放行（见 public.decorator.ts 与 auth.guard.ts）
• JWT access/refresh 机制
• refresh token 写入 httpOnly Cookie，避免前端直接触达 token（示例见 AuthController）

这让"用模板练全栈"更贴近真实业务，而不是停留在 demo 层面。

4.3 数据层：从 mock-data 到可落库演进

为了让后端具备真实项目的演进空间，这里引入：

• PostgreSQL + Prisma，支持 migrate + seed（见 apps/server/prisma）
• Docker Compose 一键拉起数据库（见 docker-compose.yml）

可以先用 seed 数据把前端跑通，再逐步把 mock-data 替换成真实表结构与业务逻辑。

4.4 工程化：把 vben 的护栏带到后端

这类模板的“核心价值”不在于多写了几个接口，而在于少搭了一套后端工程规范。

Nest 同样处于 TypeScript 生态，把后端放进 vben 的 monorepo 后，直接获得：

• 代码格式化与 lint 约束（Prettier/ESLint/Stylelint）
• Git Hooks 质量门禁（Lefthook + Commitlint，见 lefthook.yml）
• 统一依赖治理与脚本编排（pnpm workspace + turbo）

在 AI 参与编码的前提下，这套护栏能把“产出速度”与“可维护性”拉到一个更平衡的位置。

5. 快速开始

环境要求

• Node.js >= 20.19
• pnpm >= 10（推荐使用 corepack）
• Docker Desktop（推荐，用于一键启动 PostgreSQL）

安装与运行

# 克隆项目
git clone https://github.com/MiniJude/vben-nest.git
cd vben-nest

# 安装依赖
npm i -g corepack
pnpm install

# 启动数据库 (Docker Compose)
docker compose -f apps/server/docker-compose.yml up -d

# 初始化数据库结构与种子数据
pnpm -F @vben/server run db:init

# 启动后端服务
pnpm -F @vben/server run dev
# 默认端口：3000

# 启动前端 Playground (新开终端)
pnpm dev:play

默认账号

• vben / 123456
• admin / 123456
• jack / 123456

6. 目录结构速览：前端多方案 + 后端可落库

• 前端应用：apps/web-*（多 UI 方案示例）
• Playground：playground/（用于快速体验与联调）
• Mock 服务：apps/backend-mock/（vben 原生 mock 服务实现）
• Nest 后端：apps/server/（本项目新增，适配 mock 契约）

6. 全栈 + AI 的实践建议：契约先行

更推荐的协作方式是“契约先行（Contract First）”：

• 先把接口契约稳定下来（URL、method、code/data 结构、分页约定、错误约定）
• 再让 AI 生成 DTO、Controller、Service、Prisma Schema 的骨架
• 依靠 lint、类型系统、提交规范，把代码质量稳定在可维护区间

前后端分离下，工具链可以帮助联调，但契约才是协作的“唯一事实来源”。

7. 适合谁使用

• 想从 vben 上手全栈的前端同学：用熟悉的前端工程体系，把后端也纳入同一条流水线
• 想快速搭建企业级全栈脚手架的小团队：少做重复造轮子，把精力留给业务
• 想在真实工程约束下用 AI 提效的人：让 AI 提速，同时保留规范与可演进性

8. 项目链接

github.com/MiniJude/vb…

9. 后续演进

当前版本更偏向“理念与路径”的最小落地：先把接口契约与工程化护栏对齐，让 mock 能平滑替换为可演进的真实后端。面向生产的后端工程还需要持续补齐监控、日志、权限、安全、审计等能力，本项目也会按迭代节奏逐步完善。