常见问题（FAQ）
Q：飞算JavaAI在设备借用审批流中的真实水平如何？
本文以设备借用审批流系统实测飞算JavaAI 3.9.9。测试发现，需求拆解比较像Java工程，能抓住需求中真正困难的名词，最小运行闭环已经建立，项目能启动且登录链路能够走通。
Q：飞算JavaAI生成代码的不足有哪些？
最核心的并发题还没有证据，状态机只有结构没有源码级审查，数据库描述存在需要核对的地方，当前验证样本过少。
Q：飞算JavaAI如何处理权限校验和库存扣减？
生成结果没有把所有逻辑都塞进Controller，在权限校验到库存扣减的业务链路中体现了对复杂逻辑的理解，四张表背后的复杂逻辑被合理拆分到不同层级。
一、为什么这次不再让 AI 写普通 CRUD
评价一个 Java 编程模型，只看它能不能生成 Controller、Service 和 Mapper，已经很难拉开差距。真正进入业务系统后，开发者面对的是另一类问题：当前用户到底能操作哪些数据？一条申请可以从什么状态走向什么状态？库存、申请状态和操作日志能不能在同一个事务里保持一致？两个人同时抢最后一件设备时，系统会不会把库存扣成负数？
所以这次我没有让飞算JavaAI再写一套"增删改查"，而是给它设计了一套设备借用审批需求。项目不大，只有 USER 和 ADMIN 两种角色、四张核心表，但同时包含权限链路、六状态状态机、事务一致性和并发库存约束。我的目标不是预设它一定更强，而是观察飞算JavaAI 能否把这些互相牵连的业务规则拆成一套像样的 Java 工程。
二、测试环境与验证边界
表格 还在加载中，请等待加载完成后再尝试复制
这里需要提前说明：因为没有升级前版本的同题结果，我不会写"能力提升了百分之多少"。本文能回答的是这一次生成做到了什么、还缺少哪些证据，而不是给模型能力编造一个提升幅度。
三、测试需求：四张表背后的复杂逻辑
我在飞算JavaAI中一次性提交完整 Prompt。输入面板显示为 2802 / 100000，主要要求包括：
- 只生成 Java 后端，不用前端、微服务、Redis、消息队列和工作流引擎；
- 使用 Java 17、Spring Boot 3.x、Spring Security、JWT、MyBatis-Plus、H2 和 Swagger；
- USER 只能查看、取消自己的申请，ADMIN 才能审批、驳回、确认领用和确认归还；
- 用户 ID 与角色必须从 JWT 上下文获得，不能相信前端传入的身份；
- 设计
sys_user、asset、borrow_request、operation_log四张核心表； - 申请包含 PENDING、APPROVED、REJECTED、BORROWED、RETURNED、CANCELLED 六种状态；
- 批准申请时，扣库存、改状态、写日志必须处于同一个事务；
- 当可用库存只剩 1 时，两条并发审批只能有一条成功，另一条返回 HTTP 409；
- 状态判断集中在 Service 或独立状态机中，不能散落到 Controller；
- 提供自动化测试和真实验证结果，不能虚构执行成功。
图1：在 IDEA 的飞算JavaAI插件中输入完整需求。测试故意把权限、状态和库存放进同一业务流程，而不是只要求生成 CRUD。
从需求复杂度看，这个项目做了刻意收敛：不接入外部系统，也没有前端页面，但后端必须理解四类相互影响的规则。
权限：USER 只能操作自己的申请，ADMIN 执行审批动作
状态：PENDING → APPROVED → BORROWED → RETURNED
事务：库存变化 + 申请状态 + 操作日志必须共同提交或共同回滚
并发：最后一件库存只能被一条申请成功占用
如果模型只会生成表和接口，项目看起来也许很完整，但一跑非法状态、越权访问或并发审批就会露馅。这正是本次测试想观察的地方。
四、生成结果：没有把所有逻辑都塞进 Controller
从飞算JavaAI输出的项目结构看，它生成了 13 个模块分组、共 50 个截图中可见的命名文件。结构不是只有几个 Controller，而是覆盖了配置、控制器、服务、实体、DTO、VO、Mapper、安全模块、公共模块、数据库脚本、测试和文档。
图2：生成结果中的工程结构。可以看到独立状态机、安全上下文工具、业务服务实现、数据库脚本和测试文件。
我按截图逐项统计后得到下面这组结构数据：
表格 还在加载中，请等待加载完成后再尝试复制
这组数据只能证明"工程拆分与需求对应得上"，不能等价为"所有业务逻辑都正确"。但它至少说明模型没有把复杂需求降级成四个实体类加一堆通用 CRUD。
几个细节比较值得注意。
第一，用户端的 BorrowRequestController 和管理端的 AdminBorrowRequestController 被分开了。即便后端仍需在方法级继续做权限校验，这种入口拆分也比把全部动作放进一个大 Controller 更容易审查。
第二，安全模块里不只有 JWT 工具类，还出现了 JwtAuthenticationFilter、JwtAuthenticationEntryPoint、JwtUserDetails、CustomUserDetailsService 和 SecurityContextUtil。这说明模型至少在结构上理解了"身份不能由前端自己声明"，而是要把认证信息送入安全上下文。
第三，BorrowRequestStateMachine 被放进公共模块，状态枚举和操作枚举也独立存在。这与 Prompt 中"状态判断不能散落在 Controller"的要求一致。遗憾的是，当前截图没有展示该类的源码，因此我不能进一步确认它是否真的拒绝了全部非法跳转，也不能把文件存在写成逻辑已通过。
五、运行验证：项目能启动，登录链路能够走通
生成工程后，我在 IDEA 中启动了 AssetBorrowFlowApplication，然后在终端调用登录接口。实际返回内容经过脱敏后如下：
图3：登录返回结果检查。原始终端截图中含完整JWT，为避免把令牌带入公开文章，这里不直接展示该令牌。
从这一次响应能够确认五个检查点：请求成功、业务码为 SUCCESS、消息为"登录成功"、返回了 JWT、用户信息为 user1 / USER。因此，本次可见的登录检查结果是 5/5 项符合预期 ，启动与登录这一条链路为 1/1 次成功。
这个结果至少证明：项目不是停留在代码目录展示，Spring Boot 服务能够启动，初始化用户可以被认证，JWT 能被生成并放入统一响应结构。但我没有看到 HTTP 状态码截图，也没有执行错误密码、无令牌访问和普通用户调用管理员接口，所以不能顺势宣称 401、403 权限分支已经验证通过。
六、量化结果汇总
表格 还在加载中，请等待加载完成后再尝试复制
这份结果中最有价值的数据，不是"生成了多少行代码"，而是需求清单与工程结构之间能建立明确映射，同时完成了最小可运行链路。它证明了模型的业务拆解能力有可感知表现，但尚不足以证明复杂逻辑已经通过工程验收。
七、我认为做得好的地方
1、需求拆解比较像 Java 工程，而不是文件堆砌
DTO、VO、Mapper、Service、Controller 都有独立边界，认证、安全上下文、状态机和异常处理也没有完全混在业务类里。对后续维护来说，这比"一个 Service 写完所有逻辑"更容易阅读和测试。
2、能抓住需求中真正困难的名词
Prompt 的重点是权限、状态机、事务和并发。生成结构里确实出现了 SecurityContextUtil、BorrowRequestStateMachine、OperationLog 和测试类，而不是只把字段翻译成数据库表。这一点符合方向一想验证的"读懂"能力。
3、最小运行闭环已经建立
应用启动后，登录接口能查询到演示用户、校验身份并返回 JWT。对于一次从零生成来说，能够从工程结构继续走到真实 HTTP 响应，比只给出源码片段更有说服力。
八、不足和仍需补测的地方
1、最核心的并发题还没有证据
"最后一件设备只能批准一条申请"是本项目最能检验模型水平的测试，但现有截图没有展示原子更新 SQL、乐观锁条件或并发测试结果。即使存在 BorrowFlowTest，在没有测试输出前也不能认为并发已经正确。
2、状态机只有结构，没有源码级审查
独立的 BorrowRequestStateMachine 是一个好信号，但还需要检查它是否明确拒绝 PENDING → BORROWED、RETURNED → RETURNED 等非法跳转，以及失败时是否稳定返回 HTTP 409。
3、数据库描述存在需要核对的地方
原始 Prompt 指定默认使用 H2，项目结构截图底部的说明却写了 MySQL 技术栈。仅凭截图无法判断实际运行 Profile 和 SQL 方言。发布前应该打开 application.yml、schema.sql 和 pom.xml 再核对一次，避免文档与运行环境不一致。
4、当前验证样本过少
目前只有一次成功登录。文章还缺少越权访问、非法状态、库存不足、重复归还、事务回滚和双请求并发审批等失败路径。这些失败路径恰恰比成功请求更能证明模型是否真正理解业务。
九、如果继续测试，我会补这五步
- 用
user1读取user2的申请，确认后端返回 403，而不是只隐藏接口。 - 对同一条 PENDING 申请连续审批两次，确认第二次返回 409，且只产生一条有效日志。
- 把设备可用库存设为 1，并发批准两条各借 1 件的申请，确认只成功一条且库存不为负。
- 人为让操作日志写入失败，检查库存和申请状态是否一起回滚。
- 执行
mvn test，记录测试总数、通过数、失败数、首次编译错误和人工修改次数。
如果这五步都能通过，才能比较有底气地说：模型不仅把需求拆得漂亮，也把最难的边界落实进了可运行代码。
十、结论：它"读懂"了吗？
基于这次可复核的结果，我的判断是：飞算JavaAI 3.9.9 专家模型已经表现出明显的业务拆解意识。面对设备借用审批需求，它能够把两类角色、四个核心实体、六层工程结构、独立安全模块和状态机边界组织成完整项目，并跑通启动和 JWT 登录链路。这部分体验已经超出"帮我写几个 CRUD 接口"的层次。
但我不会仅凭目录完整和一次登录成功，就断言事务、状态机和并发库存全部正确。当前最关键的 403、409、回滚和并发审批仍缺少真实执行证据。因此更准确的结论是：模型在"理解并拆解复杂需求"这一步表现不错，已经具备可感知的工程化能力；在"证明复杂实现正确"这一步，仍然必须依靠源码审查、自动化测试和并发验证完成闭环。
对 Java 开发者来说，我建议把飞算JavaAI用于搭建工程骨架、拆分业务模块和生成第一版实现，同时保留开发者对权限、事务、状态流转和并发边界的最终审查权。AI 可以明显缩短从需求到可运行工程的距离，但生产可靠性仍然要靠证据，而不是靠生成完成时的一句"已实现"。
#飞算JavaAI #AI编程 #Java #Java代码生成 #AIcoding模型 #Java开发 #SpringBoot #SpringSecurity #JWT #MyBatisPlus