老 Java 项目接上新前端，AI 帮不上的地方不在代码

一个 2018 年上线的单体服务，前端去年换成了 Vite。要一起改一个需求，我把两个项目塞进了同一个 IDEA 窗口。

四步，网上教程都有，带截图。做完之后，第一次编译就停了：IDE 提示这个 JDK 版本已经不支持项目里设的语法级别。项目里写着 1.8，机器上装的是 21。

改完再编，卡在依赖。后端要连公司私服，账号在一份配置里；前端要连内部镜像，令牌在另一份配置里。两套凭据互相不认，谁也不肯替谁让路。

第三次是编码。老项目的配置文件存的是 GBK，编辑器按 UTF-8 打开，中文注释变成一排方块。启动的时候，连 bean 的名字都被读成了乱码。

三个问题，没有一个跟「AI 写得对不对」有关系。

那天我先花了半天，专门确认这些设置该往哪放。合窗口这个动作不难，难的是没人提前告诉你：两个项目的运行时本来就是两套。

先撞上的是环境，不是模型

以前两个窗口分开开，各调各的。这个窗口的设置错了，只影响这个项目，报错也跟着来，人很清楚自己在哪儿。

合成一个窗口以后，设置仍然是项目各自的，工作区不改原来的项目配置，也不改项目位置。可问题转到了人这边：同一个窗口里翻两个项目的文件、跑命令，很容易在这个项目上用了那个项目的设置，报错又指向一段自己没改过的代码。

跨端开发的第一个坎不是上下文，是环境。 两个项目各有各的运行时，摆在一块看，差异就从「两个窗口的事」变成「一个窗口里必须交代清楚的事」。

老服务的 JDK 也升不了。不是不想升，是几个内部依赖在老版本之外跑不起来，改一个要连带改三个调用点，排期里没有这个位置。前端那边也等不了，新构建工具的最低要求摆在那儿。两套运行时必须在同一台机器上共存，这件事没有第三条路。

环境不交代，AI 给的代码是另一种错法：语法全对，运行条件全错。它按旧版本的口径给你写，你那边跑在新版本上；或者前端用了只有新运行时才有的接口，团队里还有人在旧环境里。代码挑不出毛病，毛病在它不知道你跑在哪。

两个项目放进一个工作区，一次需求改两边

IntelliJ IDEA 从 2025.2 起支持 Workspace。装一个多项目插件，新建时选 Workspace，把前后端两个项目一起加进去，它们就出现在同一个窗口里。

关键的地方在这儿：工作区自己只是一个存路径的文件。后端的构建配置没动，前端的依赖清单没动，两个 Git 仓库还是各管各的，提交历史互不干扰。这一步不像「合并项目」，更像「并排放着，但互相能看见」。

这里用上了飞算 JavaAI。它是个 AI 编程插件，装在 IDEA 里，专门面向 Java 研发，从需求分析到接口、表结构设计再到生成代码都管。它的多项目支持接在工作区这一层：两个项目进了同一个窗口，智能会话能同时看见两边。一条需求丢进去，前后端一起改：后端出接口和服务，前端同时把请求方法、页面里的调用、按钮改掉。参数名和路径只定一次，没有第二次抄写。

老项目在这儿多一层收益。给老代码加功能，最难的是摸清它原来怎么写：命名习惯、返回值外面包几层、异常往上抛还是就地吞。这些东西不在文档里，在几年前的代码里。两边能同看之后，改新功能时顺手就能对照老代码，不必先花半天考古。

再往上游走，是先定需求、再定接口和表结构、然后写业务逻辑、最后生成工程代码。前几步的产物是文档，落在项目里。老系统最缺的恰好是这个：需求散在邮件和会议纪要里，三年后没人说得清某个字段为什么这么设计。让它重新梳理一遍，比翻提交历史快。

模型那一层是两路。一路是插件自带的几档，按任务分速度和质量，底座取自擅长 Java 的开源模型，做过调优封装；另一路直连外部那几家，智谱的 GLM 系列、DeepSeek 的几个版本，都能选。后一路不负责补能力，作用是不必因为换了个工具，重新赌一次手感。

它不管环境

装哪个版本、账号放哪儿、文件用什么编码，这些它不管，也不该管。项目跑不起来的时候，它连依赖都读不全。

分工得说清楚：飞算 JavaAI 管的是两个项目在同一个上下文里被改，环境归人。 环境没配好就让它动手，拿到的是一份看着对、跑不起来的代码，排查起来比手写还费劲。

环境理顺之后，第一天还会撞端口。前后端的默认端口常常撞在一起，本地代理也要指对，指错了页面能打开、接口全是 404。这类事配一次，之后不用再管。

那天下班前我做了四件事，半小时。第二天提需求，一次改完两边，联调只剩一处要修：老代码里的日期字段是老的日期类型，前端已经按标准字符串处理了。这跟环境无关，是十几年前的接口设计留下的坑。

你们那个还在维护的老项目，现在开着几个窗口？