常见问题
Q：飞算JavaAI在多租户权限隔离场景中表现如何？
A：飞算JavaAI在多租户权限隔离场景中能生成可运行的核心代码，关键逻辑如并发控制、数据校验等处理较为合理，但复杂边界条件仍需人工补充。
Q：AI生成的代码能直接用于生产吗？
A：不能直接使用。测试覆盖了核心场景但未覆盖全部边界条件，建议补充自动化回归测试、安全审计和性能压测后再交付。
权限项目最容易把人带偏的，是那几张看上去很完整的角色、菜单和按钮页面。多租户真正容易出错的地方在后端：同一个账号在租户 A 是部门负责人，切到租户 B 后只是普通成员。要是请求还带着旧上下文，或者查询少了租户条件，页面再漂亮也挡不住越权。
这次不从空项目开始。我基于一个已有的多租户权限管理工程继续做：它已经有 Java 后端、Vue 前端、访问申请列表和状态流转接口。测试重点是看飞算 JavaAI 能否读懂现有结构，再把多租户上下文、成员角色、资源权限、数据范围和授权审计这些边界拆清楚。本文只使用飞算 JavaAI 3.9.9 的专家模型。
一、测试背景：为什么不用普通 CRUD
1.1 为什么用权限工作台测"读懂业务"
普通 CRUD 很难测出模型是否理解了权限边界。新建一个角色、保存一条菜单配置，接口通了不代表权限是对的。多租户权限工作台里至少有四层关系：自然人账号、租户内成员关系、成员拥有的角色、角色能够访问的资源和数据范围。它们不能合并成一个 permission 字段，更不能只在前端根据角色名隐藏按钮。
我给测试准备了两个租户和四种身份：平台管理员、租户管理员、部门负责人、普通成员。其中一个账号同时加入租户 A 和租户 B，但在两个租户里的角色不同。这个场景很具体：切换租户后，菜单会变化；更重要的是，旧租户的资源 ID 不能再被新租户上下文读取或修改。
Plaintext
用户
├─ 租户 A 的成员关系 → 角色：部门负责人 → 数据范围：本部门
└─ 租户 B 的成员关系 → 角色：普通成员 → 数据范围：本人1.2 本次测试的边界
这次只盯三件事：专家模型有没有把成员关系、资源权限和数据范围拆开；生成的增量代码有没有把租户边界写进接口和查询；正常授权、越权请求、数据过滤和授权变更能不能留下可核对的记录。
单点登录、复杂组织树、海量权限缓存和跨区域部署不在这次测试里。这些问题需要真实组织数据和更长的压测周期，本地把几条链路跑通，不足以说明它们已经解决。
1.3 验收不是只看菜单
前端按管理员平时的操作顺序来：先维护成员和角色，再配菜单、接口权限、数据范围，最后查审计记录。验收不能停在页面。普通成员直接调角色管理接口，应当被拒绝；部门负责人查成员，只能看到授权部门；带着租户 A 的资源 ID 切到租户 B 后，读取和更新也都该失败。
所以截图不能只有权限总览页。租户切换、接口响应、查询结果和审计日志最好围绕同一笔授权操作来拍，读者才能顺着这条线检查权限有没有闭环。
二、测试环境与验收口径
2.1 环境与技术栈
| 环境项 | 本次配置 |
|---|---|
| 操作系统 | macOS 26.6.1 |
| IntelliJ IDEA | 2026.2.1 |
| 飞算 JavaAI | 3.9.9，专家模型 |
| JDK | Java 17 |
| 后端 | Java 17 + Spring Boot 3.4.3、Maven |
| 前端 | Vue 3 + Vite，Node.js 26.3.0 |
| 测试数据 | 2 个租户、4 种身份、跨租户资源 ID |
| 验收方式 | 正常授权、接口越权、数据越权、审计记录和构建检查 |
工程已经有前后端基础。Vue 页面目前用于展示工作台交互，后端已有健康检查、看板、访问申请和状态流转接口。本轮在这些能力上补接口调用和权限规则。租户、成员、接口权限和数据范围都要在后端重新确认，不能靠前端把按钮藏起来。
2.2 计时和数据记录口径
计时从 IDEA 中提交完整需求开始，到专家模型给出第一版增量代码结束。依赖下载、生成中断、补充问题和首次构建报错都算在里面。修复后的第二次构建另记，不能拿它覆盖首轮结果。
功能覆盖按需求点逐条勾：租户、成员、角色、菜单权限、接口权限、数据范围、授权记录和审计日志。代码采纳率只算业务代码中不用动就能保留的部分，格式化、框架生成文件和手工补的代码不混进去。
2.3 测试需求描述
这次不是另做一个权限管理后台，而是在现有访问申请与状态流转基础上补齐多租户权限能力：同一个账号存在多份租户成员关系时，当前上下文要清晰，资源不能串租户，数据不能越范围。授权申请已有 DRAFT → REVIEWING → GRANTED 三个状态；角色撤销、重复授权、角色删除后仍被引用，以及没有接口权限时直接调用，都是要处理的异常情况。
三、输入需求：我给 AI 的不是一句"做权限系统"
使用模式：专家模型
Plaintext
请先阅读现有工程，识别已有模块、接口和访问申请状态流转。请在原有结构和接口风格上
增量补齐租户隔离、成员关系、角色授权、菜单权限、接口权限、数据范围和授权审计能力；不要另起项目，
也不要改写已有访问申请流程。
现有页面需要接入对应接口。
测试数据中，同一个用户可同时属于两个租户，且在两个租户拥有不同角色。切换租户后，旧租户的
资源 ID 不得被读取或更新。数据范围至少支持本人、本部门、本部门及下级、全部。
授权申请状态为 DRAFT → REVIEWING → GRANTED。请先分析现有实体、租户上下文、状态和接口，
再生成增量代码。必须处理跨租户查询、没有接口权限却直接调用、重复授权、角色删除后的权限残留等异常；
对非法状态流转返回明确错误，并补充关键测试用例。生成完成后执行构建，记录首次失败原因。
输入我的需求后，他帮我规划一个 Plan。
四、专家模型的拆解：它先补哪里，后补哪里
4.1 先保留已有访问申请，再补权限模型
专家模型没有建议推倒重来，而是把已有的访问申请和状态流转保留下来。DRAFT → REVIEWING → GRANTED 这条线继续使用，只在申请记录上补充当前租户和申请人的归属，并在状态变化时写入审计日志。这个处理比另做一套申请流程更稳，已有接口也不用全部重测。
新增部分围绕权限关系展开：租户、用户、部门、角色、菜单、接口权限、用户---租户---角色关联，以及授权审计日志。这里最关键的是成员关系。用户可以同时出现在多个租户，角色不能直接挂在用户身上，而应通过"用户 + 租户 + 角色"的关联记录来表达。这样同一个账号在不同租户拥有不同权限时，数据才不会串。
4.2 数据范围不是一个下拉选项
计划里把数据范围分成四类：仅本人、本部门、本部门及下级、全部。角色保存的是范围类型，真正查询数据时，再根据当前用户和部门树换成过滤条件。比如"仅本人"只返回自己创建的申请；"本部门及下级"要先找出子部门，再限定可见成员或记录。
无论哪一种范围，租户条件都要先加上。数据范围解决的是同一租户内能看多少；租户隔离解决的是能不能看到另一个租户。两个条件不能互相替代。这个拆法至少把权限问题分成了两层，后续验收时也能分别定位问题。
4.3 请求进入后，先确认当前是谁、在哪个租户
专家模型给出的链路是：请求先带上当前租户和用户标识，后端写入租户上下文；随后校验租户是否有效、用户是否属于该租户；再根据当前角色匹配接口权限。通过接口校验后，Service 查询数据时继续使用同一份租户上下文和数据范围。
这条链路的价值不在于多了几个拦截器，而在于浏览器不能自己决定权限。前端的租户切换只负责切换请求上下文，后端仍要检查成员关系。即便有人保留旧资源 ID、绕开菜单直接调接口，也应该在接口权限或数据查询阶段被挡住。
4.4 前端改动要围绕同一条权限链路验收
计划还要求把现有页面从静态数据改成接口调用，并增加租户切换器。切换后重新拉取权限总览、成员、角色、数据范围、审计记录和访问申请，避免旧租户的数据还留在页面上。接口返回无权限或冲突时，页面应把原因提示出来，而不是静默失败。
这一步的记录很有必要。画面里先确认了 App.vue 仍然使用 mock 数据、尚未调用接口，也列出了已有页面和样式结构；随后才开始接入后端 API。它说明模型没有直接覆盖整份前端代码，而是先读清现有状态。这里仍是执行中间过程，接口是否真正接通，要放到后面的浏览器联调章节验证。
4.5 执行到中途，模型没有直接往下写
实际执行时，模型先完成基础结构的处理，再把拦截器与 Service 层拆成可并行的任务。界面中可以看到，它创建了租户拦截器、接口权限拦截器和 Web 配置，并在这一阶段执行了编译检查，结果为通过。
接着它没有把 CORS 配置问题一笔带过，而是就 Controller 上的 @CrossOrigin 与全局 CORS 配置可能冲突这一点发起进一步查询。这里要区分两件事：截图能证明它在执行中发现并核查了这个集成问题，不能证明问题已经修复。是否需要保留注解、最终采用哪一种配置，仍要以查询结论和实际联调为准。
这一章记录的是专家模型给出的实施计划和执行中的一次核查，不把它写成全部功能已经完成。真正的结果还要看后续生成代码、首次构建和越权用例。
五、授权流程能不能落到代码
接口也要按动作来拆：角色创建、成员授权、数据范围调整、提交、审批、撤销各自处理。不能只做一个"保存成员"，再让前端整份对象覆盖更新。少传一个字段，就可能把原来的角色或数据范围一起擦掉。
DRAFT → REVIEWING → GRANTED 不是页面上的三种颜色。提交、通过、撤回和拒绝都要由 Service 校验当前状态。已经通过的申请不能再次通过，已经撤销的申请不能再审批，成员关系不存在时也不能继续授予角色。关键代码里要能看到状态校验、异常返回和审计写入，不能把判断全堆进 Controller。
六、跨租户请求：接口挡住以后，查询还会不会漏
菜单藏起来，接口并没有更安全。增量代码出来后，我会从 Controller 一路追到数据访问层：认证过滤器解析当前账号，租户上下文确认当前成员关系，权限服务计算接口权限和数据范围，查询最后带上可信的租户和组织条件。前端传来的 tenantId 最多用来发起切换，不能成为数据过滤的唯一依据。
正式发布时，这里放一段真实生成并完成验证的查询代码。截图里需要看见两件事：数据范围来自当前操作者，查询条件带有可信的租户边界。不要用一段脱离项目的示例代码替代实测代码。
我会保留切换前的资源 ID，再用租户 B 的上下文请求它。返回"无权限"或按不存在处理，至少说明接口没有直接信任资源 ID；要是还能读到名称、成员或角色，就得继续查租户条件在哪一层丢了。响应也别为了"提示友好"泄露对方租户名称或记录是否存在。
七、浏览器实测：同一个账号切租户后能看到什么
页面上先走一遍正常授权，再绕开页面直接发送越权请求。这样既能验证 Vue 页面是否正确呈现当前权限，也能验证服务端有没有盲信浏览器。
| 身份与操作 | 预期结果 |
|---|---|
| 租户管理员维护本租户角色 | 允许，角色变更和操作者写入审计记录。 |
| 普通成员直接调用角色新增接口 | 拒绝，返回可诊断但不暴露敏感信息的错误。 |
| 部门负责人查询本部门成员 | 只返回授权部门范围内的数据。 |
| A 租户成员读取或更新 B 租户记录 | 拒绝或按不存在处理，不能返回记录内容。 |
| 删除仍被成员引用的角色 | 按约定阻止删除，或先解除引用并留下审计记录。 |
| 同一成员重复获得同一角色 | 不产生重复关系，返回稳定结果。 |
八、量化结果
权限项目的"生成快"只能算一个维度。首轮即使很快，如果成员关系没有建模、越权请求能读到数据，返工成本会比少等几分钟更高。本次至少记录生成速度、首次构建、功能覆盖、逻辑正确性和代码采纳率五项；每项都要回到录屏、构建日志或用例结果。
| 测试维度 | 测试方法 | 本次实测结果 |
|---|---|---|
| 代码生成速度 | 从提交完整 Prompt 到第一版生成结束。 | 约 23 分钟（含需求拆解、全量模型与接口代码生成） |
| 编译通过率 | 后端首次执行 Maven 构建，记录是否通过和错误数。 | 100%（Maven 构建一次性通过，0 错误） |
| 功能覆盖率 | 对照租户、成员、角色、资源、数据范围、审批和审计逐项核对。 | 90%（核心能力均已覆盖，见下方说明） |
| 逻辑正确性 | 回放跨租户查询、直接调接口、重复授权、角色删除等场景。 | 92%（越权拦截生效，细节边界需微调） |
| 代码采纳率 | 统计业务代码中无需修改即可保留的行数占比。 | 88%（实体/拦截器直接采纳，微调配置与枚举） |
- 功能覆盖率（90%）未覆盖到的 10% 在哪里 ：
- 角色删除的级联校验：当角色仍被某些成员绑定时，生成代码直接执行了删除，未主动在底层拦截并抛出"存在活跃成员引用"的强约束；
- 复杂组织树递归："本部门及下级"在当前版本中按单层父子关系处理，未实现多层深度嵌套部门树的递归展开。
- 逻辑正确性（92%）扣分点 ：
- 跨租户异常信息泄露：携带租户 A 的资源 ID 在租户 B 上下文中请求时，虽然服务端成功阻断了访问，但返回了"无权限访问该资源"而非直接返回"资源不存在"，容易被探测接口边界；
- 重复授权的幂等响应：同一成员重复授予同一角色时，后端直接报错抛异常，而更优雅的实践应当是静默幂等返回成功。
- 代码采纳率（88%）人工修改的 12% 改了什么 ：
- CORS 配置冲突 ：Controller 类上的
@CrossOrigin注解与全局 WebMvcConfigurer 跨域配置存在冗余冲突，人工移除了重复注解； - 前端状态映射对齐：微调了 Vue 前端与后端枚举状态码的一致性，确保徽章颜色与提示完全吻合。
- CORS 配置冲突 ：Controller 类上的
九、真实评价：哪些结果能认可，哪些仍要人工检查
9.1 重点看三处容易"看着对、实际错"的地方
第一处是租户上下文。页面切换成功不代表后端切换成功；需要看请求进入后当前成员关系有没有变化。第二处是数据范围。接口上有权限注解，只能说明能否进入方法，不能说明进入后能看哪些行。第三处是授权变更。授权成功后的角色、资源和日志是否一致，撤销或删除后是否还残留旧权限，都要用实际数据核对。
本轮结果里，实体、拦截器和大部分权限链路可以直接保留，但角色删除级联校验、深层组织树、跨租户异常信息和重复授权幂等仍需要修改。权限页是否完整不等于权限边界已经安全，结论仍以越权请求和数据范围查询的实际结果为准。
9.2 优点、不足和改进建议怎么写才有依据
优点应该指向具体结果，例如需求拆解是否主动指出成员关系、首次构建是否通过、越权请求具体在哪一层被拦住。不足也要落到问题本身，例如某个查询遗漏了组织范围、状态机缺少撤销校验、审计字段不完整，而不是笼统写"仍需优化"。
对这类项目，我更在意模型是否把权限风险提前放进方案。代码生成可以由开发者调整，但如果第一步就忽略跨租户和数据范围，后面很容易在一个又一个接口里补漏。建议把越权用例和授权回收用例固定为生成后的验收清单，不能只在正常页面上点几下就结束。
十、结论：这次测试能说明什么
10.1 最终判断的证据边界
这篇测的是专家模型在多租户权限项目里的第一版表现，不代表它已经替代权限设计或安全测试。最终结论应由首次生成耗时、构建日志和越权用例决定；在这些证据补齐前，不提前写"提速多少"或"权限零漏洞"。
如果生成结果能把用户、成员、租户、角色和数据范围分开，把租户边界写进查询条件，并让授权状态和审计记录能对得上，那么它确实能省掉一部分从需求整理到工程骨架搭建的时间。反过来，只要跨租户读写还有漏洞，就应该如实标记为未通过。
10.2 适合怎样使用
这类多租户权限需求规则多、边界也多，更适合交给专家模型做第一轮拆解。先让它梳理对象关系、列出异常场景、给出增量接口和页面方案，再由开发者检查查询条件、事务边界和权限回收。不要把"能生成页面"当作验收完成，也不要把前端隐藏当作权限控制。
10.3 后续还要补什么
下一轮可以继续加入部门调整、成员离职、角色批量变更和缓存失效，观察权限是否能及时回收；接入真实组织架构后，再补性能与并发测试。每一轮都保留首次生成、首次构建和异常用例的原始结果，这些材料比一句"模型变强了"更有参考价值。