上周帮同事查一个 bug：订单列表那一页，订单号整列是空的，接口返回里明明有值。
前端把 console.log 截图发过来，item.orderNo 是 undefined。我打开后端 DTO，字段名是 orderCode。
谁都没写错，改的时候也没人跟对方说一句。
订单号在一个前后端分离的项目里能出现六次：数据库 order_no，实体 orderNo，DTO orderCode，接口文档 orderNo，前端 interface 里的 orderNo，模板里 form.orderNo。前两处有 map-underscore-to-camel-case: true 兜着，从 DTO 往后，全靠人抄。
// 后端：觉得 orderCode 更准确，改了
private String orderCode;
// 前端：照着上一版接口写的
interface Order {
orderNo: string
}
编译能过，单测能过，Swagger 看着也正常，因为 Swagger 是从后端 DTO 生成的，它当然知道叫 orderCode。真正对不上的时候，前端拿到的是一列 undefined。你先怀疑渲染，再怀疑数据流，再把 OrderList.vue 从头到尾翻一遍，最后才想起来看一眼响应体。
这类 bug 费时间，因为它不报错，只报症状。
一个字段抄两遍，迟早对不上
这跟谁水平没关系。同一份约定，后端写一次，前端抄一次，中间没有强制手段，只有记性。赶需求的时候，记性最先掉。
有人会说，写接口文档不就行了。文档确实比口头约定强，但它有三个死穴：
- 文档和代码是两份东西。改代码的人不一定会回去改文档。
- 文档没有约束力。前端抄的时候觉得字段名别扭，顺手改一个字母，文档当场作废，而且没人知道。
- 三个月后再打开，它描述的是一个已经不存在的接口。
文档能解决「不知道接口长什么样」，解决不了「同一件事写两遍」。
我见过最典型的一份接口文档挂在 Confluence 上，最后一次更新是两年前。前端新人照着它写了两天，联调时发现四个字段名全变了，还有一个接口已经拆成两个。那两天等于白干，事后也没人觉得这是流程问题。
接口先定下来，后面才有地方可依
我现在的习惯是动手之前把接口写成文件，五项写清楚：
| 项 | 例子 | 漏了会怎样 |
|---|---|---|
| 路径和方法 | GET /api/orders/export |
前端凭感觉拼，拼错一次调半天 |
| 字段名和类型 | orderNo: string |
就是开头那个 bug |
| 必填还是可选 | status?: number |
后端返 null，前端按必填处理，页面白 |
| 时间格式 | 2026-10-21T10:33:13+08:00 |
new Date() 直接 Invalid Date |
| 错误码 | {"code": 40001, "msg": "..."} |
前端不知道 500 该弹什么 |
联调扯皮的一大半就在这五项上。缺哪项，两边各猜一个，猜出来肯定不一样。
而且写成文件以后，机器能读。只存在于脑子里的约定，工具接不过去。
把这一步提到生成之前
用飞算 JavaAI 做这个导出功能，流程是这样。
先跑 /前后端设计。它读上游的需求文档，产出数据库设计和 API 接口设计，再依据接口设计文档做前端页面设计。顺序是有讲究的：页面是接口的下游，接口还没定就画页面，画完一定得返工。三份产物落在项目的 docs/ 目录，是仓库里的文件，跟 Git 一起走，不是聊天窗口里翻两下就没了的东西。
接下来两个仓库一起改。前提是把前后端挂进同一个 IntelliJ IDEA 工作区：IDEA 2025.2 起支持，装 Multi-Project Workspace 插件，把 order-service 和 admin-web 都加进去。原项目的 pom.xml、package.json 一个字节不动，两个 Git 仓库还是各管各的。
挂好之后智能会话能同时看见两边。我把需求丢进去，「订单列表加导出，包含已取消的订单，按创建时间倒序」，后端出 Controller、Service、Mapper，前端同时把 api/order.ts 里的方法、页面上的按钮、传的参数一起改掉。路径和字段名都是同一次生成里定的，没有第二次抄写。
省下来的不是切窗口那几秒，是那份「前端还需要改什么」的清单。清单不存在，就没有抄错的机会。
模型分两栏。一栏是插件里的极速、深度、专家、基础，在 Java 领域表现好的开源模型上调优封装出来的，调的东西偏 Java：工程结构、框架约定、接口和表结构怎么定。另一栏直连第三方，智谱的 GLM-5.2、5.3，DeepSeek-V4 的三个版本，都能选。这一栏不补能力，作用是不让你换个插件就重新赌一次。
它不管联调。服务各起各的，跨域自己配，接口通了之后业务逻辑对不对还是人看。
联调那几个小时还在，查的东西换了
原来联调的第一个小时基本在查「为什么通不了」：字段名、类型、返回结构拆了几层、日期是字符串还是时间戳。这些查完才轮到业务。
现在这一段前移了。时间落在真正要人判断的地方：导出该不该包含已取消的订单、金额含不含运费、十万条数据会不会把内存撑爆、收货手机号是 null 的时候那一列显示什么。
上周那个导出接口，跑通只花了二十分钟。剩下两小时都在确认这几件事，没有一件是文档里写得出来的，得业务方拍板。
这些工具替不了。它们要的不是代码，是业务上的决定。
还有一处也省事：代码评审。跨两个仓库的改动，评审最怕前后端各看一边，谁也不知道两边的字段对没对上。约定先在文件里过一轮，评审的人至少有个东西可对，不用从头猜哪边是对的；真对不上，还能翻到当初定这份接口的那次提交。
通用 AI 编码方式也能改这些代码。把前端贴进对话，它照样写得出来。卡住的地方是它只在一个仓库里看东西：贴什么它看什么，不贴就不知道，下个需求重新贴一遍。飞算 JavaAI 把两个项目放在同一个工作区里，接口定义在生成之前就落成文件，两边读到的是同一份，中间也没有第二个人在传话。
模型几个月换一版，插件里那几档也会跟着换。工作区里那条关系装一次就一直在。
你们现在的接口定义，是落在仓库里的文件，还是某个人当时在群里说的一句话？
