写后台页面时，我最怕的一种顺序，是先让 Codex 把列表、表单、分页都写出来，最后才接接口。

页面静态数据跑得很顺，一接后端就开始散。列表拿不到数据，分页总数对不上，状态显示错位，错误提示一会儿弹出来，一会儿被吞掉。单看前端，每一段代码都像有道理；往接口结构上一对，问题就露出来了。

Codex 没有先读懂后端返回结构，它只能按常见写法猜。

前端拿到的不是接口文档，是一组约定

在 java-springboot 这份 Skill 里，后端接口有一套固定风格。返回值走 ResultEntity<T>，里面通常有 code、message、data。分页参数会用 ParamsVo，常见字段是 current、size 和一个承载查询条件的 data。列表接口可能叫 /page_list，保存接口可能叫 /save，状态更新可能叫 /update_state。

这些内容看起来是后端规范，其实会直接影响前端写法。

前端如果默认接口直接返回数组，就会写成 res.data 是列表。可统一响应包了一层以后，真正的数据可能在 res.data.data。分页接口如果返回 MyBatis-Plus 的分页对象，列表在 records，总数在 total，当前页和每页数量也有自己的字段。Codex 如果没拿到这些约定，就很容易把页面状态接到错误的位置。

这类问题不靠多写几句“请实现列表页”解决。任务开始前要先把接口契约拿出来。

我会先问四个前端问题

看到一个后端规范，我不会急着让 Codex 生成页面。我会先让它回答四个问题。

第一，成功响应的数据入口在哪里。

统一响应结构出现以后，前端要知道业务数据到底从哪一层取。是 data 本身，还是 data.data，或者项目请求封装已经把外层剥掉了。这个问题不确认，后面的列表、详情、下拉选项都会接错。

第二，分页字段怎么对应页面状态。

前端关心的是当前页、每页数量、总数和列表数据。后端关心的是分页对象、查询参数和 SQL 结果。两边字段名不一定一致。Codex 需要先把 current、size、records、total 这些字段和页面里的分页组件对上，再写翻页逻辑。

第三，状态值由谁翻译。

Skill 里有 state、del 这类字段，也有状态码常量。前端不能只看字段名就显示“启用”“停用”。它要知道值是字符串还是数字，1 和 2 各代表什么，未知值怎么兜底，删除标记是否应该出现在页面筛选里。

第四，失败响应怎么进入页面。

统一异常处理会返回错误码和消息。前端要决定哪些错误只弹提示，哪些错误要保留旧数据，哪些错误要把按钮 loading 关掉并允许重试。如果 Codex 只按 catch 里弹一个错写完，异常路径会很薄。

这四个问题答不清，页面先别写。

后端 Skill 不能直接变成前端代码

这里要有一个边界。java-springboot 是后端代码规范，它能告诉 Codex 后端项目怎样分层、接口怎样返回、分页参数怎样传。它不能替前端决定页面交互，也不能替代 Vue 项目里的请求封装。

我更愿意把它当成一份接口线索。

它告诉我后端大概率怎么组织结果，前端还要回到项目里查真实请求工具。比如项目里有没有统一拦截器，成功响应是否已经被解包，错误消息是否由全局方法处理，分页组件是否已经封装了字段映射。后端规范和前端封装要对上，才能交给 Codex 实现。

如果只读后端 Skill，不读前端项目，Codex 会把后端字段生搬硬套到页面里。反过来，如果只读前端页面，不看后端约定，它又会按旧页面的接口形状猜新接口。

联调最稳的做法，是把两边都变成证据。

交给 Codex 的任务要换一种写法

我现在不会这样写任务。

帮我写一个用户列表页，接口已经有了。

这句话把最容易出错的地方全藏起来了。Codex 会自己补接口形状，也会自己补分页结构，补出来的东西未必和项目一致。

我会改成这样。

先根据后端规范和前端请求封装抽取接口契约。
需要确认成功响应入口、分页字段、状态码含义、失败响应处理方式。
契约确认后，再改列表页。
不确定的字段先标为待确认，不要直接写死。

这段任务没有让 Codex 立刻写页面，而是先让它交一份可检查的接口契约。契约过了，页面实现才有依据。契约没过，我能在它动代码前纠偏，代价小很多。

验收时不要只看页面有没有数据

接口联调的验收，我会看五件事。

列表数据是否来自正确入口。分页总数是否来自后端分页对象。查询参数是否按后端 ParamsVo 的要求组装。状态值是否按项目字典或常量翻译。失败时页面是否关闭加载状态，并保留可以继续操作的出口。

这些都验完，页面上能看到数据才有意义。否则“有数据”可能只是碰巧字段名对上了，下一次换接口就会坏。

java-springboot 这类 Skill 对前端的价值，就在这里。它不是让前端工程师去写后端分层，而是让 Codex 在联调前知道接口背后有结构。结构清楚，页面代码才不会一路靠猜。

下一篇我会把这件事落成一份更具体的模板：怎样从 java-springboot 的后端规范里抽出前端可用的接口契约，并交给 Codex 执行。

本系列持续更新。推荐每个 skill 时，我仍然只看一件事：它能不能让 Codex 的前端产出更可控。