权限系统很适合拿来测试 AI 编程工具。

它看起来是后台项目里的常规模块，但真做起来一点都不轻。用户、角色、菜单、接口权限、登录鉴权、数据边界，每一块都不难，但只要边界没想清楚，后面就会越改越乱。

我这次没有拿一个成熟项目去测，而是建了一个很轻的 auth 项目，从接近空白的状态开始，看飞算 JavaAI 能不能先帮我把权限系统的工程框架和开发规则立起来。

这个体验反而比“直接生成一堆代码”更有意思。

一、我没有直接让它写 RBAC

如果一上来就问：

帮我写一个 RBAC 权限系统。

大概率会得到一套看起来完整、但细节很虚的代码。

比如用户表、角色表、菜单表、用户角色关联表、角色菜单关联表，它都能写出来。但权限系统的问题从来不只是“表有没有”。更关键的是：

• 菜单权限和接口权限是不是同一套？
• 按钮权限要不要单独维护？
• 登录态用 Session 还是 JWT？
• 普通用户越权访问接口时怎么拦？
• 数据权限是现在做，还是先留扩展口？
• Service 层事务和异常返回怎么统一？

这些问题如果不先定，后面生成再多代码也只是堆文件。

所以我这次先让它围绕项目做智能引导，而不是直接写 Controller。

我给的背景大概是：做一个 Spring Boot 3.x 的权限系统，JDK 17，Maven 构建，使用 JPA，先完成用户、角色、菜单和授权关系，要求有清晰分层，后续能扩展接口鉴权和按钮权限。

飞算 JavaAI 先落下来的，不是完整业务代码，而是一份项目规则。

这点我觉得挺关键。

二、它先帮我把工程规矩写清楚了

在 auth 项目里，我看到一个 .feisuan/rules/project_rule.md 文件。

里面把项目基础约束先写出来了：工作目录、Mac 环境、Maven、JDK 17、Spring Boot 3.x，以及 spring-boot-starter-web、spring-boot-starter-data-jpa、lombok 这些核心依赖。

更重要的是，它把目录结构和分层规范提前列了出来：

• Controller 只处理 HTTP 请求
• Service 负责业务逻辑和事务
• Repository 继承 JpaRepository
• Entity 不直接返回给前端
• DTO、Entity、Config 分包管理
• @Transactional 只放在 Service 层
• 使用 @Valid 和 jakarta.validation 做参数校验
• 禁止手动拼接 SQL
• 日志使用 @Slf4j
• 类、方法、字段都要求中文 Javadoc

这些东西听起来不花哨，但对权限系统这种模块很重要。

因为权限系统后面一定会持续扩展。今天只有用户和角色，明天可能要加部门、岗位、菜单树、接口白名单、数据范围、操作日志。如果一开始没有工程规矩，后面每加一块都会变成补丁。

这也是我觉得飞算 JavaAI 和普通聊天框不太一样的地方。

普通聊天框更容易给你一段答案。飞算更像是先告诉你：这个 Java 项目应该按什么规矩往下长。

三、第一版最值得看的不是代码量

我打开 auth 项目时，源码里还没有完整的权限系统，只有一个很轻的入口文件。

如果只用“生成了多少代码”来评价，这次体验当然不算惊艳。

但我反而觉得，这个阶段更适合看另一件事：它有没有把后续开发的边界先框出来。

权限系统最怕一开始就冲着代码去。

比如生成一个 UserController 很容易，但用户创建时密码怎么加密？角色授权要不要校验菜单是否存在？删除角色时已有用户怎么办？菜单树返回给前端时要不要过滤无权限节点？这些问题不解决，接口写得越快，返工越快。

所以我更愿意把这次 auth 当成一次“项目起步体验”。

飞算 JavaAI 先给了规则文件，相当于给后续生成代码立了上下文：用什么技术栈，怎么分层，事务放在哪里，实体和 DTO 怎么区分，安全和性能有哪些底线。

对初中级开发来说，这种规则文件很有帮助。

很多人学 Spring Boot 时，卡住的不是语法，而是不知道项目该怎么组织。权限系统尤其明显，表一多、接口一多，很容易写成一团。先看到一份工程规范，再继续生成业务代码，会比直接从空白文件开始舒服得多。

四、后面我会重点追三件事

如果继续把这个 auth 项目往下跑，我不会急着看页面，也不会先看接口数量。

我会先追三件事。

第一，表关系是否清楚。

用户、角色、菜单、用户角色、角色菜单这几张表必须能讲明白。按钮权限和接口权限可以先不做复杂，但至少要有扩展位置，不能写死在代码里。

第二，鉴权链路是否闭环。

登录以后怎么拿用户身份，接口怎么判断权限，未登录和无权限分别返回什么，哪些接口允许匿名访问，这些要能串起来。权限系统不能只停留在菜单展示层。

第三，生成后能不能继续按规则迭代。

我比较在意 .feisuan/rules/project_rule.md 后续是否真能约束生成结果。比如继续让它补 UserService、RoleService、MenuController 时，能不能保持 Service 层事务、Repository 数据访问、DTO 返回、中文注释这些约定。

如果能做到，这个工具就不只是“生成代码”，而是在帮你维持一个 Java 项目的开发秩序。

五、我的真实感受

这次体验给我的感觉是：飞算 JavaAI 更适合从项目起步阶段介入。

它不是一上来就替你拍板所有权限设计，而是先把工程规则、目录结构、技术栈、开发约束摆出来。这个过程没那么刺激，但对 Java 项目很实用。

权限系统这种东西，第一版不应该追求“代码很多”。真正重要的是边界清楚、规则清楚、后面能继续改。

9.9 元包月适合拿来做这种小项目练习。不要只跑一次就结束，可以像我这样从一个 auth 空项目开始，先让它生成规则，再让它补用户模块、角色模块、菜单授权，最后自己审事务、权限和异常处理。

“一天助你成为Java高手”这句话，我更愿意理解成：一天里完整走一遍从需求、规则、工程骨架到人工审查的流程。

它不会让你一天变成权限系统专家，但能让你更快知道，一个 Java 项目从 0 到 1 不能只靠写代码，还要先把工程边界想清楚。