企业官网建设流程全解析

一个指令，前后端同步开发：刚提完需求，两端代码一起落地的真实体验

前后端分离项目最常见的工作流是：提需求 → 后端写接口 → 前端等接口 → 联调对齐 → 前端调样式。每一步之间都有等待、有沟通损耗。多项目支持带来的变化很直接：一条指令下去，后端接口和前端页面同时生成，联调这一步从"事后对齐"变成了"生成时对齐"。这篇文章写写我实际用下来的体验，以及它到底省了什么。

一、先看一段典型的"两端开发"

为了让体验有对照，先还原一个很普通的开发场景——给订单列表加一个"按支付状态筛选"。

传统流程是这样推进的：

1. 产品说：订单列表要能按支付状态筛选；
2. 后端同学（或你自己切换到后端视角）：设计接口，加?status=PAID查询参数，写 Service 过滤逻辑，写完还要自测；
3. 前端同学（或你再切换回前端）：等接口文档出来，才知道参数名是status而不是payState，才开始写下拉框、绑事件、调接口；
4. 联调：前端传参对不上（大小写、枚举值、字段名），反复 Debug 对齐；
5. 最后才是样式和交互调优。

这条链路里，真正写代码的时间占比不高，损耗都花在了"等待"和"对齐"上。后端等需求理解、前端等接口定义、联调等两边口径一致。

多项目支持改变的是第 3、4 步的形态：前后端一起生成，参数名天然对齐，联调从"找问题"变成"验收"。

二、实测：一条指令，两端一起落地

我的实测环境：IDEA 2025.2 + Multi-Project Workspace 插件，一个 Spring Boot 后端项目，一个 Vue3 前端项目，通过 Workspace 挂载在同一个工作区。

我在智能会话里输入了一条需求：

订单管理页新增按支付状态筛选：后端 order/list 接口增加 status 查询参数，按 PAID、UNPAID、REFUNDED 三个状态过滤；前端列表页顶部加一个状态筛选下拉框，选择后刷新列表并携带该参数。前后端一起改。

没有任何更细的指示，没有字段命名建议，没有接口路径约定，就是上面这一段自然语言。

模型执行完，我逐个位置检查变更：

后端侧：

• OrderController的/order/list接口新增了@RequestParam(required = false) String status；
• OrderService里加了按状态过滤的条件拼接；
• 枚举OrderStatus里正好有PAID、UNPAID、REFUNDED三个值——没有额外新增，说明模型读了现有枚举定义；
• 返回结构没动，分页参数没动。

前端侧：

• 列表页顶部新增了一个el-select下拉框，选项是"全部 / 已支付 / 未支付 / 已退款"四个；
• 下拉框change事件里重置页码并重新调用列表接口，携带status参数；
• 调用的是order/list，参数名是status，传的枚举值大小写和后端一致。

最关键的对齐检查：前端拿到的筛选值和后端枚举定义完全一致。没有出现"前端传 PAID、后端认 paid"这种大小写错位，也没有"前端叫 status、后端叫 payStatus"这种字段错位。

这就是多项目上下文的作用——模型在生成前端代码时，后端代码就在它的上下文里，它不需要猜，直接照着生成。

生成过程中的两个细节

除了"改对了"，这次实测里还有两个细节让我确认它不是简单拼凑：

细节一：它读懂了项目里已有的约定。需求里我写了"按 PAID、UNPAID、REFUNDED 三个状态过滤"，但没写这三个值从哪来。模型没有凭空新建枚举，而是找到了项目里现成的OrderStatus枚举，直接复用了里面的三个值。这说明它不只是"会写代码"，而是会"按你项目的写法写代码"——这两者的差距，用过 AI 编程工具的人都懂。

细节二：它保持了向后兼容。接口新增了status参数，但模型把它标成了required = false，也就是不传也能跑，老调用方不受影响。这个默认动作对工程太重要了——如果它顺手把参数加成了必填，前端所有老页面都会立刻报错。它选择了"加参数不加约束"，这个保守策略是对的，符合对存量系统的最小侵入原则。

这两个细节也给你一个判断生成质量的标尺：先看它有没有复用你项目里已有的定义，再看它有没有破坏原有的调用约定。两条都满足，比"代码能跑"更接近高质量生成。

三、省掉的到底是什么

把传统流程和实测流程放在一起对比，能清楚看到差在哪：

其中价值最大的不是"少敲几行代码"，而是减少了上下文切换和口径对齐这两类纯损耗。

传统方式里，后端和前端是两套知识在两个地方转译——后端写PAID，前端写成什么取决于前端同学有没有仔细看文档；即便文档写了，代码评审时也可能漏。多项目模式下，模型在单一上下文里完成转译，这个损耗在生成阶段就消掉了。

再算一笔更粗略的账：一个跨端需求，传统方式从提需求到联调通过，快则半天、慢则一天；Workspace 模式下，生成几分钟、验收几十分钟。省下的不是代码量，而是等待和沟通。

把"隐性工时"列成账

有人会觉得上面的账太粗。我把一个典型跨端需求（比如这次的状态筛选）在两种模式下各环节耗时拆开，你对着自己的日常感受一下：

注意传统方式里，"接口同步"和"联调排错"两个环节在 Workspace 模式里基本消失了——不是变快了，是不再需要存在。这正是多项目上下文的价值：把"转译需求、传递约定"这两个纯损耗环节从流程里删掉，而不是压缩。

四、什么场景收益最大

不是所有需求都值得用多项目同步开发，我帮你分分类：

收益最大的场景：

• 常规增删改查 + 列表筛选，前后端逻辑都规整，模型一次生成成功率极高；
• 接口新增 + 前端页面同步新增的成对需求；
• 文档型业务（前端表单 + 后端接收），字段多但模式固定。

需要人工多把关的场景：

• 涉及复杂事务、分布式一致性的核心接口——代码可以生成，设计必须你把关；
• 前端交互特别重的页面（复杂拖拽、动画、实时协作）——生成的是基础版，交互要再调；
• 历史包袱重的老项目——模型得先理解你项目里那些"约定俗成"的写法，首次生成质量取决于上下文理解度。

不适合直接生成的场景：

• 架构级改造（模块拆分、服务化）、安全敏感逻辑（权限边界、支付回调验签）、需要强业务判断的需求。这类需求的"大模型出代码"部分仍然高效，但"工程决策"必须人来定——这也正好对应了"大模型解决代码问题，AI 编程工具解决工程问题"这条主线。

一个判断"该不该直接生成"的口诀

实操里我总结了一个三问判断法，遇到拿不准的需求就问自己三句：

1. 这个需求的"正确性"可验证吗？能跑通、能比对、有明确预期结果的，适合直接生成；靠业务经验才能判断对错的，先自己设计。
2. 改了它，影响面可控吗？涉及事务、资金、权限的核心路径，影响面大、出错的代价高，生成后必须加严验收；边缘功能、内部工具，生成完顺手一验就行。
3. 需求的上下文完整吗？你自己都还没想清楚"到底要什么样的行为"，就别指望 AI 替你想清楚。先把需求描述到"人人看了都理解一致"，再交给生成。

三条都满足，大胆直接生成；任何一条含糊，就把含糊的那部分先设计清楚。这个口诀比"看场景分类"好用，因为它把判断标准从"类型"变成了"可验证性"——后者才是决定生成质量的关键。

五、验收清单：每次同步开发后查这三条

同步开发省事，验收不能省。我给自己定了一个固定三项检查：

1. 参数对齐：前端请求参数名、类型、枚举值是否和后端 Controller 一致。重点查大小写和枚举。
2. 边界处理：接口的参数是否required、无值时的默认行为、空列表的返回，前端是否处理了空态。
3. 回归影响：新增过滤条件后，原有调用方是否受影响——老接口不传 status 时行为是否和以前一致（向后兼容）。

其中第 3 条最容易漏：模型新增参数时，默认会让参数"可选"，但如果它把新字段加成了必填，老调用方立刻被打挂。所以每次生成完，先跑一遍原有调用链的接口测试，再验收新功能。

三个常见的"验收翻车"现场

验收清单写得出来，执行的时候还是容易翻车。列三个我踩过的或见过的现场，给你排雷：

翻车1：只验新路径，不验老路径。生成完状态筛选后，页面筛选功能一切正常，但老入口（比如从详情页跳回来）传的旧参数格式没适配，页面白屏。教训：验收要从"用户所有入口"过，不是从"演示路径"过。

翻车2：只验前端能调通，不验后端独立性。前端传status能通，但你把前端停掉、直接 curl 后端接口，发现没传 status 时返回的 total 和实际数据条数对不上。教训：前后端各自单独验一次，两端对接是最后一次校验，不是唯一一次。

翻车3：只验成功分支，不验异常分支。状态值传了个非法值（比如PAYING），后端有没有做参数校验、返回什么错误码、前端有没有兜底提示？生成代码最常见的问题就是异常路径不全。教训：把"出错时会发生什么"当验收的一项，而不是只验"正常时能跑"。

除了上面三个高频翻车点，还有两个低频但更隐蔽的坑，遇到一次代价都不小：

坑4：两端同步改了，第三端忘了。状态筛选这个需求，改的是订单管理前端 + 订单服务后端。但如果还有移动端、还有数据报表服务也在消费同一个订单接口，同步生成的两端是"自洽"的，第三端却被甩在旧契约上。跑完两端联调发现没问题，上线后报表服务悄悄报错。教训：动手前先盘一遍"这个接口到底有几个消费端"，把消费端清单也写进需求描述里，让模型知道自己要兼容谁。

坑5：注释和文档停留在"生成时的版本"。AI 生成代码时不只写代码，还会顺手更新了接口文档、留了新注释。这是好事——但只在它生成的那一轮。之后人手动改了字段语义，文档和注释不会自动跟上，错位又开始了。教训：把"文档随代码一起变"当成一种临时状态，而不是永久承诺，关键契约文档仍然需要人定期过一遍。

这两个坑的共同点：它们都不在多项目的直接作用范围内，属于"工具帮你把主干做完之后，边界依然要靠人"的典型场景。意识到这一点，对工具的使用预期会更准确——同步开发解决的是"两端对齐"的高频问题，不是所有协作问题。

六、体验总结：从"等接口"到"验接口"

用一句话总结这次实测的体验：以前开发跨端需求是"等着别人/另一端的代码"，现在变成了"验收两端一起生成的代码"。

变化不是"从写代码变成不写代码"，而是工作重心从"转译需求 + 对齐口径"转移到了"审核生成、把关边界、验回归"。后者是更接近工程本质的工作。

如果你也是前后端分仓库、一个人扛需求、或者整天被联调折磨，建议按上篇文章的步骤把 Workspace 搭起来，拿一个真实的筛选类需求试一次。跑通之后你就会发现，以前最花时间的"联调对齐"，变成了生成时就完成的事。