飞算JavaAI 48分钟能做完Java全栈项目吗？

常见问题

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

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

Q：AI生成的代码能直接用于生产吗？

A：不能直接使用。测试覆盖了核心场景但未覆盖全部边界条件，建议补充自动化回归测试、安全审计和性能压测后再交付。

一、为什么要记录这 48 分钟？

现在让 AI 写一个 Controller、Entity 或普通 CRUD，并不难。真正影响开发效率的，往往是 Controller 之后的工作：认证能否跑通、前后端字段是否一致、状态流转是否正确、数据库能否开箱启动、构建报错后能不能继续修复，以及最终是否真的出现一个可以操作的页面。

所以这次我没有测试"10 秒生成一段代码"，而是给飞算JavaAI的专家模型布置了一个完整但刻意控制范围的任务：从零搭建校园设备报修与工单处理系统"速修通（FixFlow）"。

项目需要同时包含：

• Spring Boot 3 + Vue 3 前后端分离；
• JWT 登录与两种角色权限；
• 报修、取消、接单、完成四类操作；
• 待处理、处理中、已完成、已取消四种状态；
• H2 默认演示环境和可选 MySQL 配置；
• Swagger、统一响应、全局异常处理和自动化测试；
• 登录、数据概览、新建报修、我的工单、维修工作台五个页面。
  我给自己的判断标准也很直接：48 分钟里生成了多少文件只是过程，最终能否构建、启动并完成工单主流程，才决定这些代码有没有效率价值。

二、测试环境与计时规则

项目	本次实测配置
操作系统	macOS 26.6.1, Apple Silicon (arm64)
IDE	IntelliJ IDEA 2024.1.7
飞翼JavaAI	插件 3.9.8，专家模型
项目 Java	Java 17
Maven	3.9.16
Node.js / npm	24.16.0 / 11.13.0
后端	Spring Boot 3.3.5, Spring Security 6, JWT, MyBatis-Plus 3.5.7, H2 / MySQL, Springdoc OpenAPI
前端	Vue 3.5, Vite 5, Vue Router, Pinia, Axios, Element Plus
计时口径	提交提示词 → 生成 → 模型修复 → 构建 → 前后端成功启动
端到端总耗时	48 分钟

这里特别说明一下：48 分钟来自我在测试过程中的外部连续计时，不以单个文件的创建或修改时间推算。首次编译、首次构建是否一次通过，以及人工逐文件编辑次数，当时没有单独形成完整统计，因此本文不补填、不反推。

为了让这个测试可以复现，我在提示词里锁死了三条边界：

1. 不加入图片上传、自动派单、消息通知、Redis、消息队列、微服务、工作流引擎和 Docker。
2. 默认使用 H2 内存数据库，避免复现者先花时间安装数据库；同时保留 MySQL 8 Profile。
3. 不只生成代码片段，必须把完整工程写入工作区，并继续处理构建和启动阶段暴露的问题。

三、我给专家模型的需求：完整，但不故意堆复杂度

我使用的是一份结构化提示词。开头先定义项目名、目录、基础包和技术栈，再给出角色、状态机、接口、页面、测试和完成标准。

提示词的核心可以压缩成下面这段：

请从零生成一个完整、可运行的前后端分离 Java 项目"速修通 FixFlow"。
后端使用 Java 17、Spring Boot 3、Spring Security 6、JWT、MyBatis-Plus、
H2 / MySQL、Swagger、JUnit 5 和 MockMvc；前端使用 Vue 3、Vite、
Vue Router、Pinia、Axios 和 Element Plus。

系统只有 EMPLOYEE 和 MAINTAINER 两种角色。报修用户可以创建、查看并取消
自己的待处理工单；维修管理员可以查询全部工单、接单并填写处理结果完成工单。
当前用户身份必须来自 JWT，不能相信前端传入的用户 ID 或角色。

状态固定为 PENDING、PROCESSING、COMPLETED、CANCELLED。
只有 PENDING 可以取消或接单；只有接单人可以完成 PROCESSING 工单；
状态更新和操作记录必须在同一个事务中；重复接单最多一个成功，冲突返回 409。

请实际完成后端测试、前端构建与前后端启动。若出现错误，根据真实结果修复，
不要声称未执行的命令已经通过。

提示词末尾还规定了生成顺序：先建工程和后端，再做认证、权限与工单业务；随后完成测试、前端页面、构建、接口核对和启动。

这个约束很重要。AI 生成项目时最容易出现的情况，是页面做得很快，但后端字段、路径和权限逻辑没有对齐。把"构建、修复、启动"写进完成标准，才能测试端到端效率，而不是只测输出速度。

四、48 分钟里发生了什么？

这次过程不是"提交提示词，然后 48 分钟什么都不管"。专家模型大致经历了四个阶段。

1. 先搭后端骨架和业务边界

模型先创建 Maven 聚合工程与 fixflow-server，随后补齐 Spring Boot 配置、H2 建表脚本、JWT 认证、统一响应、异常处理、用户与工单实体、Mapper、Service 和 Controller。

在业务层，它没有把逻辑全部塞进 Controller，而是将权限、状态判断、操作记录和事务放进 RepairService。核心状态路径是：

创建工单 → PENDING（待处理）
PENDING → CANCELLED（报修用户取消）
PENDING → PROCESSING（维修管理员接单）
PROCESSING → COMPLETED（接单管理员完成）

2. 再生成前端和五个页面

前端采用 Vue 3 + Vite，包含 Axios 请求封装、Pinia 登录状态、路由守卫和五个业务页面。角色菜单也做了区分：报修用户看到"新建报修"和"我的工单"，维修管理员看到"数据概览"和"维修工作台"。

3. 不是停在生成结果，而是继续检查和修复

从专家模型的过程记录看，它在生成后检查了 VO 映射、统计返回字段、H2 与 MySQL Profile、Maven 工程结构、Mapper 扫描、前端登录会话恢复，以及维修工作台的按钮权限。

这部分是我本次最明显的"提速体感"：它不是只给出一个初版后让我自己从报错堆栈里逐个找文件，而是能围绕已经定位的问题继续修改。例如，记录中能看到它主动补全了 MySQL 建表脚本引用、Mapper 扫描和维修工作台完成按钮的权限显示。

不过这里也要客观说：过程出现多轮定点修复，说明这不是"一次生成零问题"。更准确的描述是：专家模型把生成、检查和修复串成了一个连续工作流，最终在 48 分钟内把工程推进到可运行状态。

4. 最后进入真实构建和启动

最终项目在 IDEA 中完成了 Maven 与 npm 阶段，并启动 Spring Boot。终端截图可以看到 Tomcat 运行在 8080 端口，FixFlowApplication 启动完成。

五、48 分钟最终交付了什么？

根据飞算工作区快照统计，排除 target、node_modules 和 dist 等构建产物后，本次工程约有 61 个非构建文件：

指标	实测结果
端到端总耗时	48 分钟
非构建文件	约 61 个
Java 文件	35 个
Vue 页面/组件文件	6 个
后端接口	12 个
核心数据表	3 张
角色	2 种
工单状态	4 种
自动化测试场景	8 个
最终后端启动	成功，Tomcat 端口 8080
最终前端页面	成功打开并完成报修、列表、详情与统计展示
首次编译/构建是否一次通过	未单独记录，不作结论
人工逐文件修改次数	未单独记录，不作结论

这套工程不只是一个表单页面。后端包含 JWT 过滤器、BCrypt 密码、DTO / VO、MyBatis-Plus Mapper、统一响应、全局异常、H2 / MySQL 配置、状态更新和操作记录；前端包含请求拦截、登录状态、路由与角色菜单。

六、实际页面验收：从报修到工单管理

1. 登录页和两种演示角色

登录页提供报修用户和维修管理员两个本地演示账号。页面结构简洁，打开后可以直接切换角色验证不同菜单。

这些账号和密码只用于本地演示。生成工程使用 BCrypt 保存密码摘要，正式环境不应保留演示账号、H2 Console 和示例 JWT 密钥。

2. 报修用户可以创建工单

新建报修页包含工单标题、设备类型、地点、故障描述、联系电话和优先级。截图中的原始测试数据包含完整联系电话，因此本文不公开展示该图；从代码核对看，后端 DTO 对必填项、长度和中国大陆手机号格式都做了校验。

@NotBlank(message = "联系电话不能为空")
@Pattern(regexp = "^1[3-9]\\d{9}$", message = "联系电话必须为中国大陆手机号")
private String contactPhone;

这意味着前端校验被绕过后，后端仍会返回明确的 400 错误，而不是只依赖浏览器表单。

3. 我的工单：待处理与已取消状态可见

提交后，报修用户可以在"我的工单"查看工单编号、设备类型、地点、优先级和状态。截图中一条记录为"待处理"，另一条已经完成取消，说明创建与取消路径能够在页面中体现。

工单详情还展示了状态、维修人员、创建时间和操作记录。由于原始详情截图包含完整联系电话，本文同样不公开引用；这也是技术博客发布前容易忽略的隐私清理点。

4. 维修管理员数据概览

切换到维修管理员后，首页展示工单总数、待处理、处理中、已完成和已取消五组统计。截图中共有 2 条工单，其中 1 条待处理、1 条已取消，与"我的工单"列表一致。

维修工作台还支持按状态、优先级、设备类型和关键词筛选；接单后进入 PROCESSING，只有当前接单管理员才能填写 5～500 字处理结果并完成工单。

七、关键代码检查：专家模型不只写了页面

1. 权限身份来自 JWT 上下文

创建工单时，报修人 ID 不是前端传入，而是来自当前登录用户：

order.setReporterId(currentUser.id());
order.setStatus(RepairStatus.PENDING);

查看与取消时也会校验数据归属：

if (!currentUser.id().equals(order.getReporterId())) {
    throw BusinessException.forbidden("不能取消他人的工单");
}

这一点比"不同角色隐藏不同菜单"重要得多，因为直接调用 API 也不能绕过后端数据范围。

2. 状态更新同时检查当前状态和版本号

接单不是无条件更新。Mapper 把工单 ID、当前状态与版本号一起放进 WHERE 条件：

@Update("""
    UPDATE repair_order
    SET status = 'PROCESSING', maintainer_id = #{maintainerId},
        started_at = #{now}, updated_at = #{now}, version = version + 1
    WHERE id = #{id} AND status = 'PENDING' AND version = #{version}
    """)
int startPending(Long id, Long maintainerId, Long version, LocalDateTime now);

如果两个维修管理员重复接单，只有一个更新能命中，另一个请求会得到 409：

if (repairOrderMapper.startPending(id, currentUser.id(), order.getVersion(), now) != 1) {
    throw BusinessException.conflict("工单已被其他维修管理员处理，请刷新后重试");
}

自动化测试也真实创建两个线程同时请求接单，并断言一个返回 200、另一个返回 409。对于一个限时全栈项目，这比只完成 CRUD 更接近工程实践。

3. 状态变化与操作记录放在同一事务

创建、取消、接单和完成方法都加了 @Transactional，状态更新成功后写入 operation_record。其中任何一步抛出异常，整个事务回滚，避免页面显示已完成但操作时间线缺失。

八、怎么评价这 48 分钟？

优点

1. 端到端效率可感知。 48 分钟覆盖了需求提交、工程生成、问题修复、构建和启动，而不是只统计模型吐出第一段代码的时间。
2. 工程形态完整。 后端、前端、数据库脚本、测试、README 和测试记录模板都在工程中，不是零散片段。
3. Java 业务约束基本在线。 JWT 上下文、后端数据归属、状态机、事务、乐观并发条件和 409 冲突都进入了代码。
4. 修复过程有上下文。 专家模型能围绕 VO、Mapper 扫描、Profile 和前端权限显示继续定位，不需要每轮从零描述项目。
5. 复现门槛低。 默认 H2 模式不要求先安装 MySQL，两个本地演示账号可以直接验证角色流程。

不足

1. 不是一次生成零问题。 从过程记录看，模型做了多轮定点修复；如果只截最终页面，会掩盖真实调试成本。
2. 量化记录还可以更细。 本次只可靠记录了端到端 48 分钟，没有分别记录首次生成、首次编译、首次构建、模型修复和人工操作各占多少时间。
3. 首次通过率和人工编辑次数缺失。 因为当时没有逐项登记，本文无法给出首次编译通过率或代码采纳率百分比。
4. 演示配置不能直接上生产。 H2 Console、演示账号和示例 JWT 密钥仅适合本地复现，生产环境需要环境变量、密钥轮换和更严格的 CORS 配置。
5. 页面功能覆盖截图仍可更完整。 当前截图证明了登录、创建结果、取消、详情、统计和最终启动；如果正式做基准测试，还应补充接单、完成和重复接单 409 的接口或页面证据。

给飞算JavaAI的建议

1. 在任务结束时自动输出分阶段耗时：分析、生成、修复、构建、启动各用了多久。
2. 自动保存首次 mvn test 与 npm run build 的原始结果，避免用户只能记录最终状态。
3. 生成一个事实化验收报告，区分"静态检查通过""命令执行通过"和"页面人工验收通过"。
4. 检测截图或日志中的手机号、账号等信息，发布前主动给出脱敏提醒。

九、最终结论：48 分钟完成可运行项目，但验证仍不能省

回到标题：飞算JavaAI专家模型的提速体感是不是玄学？

就这次 FixFlow 实测而言，我的答案是：不是。 在需求边界清楚、技术栈固定、完成标准明确的情况下，专家模型确实把"从空目录到可运行 Java 全栈项目"的过程压缩到了 48 分钟。最终我拿到的不只是接口代码，还有登录、角色菜单、报修、工单列表、取消、详情、管理员统计，以及对应的后端权限、状态与并发控制。

但我也不会把它描述成"48 分钟生成生产系统"。这次结果更准确的定位是：一个可以启动、可以演示、具备基础工程约束的 MVP。模型完成了大量目录搭建、样板代码、业务实现和定点修复，开发者仍需负责测试证据、代码审查、安全配置与生产化改造。

如果你的目标是快速验证一个后台业务模块、内部工具或 MVP，专家模型的价值很直接：它让你更早进入"运行---发现问题---修复---验收"的阶段。至于最终能不能上线，判断标准仍然不是生成了多少文件，而是构建、测试、安全和真实业务场景能不能经得住检查。