上一篇把问题讲清了。移动端列表分页容易乱通常乱在刷新、触底和请求状态没有先定规则。这篇我把它压成一份可以交给 Codex 的任务模板。模板不负责替项目做决定它负责逼 Codex 先查证据再写代码。先查已有列表页我不会让 Codex 上来就写current、size、hasNext。这些字段在uni-wx里有推荐写法但目标项目未必完全一样。先查已有列表页才知道项目真实使用的是哪套状态。任务可以这样写。先查当前项目已有 UniApp 列表页。 确认是否使用 xt-page、useTableMixin、listData.pageObj、xt-noData。 记录 current、size、total、hasNext、requestState 的真实字段名和更新时机。 无法确认的字段标为待确认不要直接补一套新状态。这一步做完Codex 才知道自己是在复用项目规则还是需要按uni-wx的通用规范补齐缺口。刷新规则要先落下来刷新规则要写得很具体。项目推荐让 Codex 说明触发入口downRefreshFn、页面下拉刷新或项目已有回调页码刷新时回到第一页列表是否立即清空旧列表更多数据刷新时重置hasNext请求状态刷新期间如何设置requestState失败恢复失败后是否保留旧列表刷新动画如何结束这里有一个取舍。刷新时是否清空旧列表没有唯一答案。数据敏感的页面可能希望清空后再展示新结果普通信息流可能更适合保留旧列表直到新数据回来。Codex 不能自己替项目做这个取舍。任务里要么明确给出规则要么要求它参考已有页面。没有依据时写“待确认”。触底规则要防住重复请求触底规则主要防两件事重复请求和无更多数据还继续请求。我会把任务写成这样。触底加载前先检查 requestState 和 hasNext。 正在请求时直接返回。 hasNext 为 false 时直接返回。 下一页请求成功后再拼接列表并更新 total、current、hasNext。 下一页请求失败时保留旧列表并保证下一次触底仍能请求正确页码。这里最关键的是当前页更新时机。Codex 要么采用成功后更新要么采用请求前更新并在失败时回滚。两种写法都要在任务记录里说明。它不能只写“加载更多失败提示一下”因为页码已经可能变了。空状态要和请求状态一起看空状态要和请求状态一起看。我会让 Codex 写出这张表。条件页面表现首次请求中展示加载不展示xt-noData首次请求成功且列表为空展示xt-noData刷新请求中且已有旧数据保留旧列表或按项目规则处理触底请求中列表底部展示加载状态不清空列表请求失败且列表为空展示错误提示或重试入口请求失败且已有旧数据保留旧列表提示失败这张表能避免一个常见写法直接用list.length 0判断空。这个判断太粗了。空列表、加载中、失败后无数据在视觉上都可能是空但页面含义完全不同。xt-noData只负责统一展示正常空状态。错误和加载要走自己的状态。最后再交完整任务整合以后我会把任务写成这样。按 uni-wx 规范实现一个 UniApp 列表页。 开始前先查已有列表页和 useTableMixin确认 xt-page、listData.pageObj、xt-noData 的真实用法。 先输出列表状态规则表覆盖刷新、触底、首次加载、无更多数据、请求失败和空状态。 规则确认后再写代码。 页面请求、分页和数据转换优先放到当前页面 service 文件页面只保留生命周期和调用入口。 提示使用 mess加载使用 loading跳转使用 navigateFn。 样式使用 rpx、SCSS 变量和项目原子类。这段任务的价值在于把实现顺序改了。Codex 先交规则再写代码。规则里说不清的地方先停在规则层不要用代码猜。我会怎样验收这份实现实现完成后我会按动作验收。先看代码有没有复用项目入口。xt-page、xt-nav、xt-noData、useTableMixin或已有列表服务是否按项目方式使用。再看状态迁移刷新、触底、失败和空状态是否能从代码里找到对应处理。然后看连续操作。第一页加载成功后下拉刷新。刷新未结束时触底。触底加载时再次触底。接口返回空列表。接口返回失败。列表已有数据时下一页失败。这些动作都过了列表分页才算完成。只跑通首次加载移动端列表还远远不够。这类规则适合写进 Skill 吗如果一个项目长期使用 UniApp而且多个页面都走同一套xt-page、useTableMixin和pageObj这类规则很适合继续沉到项目 Skill 或项目指令里。但我不会把所有细节一次塞进去。先沉公共稳定的部分比如公共组件、公共方法、生命周期边界、列表状态字段。某个页面特有的刷新策略留在当前任务里就够了。Codex 需要稳定规则也需要当前任务的具体决定。两者分开移动端列表才不会越写越重。下一篇会继续沿着uni-wx写移动端反馈拆 Toast、Loading、Modal 在真实页面里怎么分工以及为什么反馈冲突会让页面看起来不可靠。本系列持续更新。每篇都尽量把一个移动端问题拆到能交给 Codex 执行和验收。