Cursor 或 Agent 生成 Vue3 后台时，最容易让人误判的一点是：页面能跑，不等于状态是干净的。登录态、菜单树、按钮权限、通知、WebSocket、用户资料，如果被分散到两套 Pinia 目录里，短期看只是“偶尔刷新丢菜单”，上线后就会变成权限错乱：A 角色看到了 B 角色的菜单，按钮隐藏了但接口还能打，刷新后前端状态和 Go 后端返回的权限又对不上。

这篇不讨论 AI 会不会替代前端，也不写工具清单。只看一个能落地的排查问题：AI 生成或重构 Vue3 管理后台后，怎么检查 Pinia 状态树、动态路由和 Go 后台 RBAC 是否还在同一套规则里。

先判断是不是“状态树分叉”

很多后台项目会有类似目录：

src/ store/ modules/ user.ts permission.ts app.ts stores/ backend/ chat.ts notification.ts websocket.ts

这不一定马上报错。真正的问题是两个目录可能各自维护登录态、菜单、权限点或连接状态。AI 重构时尤其容易这样做：它看到老目录就沿用老目录，看到新模块又新增一套模块，最后页面上能 import 成功，但状态来源已经不唯一。

可以先用下面几个命令做静态检查：

# 1. 找出项目里所有 Pinia store 定义 rg "defineStore\(" src # 2. 找出谁在读取菜单和按钮权限 rg "menu|menus|permission|permissions|button|buttons" src/store src/stores src/router src/views # 3. 找出 localStorage / sessionStorage 里是否保存了重复权限字段 rg "localStorage|sessionStorage" src

如果结果里同时出现 `src/store/modules/permission.ts` 和 `src/stores/backend/*`，就要继续查这些模块是否互相隔离。后台系统里最怕的不是多几个文件，而是同一个“当前用户权限”被拆成两份。

一个常见故障：菜单刷新后变了，接口权限没变

假设后端给当前用户返回这样的菜单和接口权限：

{ "userId": 1001, "roleKeys": ["operator"], "menus": [ {"name": "UserList", "path": "/system/user", "type": "menu"}, {"name": "UserQuery", "path": "GET /admin/user/list", "type": "api"} ], "buttons": ["system:user:query"] }

前端如果只拿 `menus` 生成动态路由，却把 `buttons` 放到另一套 store，按钮权限就容易和路由权限脱节。页面上可能看不到“删除用户”按钮，但某个旧组件还从旧 store 里读到了 `system:user:delete`，或者接口层没有用后端 RBAC 再拦一次。

上线前至少跑这三类验证：

# 菜单接口：当前角色只能看到用户列表 curl -s 'http://127.0.0.1:8000/admin/user/menu' \ -H 'Authorization: Bearer <operator-token>' | jq '.data.menus' # 允许的查询接口应返回 200 curl -i 'http://127.0.0.1:8000/admin/user/list' \ -H 'Authorization: Bearer <operator-token>' # 不允许的删除接口必须返回 403 curl -i -X DELETE 'http://127.0.0.1:8000/admin/user/delete?id=1001' \ -H 'Authorization: Bearer <operator-token>'

如果第三个请求返回 200，前端 store 再整齐也没用。按钮隐藏只能改善交互，不能替代后端接口鉴权。

Pinia 侧怎么查：每个权限字段只能有一个来源

我通常会把检查点压到很具体，别只看“页面有没有报错”。

// src/store/modules/permission.ts import { defineStore } from 'pinia' import { getUserMenus } from '@/api/system/permission' export const usePermissionStore = defineStore('permission', { state: () => ({ routes: [] as AppRouteRecordRaw[], buttons: [] as string[], apiPerms: [] as string[], loaded: false }), actions: { async loadPermission() { const res = await getUserMenus() this.routes = buildRoutes(res.data.menus) this.buttons = res.data.buttons || [] this.apiPerms = res.data.apiPerms || [] this.loaded = true }, hasButton(code: string) { return this.buttons.includes(code) }, hasApi(perm: string) { return this.apiPerms.includes(perm) } } })

关键不是这段代码长什么样，而是它要成为唯一入口。组件里不要再到处写：

const buttons = JSON.parse(localStorage.getItem('buttons') || '[]') const menus = userStore.userInfo.menus const oldPerms = backendStore.permissionList

这种写法短期最省事，也最容易把 AI 生成的补丁变成隐患。建议用搜索把这些旧入口删干净：

rg "permissionList|userInfo\.menus|localStorage\.getItem\('buttons'\)|backendStore" src

每命中一处，就确认它是不是仍在参与权限判断。不是的话删掉；是的话迁到统一 store。

Go 后端也要给前端一个稳定契约

前端状态能不能稳定，取决于后端接口返回是否稳定。不要让菜单接口今天返回 `buttonCodes`，明天返回 `permissions`，后天又让前端从角色详情里拼。

一个比较清楚的返回结构可以这样定：

type UserPermissionRes struct { UserId uint64 `json:"userId"` RoleKeys []string `json:"roleKeys"` Menus []MenuItem `json:"menus"` Buttons []string `json:"buttons"` ApiPerms []string `json:"apiPerms"` } type MenuItem struct { Name string `json:"name"` Path string `json:"path"` ParentId uint64 `json:"parentId"` Type string `json:"type"` // menu / button / api }

接口层再用同一套 `ApiPerms` 做校验：

func PermissionMiddleware(r *ghttp.Request) { user := contexts.GetUser(r.Context()) if user == nil { r.Response.WriteStatusExit(401) return } perm := strings.ToUpper(r.Method) + " " + r.URL.Path ok, err := service.Permission().UserCanAccess(r.Context(), user.Id, perm) if err != nil { g.Log().Warningf(r.Context(), "permission check failed: %v", err) r.Response.WriteStatusExit(500) return } if !ok { r.Response.WriteStatusExit(403) return } r.Middleware.Next() }

这样前端只负责“显示什么”，后端负责“能不能做”。两边用同一份权限语义，但不要互相替代。

数据库里也能查出不一致

如果怀疑菜单、按钮、接口没有绑在一起，可以直接从库里查。下面用一组中性表名示例：

-- 查某个角色拥有的菜单和按钮 SELECT r.role_key, m.id, m.title, m.type, m.permission_code, m.api_perm FROM admin_role r JOIN admin_role_menu rm ON rm.role_id = r.id JOIN admin_menu m ON m.id = rm.menu_id WHERE r.role_key = 'operator' ORDER BY m.parent_id, m.id; -- 查有接口权限字段但没有挂给任何角色的动作 SELECT m.id, m.title, m.api_perm FROM admin_menu m LEFT JOIN admin_role_menu rm ON rm.menu_id = m.id WHERE m.api_perm <> '' AND rm.menu_id IS NULL; -- 查按钮权限存在，但缺少后端接口映射的记录 SELECT id, title, permission_code FROM admin_menu WHERE type = 'button' AND (api_perm IS NULL OR api_perm = '');

这三条 SQL 很适合放进上线前检查。尤其是第三条：按钮权限如果没有接口映射，前端很可能“看起来管住了”，后端却没有真正拦住。

AI 重构后再跑一次构建和权限冒烟

状态树分叉经常不是 TypeScript 第一时间报错，而是在运行时暴露。可以把检查步骤固定下来：

# 前端类型和构建 pnpm typecheck pnpm build # 后端测试或最小启动 go test ./... go run main.go # 权限冒烟：普通角色不能访问管理员动作 curl -i -X DELETE 'http://127.0.0.1:8000/admin/user/delete?id=1' \ -H 'Authorization: Bearer <operator-token>'

日志里至少要能看到权限被拒绝的原因，而不是只有一个 500：

WARN permission denied user_id=1001 role=operator perm="DELETE /admin/user/delete" HTTP/1.1 403 Forbidden

如果这里打出 500，说明权限异常和业务异常混在一起了。后面排查会很痛苦。

什么时候该用代码生成器约束 AI

AI 适合补页面、补字段、补测试草稿，但后台项目里的确定性最好别全靠提示词。表结构、接口路径、菜单权限、按钮编码、前端 store 入口，这些东西越早固定，后面越少返工。

XYGo Admin 最近一次提交里做过一个很典型的维护动作：把 `stores/backend` 下的 chat、notification、websocket 迁到统一的 `store/modules`，同时修前端 TypeScript 配置。这类改动不炫，但它说明一个现实问题：后台项目跑久以后，真正消耗时间的往往不是再生成一个 CRUD，而是把状态、路由、权限、类型这些边界收回来。项目源码可以看这里：`GitHub - z312193608/xygo-admin: Open-source admin framework built with GoFrame v2 and Vue 3, featuring RBAC, full-stack CRUD code generation, MySQL/PostgreSQL, plugins, and single-binary deployment. · GitHub`。

我的建议是：让 AI 写代码之前，先把生成规则和验收表写清楚。比如：

1. 新模块必须使用 src/store/modules 下的 Pinia store 2. 菜单、按钮、接口权限必须来自同一个权限接口 3. 前端隐藏按钮后，后端 DELETE/POST 接口仍要返回 403 4. 新增字段后必须同步表单、列表、查询条件和导入导出 5. 构建、类型检查、curl 权限冒烟全部通过后才合并

这比“帮我生成一个后台管理模块”有效得多。AI 可以很快把文件铺出来，但能不能上线，最后还是看这些边界有没有被验过。

再补一层字段同步检查

状态树收拢以后，还要看 CRUD 二次生成有没有把字段同步完整。AI 很容易只改表单，不改列表；只改前端类型，不改 Go 入参；只改数据库字段，不补导入导出。结果就是页面能保存，搜索条件却查不到，或者导入模板里还是旧字段。

可以从数据库开始对字段做一次对账。假设新增了 `mobile`、`status`、`remark` 这几个字段，先确认表结构里真实存在：

SELECT column_name, data_type, is_nullable, column_default FROM information_schema.columns WHERE table_name = 'admin_user' AND column_name IN ('mobile', 'status', 'remark') ORDER BY ordinal_position;

再检查后端请求结构体有没有同步：

rg "type .*Req struct|Mobile|Status|Remark" internal api app

前端也要查四个地方：列表列、表单项、搜索条件、导入导出字段。不要只看页面上有没有输入框。

rg "mobile|status|remark" src/views src/api src/types

如果你用的是生成器，二次同步按钮或命令应该至少更新这些文件：

api 请求类型 Go 入参/出参结构体 service/logic 保存逻辑 Vue 列表列配置 Vue 表单字段 搜索条件 导入导出模板 权限按钮编码

这里最容易出错的是“旧字段还在参与搜索”。比如前端发了 `phone`，后端实际只认 `mobile`，接口不一定报错，只是查不到数据。上线前用一条请求把它打出来：

curl -G 'http://127.0.0.1:8000/admin/user/list' \ -H 'Authorization: Bearer <admin-token>' \ --data-urlencode 'mobile=13800000000' \ --data-urlencode 'status=1'

日志里应该能看到最终 SQL 使用的是新字段：

SELECT * FROM admin_user WHERE mobile = ? AND status = ? LIMIT 10

如果日志里还是 `phone = ?`，说明生成后的某一层没有同步。这个问题和 AI 关系不大，手写也会犯；AI 只是把文件生成得更快，让这种不一致更不容易被肉眼发现。

发布前检查表

最后给一份可以直接复制的检查表：

[ ] 项目里只有一套 Pinia 权限入口 [ ] 动态路由、按钮权限、接口权限来自同一个后端响应 [ ] localStorage 里没有旧权限字段继续参与判断 [ ] 普通角色访问管理员接口返回 403 [ ] SQL 能查出未绑定角色的接口权限 [ ] 新增字段后列表、表单、搜索、导入导出同步更新 [ ] pnpm typecheck / pnpm build / go test ./... 通过 [ ] 权限拒绝日志能定位 user、role 和 perm

如果你正在用 Cursor 或 Agent 生成 GoFrame + Vue3 后台，建议先跑这张表。页面生成得快是好事，但后台系统真正怕的是“看起来能用，权限和状态其实各走各的”。