45 张系统表：GewuMind Boot 的底座长什么样

上一篇我们留了一个问题：让 AI 写后端，最好站在一套「成熟底座」上。那这套底座到底是什么？

这一篇直接给答案：45 张系统表。

一、场景：AI 写得快，为什么还在重建表

很多团队已经习惯让 AI 写后端：生成一个 CRUD 接口、补一段 SQL、写一个实体类，单文件层面确实比手敲快。

但落到一个企业后台项目上，节奏并没有变快多少。AI 写完接口之后，剩下的是：权限怎么挂到菜单和按钮上、数据范围怎么按部门隔离、操作日志谁来记、字典值在前端怎么翻译。

这些部分和业务无关，却存在于每个后台项目里，而且每个项目都要重写一遍。于是出现这样的局面：AI 几分钟写完一个接口，你要花几天去对齐它生成的表结构、权限逻辑和菜单配置。

二、问题：后台的「公共部分」被反复重造

把一套企业后台的表拆开看，其实是两类：

  • 业务表：客户、订单、项目，每个项目都不一样；
  • 系统表：用户、组织、角色、权限、菜单、字典、日志、工作流、报表，每个项目都一样。

问题就出在后一类。AI 从零生成项目时，会现场发明一套用户表、角色表、权限表，表名、字段、权限逻辑都取决于那一次生成：这次叫 sys_user，下次叫 t_user；这次权限校验写在拦截器里，下次写在 Controller 里。

代码能跑，但有三件事跑不歪不了：

  1. 和系统里已有的约定不一致。你原有的用户表、权限表是一套，AI 又生成一套；
  2. 隐含约束补不全。「有编辑权限才能看到导出按钮」这类规则，同时存在于后端、路由和菜单配置里，AI 只看到你发给它的那一段；
  3. 接手成本高。一套没有历史、没有约定的代码，维护之前得先读懂。

这部分「发明」的成本不在代码行数，而在跨模块的一致性工作上。

三、原因：基建不是一张表，是一套约定

为什么 AI 不能干脆一次生成到位？因为系统表承载的不只是结构，还有一整套约定：

  • 表结构约定：统一什么引擎、什么字符集、每张表必须有哪些审计字段；
  • 命名约定：系统表怎么命名、业务表怎么命名、主键怎么生成；
  • 权限约定：角色如何授权到菜单、数据范围怎么算、什么角色可以免校验；
  • 运行约定：软删除怎么标记、字典怎么翻译、改密之后缓存怎么清。

AI 能生成一张表，但没法保证它生成的表和你要写的权限逻辑、要配的菜单、要写的前端翻译规则是同一套。约定越多，各自发明的结果越容易「各说各话」。

这也是「让 AI 写快」和「让 AI 写对」的区别：前者靠模型能力，后者靠一个带着约定的起点。

四、方案：一个基线文件，45 张表

GewuMind Boot 用一份 SQL 回答这个问题：db/init/01-baseline.sql。

导入这一个文件，就有 45 张表，外加平台自带的菜单、角色、字典、配置与页面组件数据。文件头注释写清了它的边界：包含全部系统表结构，以及平台自带的基础数据（菜单、角色、字典、配置、图标、动态组件、开放接口、组织机构）；不包含日志、消息、AI 会话、文件等运行期数据；也不包含业务方自己的业务表。如果你的业务还有表，自带一份 02-xxx.sql，按 01→02 的顺序导入即可。

45 张表怎么分组

45 张表全部是真实的 CREATE TABLE，按能力分组如下：

分组 表数 表名
用户与组织 2 sys_user、sys_office
角色与权限 7 sys_role、sys_user_role、sys_role_menu、sys_role_module、sys_role_office、sys_permission_code、sys_user_code
菜单与模块/组件 6 sys_menu、sys_menu_icon、sys_module、sys_module_menu、sys_dynamic_component、sys_dynamic_component_history
字典与配置 3 sys_dict、sys_dict_items、sys_configure
工作流引擎 6 sys_wf_instance、sys_wf_task、sys_wf_cc、sys_wf_history、sys_wf_callback_log、sys_wf_process_biz
工作流演示业务表 5 biz_cross、biz_leave、biz_expense、biz_purchase、biz_purchase_item
报表 1 sys_report
消息 1 sys_message
开放接口网关 3 sys_open_app、sys_open_app_api、sys_open_app_request_log
AI 3 sys_ai_api_key、sys_ai_message、sys_ai_session
日志 2 sys_login_log、sys_oper_log
其他平台表 6 sys_file、sys_gen_info、sys_test_data、magic_backup_record_v2、magic_group、magic_api_info

其中 5 张 biz_* 表是内置的工作流演示业务表：biz_cross 是跨部门申请，biz_leave 是请假申请，biz_expense 是报销申请，biz_purchase 和 biz_purchase_item 是采购。clone 下来就能直接看到一套完整工作流在这套底座上是怎么跑起来的。

表规范：把约定写进结构

项目有一套统一的表规范，正是上一节「约定」问题的解法：

  • 表引擎与字符集统一：ENGINE=InnoDB、utf8mb4、ROW_FORMAT=DYNAMIC；
  • 业务表必含 6 个审计字段：is_del、create_by、create_date、update_by、update_date、remarks；
  • 系统表统一 sys_ 前缀，业务表用业务前缀；
  • 主键二选一：业务表用 UUID VARCHAR(32)，日志/关联表用 INT 自增；
  • 业务查询必须带 is_del = 0。

规则固定下来之后，AI 生成新的业务表时不需要「发明」，只需要填业务字段，生成的结构和 45 张系统表天然对齐。

快速上手：导入 → 启动 → 登录

前置：JDK 17、Maven 3.8+、MySQL 8（默认 localhost:3306 的 gewumind-boot 库，应用端口 9089）。

# 1. 建库
CREATE DATABASE gewumind-boot DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

# 2. 导入基线（45 张表 + 自带菜单/角色/字典/配置/页面组件）
mysql -h127.0.0.1 -uroot -p gewumind-boot < db/init/01-baseline.sql

# 3. 注入数据库账号密码环境变量（仓库不写死）
export SPRING_DATASOURCE_USERNAME=your_username
export SPRING_DATASOURCE_PASSWORD=your_password

# 4. 打包并启动（停止：scripts/stop.sh；换端口：SERVER_PORT=9090 bash scripts/start.sh）
mvn clean package -DskipTests
bash scripts/start.sh

启动后三个地址可以验证：

  • 后台管理：http://localhost:9089/（默认账号 admin / 123456）
  • 在线编程 / 接口文档：http://localhost:9089/magic/web
  • Druid 监控：http://localhost:9089/druid

许可方面：内核 Apache License 2.0 开源，clone 下来自由使用；SSO、工作流、模块管理、Redis/共享会话、MQTT、Kafka、SSE、TCP、WS 等企业能力需商业版离线 License 解锁，未授权可免费试用 30 天。对需要私有化部署的团队来说，这套许可结构意味着底座能力可控。

五、示例：AI 接到「按组织隔离数据」的需求

拿后端需求里最高频的一条举例：「不同部门看到不同的数据」。

从零做的方案里，这套东西要自己写：建组织表、设计层级字段、写「当前用户可见下级组织」的递归查询，再在每个业务查询里用它过滤。

在 GewuMind Boot 底座上，这个需求变成复用现成设施：

  1. 组织结构已经在 sys_office 里，用 pid 字段构成多层组织树，不需要新建组织表；
  2. 脚本里一行 office() 就能取到当前用户可见的 user_id 列表，用它做数据权限过滤，不需要写递归查询；
  3. 权限校验也不用写：'admin' 角色自动跳过权限校验，其余角色通过 sys_role_menu 显式授权，只需要配置这个角色看到哪些菜单和按钮；
  4. 前端字典值不用手动转：mb-table 组件设置 dictType，翻译自动完成。

还有两件事也是现成的：密码统一用 SaSecureUtil.sha256 存储与比对；修改密码时自动清理 permissions:${id} 权限缓存。

对比一下 AI 要写的东西：从零方案里是组织表 + 递归查询 + 各业务的过滤逻辑，几百行；底座方案里只剩业务表、业务接口，以及挂菜单、配权限这几步。最容易出错、最重复的那部分，被底座吃掉了。

六、结论：底座的价值在起点

回到上一篇的问题：底座到底是什么？

答案现在很具体：45 张系统表，覆盖用户、组织、角色、权限、菜单、字典、日志、工作流、报表、消息、开放接口、AI 的全套系统能力；加上平台自带的菜单、角色、字典、配置与页面组件数据；再加上写进结构里的一整套表结构、命名与权限约定。

这正是 README 里的一句话：一个「AI 驱动的低代码后端容器」——接口用脚本写，页面用组件文件维护，菜单、角色、字典、配置全部在线管理，clone 下来三步就能跑起一整套可用后端。装上 skill，AI 接到的需求可以直接变成应用，业务用「配置 + 脚本」表达，而不是重复写样板代码。

底座的价值不在于表的数量，而在于让 AI 从「接入现成能力」这一步开始写，而不是从「重新发明能力」这一步开始。

想亲眼看看这 45 张表，可以 clone GewuMind Boot 仓库，三步导入基线 SQL、启动服务、登录后台；也可以到官网查看完整能力清单与许可说明。

官网：https://gewumind.github.io/?utm_source=cnblogs&utm_medium=article&utm_campaign=principle-01-45-system-tables

posted @ 2026-11-05 18:45  gewumind  阅读(3)  评论(0)    收藏  举报