凌晨一点我盯着屏幕上的 502 发呆。前端明明已经从 Mock 接口拿到了和后端一模一样的 JSON联调时后端却说前端传错了字段。这不是我第一次栽在 Mock 数据上了。Mock 解决了联调前“没接口可用”的问题却制造了另一个更隐蔽的问题前后端对接口契约的理解慢慢分叉等真正联调时一起爆发。所以我想试一件事既然后端代码是接口契约最准确的“唯一事实来源”那能不能让 AI 直接去扫描后端源码把路由、参数、返回类型全部抽取出来一次性生成真正对接真实接口、能直接跑起来的前端这一周我抽时间把这条路完整走了一遍从 Spring Boot 后端源码开始配合 AI 编程工具做了接口提取、类型生成、请求层搭建和页面落地最后真的把一个订单管理前端跑起来了全程没有手写一行 Mock 数据。如果你也在做前端开发、全栈开发或者对 AI Agent 辅助编程感兴趣这篇文章能把整套思路和可复现的步骤讲清楚包括我踩过的坑。1. 为什么要干掉 Mock前后端协作的契约断层1.1 Mock 数据的三宗罪字段、类型、业务状态先别急着把所有 Mock 都一棒子打死纯前端做 UI 验证时 Mock 依然有用。但在涉及真实业务接口的中后台系统里Mock 带来的问题远比我以前以为的严重。第一是字段对不上。后端返回userNameMock 里写name后端是createTimeMock 里写createdAt。前端先按 Mock 把表格列、表单字段都写好了联调时发现一半字段名是错的改起来连锁反应极大。字段名不一致的根本原因并不是谁粗心而是 Mock 数据是“人写的想象”后端代码才是“客观事实”这两者天然存在漂移。第二是类型不匹配。后端的Long类型 ID 在 JSON 序列化后可能是字符串也可能强转成了 numberLocalDateTime可能被序列化成2026-05-11T10:30:00也可能变成时间戳。Mock 里随手写一个字符串页面渲染没问题等接了真实接口排序、比较、格式化全乱了。第三是业务状态缺失。Mock 数据通常只覆盖“正常情况”。登录失效怎么办接口限流返回 429 怎么办后端返回业务错误码40010前端该怎么提示这些在后端代码里都有明确设计但 Mock 数据里根本体现不出来。等用户真上线遇到问题前端才发现自己压根没处理过这种状态。1.2 后端代码才是真正的“接口文档”很多团队有接口文档但文档和代码一旦不同步文档就变成了历史记录而不是契约。我的经验是文档适合人类看但机器始终应该以代码为准。后端代码里藏着全部关键信息——RequestMapping定义的路由路径、RequestParam和RequestBody定义的入参结构、方法返回类型与 DTO 字段、NotNull之类的校验注解、PreAuthorize之类权限注解。这些信息就在源码仓库里而且是当前真实运行版本的准确描述。与其让 AI 去猜接口长什么样不如直接让 AI 去读代码。这就是“AI 直接扫描后端代码生成前端”的核心逻辑把数据源从“人写的 Mock”换成“机器可读的源码”AI 的幻觉空间会小非常多。1.3 这套方案适合哪些项目不适合哪些项目适合的条件后端是主流 Web 框架Spring Boot、Django、FastAPI、Express、Go Gin 等路由注解和参数定义比较规范前端需要对接真实接口而不是纯静态展示团队有前后端联调环节希望压缩接口对齐时间。不适合的也有。如果是几十个接口的 very old 遗留系统接口写法完全没有规律那 AI 扫描的结果也会很乱不如手写。如果只是为了做设计稿还原、UI 走查那 Mock 或静态数据可能更高效。对外宣传用的官网页面更不需要接后端。工具要用在刀刃上。2. 整体思路拆解先建契约再让 AI 干活2.1 三步走扫描后端抽契约生成前端我这套方案的整体路径非常清晰就是三层扫描层、契约层、生成层。扫描层负责从后端代码里抽取接口元数据。最常见的手段是先找 Controller 层的所有路由方法再递归找到请求对象和响应对象的字段定义。这一层是纯技术活不涉及 AI 判断最好用确定性脚本完成因为接口路由不能靠“大概了解”必须精确到每一个 URL、每一条 HTTP 方法和每一种参数。契约层把扫描结果整理成结构化的中间产物通常是 JSON。这个 JSON 约等于给后端代码画了一份“机器能读的接口说明书”里面要有路由、方法、请求参数、返回类型、字段名、字段类型、是否必填、嵌套结构。如果后端已经有了 OpenAPI/Swagger 文档可以直接用它作为契约没有的话就用脚本从注解和源码里提取。生成层把契约 JSON 交给 AI让 AI 做它擅长的事在理解业务语义的基础上生成 TypeScript 类型、API 请求层、页面组件和路由配置。AI 不要从空泛的“给我做一个订单系统”开始写而是基于一份精确到字段的契约 JSON 来写效果完全不一样。2.2 为什么选“契约优先”而不是让 AI 自由发挥你可能见过别人演示 AI 编程丢一句“帮我写一个电商后台”AI 就哗哗生成十几个页面看起来挺唬人。但这种开发方式有个致命问题AI 会自由发挥接口字段。它会默认orderId是字符串默认列表接口叫getOrderList默认分页参数是pageNum/pageSize。这些默认值一旦和后端真实实现不一致生成得越多返工越多。契约优先的本质是限制 AI 的想象空间。你告诉它路由就是/api/orders请求参数就是page和size返回字段就是records、total、orderNo它就没有理由去编一个新的结构。AI 的创造力应该用在页面组织、交互逻辑和组件复用上而不是用在猜测接口签名上。这里也涉及一个认知AI 编程不是替代工程能力而是替代重复劳动。接口对接本身是重复劳动业务理解才是核心价值。把重复劳动标准化把理解留给人和 AI 协作才是合理的分工。2.3 技术选型AST 解析、正则、还是直接读 OpenAPI实际动手之前我先在识别接口元数据用什么技术上纠结了一会儿这里分享下我最后的选择和理由。如果你的项目本身有 OpenAPI/Swagger 文档这是最优先的方案。Spring Boot 项目接入springdoc-openapi后通常可以直接访问/v3/api-docs得到一份完整的 JSON 文档里面包含所有接口路径、参数、响应结构。AI 编程工具对这种结构化 JSON 的理解非常稳定基本不会出错。如果没有现成的 OpenAPI就需要自己写了。这里有两条路正则匹配和抽象语法树解析。正则匹配适合快速盘点比如用一行rg命令把GetMapping(/orders)全部列出来找出路由和 HTTP 方法的对应关系。优点是快缺点是处理不了复杂情况继承父类路由、泛型返回值、多个参数对象嵌套、注解里用 SpEL 表达式等。抽象语法树解析可以拿到真正的类型信息和结构但代价是要引入解析框架比如 Java 项目的JavaParser写出来的脚本会复杂不少。我的建议是分阶段走先用正则快速盘点接口清单摸清项目规模如果接口数量大、结构复杂再上 AST 或者直接引导后端项目固定输出 OpenAPI甚至可以在第一步就把已经存在的/v3/api-docs接口检查一下很多项目其实已经开了 Swagger只是前端不知道。2.4 工具链全景图环节工具/手段作用接口发现rg、grep、JavaParser 或树形解析器从 Controller 代码中定位路由方法契约生成Python/Node 脚本or OpenAPI JSON输出结构化接口清单类型生成AI 大模型 TS 代码生成将 DTO 字段翻译为 TypeScript interface请求层生成AI axios/fetch 拦截器统一 token、错误码、超时处理页面生成AI React/Vue 组件库列表页、表单页、详情页落地联调验证Vite/Webpack 代理 浏览器 Network验证真实接口是否被正确调用整套链路中只有“页面生成”强烈依赖 AI 语义理解其他环节都可以用确定性手段做一部分。这能有效降低项目的不可控性。3. 核心细节从后端源码到可运行前端的关键环节3.1 接口清单怎么提取Controller 扫描实战我以前端开发者的视角看 Spring Boot 源码第一反应是有点懵。但找到规律后就不难了所有接口入口都集中在RestController或Controller类里每个对外接口方法上有GetMapping、PostMapping、PutMapping、DeleteMapping这类注解方法参数上又有RequestBody、RequestParam、PathVariable。我实际用的第一步是先用rg快速盘点一下规模rg -n (RestController|RequestMapping|GetMapping|PostMapping|PutMapping|DeleteMapping) \ src/main/java/com/example/order/controller这条命令会列出一大把接口行先不管字段不字段至少能判断出控制器数量和路由密度。如果数量很大比如超过两三百个我建议分模块处理别指望一次性把整个后端啃下来。比如先只扫order模块。第二步是提取每个方法的完整签名。用一个简化版的 Python 脚本可以做到初步提取import re, json, pathlib controllers [] for path in pathlib.Path(src/main/java/com/example/order/controller).rglob(*.java): text path.read_text(encodingutf-8) for m in re.finditer(r(Get|Post|Put|Delete|Request)Mapping\(\(.*?)\\), text): method_verb m.group(1) route m.group(2) class_match re.search(rclass (\w), text) controllers.append({ class: class_match.group(1) if class_match else , method: method_verb, route: route, file: str(path) }) print(json.dumps(controllers, ensure_asciiFalse, indent2))这个脚本有很多粗糙的地方比如它会把一个文件里重复的注解抓乱、也处理不了RequestMapping类级前缀拼接。但它能在三分钟内给我一份“接口在哪、方法是什么、路径是什么”的初稿足够后续让 AI 去精读了。有了初稿之后我把它连同 Controller 的核心源码片段一起丢给 AI明确要求它补全参数类型、返回类型和请求体结构。这一步就是“人机协作”人负责盘点AI 负责理解代码语义并整理成结构化的契约。3.2 DTO 到 TS 类型继承、泛型、枚举怎么处理契约拿到后最枯燥的环节就是写 TypeScript 类型。让 AI 来做这件事需要给它喂足够的上下文不是只给一个 DTO 类名而是要把对应的 Java 类源码或者契约 JSON 片段给它。简单场景下后端返回一个OrderResppublic class OrderResp { private Long id; private String orderNo; private BigDecimal amount; private LocalDateTime createTime; private ListOrderItemResp items; }AI 生成的 TypeScript interface 应该是export interface OrderResp { id: number; orderNo: string; amount: string; // 或 number取决于后端序列化配置 createTime: string; // LocalDateTime 通常序列化为字符串 items: OrderItemResp[]; }这里有两个我踩过的坑需要提醒。第一个是金额字段。BigDecimal在 JSON 序列化时可能被 Jackson 默认输出为 number也可能被配置成 string。仅看 Java 源码并不能确定需要结合后端全局配置确认。我的处理方法是在 Prompt 中要求 AI 把不确定类型标成string | number并生成注释联调时再按真实响应收敛。不要为了“类型看起来漂亮”直接写死成 number。第二个是时间字段。LocalDateTime最常见的序列化结果是2026-05-11T10:30:00字符串但也要确认时区配置。如果后端在全球部署前端展示时应该转成用户在本地时区看到的时间。这个细节接口文档里往往不写但从源码扫描后至少能暴露出来。遇到 Java 泛型返回结构比如PageResultOrderRespAI 生成的 TS 泛型一定要保留住export interface PageResultT { records: T[]; total: number; page: number; size: number; }我见过 AI 在生成时把泛型展开成具体类型导致后续列表页复用其他接口时又要重写。这里的经验是生成类型时一定要在 Prompt 里强调“保留泛型和嵌套结构不要拍平成单一类型”。说得越具体返工越少。3.3 请求层生成拦截器、错误处理、鉴权类型生成后下一步是生成真正发请求的 API 层。这是前端“可真实运行”的根基也是很多 AI 生成代码的薄弱环节——它喜欢生成 fetch 单发请求完全没有拦截器、没有统一错误处理。我建议你让 AI 按如下模板生成 axios 实例并明确告诉它这四点统一注入 token、统一错误响应格式、超时时间、401 处理。// src/api/http.ts import axios, { AxiosError } from axios; export const http axios.create({ baseURL: import.meta.env.VITE_API_BASE_URL, timeout: 10000, }); http.interceptors.request.use((config) { const token localStorage.getItem(token); if (token) { config.headers.Authorization Bearer ${token}; } return config; }); http.interceptors.response.use( (response) response, (error: AxiosError) { if (error.response?.status 401) { window.location.href /login; } return Promise.reject(error); } );后端的鉴权方式多种多样有的是 Header Authorization、有的自定义 Header 名、有的是 Cookie 会话。扫描后端代码时如果看到 Filter 或 HandlerInterceptor 里读取某个 Header就把这个信息告诉 AI请求层才能一次到位。我见过 AI 默认生成Authorization: Bearer xxx而后端实际只认X-Auth-Token这种接口一调就是 401浪费很长时间排查。3.4 页面骨架生成表单、列表、详情页页面生成环节最考验 Prompt 的引导能力。因为页面不仅要有 UI还得正确处理 loading、空数据、错误提示和表单校验这些细节最容易在 AI 生成的初版里缺失。我常用的一段 Prompt 是这样写的当前项目是 Vue3 TypeScript Element Plus已有 src/api 下的请求层。 契约 JSON 如下 {接口清单或关键接口} 请生成三个页面 1. 订单列表页路径 /orders支持分页、搜索订单号、状态筛选 2. 创建订单页路径 /orders/new字段校验规则按后端的必填项设置 3. 订单详情页路径 /orders/:id展示订单基础信息和商品明细。 要求 - 每个页面必须调用真实 API禁止使用本地 mock 数据 - 列表页、表单页都要有 loading 状态 - 请求失败时用 message 组件提示后端返回的错误信息 - 组件使用 Composition API 的 setup 语法 - 不生成多余的文件结构保持简洁。关键技巧是“把期望写具体”。想让 AI 生成能跑的页面就得让它知道路径、组件库、语法风格和交互限制。不然它会在每个文件里塞一堆高级抽象代码量翻倍可读性反而下降。我会特别强调“不生成多余的文件结构”。AI 有很强的过度设计倾向动不动生成types/、constants/、hooks/、utils/的目录对一个小前端项目来说负担太重。直接约束它比事后删文件效率高。4. 实操过程一次完整的“源码扫描 AI 生成”实录4.1 准备后端工程与本地启动完整走一遍之前先把后端跑起来是最省事的选择。因为“可真实运行的前端”必须先有真实的后端地址。我这个实验里用的是 order-service一个 Spring Boot 项目。我先把代码 clone 到本地检查数据库配置然后用 Maven 直接启动cd order-service mvn spring-boot:run -Dspring-boot.run.profilesdev启动成功后先手动访问一次 Swagger 或直接curl一个接口确认连得上。这一步不要跳过很多 AI 生成前端联调失败的根因不是前端代码问题而是后端压根没启动成功。因为我的目标是模拟大多数团队的真实状态所以我没有依赖 Swagger而是直接从注解源码里提取接口。在实际项目里如果后端已经配置了 springdoc通常访问http://localhost:8080/v3/api-docs就能拿到 OpenAPI JSON那后面就会省心很多。有些老项目里配置路径是/v2/api-docs或/swagger-resources可以先读后端配置文件确认。4.2 提取接口元数据并生成契约文件先生成一个干净的目录放生成物mkdir -p /tmp/ai-frontend/contract然后把第 3.1 节里的 Python 脚本稍作改进输出一个初步的接口清单。再把包括OrderController.java、CreateOrderReq.java、OrderResp.java、OrderItemResp.java在内的核心源码合并成一个上下文文件cat /tmp/ai-frontend/contract/context.java EOF // OrderController.java ... // OrderResp.java ... EOF这一步的目的是给 AI 一个“局部但完整”的视图不需要把整个仓库所有代码都喂进去。AI 不是仓库索引器它需要的是有上下文的源码片段而不是几万个文件的代码树。拿到这些材料后我要求 AI 先输出一份契约 JSON而不是直接生成页面。这一步非常关键先让 AI 产出“机器和人都能审查”的中间产物我再人工检查一遍路由有没有遗漏、路径拼接对不对、参数名是不是后端真实字段。检查通过之后后面生成前端代码就不容易再出大幺蛾子。契约文件长这样{ basePath: /api, endpoints: [ { method: GET, path: /orders, queryParams: [ {name: page, type: integer, required: true}, {name: size, type: integer, required: true}, {name: orderNo, type: string, required: false} ], response: { type: PageResultOrderResp, fields: { records: OrderResp[], total: integer, page: integer, size: integer } } } ] }有了契约 JSON后面生成的所有前端代码都以它为准所以这一步值得停下来认真看一遍。宁可多花十分钟也不要让一个错误的路径污染后面全部代码。4.3 构建 AI Prompt 并生成前端工程契约文件准备好了接下来我用一段相对完整的 Prompt 把整个过程串起来。为了方便你说清我把一次生成的类型和请求层 Prompt 作为一个固定模板保存每次只需替换契约 JSON。我仍然用第 3.4 节的 Vue3 项目说明完整 Prompt 看起来是你是资深前端工程师。请根据以下后端接口契约生成一个可运行的 Vue3 TypeScript Element Plus 前端工程涉及订单模块。 契约 JSON {把上面的 contract.json 贴进来} 需要生成的内容 1. src/api/http.tsaxios 实例含 token 注入、401 处理 2. src/api/order.ts订单相关请求方法类型从契约生成 3. src/types/order.ts所有接口类型定义 4. src/views/order/OrderList.vue、OrderCreate.vue、OrderDetail.vue 5. src/router/index.ts包含三个页面的路由 6. src/App.vue src/main.ts完整的项目入口。 约束 - 禁止 mock 数据所有数据必须通过真实请求获取 - 表单校验规则根据后端必填字段定义 - 代码风格保持简洁不要引入多余依赖 - 列出前端工程启动所需的 package.json 关键依赖和 vite.config.ts 的代理配置。我一般分两个阶段来执行而不是让 AI 一口气把全部 6 个文件全塞出来。第一阶段让它生成类型和请求层第二阶段生成页面和路由。这样每一阶段的 diff 都相对可控出问题时也更容易定位是类型写错还是页面逻辑写错。4.4 落地启动与第一次真实联调生成完代码后我把它们放到一个新建的 Vue3 工程里npm create vitelatest order-frontend -- --template vue-ts cd order-frontend npm install再补上 Element Plus、axios、vue-routernpm install element-plus axios vue-router然后配置 vite 代理把前端开发环境的/api转发到后端地址// vite.config.ts export default defineConfig({ plugins: [vue()], server: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true, }, }, }, });这个代理配置非常重要。直接在前端代码里写http://localhost:8080也能跑通但会遇到跨域问题或生产环境 URL 写死的问题所以统一走/api相对路径、由代理转发是最稳妥的方案。启动前端npm run dev打开页面打开浏览器 Network 面板刷出订单列表后先看一眼实际请求的 URL、Query 参数、RequestBody 是否正确。我第一次跑的时候列表接口返回了数据但分页参数没生效检查后发现 AI 生成代码里把分页参数名写成了pageNum而后端契约里定义的是page。原因是我在契约 JSON 里没有强调 “page 就是后端接口真实参数名”AI 凭经验习惯性地改成了pageNum。这个经历让我养成了习惯在最终联调前先用一个最小请求脚本直接 curl 后端接口确认字段名再让前端调用。省下的排查时间远超这点工作量。5. 常见问题与排查实录5.1 快速排查表症状可能原因排查方法接口 404路由前缀没拼对类级 方法级打开 Network 对比实际 URL 与后端 Controller 注解接口 401token 注入 Header 名错误检查后端 Interceptor/Filter 读取的是哪个 Header接口 400请求体结构不对或必填字段缺失对照后端 DTO 的字段注释和校验注解字段都是 undefinedTS 类型与真实 JSON 字段大小写不一致在浏览器 console 打印原始 response 对照时间显示不对时区或日期格式未按后端处理看后端 Jackson 全局配置和返回样例能返回数据但页面空白数据层级不对比如没剥开 data 字段检查 axios 拦截器是否返回了response.data.dataCORS 报错前端直接访问后端跨域改用 vite 代理或后端允许跨域5.2 鉴权绕不过去怎么办中后台系统基本都有登录接口AI 生成前端时最棘手的就是登录态获取。我试过让 AI 帮我生成登录页输入的是后端登录接口的契约它生成完请求层后我手动验证了一下登录接口能拿到 token再让前端把 token 存到localStorage。有一个坑值得单说很多后端接口不仅校验 token还校验权限比如PreAuthorize(hasRole(ADMIN))。AI 生成的前端页面如果调了一个你没有权限的接口返回 403页面提示也会很粗糙。这种情况尽早联系后端确认当前账号需要的权限或者准备一个白名单测试账号。5.3 大仓库 token 超限怎么办如果你扫描的是一个大型后端项目几十个模块、几百个 Controller一次性把代码全部交给 AI 极易触发上下文长度限制。我的做法是分模块分批处理或者先只挑核心链路比如“订单创建流程”涉及 OrderController、CreateOrderReq、OrderService、OrderMapper那么只扫这几个类就够了不需要把库存、支付、用户全部拉进来。分批生成的裂缝在于模块之间可能有共享类型比如分页对象PageResult在多个模块里被反复引用。我的处理是先把共享基础类型单独让 AI 生成一份再在后续模块的 Prompt 里声明“PageResult 类型已存在不要重复生成”。5.4 AI 幻觉字段怎么发现和纠正这是我最想强调的一点。AI 生成代码时即使给它精确到了字段名的契约 JSON它偶尔还是会“脑补”出一些后端根本没有的字段。比如它会顺手生成一个statusText或者totalAmount理由可能是“这样更合理”但后端没有这个字段接口就得 400。要根治这个问题不能只靠肉眼 review。我建议在前端开发环境里写一个类型一致性校验脚本或者退一步用最笨但有效的方式拿到真实接口响应后把 JSON 存下来和 AI 生成的 TS 类型逐一对比。如果字段数量不一致就在 Prompt 里反馈纠正。我的做法是直接在浏览器 Network 里把响应 JSON 导出然后用diff和 AI 生成的类型文件比对。你不用写太复杂的工具哪怕就是肉眼过一遍字段名也比直接上线拿用户当测试者强得多。5.5 分享一个保留“生成系统说明书”的习惯最后分享一个我在这个实验里收获的小习惯让 AI 生成前端的同时输出一份接口消费说明书。它会包含当前前端已经覆盖的接口清单、字段说明、鉴权方式、联调要点以及下次后端字段变更后应该改前端的哪里。这份说明书我不会拿去做正式文档它更像是我和后续接手的同事之间的交接备注。有这个说明书存在下次后端同事改接口时我能快速知道影响范围下次前端同事接手这个模块时也不用从头去猜哪些接口是 AI 生成的、哪些文件是手工改出来的。这个小投资回报来得比想象快。我自己实际跑通这条路之后最大的感触是AI 生成代码的能力早就不是瓶颈瓶颈在于我们怎么给它提供可信的输入。让 AI 直接读后端源码本质上是在为它建立“事实基础”把最容易出错的接口契约部分用确定性手段解决掉再用 AI 的语义能力生成前端代码。这种组合的稳定性已经足够让“一次生成、真实可运行”从实验变成日常可复用的工作流。你只要把契约提取这一步做扎实后面真的可以少写很多前端代码。