1. 项目缘起为什么让AI从零构建权限系统最近在做一个内部管理后台用户角色和权限这块的需求越来越复杂。一开始只是简单的管理员和普通用户后来产品经理提了需求要支持部门主管、审核员、运营专员每个角色能看到的菜单、能操作的数据范围都不一样。如果还是像以前那样在代码里写死一堆if-else来判断权限代码很快就会变成一坨难以维护的“屎山”。而且每次加一个新角色或者调整权限都得重新改代码、测试、上线非常麻烦。这时候一个标准化的用户权限系统就成了刚需。业内最成熟的方案就是RBACRole-Based Access Control基于角色的访问控制。它的核心思想是把用户和权限解耦用户关联角色角色关联权限。这样一来权限的分配和变更就变得非常灵活。比如新来一个“数据分析师”角色我只需要创建一个新角色把“查看报表”、“导出数据”这几个权限赋给它再把新用户关联到这个角色上就完成了完全不用动一行业务代码。正好最近在深度体验各种AI编程助手从GitHub Copilot到Cursor再到Claude。我就想能不能把需求完全交给AI让它从零开始把一个可用的RBAC权限系统给“啃”出来这既是对AI编程能力的一次压力测试也能为我自己以及可能遇到同样问题的开发者留下一份完整的、可复现的实践记录。整个过程我会扮演一个“挑剔的产品经理”和“严格的代码审查者”只提供需求不写一行代码看看AI到底能走到哪一步。2. 技术选型与需求澄清给AI划定跑道在把任务丢给AI之前我得自己先把技术栈和核心需求定下来给AI一个明确的“跑道”。不然它可能会天马行空用Python Django或者Go Gin给我实现一个虽然也能用但和我的技术栈不匹配就白忙活了。2.1 后端框架为什么是Spring Boot我的项目主体是Java技术栈Spring Boot是不二之选。它约定大于配置能快速搭建可独立运行的、生产级的应用。对于权限系统来说Spring Security是Spring生态中处理认证和授权的“官方指定”框架它与Spring Boot的集成是无缝的。虽然Shiro也是一个选择但Spring Security的功能更强大社区更活跃特别是对于OAuth2、JWT等现代安全协议的支持更好。因此我决定后端使用Spring Boot 3.xSpring Security的组合。2.2 权限模型RBAC的核心表结构设计RBAC有几种常见的模型最基础的是RBAC0标准模型还有包含角色继承的RBAC1、包含约束的RBAC2等。对于大多数后台管理系统RBAC0已经足够。我需要AI帮我设计出最核心的几张表用户表 (sys_user)存储用户基本信息如用户名、密码加密后、邮箱等。角色表 (sys_role)存储角色信息如角色名、角色标识符如ROLE_ADMIN、描述等。权限表 (sys_permission)存储权限点可以细化到“接口级别”或“资源级别”。通常包括权限标识符如user:add、权限名称、所属菜单/模块等。用户-角色关联表 (sys_user_role)记录用户和角色的多对多关系。角色-权限关联表 (sys_role_permission)记录角色和权限的多对多关系。除了这些通常还需要菜单表 (sys_menu)来管理前端侧边栏的导航结构菜单可以和权限绑定实现“有权限才看到菜单”的效果。2.3 关键需求点给AI的PRD我把这些需求整理成一份简明的“产品需求文档”准备喂给AI核心功能实现基于RBAC模型的用户、角色、权限管理。技术栈Spring Boot 3.x, Spring Security, JWT (用于无状态认证), MyBatis-Plus (简化数据库操作), MySQL。接口要求提供标准的RESTful API用于对用户、角色、权限进行增删改查CRUD以及关联操作。安全要求登录接口签发JWT后续请求需在Header中携带JWT进行鉴权根据用户角色和权限动态决定能否访问某个API。数据范围后续可能需支持“数据权限”例如部门主管只能看本部门数据第一期可只实现“功能权限”。输出要求生成完整的、可运行的代码包括实体类、Mapper、Service、Controller、Security配置类并提供基础的SQL建表语句。3. 与AI的协作实战Claude Code的“编码马拉松”我选择了Claude Code作为本次的主力AI。因为它不仅支持对话还能在IDE中直接操作项目文件上下文能力也足够强。整个过程更像是一场我指挥它动手的“结对编程”。3.1 第一回合搭建项目骨架与基础实体我的第一个提示词是“使用Spring Boot 3.x创建一个项目集成Spring Security和JWT并实现RBAC权限模型所需的核心数据库表结构设计。请先给出SQL建表语句。”Claude Code很快给出了响应。它先是用Spring Initializr的依赖列表创建了一个pom.xml包含了spring-boot-starter-security,jjwt用于JWT操作,mybatis-plus-boot-starter,mysql-connector-j等关键依赖。然后它生成了SQL语句。踩坑记录1JWT库的版本兼容性Claude最初生成的jjwt依赖版本是0.9.x这是一个很老的版本。而Spring Boot 3.x推荐使用更高的Java版本老版本的jjwt可能会有兼容性问题。我立刻打断了它“检查并更新jjwt依赖到与Java 17及以上兼容的最新版本。” Claude随后将其更正为io.jsonwebtoken:jjwt-api:0.12.3和io.jsonwebtoken:jjwt-impl:0.12.3等并说明了新版本API的变化。接着它生成了核心的实体类Entity如User、Role、Permission。这里我发现了第一个需要深度介入的设计点。3.2 第二回合深入细节与设计决策Claude生成的User实体直接包含了ListRole字段并使用ManyToMany注解。这在简单的演示中可以但在真实项目中用户角色关系可能附带额外属性如生效时间且直接查询可能导致性能问题N1查询。我要求它做出调整“将用户-角色、角色-权限的关联改为通过独立的关联实体如UserRole来管理并在Service层中实现关联的逻辑操作而不是完全依赖JPA的级联查询。同时用户的密码字段在返回给前端时必须被排除请考虑使用JsonIgnore注解。”Claude理解了需求将关联关系从ManyToMany拆解为OneToMany和ManyToOne并创建了UserRole和RolePermission实体。同时它在User的password字段上添加了JsonIgnore。但它忽略了一点在创建或更新用户时我们仍然需要通过接口接收密码。我进一步提示“JsonIgnore会导致反序列化接收请求时也忽略该字段。我们需要JsonIgnore只在序列化返回响应时生效反序列化时仍然接受密码字段。该如何处理”Claude给出了两种方案一种是使用JsonProperty(access Access.WRITE_ONLY)另一种是创建独立的DTOData Transfer Object。我选择了后者因为DTO能更清晰地区分API模型和持久化模型是更规范的做法。于是我们增加了UserDTO、UserCreateDTO等类。3.3 第三回合Spring Security与JWT的核心配置这是最复杂的一环。我给出的提示是“现在配置Spring Security。我们需要一个/api/auth/login接口进行登录并返回JWT。其他所有/api/**开头的接口都需要JWT认证。JWT中需要包含用户名和用户拥有的权限标识符列表。请编写JwtUtil工具类、JwtAuthenticationFilter、SecurityConfiguration。”Claude开始了它的表演。它创建了JwtUtil用于生成和解析JWT。然后创建了JwtAuthenticationFilter这个过滤器会拦截请求从Header中取出Token解析出用户名然后加载用户详情和权限。核心原理如何让Spring Security认识我们的权限Spring Security需要UserDetails对象来承载用户信息。Claude创建了一个UserDetailsServiceImpl实现了loadUserByUsername方法。这里的关键是我们不能只返回用户基本信息必须将用户拥有的所有权限从sys_permission表查出的标识符如user:add封装成SimpleGrantedAuthority对象列表并设置到UserDetails中。这样Spring Security才能在后续的鉴权判断中使用它们。接下来是重头戏SecurityConfiguration。Claude的初版配置存在一个典型问题Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http .csrf().disable() // 禁用CSRF因为使用JWT无状态 .authorizeHttpRequests(authz - authz .requestMatchers(/api/auth/**).permitAll() .anyRequest().authenticated() ) .addFilterBefore(jwtAuthenticationFilter, UsernamePasswordAuthenticationFilter.class); return http.build(); }这个配置只做到了“认证”Authentication即判断用户是否登录。但没有实现“授权”Authorization即判断登录的用户是否有权限访问某个接口。我立刻指出“目前的配置任何登录用户都能访问所有/api/**下的接口。我们需要实现基于权限标识符的动态授权。请使用PreAuthorize注解或hasAuthority(‘permission:code’)表达式在接口上进行控制。”Claude理解了它修改了配置开启了全局方法安全注解支持EnableMethodSecurity并在UserController的删除用户接口上添加了注解PreAuthorize(“hasAuthority(‘user:delete’)”)。这是一个好的开始但还不够。因为我们需要一种方式将数据库中的权限列表动态地映射到这些注解上而不是硬编码在每个Controller方法里。3.4 第四回合动态权限与全局异常处理我提出了更高级的需求“PreAuthorize注解需要硬编码权限字符串不便于维护。能否实现一种方式将某个接口的URL路径如DELETE /api/users/{id}与所需的权限如user:delete动态关联起来我们可以维护一个Permission实体其中包含url和method字段。在应用启动时或通过管理界面将URL与权限绑定。然后在SecurityConfiguration中动态配置这些路径的权限要求。”这是一个挑战。Claude经过几轮思考提出了一个方案实现一个自定义的DynamicSecurityMetadataSource它实现了Spring Security的FilterInvocationSecurityMetadataSource接口。这个类的作用是在收到一个受保护的URL请求时去查询数据库或缓存获取访问这个URL所需的权限列表。然后它再结合DynamicAccessDecisionManager实现AccessDecisionManager接口来判断当前用户是否拥有这些权限。这个方案非常接近生产级的动态权限控制了。虽然实现起来代码量稍大但Claude一步步地将其实现出来包括缓存权限数据以避免每次请求都查库。此外一个健壮的系统还需要统一的异常处理。我要求Claude创建一个全局异常处理器GlobalExceptionHandler用RestControllerAdvice注解专门捕获Spring Security抛出的AccessDeniedException权限不足和AuthenticationException认证失败并返回结构统一的JSON错误信息而不是默认的Whitelabel错误页。4. 前后端协作与接口测试后端API成型后我需要验证它们是否工作。虽然项目描述主要是后端但一个可用的系统离不开前端交互。我让Claude顺带生成了一个简单的UserController包含基本的CRUD接口。4.1 使用Postman模拟全流程注册/登录首先调用POST /api/auth/login传入用户名密码。成功后会返回一个token。携带Token访问在Postman的“Authorization”选项卡中选择“Bearer Token”类型将登录返回的token粘贴进去。测试权限控制用一个只有user:view权限的普通用户登录去调用DELETE /api/users/{id}接口。预期结果返回403 Forbidden错误错误信息为“权限不足”。用拥有user:delete权限的管理员用户登录再次调用删除接口。预期结果成功删除或返回成功消息。通过这个流程可以完整验证从认证JWT到动态授权权限拦截的整个链条是否通畅。4.2 前端权限控制的延伸思考Claude生成的后端权限系统其权限信息已经包含在JWT或用户详情接口中。前端如Vue、React可以根据这些信息做两件事动态路由只加载和显示当前用户有权限访问的菜单和页面。按钮级控制在页面上根据权限列表判断“删除”按钮是否应该显示或禁用。虽然本次任务聚焦后端但AI也可以根据这些思路为前端生成对应的权限校验工具函数或Vue指令的示例代码。5. 复盘、优化与AI编程的边界项目核心功能跑通后我进行了一次完整的复盘看看还有哪些坑要填以及AI的极限在哪里。5.1 必须手动干预的“深水区”数据权限这是RBAC功能权限之外的另一个维度。例如“部门经理只能查询本部门员工”。这涉及到在SQL查询层面动态添加WHERE department_id ?条件。AI虽然能理解这个概念但实现一个优雅、通用的数据权限框架如使用MyBatis插件拦截器动态修改SQL非常复杂需要深厚的架构设计能力。Claude只能提供一些零散的思路和代码片段无法独立完成一个生产可用的方案。权限变更的实时性用户权限被修改后如何立即生效如果权限信息缓存在后端服务器内存中修改数据库后缓存不会失效。这就需要引入分布式缓存如Redis并设置合理的过期策略或者在权限变更时主动通知各服务节点清理缓存。这个涉及分布式系统设计AI很难自主完成闭环。复杂的多租户场景如果是SaaS系统需要隔离不同租户的数据和权限。这需要在所有实体表中增加tenant_id字段并在每一次数据查询和权限校验中自动带入。AI可以帮你修改SQL和实体类但如何设计一个无侵入、低耦合的多租户架构依然需要人工主导。5.2 AI编程的独特价值与当前局限价值效率爆炸从零到搭建出一个具备核心认证授权功能的可运行系统如果我自己编码至少需要1-2个完整工作日。在AI的辅助下这个时间被压缩到了几小时内大部分时间花在需求澄清和设计复审上。知识查漏AI能快速提供不同技术方案的选择。比如在实现JWT过滤器时它会提醒你注意Token过期、刷新Token等问题这些都是容易遗漏的细节。样板代码生成器创建实体类、Mapper接口、基础的Service和ControllerAI几乎不会出错且格式标准极大地减少了枯燥的重复劳动。局限设计决策依赖人类AI是优秀的“执行者”但不是“架构师”。像是否使用DTO、关联关系如何设计、缓存策略如何选型这些关键设计点必须由人类做出判断。AI只能在你选定方向后提供实现方案。对复杂业务逻辑理解有限对于高度定制、充满业务规则的逻辑AI容易“跑偏”。你需要将需求拆解得极其细致步步为营。调试与排错能力弱当代码运行报错时AI能根据错误日志提供一些排查方向但深度分析、定位根因的能力远不如一个有经验的程序员。你最终还是得靠自己去看日志、打断点。5.3 给开发者的实操建议如果你也想用AI辅助完成类似项目我的经验是自己必须懂你至少要对Spring Security、RBAC、JWT有基本概念。否则你无法评估AI生成的代码是否正确、是否安全更无法提出正确的改进指令。需求分阶段指令要具体不要一次性说“做一个权限系统”。把它拆解成“设计表结构”、“实现登录和JWT签发”、“实现基于角色的权限拦截”等具体任务。每个任务的指令都要明确技术栈和关键要求。扮演严格的Code Reviewer不要假设AI生成的代码就是完美的。要带着审查的眼光去看每一行代码特别是安全相关如密码加密、SQL注入防护、性能相关如N1查询的部分。善用AI的“学习”能力当AI给出的方案不理想时告诉它为什么不行“这个方案在并发下会有问题因为…”并提供更好的思路“请考虑使用Redis缓存权限数据并设置过期时间”。AI会在后续的响应中应用这些反馈。让AI从零构建一个权限系统与其说是一次自动化开发不如说是一场高强度、高密度的“编程思维训练”。它迫使你将模糊的需求转化为精确的指令将宏观的设计拆解为微观的实现。最终得到的不仅仅是一套可运行的代码更是一份关于如何与AI协作解决复杂工程问题的清晰地图。