进入具体前端场景以后我最不愿意用的一句验收结论是页面已经出来了搜索、表格和分页也能用。这句话只能证明主路径暂时走通不能证明页面结构经得住下一次修改。后台列表看起来很固定上面放搜索条件中间放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 多解释而是把结构问题提前暴露出来。如果这些问题还说不清我不会让它继续堆表格列。因为列配置改起来通常不难状态归属和调用关系一旦写乱后面每个需求都会放大返工。写在最后后台列表真正的复杂度不在于会不会写el-table而在于搜索、分页、接口、操作和项目封装能否组成一条稳定的数据流。我先查六个结构问题实际上是在确认三件事谁负责、状态从哪里来、变化最终回到哪里。下一篇我会继续往前一步不让 Codex 凭通用经验猜列表结构而是要求它从相邻页面、公共组件、组合函数和接口封装中找出这个项目真正采用的列表页范式。本系列持续更新接下来会围绕 Vue3 与 Element Plus 后台列表把前两周形成的 AI 协作闭环放进具体页面结构中验证。参考资料OpenAI Codex 用例理解大型代码库追踪请求流并定位相关模块