ai coding 项目案例开发

从 0 到 1搭建企业级通用业务基座平台统一身份 · 统一权限 · 统一基础数据每一个做过多套业务系统的团队都经历过重复造轮子的痛苦每开一个新项目就要重新写一遍登录、权限、用户、部门、字典……今天就分享如何一次性把这些公共能力沉淀成一个企业级通用业务基座平台让后续所有业务系统直接复用。一、为什么要做业务基座先看一个常见的痛点公司有 ERP、CRM、OA、报表中心等多个系统每个系统都各自维护一套自己的登录注册和密码体系自己的用户表、角色表、权限表自己的部门组织架构还不一致自己的数据字典男/女的取值都可能是 1/2 或 M/F自己的系统配置改个系统名称要翻代码。结果就是用户在多个系统要记多套密码管理员要重复配置 N 遍权限基础数据各说各话。企业级基座平台就是用来根治这个问题的它作为整套业务体系的底层根基对外统一提供身份认证、RBAC 权限控制、组织架构、数据字典、系统全局配置、数据可视化仪表盘等公共能力让其他业务系统只做业务、不重复造轮子。一句话多应用统一身份、统一权限、统一基础数据管理。二、需求拆解10 大核心功能我们把它拆成 10 个可交付的功能模块编号功能说明1用户管理用户 CRUD、角色分配、状态启停、重置密码2登录注册JWT 认证、注册自动分配默认角色、登录日志3RBAC 角色管理基于角色的访问控制角色 CRUD 数据权限范围4按钮级权限权限颗粒化到按钮前端指令 后端中间件双重校验5菜单管理目录/菜单/按钮三级动态路由、权限分配可视化6组织架构集团 → 公司 → 部门三级树形组织7数据字典字典类型 字典数据动态数据、全局常量的唯一来源8系统配置系统名称/Logo/分页/安全级别配置值受数据字典控制9个人中心用户自我管理资料、头像、密码10数据仪表盘基础数据可视化 仪表盘升级能力为更多模块分析预留入口三、技术选型以及为什么不是 Spring Boot作为中文企业级项目大家第一反应通常都是Spring Boot MyBatis-Plus MySQL。但这次我选择了全栈 Node.js后端Node.js Express SQLitenode:sqlite 内置模块 前端Vue 3 Vite Element Plus Pinia ECharts原因主要有三零原生依赖。Node 22.5 内置了node:sqlite模块不需要安装任何原生编译的数据库驱动跨平台开箱即用学习成本也低。一套语言打通全栈。前端 Vue、后端 Node 都是 JavaScript/TypeScript模型定义、枚举常量前后端可以共享心智不用在 Java 和 JS 之间来回切换。轻量、易部署、易复用。基座平台本身要轻其他业务系统集成它时Node 后端比 Java 后端更接近前端团队的技术栈。架构上做好了分层和接口抽象如果未来要切 MySQL/Spring Cloud数据访问层和服务层都可以平滑替换——基座的定位是能力沉淀不是技术绑定。四、系统架构┌─────────────────────────────────────────────┐ │ 前端 webVue3 Element Plus │ │ 动态路由 │ v-permission 按钮指令 │ ECharts │ └───────────────┬─────────────────────────────┘ │ /apivite 代理 / axios ┌───────────────▼─────────────────────────────┐ │ 后端 serverExpress │ │ routes → middleware(认证/RBAC) → services │ │ → dbSQLite / node:sqlite │ └─────────────────────────────────────────────┘ 统一提供认证 / 权限 / 组织 / 字典 / 配置 / 统计核心设计原则前后端分离接口统一/api前缀天然适合作为公共基座被其他系统调用分层清晰路由层只管 HTTP中间件管认证与鉴权服务层管业务数据层管 SQL约定大于配置统一响应格式{code, msg, data}、统一分页结构、统一异常处理。五、数据库设计核心表全部围绕用户-角色-权限和元数据驱动两大主题用户 sys_user 用户基础信息 所属部门 是否超管 组织架构 sys_dept 集团/公司/部门 三级树 角色 sys_role 角色 数据权限范围 用户角色 sys_user_role 多对多 菜单/权限 sys_menu 目录/菜单/按钮三级按钮含权限标识 perms 角色权限 sys_role_menu 多对多 字典类型 sys_dict_type 如 sys_user_gender、sys_security_level 字典数据 sys_dict_data 如 {男:1, 女:2} 系统配置 sys_config 配置项 关联字典类型 dict_type 登录日志 sys_login_log 仪表盘数据来源其中sys_menu是 RBAC 的核心它把菜单和权限统一建模typeM目录如系统管理typeC菜单可跳转的页面路由typeF按钮perms字段存权限标识如system:user:add。按钮级权限就是这么来的一个新增用户按钮在权限树里就是一个叶子节点权限标识为system:user:add。角色勾选了这个节点用户就拥有了对应的操作权。六、几个核心实现1. RBAC 按钮级权限前端 后端双重校验后端——每个接口都要过权限中间件// 权限中间件没有 system:user:add 权限直接 403 router.post(/, authenticate, checkPerm(system:user:add), handler)前端——按钮级显隐用指令控制el-button v-permissionsystem:user:add typeprimary新增用户/el-button指令内部逻辑从用户 Store 的权限码集合判断无权限直接移除该 DOM 节点app.directive(permission, { mounted(el, binding) { const perms useUserStore().perms; // 登录后由后端下发 const has perms.includes(binding.value); if (!has) el.parentNode.removeChild(el); // 无权限 → 按钮消失 }, });为什么双重校验前端控制看得到后端控制用得了。即使有人绕过前端直接调接口后端 403 依然兜底。安全永远不能只依赖前端。动态路由同样由权限驱动登录后后端返回该用户有权限的菜单树前端据此动态注册路由 渲染侧边栏普通员工登录后系统管理根本不会出现在路由表里。2. 数据字典驱动的系统配置需求第 8 条有个硬约束系统配置的相关数据必须从数据字典进行控制和获取。实现上sys_config每个配置项可以关联一个字典类型sys.page.size 10 → 来源字典 sys_page_size_options10/20/50/100 sys.security.level MEDIUM → 来源字典 sys_security_level低/中/高 sys.dashboard.version basic → 来源字典 sys_dashboard_version基础/专业/旗舰后端在保存配置时做了字典值强校验if (dictType configType Y) { const valid one(SELECT id FROM sys_dict_data WHERE dict_type_id? AND value?, [dict.id, value]); if (!valid) return res.json(fail(配置值必须来源于数据字典「${dictType}」)); }于是系统名称、Logo、分页大小、安全级别这些配置全部通过字典界面维护不碰一行代码。前端还能直接GET /api/configs/public拿到 key-value 全量配置做初始化系统名称、Logo 都会实时反映到登录页和顶栏。3. 数据仪表盘 升级机制仪表盘是本平台的门面需要基本的数据分析和可视化6 张统计卡片用户/启用用户/今日登录/角色/部门/菜单数量4 组 ECharts 图表近 7 日注册趋势、登录成功/失败对比、组织架构用户分布饼图、角色用户数分布最近登录日志表格。同时需求还要求为更多模块数据的分析和可视化保留可能性所以我们设计了仪表盘版本升级机制版本由sys.dashboard.version数据字典控制系统配置页提供三档升级方案基础版/专业版/旗舰版一键切换版本基础版展示公共模块数据专业版/旗舰版预留登录安全分析、权限审计、组织全景等模块入口。新业务模块上线后只需往仪表盘模块分析中心追加自己的可视化卡片即插即用。4. 手写 JWT 与密码哈希后端依赖做到了极致精简只装了 express corsJWT 签发校验和密码哈希全部用 Node 内置模块实现// JWTHMAC-SHA256 签名crypto 内置 const signature crypto.createHmac(sha256, secret) .update(${headerStr}.${bodyStr}).digest(base64url); ​ // 密码scrypt 随机盐 const hash scryptSync(plain, salt, 64).toString(hex); const verify timingSafeEqual(Buffer.from(hash, hex), test); // 恒时比较防时序攻击不引第三方依赖既减少了供应链风险也让代码更可控——基座本来就该把最基础的东西握在自己手里。七、开发过程中的几个坑node:sqlite的返回值lastInsertRowid可能是 BigInt拼接 SQL 参数时记得Number()转一下。动态路由的组件加载Vite 无法在运行时静态解析模板字符串 import需要用import.meta.glob预注册所有视图再按 key 取用。树形数据删除删除部门/菜单前必须检查是否有子节点/是否有用户否则会留下孤儿数据。权限树回显角色分配权限用el-tree时父子联动会把父节点置为半选态保存时要合并getCheckedKeys() getHalfCheckedKeys()否则父目录权限会丢。中文参数乱码本地 curl 调试带中文 query 参数时遇到编码问题最后统一用 code/ID 查询规避前端 axios 传参无此问题。八、效果展示与使用默认三套账号即可演示完整权限体系账号密码角色可见能力adminadmin123超级管理员全部模块zhangsan123456系统管理员系统管理 仪表盘lisi123456普通员工仅仪表盘 个人中心用lisi登录你会看到侧边栏只有数据仪表盘直接访问/system/user会被路由守卫拦下调接口会被后端 403——权限从入口到出口都是通的。九、如何让 AI 帮你完成这样的项目这次整个项目是用 Claude Code 从需求直接生成的。分享几点经验需求要拆到可验证把权限管理拆成用户/角色/菜单/按钮级权限等明确条目AI 才能逐条落地。技术选型交给环境说话先让 AI 检查本机环境Node/Java/数据库再决定技术栈保证能跑起来。种子数据是试金石项目能演示靠的是预置的组织架构、字典、账号数据这一步不能省。让它边做边自测生成后立即启动服务用 curl 跑一遍登录 → 鉴权 → CRUD 全链路回归把看起来对变成验证过对。十、写在最后企业级基座平台的价值不在于某个功能有多炫而在于它把重复建设消灭在源头新业务系统接入时身份认证、权限控制、组织、字典、配置、可视化都是现成的。它不只是一个系统而是一套可复用的开发范式。如果你也在规划企业级产品矩阵建议尽早把公共能力沉淀为基座——造一次轮子然后永远不再造它。项目完整源码、数据库设计、启动说明见项目 README文中所有实现均为可运行代码可在本地npm install npm start一键体验。