一句话生成的页面很漂亮，然后呢？它接不进你的 Spring Boot 工程

现在让 AI 生成一个页面，已经容易到有点不真实。

一句话：“给我一个用户管理页面，带搜索、分页和批量删除。”

十几秒后，一个排版工整、配色现代、交互齐全的页面就出来了。截图发出去，看着比很多上线系统的界面还讲究。

然后你把它放进项目里，发现——接不上。

不是样式丑，不是代码乱，是它跟你后端那套东西对不上。

一、"一句话出页面"解决了什么，没解决什么

先公平地说，这类工具解决的问题是真实的。

它解决的是：从零到有一个能看的东西。

以前你要先搭工程、配路由、装组件库、写布局，可能半天过去了还没见到一个按钮。现在一句话就有。这一步的效率提升是实打实的，尤其在验证想法、做内部原型、给非技术同事演示这类场景里，价值非常明确。

它没解决的是另一件事：这个页面怎么跟你已经存在的后端工程对齐。

这两件事之间的距离，比大多数人以为的要远。

一个能看的页面，和一个能接进 Spring Boot 工程的页面，中间差的不是"再优化一下"，是它们根本是从两个不同的起点长出来的。

你手上的工程，是从接口长出来的：先有数据库表，再有 API，再有返回结构，页面是最后那一层。

AI 生成的页面，是从 UI 长出来的：先有界面长什么样，字段、请求、状态都是顺着界面倒推出来的。

方向相反。 这就是"接不进去"的根本原因。

二、差的那一口气，具体差在哪

把这口气拆开，通常是五个地方对不上。

1. 字段命名。

后端返回 userName，页面写的是 name。后端用下划线 create_time，页面用的是驼峰。每一处都不难改，但一个中等复杂度的页面，这种地方有几十处。

2. 分页和排序的约定。

你的后端是 pageNum + pageSize，返回 total 和 list。它生成的是 page + limit，返回 data 和 count。数据结构不一样，页面上的总数和翻页逻辑就得重写——而这部分逻辑通常散落在好几个地方。

3. 错误码的处理位置。

你的后端有一套自己的响应包装，业务失败是 code: 4001 加提示语，HTTP 状态码永远是 200。它生成的页面默认按 REST 语义处理，见到非 2xx 就当网络异常。结果就是：所有业务错误在页面上全变成了"请求失败"。

4. 状态的持有方。

筛选条件是放在组件里，还是放在 URL 上？批量删除的勾选状态在刷新后要不要保留？这些决定直接影响你后端要不要提供额外的接口。AI 生成的时候不知道你的后端长什么样，它只能挑一个最常见的做法。

5. 权限和字段级可见性。

哪些按钮对哪些角色可见、哪些字段某些人不能看——这类信息不在界面里，在你的业务规则里。AI 看不见规则，它只会把按钮全画出来。

这五处里，没有一处是"AI 不够聪明"。每一处都是它拿不到你工程里的那份契约。

三、先有接口文档，才有页面

这里有个值得注意的做法。

在飞算 JavaAI 的智能会话里，前后端设计这条指令走的是一个特定的顺序：它先读取上游的需求文档，产出数据库设计和 API 接口设计，然后依据这份 API 接口设计文档去做前端页面设计。

注意这个顺序——页面是从接口文档派生出来的，不是独立生成的。

这意味着页面上出现的字段、请求路径、返回结构、分页参数的命名，全部来自前面那一份接口设计。不是在页面写完之后再去跟后端对齐，而是从一开始就长在同一套定义上。

还有一个细节更有意思：前端开发这条指令强依赖上游产物。如果当前是一个纯后端项目、还没有前端相关的设计文档，它会停下来，提示你回到前后端设计环节把文档补齐，补完之后才能继续。

这个"停下来"很关键。

它意味着系统清楚地知道：跨层开发里最贵的错误，不是写错，而是在上游还没定的时候就往下写。写错一行代码，改一行；上游没定就往下写，改的是一整个方向。

当然，边界也要说清楚：它不保证生成的页面在视觉上符合你的审美，也不替你决定业务流程该怎么拆。它保证的是一致性——页面和接口说的是同一套话。至于这套话本身对不对，还是得你来判。

四、为什么手工改一遍比重写还累

顺序反过来是什么样，很多人其实已经体验过了：你把生成的页面拿来改，改到一半发现比重写还费劲。

原因不难理解。

自上而下生成的页面，它的契约是分散的。 字段散在各个组件里，请求散在各个事件处理函数里，错误处理散在各个 catch 块里。你要对齐的不只是一处，而是几十处彼此独立、又互相牵扯的地方。

改一处可能引发三处不一致。改完分页发现总数不对，改完总数发现空状态没处理，改完空状态发现 loading 的时序变了。

而如果你的页面是从接口文档长出来的，情况就完全不同：字段只有一处定义，请求路径只有一处定义，错误码的映射只有一处定义。对齐的工作从"找几十处"变成"改一处"。

这就是为什么"契约先于代码"不是一句口号。 它直接决定了后续对齐工作的量级。

五、契约一致性，具体该怎么落

如果你现在手上的项目就是"AI 生成页面 + 手工对齐"的路子，有三件事值得先做：

第一，让接口定义成为唯一的事实来源。

不管你是用 OpenAPI、YAML 还是内部文档，接口字段和返回结构必须只有一份权威定义。前端页面的生成读它，后端的实现也读它。只要出现第二份，漂移就开始计时。

第二，把"对齐"变成生成之前的动作，不是生成之后的动作。

顺序错了，工作量会翻倍。先出页面再对接口，是在几十处地方改；先定接口再出页面，是在一处地方改。

第三，给缺失的环节设一个硬卡点。

这是最容易被忽略的一条。当上游文档不存在时，系统（或者你的流程）应该停下来提示，而不是默认一个继续往下跑。

Sonar 在 2026 年的开发者调查（1149 名开发者参与）里有一个数字很能说明问题：96% 的开发者不完全信任 AI 生成代码的正确性，但只有 48% 会在提交前始终检查。

也就是说，超过一半的情况下，那些"AI 自己猜了一个字段名写下去"的地方，是没人复查就进了仓库的。

一个会卡住的流程，价值就在这里——它把"猜"这个动作挡在了提交之前。

六、所以问题不在 AI，在顺序

回到开头那个场景。

一句话生成的页面很漂亮，这件事是真的。它接不进你的 Spring Boot 工程，这件事也是真的。两者并不矛盾，因为它们本来就是两件不同的事。

前者是 UI 生成，后者是工程交付。

UI 生成的起点是界面，所以它对得上"好看"，对不上"对得上接口"。

工程交付的起点是契约，所以它对得上"能跑通"，代价是你得先把契约定下来。

如果你要的是给老板演示的原型，一句话生成的页面完全够用，甚至更好用——快，而且好看。

如果你要的是接进现有系统、跟已有接口和表结构对齐、半年后还有人能维护的页面，那顺序就得反过来：先有接口文档，才有页面。

判断标准其实很简单——你要的是一张图，还是一个能进仓库的东西。

你有没有过这种经历：AI 生成的页面跑起来了，因为字段命名跟后端对不上，最后手动改了两个小时？

如果有的话，你当时是先写的页面还是先定的接口？评论区聊聊你的顺序。