飞算JavaAI 全栈实测：1 个人 1 天交付完整项目，后端还需要补前端吗？

项目

本次条件

选"会议室与设备预约系统"这个需求，不是随手挑的。它是个典型的"看着简单、写起来全是坑"的中后台：

• 有两个角色（普通用户 / 管理员），权限边界必须在校验层而不是页面层；

• 有资源（会议室 + 设备）的增改停用；

• 有预约冲突检测，而且是左闭右开的时间区间语义；

• 有并发场景，两个人同时点"提交预约"不能都成功；

• 有时区约定，所有时间统一按 Asia/Shanghai 处理。

也就是说，只要这套东西能跑通，它就不是一个玩具 Demo。

2.2 第一步：用一段人话，把需求说清楚

我没有写任何设计文档，也没有画原型图。我把需求按"角色 / 页面范围 / 业务规则 / 交付与验收"四段直接写进对话框：

需求里我特意写死了几条容易扯皮的点，这些恰恰是以前前后端联调时最爱吵架的地方：

三、业务规则 1. 结束时间必须晚于开始时间，不能预约过去的时间。 2. 同一资源的有效预约不能时间重叠。 3. 使用左闭右开的时间区间：10:00—11:00 与 11:00—12:00 允许同时存在。 4. 已取消预约不再占用时段。 5. 停用资源禁止新增预约，历史预约保留。 6. 冲突检查必须在后端完成，并采取措施防止并发请求同时预约成功。 7. 冲突提示说明资源和占用时段，不展示其他用户的预约用途。 8. 前后端统一时间格式，明确按 Asia/Shanghai 时区处理。

这一步是整个流程里我唯一"必须自己动脑"的地方，而且我觉得它就该由人来写。 需求写得越具体，后面返工越少——这一点无论用不用 AI 都成立。

2.3 第二步：它把我的需求拆成了 26 个关键点

提交需求后，工具没有直接吐代码，而是先进入"理解需求"环节，把整段自然语言拆成 26 个可勾选、可增删、可排序的关键点：

拆出来的东西是可以逐条改的，比如这几条：

• 需要预约时间合法性校验功能，校验结束时间必须晚于开始时间，且不能预约过去的时间；

• 需要资源启用状态校验功能，创建预约时校验资源是否处于启用状态，停用资源禁止新增预约；

• 需要预约冲突检查功能，基于左闭右开时间区间规则校验同一资源有效预约是否存在时间重叠；

• 需要并发冲突控制功能，利用数据库行级锁或乐观锁机制防止并发请求同时预约同一时段成功。

这个环节的价值其实不在"AI 很聪明"，而在于它逼你把需求过一遍第二遍。我在这里改了两项：把"冲突提示不展示他人用途"单独拆出来，把时区约定提到更高优先级——这两条如果我直接生成代码，八成会漏。

2.4 第三步：10 个接口，先于代码定型

接着是"设计接口"环节，生成 10 个接口方案，每个接口都带上了入参校验、权限校验、返回结构：

截几个关键的说：

• 用户认证：账号密码登录，校验通过后签发 JWT；后续业务接口统一携带 Token，后端解析身份与角色，无效或过期统一返回标准错误响应。

• 演示数据初始化：建表脚本 + 初始数据脚本在启动时执行，预置普通用户与管理员账号、演示资源与历史预约数据，保证幂等，重复启动不产生重复数据。

• 资源查询：返回名称、类型、地点、容量、启用状态，支持按类型和状态筛选。

• 资源维护：仅管理员可操作，停用后保留历史预约但禁止新增预约，非管理员访问返回权限异常。

我格外看重"演示数据初始化要幂等"这一条——这是很多人自己写 Demo 时会忽略的点，insert 跑两遍数据库就脏了。

2.5 第四步：3 张表，字段和约束一起出来

数据库这块选了 MySQL，生成了 3 张表：

以 t_user 为例，除了业务字段，审计字段也一起给全了：

字段名

描述

类型

是否主键

是否自增

是否必填

另外两张是 t_resource（资源信息表）和 t_reservation（预约记录表）。这三张表的结构是后面所有代码的地基，所以我在这一步停了最久，确认了角色字段用枚举字符串而不是数字、时间字段统一 datetime 之后再往下走。

2.6 第五步：先出 37 项交付清单，再写代码

这一步是我觉得最有价值、也最容易被同类工具跳过的环节——代码生成计划。它先把要产出的东西列成 37 个条目给我看：

清单里既有文档，也有代码：

• 设计文档总览、数据库设计文档、时间格式与时区约定文档、页面交互设计文档；

• 接口契约（用户认证、资源查询、资源新增/编辑/停用、预约创建、预约取消）；

• 后端实体、Repository、Service、Controller 分层实现；

• 前端页面与交互实现。

先出计划的意义在于：能在"零成本"的阶段发现遗漏。 我在这份清单里补了一项——并发冲突测试用例。如果等代码生成完再想起来，改起来就是伤筋动骨。

2.7 第六步：生成源码，52 个文件

确认计划后点"生成源码"，最终产出了 52 个文件：工程结构是标准的 Maven 分层，可以直接在 IDEA 里打开运行：

生成的 README 里写明了环境要求：JDK 17+，推荐 JDK 17.0.20。前端不是独立工程，而是 4 个静态页面 + Vue 3 + Element Plus，天然对接后端接口，不需要联调——这一点后面我会展开说。

2.8 耗时到底差在哪

把这次实测按环节拆开，跟官方口径的传统模式对照一下：

环节

传统模式（官方口径）

本次实测（含人工确认）

需要说明两点，以免误导：

真正被消掉的不是"写代码的时间"，而是"联调的 2 天"和"前端开发的 3 天"。 联调为什么会归零？因为接口契约和前端页面是在同一个上下文里生成的，前端调用的字段名、类型、返回结构，跟后端定义是同一份来源，不存在"我以为你返回的是数组，你返回的是对象"这类问题。

三、验收现场：一行前端代码没写，页面能不能看

后端工程师对"AI 生成的前端"普遍有心理阴影——大概率是一堆能跑但很难看的原生 HTML。所以这一节我直接把四个页面原样贴出来，你自己判断。

3.1 登录页

左侧是产品标识和三条能力说明，右侧是登录表单，演示账号做成可点击填入，省掉了"账号密码在哪"这种低效沟通。三个预置账号覆盖了完整权限矩阵：

账号

用户名

密码

角色

"两个普通用户 + 一个管理员"这个设计比"一个普通用户 + 一个管理员"要聪明：只有两个普通用户，才能验证"我看不到别人的预约用途"这类数据权限规则。

3.2 资源列表

会议室和设备共用同一套资源模型，用"类型"字段区分，这是我在需求里明确要求的——避免为会议室和设备写两套逻辑。页面右上角常驻显示当前时区（Asia/Shanghai）和登录身份，这类小细节决定了这套系统看起来像不像"能交付的东西"。

3.3 预约资源（最难的一页）

这一页是整个项目的核心，也是最能看出"有没有真的理解需求"的地方：

• 左半边是当天该资源的占用列表，9:00—10:00 显示"已占用"，14:00—15:00 显示"我的预约 · 项目评审会议"；

• 右半边是创建预约表单，选中资源和日期后，填开始时间、结束时间和用途；

• 关键点：占用列表只显示时段，不显示其他用户的用途（需求第 7 条）；自己的预约才显示用途。

我把开始时间填 10:00、结束时间填 11:00 提交——按左闭右开的规则，这和 9:00—10:00 不冲突，应该成功。结果如预期，直接通过。

3.4 我的预约

列表里同时出现了三种状态：待开始、已取消，以及不同资源的混合预约。几个细节值得一提：

• 预约编号（如 RL-DEMO-0107）是系统生成的业务编号，不是数据库自增 ID，对外展示更体面；

• 已取消的记录保留在列表里，但不再占用时段（需求第 4 条）；

• "取消"按钮只对"待开始"的记录出现，已经开始的记录不可取消——这条我一开始没写进需求，是它在业务规则校验里补上的。

3.5 三个"硬骨头"，它是怎么处理的

页面好看是及格线，业务规则才是验收标准。三个地方我专门盯了：

（1）左闭右开的时间区间

这是最容易写错的地方。正确的判定条件是"新开始时间 < 已有结束时间 且 新结束时间 > 已有开始时间"，而不是 <= / >=。用错一个符号，11:00—12:00 就永远约不上。

（2）并发冲突控制

需求第 6 条要求"必须防止并发请求同时预约成功"。如果只在 Service 层用 Java 代码做"先查再插"，两个请求同时通过检查、同时插入，就会产生重叠预约。生成的方案是在事务内对资源行加锁，把并发串行化：

配套生成了并发测试用例 ReservationConcurrencyTest.java，用多线程同时提交同一时段，断言只有 1 个请求成功、其余全部返回冲突提示。

（3）时区统一

时区问题是分布式项目的隐形杀手。这份代码的做法是在配置层统一约定：

spring: jackson: time-zone: Asia/Shanghai date-format: yyyy-MM-dd HH:mm:ss

并在接口契约里明确：所有时间字段统一按 Asia/Shanghai 解析与返回，不接受客户端传入带偏移量的时间串。前端页面右上角常驻时区标识，避免不同环境的理解歧义。

另外，需求里要求的加载中、空数据、校验失败、提交中四种状态，四个页面都有对应的展示，不是只有"成功"一条路径。

四、面试桌上怎么讲：把"会全栈"翻译成招聘方听得懂的语言

好，回到最开始那个问题：「能独立交付前后端项目的 Java 工程师」在求职市场的溢价空间，到底体现在哪？

我的判断是：溢价不在"会前端"这三个字上，而在"交付确定性"上。 下面是我认为可以直接用的三套话术。

4.1 简历：把"会"改成"交付过什么"

绝大多数简历写的是"熟悉 Spring Boot、了解 Vue"，这类描述的问题在于无法验证。换成结果导向的写法，效果完全不同。

同一个项目，三种写法：

第二种写法哪怕没有任何数字，招聘方也能立刻判断"这个人能一个人把事做完"；第三种写法则在告诉你"我处理过真问题"。

一个可复用的简历句式：

独立交付【什么系统】（【技术栈】），实现【2-3 个有难度的技术点】，覆盖【从需求到上线的完整链路】，由 1 人完成。

4.2 面试：三个几乎一定会被追问的问题

Q1：这个项目前端是你写的吗？

这是最需要提前准备的一问，也是最容易翻车的一问。我的建议是不要含糊：

"前端页面是通过飞算 JavaAI 的全栈功能生成的，接口契约和前端代码同源，所以不需要联调。但架构选型、需求边界、权限模型、并发方案的取舍是我定的，我自己写了并发测试并逐页验收。"

诚实说明来源，同时明确划出"我负责的部分"。面试官在意的是后者。

Q2：并发场景你是怎么处理的？为什么这么设计？

这题是加分题，因为它考的是你对"先查再写"这个经典陷阱的敏感度：

"只在业务层做'先查询冲突再插入'是不够的，两个事务可以在检查阶段同时通过。所以我把冲突查询放进加锁事务里，对资源行做 SELECT … FOR UPDATE，把同一资源的并发预约串行化，锁内二次校验后再写入。代价是同一资源高并发写入会有排队，对这个量级的系统可以接受；如果资源粒度更细，可以考虑乐观锁 + 唯一索引兜底。"

注意：这题答不好，"项目是不是你做的"就一目了然了。 所以我在第三节花了那么多篇幅拆左闭右开和行级锁——那些不是写给你看的，是写给面试官看的。

Q3：如果让你重做，你会改哪里？

这题考的是反思能力。把第五节"不足"里的一两条原样搬出来就行，比如：

"我会把并发测试补成压测，而不只是多线程断言；另外前端这块我能讲清接口和交互，但真要手改复杂的 Vue 响应式逻辑，还是得补功课。"

4.3 哪些岗位的溢价最明显

不是所有岗位都吃这一套。我观察下来，下面三类最直接：

反过来，大厂的核心中间件、平台型岗位基本不吃这一套——那些岗位考的是深度（JVM、并发模型、分布式一致性），你能不能画页面几乎不影响评级。所以"要不要学前端"的答案，2026 年真的不是"要 / 不要"，而是"你下一步要去哪"。

五、把话说透：优点、不足与使用建议

按"三真实"的要求，好的坏的都写。

5.1 做得好的地方

5.2 不足的地方（真实评价）

5.3 我的使用建议

如果你现在是后端，正在纠结"要不要补前端"：

• 先分清目的。"为了下一份工作能独立交付一个完整项目"——用这个工具补位，性价比很高；"为了转岗做前端"——那还是老老实实学，工具替代不了系统学习。

• 别把工具当免修课。面试会问设计，不会问你用了什么插件。 需求怎么拆、权限怎么划、并发怎么控，这些你得能自己讲明白。

• 用真实项目练手，别用 TodoList。挑一个有权限、有状态流转、有冲突检测的中后台需求，跑一遍完整流程，这个过程本身就是一次很好的架构训练。

如果你正在面试： 把这个项目原样讲一遍，重点讲"我为什么这么设计"，而不是"我用什么工具生成"。

如果你在带团队： 这套模式最适合"内部工具、原型验证、演示项目"这类需求。它的收益在缩短链路，成本在前期需求描述的投入——需求写得越细，回报越高。

5.4 结语

回到开头那个问题。

金九银十里"会全栈"的 Java 工程师更值钱吗？

我的答案是："会全栈"本身不溢价，"能把一个项目从需求关到上线"才溢价。 前者是技能标签，后者是交付能力。企业付钱买的从来是后者。

这轮实测给我的最大感受不是"AI 写代码好快"，而是：当联调和前端开发这两段最长、最碎的流程被压缩掉之后，后端工程师真正被释放出来的，是从"写文件"回到"做设计"的那部分时间。

至于要不要学前端——我的建议是，先把"独立交付"这件事的标准立起来，再决定要不要把时间投在前端语法上。因为你缺的可能从来不是前端知识，而是一套能把链路走完的工具和方法。