飞算JavaAI写全栈项目提速是玄学吗？

常见问题

Q：飞算JavaAI在全栈项目提速场景中表现如何？

A：飞算JavaAI在全栈项目提速场景中能生成可运行的核心代码，关键逻辑如并发控制、数据校验等处理较为合理，但复杂边界条件仍需人工补充。

一、为什么这次不只测一个 CRUD

最近体验 AI 编程工具时，我越来越不想只看"能不能补全一个方法"或者"能不能生成一张表的 CRUD"。真正会占用开发时间的，往往是把需求拆成前后端工程、统一接口字段、处理认证和业务边界，再经过编译、测试、启动和联调，把代码变成一个能交付演示的项目。

所以这次我给飞算JavaAI的任务，是从零生成一个完整但不刻意堆技术的全栈项目：保质哨兵 ShelfGuard。它是一套食品库存与临期预警系统，需要包含 JWT 登录、食品分类、食品批次、动态状态计算、库存入库/出库/报损、库存流水以及数据看板；后端使用 Spring Boot，前端使用 Vue，默认用 H2 降低复现门槛，同时保留 MySQL 配置。

这篇文章不做"几分钟生成完整系统"式的结论。原因很简单：本轮没有连续记录从提交提示词到最终运行的总分钟数，也没有做升级前版本或纯手写的同需求对照。能够量化的部分，我只采用实际项目和本轮验证数据；没有记录的耗时与采纳率，明确标记为未统计。

二、测试条件与需求边界

1、测试环境

|---------------|----------------------------------------------------------------------|
| 项目 | 实际值 |
| 操作系统 | macOS 26.6.1，Apple Silicon（aarch64） |
| IntelliJ IDEA | 2024.1.7（IU-241.19416.15） |
| 飞算JavaAI | 3.9.8 |
| JDK | OpenJDK 17.0.20 LTS |
| Maven | 3.9.16 |
| Node.js / npm | v24.16.0 / 11.13.0 |
| 后端框架 | Spring Boot 3.3.13、Spring Security、MyBatis-Plus 3.5.7、JWT、H2 / MySQL |
| 前端框架 | Vue 3.5、Vite 6、Vue Router、Pinia、Axios、Element Plus |

本机全局 mvn -version 默认显示的运行时是 Java 26，但项目要求 JDK 17，因此验证脚本会显式定位并使用 JDK 17。这个细节很重要：只写 java.version=17 并不等于 Maven 一定运行在 JDK 17 上。

2、我给 AI 划定了什么范围

为了让测试接近真实开发，同时控制在个人可以复现的规模，我在提示词里设置了几条硬约束：

• 根目录为 shelf-guard，后端和前端分别放在 shelfguard-server、shelfguard-web

• 后端提供 REST API、JWT 认证、统一响应、参数校验、全局异常处理和自动化测试

• 前端包含登录、看板、食品批次、库存流水、分类管理 5 个页面

• 食品状态不持久化，根据库存、到期日和当前日期实时计算

• 所有库存变化必须留下不可编辑的流水，并通过版本号避免旧请求覆盖新库存

• 默认 H2 开箱即用，同时提供 MySQL 8 配置

• 禁止扩展供应商、采购、销售、消息通知、多门店、审批流等无关模块

图 1：完整提示词的项目名称、目录、技术栈和范围约束

图 2：提示词进一步规定测试、构建、联调和最终交付标准

这里最有价值的不是提示词写得长，而是它把"做到什么程度"说清楚了。若只说"生成一个库存管理系统"，AI 很容易给出几张 CRUD 页面，却忽略认证、库存并发、业务异常和可复现性。

三、从提示词到完整工程：生成过程实录

1、先让 AI 建立工程骨架和安全边界

提交提示词后，飞算JavaAI没有只在聊天框里返回零散代码，而是直接在工作区创建文件。截图中可以看到它按安全层、实体、枚举、DTO、VO、Mapper 等顺序逐步落盘，例如 JwtAuthenticationFilter.java、SecurityConfig.java、FoodBatch.java、StockRecord.java 和多个请求对象。

图 3：生成过程中可查看单个步骤的思考时间和已创建文件

这种过程反馈带来的体感并不是"每个文件瞬间完成"，而是我能看到任务正在被拆解：先认证，再数据模型，再请求和响应对象，之后才进入服务与接口。截图中部分单步显示 5 秒到 23 秒不等，但这些数字只是局部步骤，不能相加当作项目总耗时。

项目树最终形成了标准的分层结构。后端包含 controller、service、mapper、entity、dto、vo、security、config 和 exception；资源目录中同时有 H2 与 MySQL 配置。前端则是独立 Vue 工程，通过 Vite 代理访问后端 /api。

图 4：IDE 中生成的前后端工程和后端分层目录

从最终工程统计看，共有 81 个有效项目文件 （排除 node_modules、target 和 dist），其中后端主代码有 46 个 Java 文件 ，前端 src 下有 20 个源文件。这比生成单个 Controller 更能检验 AI 是否能维持跨文件命名、字段和接口的一致性。不过，这些数字只能代表最终工程规模；由于没有完整保留生成后的逐文件修改记录，不能拿它们计算代码直接采纳率。

2、先跑通最短闭环，而不是先做漂亮页面

这个项目的最短闭环是：用户登录获得 JWT，前端保存登录状态，请求看板接口，再把 H2 中的演示批次显示出来。最终登录页可以直接使用本地演示账号进入系统。

图 5：生成后的登录页，演示账号为 admin / Demo@123

认证实现并非前端假登录。后端的 JwtAuthenticationFilter 会读取 Authorization: Bearer ...，解析令牌后写入 Spring Security 上下文；未认证请求由安全链返回 401。这里展示一段核心代码：

String authorization = request.getHeader("Authorization"); if (authorization != null && authorization.startsWith("Bearer ")) { try { CurrentUser.UserIdentity identity = jwtService.parse(authorization.substring(7)); SecurityContextHolder.getContext().setAuthentication( new UsernamePasswordAuthenticationToken(identity, null, List.of())); } catch (Exception ignored) { SecurityContextHolder.clearContext(); } }

filterChain.doFilter(request, response);

这段代码的优点是链路短、职责明确，非法令牌不会直接打断过滤器链；但如果进入生产项目，我会继续补充可观测性与更细的认证失败上下文，同时确保日志绝不记录令牌原文。

3、把"临期"从数据库字段变成业务规则

库存系统最容易写成普通 CRUD，但 ShelfGuard 的核心要求是状态必须随日期变化。项目没有把"正常、临期、过期、售罄"固化在数据库，而是每次查询时计算：

public FoodStatus calculate(LocalDate expirationDate, int currentStock) { if (currentStock == 0) { return FoodStatus.SOLD_OUT; } LocalDate today = LocalDate.now(clock); if (today.isAfter(expirationDate)) { return FoodStatus.EXPIRED; } if (!expirationDate.isAfter(today.plusDays(7))) { return FoodStatus.NEAR_EXPIRY; } return FoodStatus.NORMAL; }

这里有两个值得保留的设计。第一，售罄优先于日期判断，库存为 0 时不会再显示"过期"；第二，时间来自注入的 Clock，测试可以固定日期，不需要依赖运行当天。自动化测试覆盖了到期日前 1 天、当天、未来 7 天和未来 8 天等边界。

看板把规则计算后的数据集中展示出来：4 个食品批次、184 件当前库存、1 个临期批次、1 个过期批次和 1 个售罄批次。页面还列出了最近库存流水，便于从汇总进入明细。

图 6：数据看板实时汇总四种状态和最近库存流水

4、从列表页验证跨层字段是否对得上

食品批次页同时依赖分类、状态、库存、生产日期、到期日和版本号。搜索、批次号、分类和状态筛选都要从 Vue 表单进入 Axios 参数，再经过 Controller、Service 和 Mapper，最后映射回前端卡片。这类跨层一致性通常比生成一段孤立代码更考验上下文。

图 7：食品批次支持条件筛选，并可执行入库、出库、报损和详情操作

库存修改也没有直接执行"先查再保存"。每次请求都携带 expectedVersion，后端使用带版本条件的更新；如果客户端拿着旧版本重复提交，更新行数不是 1，接口返回 409，提示刷新后重试。出库和报损还会校验库存不能为负，过期食品禁止出库但允许报损。

int updated = batchMapper.updateStock( batchId, delta, request.expectedVersion() ); if (updated != 1) { throw BusinessException.conflict( "STALE_STOCK_VERSION", "库存已发生变化，请刷新后重试" ); }

每次库存变化都会写入 stock_record，保留操作类型、数量、操作前库存、操作后库存、操作人和时间。流水页只允许查询，不提供编辑入口，这让页面呈现与后端约束保持一致。

图 8：库存流水显示操作前后数量、操作类型、备注和时间

分类管理看起来最接近 CRUD，但仍包含业务限制：分类可以启用或停用，停用后保留历史归属但不再用于新批次；已经被批次引用的分类不能直接删除。这样不会为了"删除成功"破坏已有数据关系。

图 9：分类管理支持新增、编辑、停用和带引用校验的删除

5、用测试和构建决定"完成"，而不是看文件数量

我用项目自带的 scripts/verify.sh 同时执行后端测试与前端生产构建：

bash scripts/verify.sh

最终验证结果如下：

• Maven 测试：8 个测试全部通过，失败 0、错误 0、跳过 0，BUILD SUCCESS

• 前端构建：Vite 6.4.3 构建成功，转换 1678 个模块

• 页面：登录、看板、食品批次、库存流水、分类管理，共 5 个 Vue 页面

• 后端：5 个 Controller，共 16 个 HTTP 路由映射

• 数据：默认 H2 内存库可直接启动，无需先安装 MySQL

前端构建并非完全没有警告。主 JavaScript 产物压缩后约 1098 kB，Vite 提示单个 chunk 大于 500 kB。这不影响本地演示，但说明 Element Plus 等依赖仍有按需加载和拆包空间。真实评价不应该把"构建成功"等同于"已经达到生产优化标准"。

四、可验证的结果，以及不能下的结论

1、量化结果汇总

|---------|--------------|-------------------------|
| 测试维度 | 本轮结果 | 证据口径 |
| 项目有效文件 | 81 个 | 排除依赖、构建输出目录 |
| 后端主代码 | 46 个 Java 文件 | src/main/java 实际统计 |
| 前端源文件 | 20 个 | shelfguard-web/src 实际统计 |
| 前端页面 | 5 个 | 登录 + 4 个业务页面 |
| REST 接口 | 16 个 | Controller 映射实际统计 |
| 后端自动化测试 | 8 / 8 通过 | Maven Surefire 最终结果 |
| 前端生产构建 | 通过 | Vite 6.4.3，1678 个模块 |
| 浏览器页面 | 5 个有运行截图 | 登录、看板、批次、流水、分类 |
| 生成总耗时 | 未统计 | 没有连续计时，不补写分钟数 |
| 文件直接采纳率 | 未统计 | 没有完整记录每个文件的修改历史 |

这组数据至少覆盖了文件规模、功能页面、接口数量、编译/测试和浏览器呈现几个维度。它能支持的结论是：飞算JavaAI可以把一段边界明确的需求推进到完整工程和可验证成品，而不只是输出代码片段。

它不能支持两种更强的说法：第一，不能据此声称"比旧版提升了某个百分比"，因为没有使用旧版完成同一需求；第二，不能声称"比手写快多少倍"，因为没有在同一环境下做纯手写对照。生成过程中的局部思考秒数可以反映反馈节奏，却不能替代完整计时。

2、我感受到的提速点

最明显的提速来自"横向铺开工程"的阶段。一个需求需要同时创建 Maven 配置、Spring Security、DTO/VO、实体、Mapper、Service、Controller、SQL、Vue 路由、状态管理、请求层和页面。手工开发时，这部分常常不是难在某一行代码，而是重复创建文件、保持命名一致并补齐样板。AI 一次性把这些层铺开，开发者可以更早进入验证业务规则的阶段。

第二个提速点是跨端闭环。最终项目不是前端写死数据，而是登录、看板、批次、分类和流水通过真实 API 连接。对于原型、内部工具、课程演示或需求验证，这种"先得到可以点的系统，再逐项收紧规则"的方式很有效。

3、它还没有替我省掉什么

首先，环境问题仍然需要开发者判断。例如原规格使用前端端口 5173，但本机已有服务占用，因此项目调整为 5174；Maven 默认运行时与目标 JDK 不一致，也需要验证脚本显式指定 JDK 17。AI 可以给出配置，但无法替代对本机进程和工具链的核对。

其次，生成代码仍要通过业务边界测试。状态优先级、到期日边界、超库存扣减、过期出库、旧版本请求、被引用分类删除，这些都不能只看页面是否漂亮。当前 8 个测试覆盖了关键主路径，但还没有前端端到端测试、性能测试和安全扫描。

最后，工程距离生产化仍有差距。默认 JWT 密钥、演示账号和 H2 Console 仅适合本地；生产环境需要外部密钥、独立数据库账号、关闭 H2 Console，并补充审计、权限、监控、限流与部署配置。前端大 chunk 警告也应在正式发布前处理。

五、优点、不足与改进建议

1、优点

• 工程生成完整 ：从 pom.xml、数据库脚本到 Vue 页面和 README，交付物不是不可运行的代码片段

• 上下文连续：前后端字段、状态枚举、分页结构和 API 路径整体一致，联调阶段没有重新设计整套协议

• 业务约束可落地：售罄优先、7 天临期、过期禁止出库、库存版本冲突等规则进入了服务层和测试，而非只显示在页面文案中

• 复现成本低：默认 H2，使用演示数据，运行后即可登录查看；同时保留 MySQL 方案

• 过程可观察：生成时能看到正在思考的步骤、已创建文件和工作区变更，便于判断是否偏离需求

2、不足

• 没有自动形成完整的总耗时、修复轮数和文件采纳率报告，做效率评测仍需人工提前准备记录表

• 一次生成的工程规模较大，开发者必须审查安全配置、事务边界和异常处理，不能因为文件齐全就直接上线

• 前端构建存在大 chunk 警告，说明可运行和构建通过不代表性能优化已经完成

• 当前测试集中在后端业务和认证，缺少浏览器端自动化回归、并发压测与静态质量扫描

• 本机端口和 JDK 运行时差异仍需人工排查，环境适配无法完全交给模型

3、给工具和使用者的建议

对工具侧，我希望增加一份自动生成的"本次任务实测报告"：记录开始与结束时间、创建/修改文件数、执行命令、首次和最终构建结果、错误修复轮数。这样方向二的效率数据不必依赖人工记秒表，也更容易复盘。

对使用者，我建议采用"明确范围---生成骨架---立即构建---验证核心规则---再优化界面"的顺序。提示词里要写清禁止扩展项、完成标准和测试命令；每完成一个闭环就运行测试，而不是等几十个文件全部生成后才第一次编译。对于认证、库存、支付、权限等高风险逻辑，必须阅读代码并补边界测试。

六、结论：提速可感知，但不是免检通行证

这次 ShelfGuard 实测给我的结论是：飞算JavaAI 3.9.8 的价值，主要体现在把需求到完整工程骨架这段路显著压缩。面对技术栈明确、边界清楚、数据模型适中的管理型应用，它能一次覆盖后端分层、前端页面、认证、数据库、测试和文档，让开发者更快进入"运行---发现问题---修复---验收"的循环。

但我不会把这次结果包装成确定的倍数提升。因为没有总计时、旧版对照和纯手写基准，严格来说还不能回答"快了多少"。目前可以确认的是，成品有 81 个有效文件、5 个页面、16 个接口，后端 8 个测试全部通过，前端生产构建通过；截图也证明系统确实在浏览器中跑了起来。

如果下一轮继续测试，我会提前开启完整计时，并用同一份需求分别跑飞算JavaAI与纯手写流程，记录首次编译、最终通过、人工修改文件数和功能完成率。只有把这些条件固定下来，提速体感才能真正从"感觉很快"变成可复查的数据。

本文测试基于本地演示工程，不代表生产部署结论。演示账号、默认 JWT 密钥和 H2 Console 不应直接用于生产环境。

#飞算JavaAI #AI编程 #Java #Java代码生成 #AI coding模型 #Java开发 #SpringBoot #Vue #CRUD