上一篇把问题讲清了。移动端列表分页容易乱，通常乱在刷新、触底和请求状态没有先定规则。

这篇我把它压成一份可以交给 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 执行和验收。