当前位置：首页 > news >正文

AI 写的后台列表能跑，为什么我还是会先查这 6 个结构问题

news 2026/8/12 18:23:27

进入具体前端场景以后，我最不愿意用的一句验收结论是：

页面已经出来了，搜索、表格和分页也能用。

这句话只能证明主路径暂时走通，不能证明页面结构经得住下一次修改。

后台列表看起来很固定：上面放搜索条件，中间放el-table，下面接分页，旁边再塞新增、编辑和删除按钮。正因为结构太熟悉，Codex 很容易根据 Vue3 和 Element Plus 的通用知识，快速拼出一张“像后台列表”的页面。

问题是，它知道通用组件怎么写，却不知道当前项目怎样分配职责。

有的项目把搜索表单单独拆成组件，有的项目由页面统一持有查询状态；有的项目通过tabMixin管理列表和分页，有的项目使用组合式函数；有的接口直接接收查询字段，有的接口要求先做参数转换。

如果这些差异没有先确认，页面越完整，后面的返工范围反而越大。

所以，我审查 AI 生成的后台列表时，不会先纠结表格间距和按钮颜色，而是先查下面六个结构问题。

一、页面组件承担了多少职责

我先看页面文件里同时出现了什么：

搜索表单字段和校验；
列表、总数和分页状态；
请求参数转换；
列表接口与删除接口调用；
新增、编辑、查看弹框状态；
权限判断；
时间、状态等展示格式化；
大量局部样式。

这些内容全部写进一个.vue文件，不一定马上报错，却说明页面已经变成了多个职责的汇合点。

我不会机械地要求“一个区域一个组件”。拆分不是为了让文件数量好看，而是为了让变化边界清楚。我通常按下面三个问题判断：

搜索条件变化时，是否需要理解表格内部实现？
新增或编辑弹框变化时，是否会迫使列表页面一起修改？
另一张列表页能否复用分页、请求和删除流程？

如果答案频繁是“会”，说明职责边界还没有建立。

对当前可用的web-skills规范来说，常见范式是：搜索组件负责表单交互，页面负责组合区域，tabMixin统一列表、分页和删除流程，弹框由useDialogImp管理。这是当前规范中的项目约束，不是所有 Vue3 项目的唯一答案。

真正需要 Codex 做的，是识别目标项目采用了哪一种结构，而不是默认套用它最熟悉的写法。

二、同一份状态是否出现了多个“主人”

后台列表最容易复制的状态有三类：搜索条件、当前页和每页条数、列表加载状态。

例如，搜索组件里有一份form，父页面里又有一份queryParams，请求函数里再拼一份临时对象。三个对象字段相似，却没有明确谁是最终事实来源。

这时会出现很典型的现象：

输入框显示的是新条件，请求发出的还是旧条件；
点击重置以后表单清空了，分页查询仍带着上一次参数；
翻页时使用父页面保存的条件，再次查询时却使用子组件的新值；
修改每页条数后页码没有归一，得到空列表。

我会给每类状态明确一个负责人：

状态	需要确认的问题
搜索编辑态	用户正在输入但尚未查询的值由谁持有
已提交查询态	翻页和刷新时实际复用哪一份条件
分页态	当前页、每页条数和总数由谁统一修改
列表态	数据、空状态、错误状态和加载状态由谁维护

AI 经常把“能访问到状态”误当成“应该拥有状态”。我更关心的是：修改入口是否唯一，调用链是否看得懂。

三、界面字段和接口字段是否直接绑死

搜索表单里的字段，是为了方便用户编辑；接口参数，则要满足后端契约。两者经常不是同一种形状。

日期范围就是一个常见例子。界面组件可能需要：

form.createTime = ["2026-08-01 00:00:00", "2026-08-12 23:59:59"];

接口却可能要求：

{ startCreateTime: "2026-08-01 00:00:00", endCreateTime: "2026-08-12 23:59:59" }

如果 Codex 直接把表单对象交给接口，短期看只是多传一个字段；长期会把界面状态、接口契约和重置逻辑绑在一起。

我会要求参数转换集中在明确的边界完成，并检查三件事：

临时界面字段是否会误传；
空字符串、空数组和undefined是否符合接口约定；
转换是否修改了原始表单对象。

当前web-skills中的时间范围处理和tabMixin参数组装，正是在处理这类边界。上面的字段只是结构示意，实际名称仍要以目标项目和接口契约为准。

四、获取列表是否存在多个请求入口

一张列表页至少会在这些时机请求数据：页面初始化、查询、重置、切换页码、修改每页条数，以及新增、编辑或删除成功之后。

如果每个事件都自己调用接口、自己拼参数，页面里很快就会出现多个“差不多”的请求入口。

我会追问：

无论从哪里触发，最后是否都进入同一个列表获取函数？

这个统一入口不一定叫getList，但它至少应该统一完成：

合并已提交查询条件与分页参数；
调用列表接口；
更新列表和总数；
处理加载结束；
输出可判断的成功或失败结果。

统一入口的意义不是少写几行代码，而是让查询规则、分页规则和异常处理只有一个落点。否则 AI 修正某个入口时，其他入口仍可能保留旧行为。

五、行操作有没有形成完整闭环

Codex 很容易把操作列写得很完整：查看、编辑、删除按钮一个不少。但“按钮能点击”只完成了入口，远没有形成闭环。

查看要确认是否只读、是否需要请求详情、关闭时是否产生无意义刷新。

编辑要确认传入的是行对象引用、浅拷贝，还是只传 ID 后重新获取详情；编辑过程中会不会直接污染表格当前行；保存成功后是否按既定规则刷新。

删除要确认是否有二次确认、权限是否沿用项目指令、删除当前页最后一条后怎样处理页码、接口失败时是否保留现有数据。

这些都不是 Element Plus 能替项目决定的业务规则。AI 可以按已知规则实现，但人必须先确认规则来自哪里。

六、有没有绕过项目已经存在的封装

这是我最常见、也最先阻止的一类结构问题。

项目已经有搜索按钮组件、分页组件、请求封装、权限指令和列表组合函数，AI 却又写了一套：

直接使用新的ElPagination参数；
自己创建 Axios 实例；
用普通布尔值重复实现全局 Loading；
用条件渲染替代已有权限指令；
手写删除确认，绕过统一消息组件。

单看局部，这些写法可能都成立；放回项目，它们会制造第二套规则。

我判断是否应该复用，不只看“项目里有没有同名组件”，还会看：

相邻列表页是否稳定使用它；
封装是否承担了隐藏契约，例如权限、加载状态和参数转换；
当前需求是否确实超出了封装能力；
绕过封装会不会让交互和错误处理不一致。

如果现有封装不适用，也不能让 Codex 悄悄绕过。它应该先说明差异、影响范围和替代方案，再由人决定是扩展封装还是局部例外。

我会先让 Codex 交一张结构检查表

在它继续补功能之前，我会要求先回答：

## 后台列表结构检查  1. 页面由哪些区域和组件组成？ 2. 搜索态、已提交查询态、分页态和列表态分别由谁持有？ 3. 表单字段在哪里转换为接口参数？ 4. 初始化、查询、重置、翻页和操作成功是否共用请求入口？ 5. 查看、编辑、删除各自怎样完成闭环？ 6. 项目已有的列表、搜索、分页、弹框、请求和权限封装有哪些？ 7. 当前方案有哪些地方没有沿用项目范式？为什么？

这张表不是为了让 AI 多解释，而是把结构问题提前暴露出来。

如果这些问题还说不清，我不会让它继续堆表格列。因为列配置改起来通常不难，状态归属和调用关系一旦写乱，后面每个需求都会放大返工。