上周给订单列表加导出。后端在 order-service 加接口，前端在 admin-web 加按钮。
两个仓库，两个 IDEA 窗口。让 AI 帮忙改，后端那一半做得挺利索：Controller、Service、DTO、分页查询，风格跟现有代码一致。改完它给我一份清单，前端需要在 src/api/order.ts 里加两个方法，在订单列表页加按钮和轮询。
那一半得我自己搬。
搬的过程是这样：切窗口，找文件，照着清单写。中间传参名对不上，后端收 pageSize，清单里写的是 page_size，它生成后端代码时用驼峰，写清单时又按前端的习惯改了。改完再切回去，发现返回结构外面包了一层 Result，前端解构的位置错了。
来回三次。
不是模型不行，是它只看得见一个仓库
容易被归因成「模型能力不够」，其实不是。那几段代码它写得没问题，问题在它做每一次判断时用的同一个前提：当前打开的这个项目，就是全部的世界。
后端项目里没有前端的路由、没有页面组件、没有 axios 拦截器。它不知道你的前端把 Result 拆了几层，不知道参数名在那边叫什么，不知道订单列表页的文件叫 OrderList.vue 还是 list/index.vue。
所以它能交付的只能是「这一侧改完，再加一份给另一侧的说明」。说明写得再细也是二手的：它描述的是它想象中的前端，不是你真实的前端。
通用 AI 编码方式在这一层能做的，也就到这儿。你把前端代码贴进对话，它能处理这一次；换个会话，贴进去的上下文就没了。工程上没有位置存放「两边的关系」，每次靠人临时搬运。
搬运的人，成了整条链上最容易漏的一环
搬运看着只是切窗口，成本不高。真正的成本在别处。
一处是漏。后端加了接口，前端忘了加调用；或者加了调用没加按钮；或者加了按钮权限没配。这些东西编译不报、单测不报，要等人点那个按钮才发现。
另一处是漂移。两边分开改，各自都在做合理的选择，合起来就不一致：后端把状态字段从数字改成枚举，前端还按数字判断；后端给日期加了 @JsonFormat，前端还按 ISO 字符串解析。
一个需求八个文件，两个仓库。靠脑子记哪边改了哪边没改，能撑住一个需求，撑不住一周。
把两个仓库放进同一个视野，那一半才有人接
IntelliJ IDEA 从 2025.2 起提供了 Workspace。装一个 Multi-Project Workspace 插件，File > New > Project 里选 Workspace，把 order-service 和 admin-web 一起加进去，两个独立项目就出现在同一个窗口里。
关键在于它不改变原有项目的配置，也不改变项目的位置。工作区本身只是一个 jb-workspace.xml，里面存着两个项目的路径。后端的 pom.xml 一个字节没动，前端的 package.json 也没动，两个 Git 仓库各自独立。
飞算 JavaAI 的多项目支持接在这一层上。两个项目挂在同一个工作区之后，智能会话能同时看到前后端，一次需求输入进去，两边同步改：后端出 Controller 和 Service，前端同时把 api 定义、页面里的调用、按钮一起改掉，接口路径和参数名是同一次生成里定下来的。
它补的不是切换窗口那点时间，是那一半的归属。 原来「另一半」是一份需要人执行的清单，现在它是同一批改动里的一部分。约定只写一遍，两边就不会各写各的。
模型这一头也有交代。插件里的极速、深度、专家、基础几档，是在 Java 领域表现好的开源模型上调优封装出来的，调的是工程结构、框架约定、接口和表结构这些 Java 侧的东西。旁边另开一栏直连第三方，智谱的 GLM-5.2、5.3，DeepSeek-V4 的三个版本，都在可选范围里。这一栏不负责补能力，负责让团队不用为换个插件重新赌一次。
边界得说清楚：它管的是让两个项目在同一个上下文里被改，不管联调。 服务还是各起各的，跨域还是自己配，接口通了之后业务逻辑对不对还是人判断。约定漂移这类错误少了，联调本身一次没少。
这一层的差别，不在模型在工程
把两件事并排放。
一边是通用 AI 编码方式，模型很强，但它在单个仓库的上下文里工作，跨项目的那部分交给人。
有些做法是把上下文窗口做大了，一次能读进几十个文件，看着像解决了。但那些文件是人手动挑的，挑哪些、按什么顺序贴，判断还在人这边。下一次改动，重新挑一遍。
另一边是把工作区、五步链路、产物落盘这些工程层做起来的做法。多项目支持属于这一层：它解决的不是「模型懂不懂前端」，是「模型能不能同时看见前端」。项目之间的关系存在工作区的配置里，不在某个人的剪贴板里。
模型换代是几个月一轮的事，工作区里那条关系装一次就一直在。同一个模型，装在不同的工程结构里，交付出来的东西不是一回事。
飞算 JavaAI 把筹码押在后一层。工程链把需求分析、接口和表结构设计、业务逻辑、生成工程代码串起来，产物落在项目的 docs/ 里，多项目支持让这条链能跨两个仓库走完。
你上一次跨前后端改一个功能，那份「前端还需要改什么」的清单，最后是谁执行的？
