上一篇讲了一个判断：前端接接口前，Codex 要先读懂后端返回结构。

这篇继续往下落。我会把 java-springboot 这类后端 Skill 里的内容，压成一份前端能用的接口契约。它不追求完整覆盖后端所有分层，只关心页面会真正碰到的那几类约定。

这份契约越早出来，后面的列表、表单、分页和错误处理越少返工。

第一块，响应外壳

后端统一返回 ResultEntity<T> 时，前端最先要确认外壳长什么样。

我会让 Codex 先写清楚这些字段。

项目	需要确认的内容
成功码	哪些 code 表示成功
消息字段	错误提示来自 message 还是别的字段
业务数据	真正的数据在响应的哪一层
前端封装	请求工具是否已经解开外壳

这里最容易出错的是最后一项。后端规范说返回 code/message/data，不代表页面代码一定要写 res.data.data。很多前端项目会在请求拦截器里处理一层。Codex 必须先查当前项目的请求封装，再决定页面里取哪一层。

如果这一项没有查，我会要求它停止实现，只交“待确认”。

第二块，分页契约

列表页的问题常常挂在分页上。

java-springboot 规范里会出现 ParamsVo，常见参数是 current、size 和查询条件 data。MyBatis-Plus 分页结果里通常会有当前页、每页数量、总数和记录列表。前端要做的事，是把这套结构和页面分页组件对齐。

我会让 Codex 交这样一张表。

前端状态	后端字段或来源	处理方式
当前页	current	新查询回到第一页，翻页按组件事件更新
每页数量	size	改变后重新请求，并处理第一页规则
列表数据	待确认，如 records	不确认前不写死
总数	待确认，如 total	用于分页组件展示
查询条件	data 或普通参数	按项目请求封装决定是否序列化

这张表的价值不在形式，在于它逼 Codex 把字段来源说清楚。它如果写“从接口返回中获取列表”，我会让它重写。返回中哪里，字段名是什么，前端封装是否改过，这些都要落到具体位置。

第三块，状态与字典

后台页面离不开状态字段。state、del、status、type 这些字段看起来都普通，实际最容易显示错。

我会让 Codex 分三步处理。

先查后端规范或常量，确认状态值的含义。比如 state 可能用 1 表示启用，用 2 表示停用；del 可能用来区分删除和未删除。

再查前端项目里有没有字典、过滤器或公共组件。项目已经有状态标签组件，就不要在当前页面重新写一份映射。

最后给未知值兜底。接口返回新状态时，页面至少要显示原始值或“未知状态”，不能直接空白，也不能把未知值归到某个正常状态里。

状态这块，我不让 Codex 自己猜文案。文案要来自后端注释、接口文档、前端字典或产品明确给出的规则。

第四块，提交与异常

表单提交前，也要抽契约。

保存接口走 /save，状态更新走 /update_state，这类路径只是线索。前端还要确认请求方法、参数位置、成功后的刷新动作和失败后的恢复动作。

我会让 Codex 写出四项。

动作	需要确认
新增或编辑	用同一个接口还是分接口
参数来源	表单字段是否要转换成后端字段
成功后	关闭弹窗、刷新列表、保留查询条件
失败后	关闭按钮加载、保留表单、展示错误消息

这一块会直接影响用户操作。保存失败后表单被清空，或者按钮一直转圈，用户看到的是前端问题；根子可能是 Codex 没把异常契约写清楚。

我会这样交给 Codex

真正执行时，我会把任务压成一段很短的指令。

读取 java-springboot 规范和当前前端项目请求封装。
先输出接口契约表，覆盖响应外壳、分页字段、状态字典、提交与异常。
每一项标明证据来源，无法确认的写待确认。
契约通过后，再改页面代码。

这段指令的关键，是把“先输出契约表”放在改代码前面。Codex 一旦先动了页面，后面发现字段错了，就会连着改状态、分页和错误处理。先抽契约，错也错在纸面上。

验收这份契约

契约交出来以后，我会看三类问题。

第一类是来源缺失。字段写得很完整，却没有说明来自后端 Skill、接口文件、请求封装还是已有页面，这种契约不能用。

第二类是前后端混用。后端规范里的字段直接塞进页面状态，没有检查前端是否已经封装过响应，这种写法风险很高。

第三类是待确认项被悄悄写死。契约里标了待确认，代码里却直接按猜测实现，这是我最不能接受的情况。

通过这三类检查，java-springboot 才真正帮到了前端。它让 Codex 先看到后端结构，再回到前端项目里找承接点。两边都确认以后，页面实现才开始。

下一篇我会继续推荐下一个辅助 Skill，把视角从接口契约拉回到前端项目本身，讨论 Codex 在移动端和 Web 页面之间切换时，为什么不能直接复用同一套写法。

本系列持续更新。工具会换，检查方式不换：先看它补哪一类质量，再看它能不能被验证