写完几篇接口契约以后，下一步自然会碰到移动端页面。

我不太愿意让 Codex 直接把 Web 后台那套经验搬到 UniApp。后台页面常见的是搜索表单、表格、分页器和弹窗按钮。UniApp 页面面对的是手机屏幕、页面生命周期、下拉刷新、触底加载、返回行为和系统弹框。两边都用 Vue，代码感觉很近，实际约束差得很远。

这种差距如果一开始不讲清楚，Codex 会按它最熟的 Web 写法动手。页面可能能显示，交互会别扭。

移动端页面先看容器

uni-wx 这份 Skill 里，页面容器不能随便写一个 <view> 开始。它明确要求优先使用 xt-page 和 xt-nav。列表空状态有 xt-noData，图片展示有 xt-img，表单输入有 xt-ipt 和 xt-iptSel。

这类约束对 Codex 很重要。

如果任务只说“写一个列表页”，Codex 很可能自己写导航、自己写空状态、自己写图片容错。代码看着完整，却绕开了项目已有组件。后面要统一导航高度、空状态样式、图片预览和底部留白时，这一页就成了孤岛。

移动端页面第一步要先接上项目的页面外壳。外壳接对了，导航、安全区、下拉刷新和底部空间才有共同入口。布局可以往后排一点。

列表逻辑不能照搬分页器

Web 后台列表经常围绕分页器写。点第几页，请求第几页，分页组件把当前页和总数展示出来。

移动端列表更常见的动作是刷新和继续加载。用户下拉，页面回到第一页；用户滑到底部，请求下一页；请求期间要防重复触发；没有更多数据时要停住；接口失败时还要恢复到可继续操作的状态。

uni-wx 里对 xt-page 的说明已经把这些线索放出来了。它有 downRefreshFn、scrollBotFn、listData 和 pageObj 这类约定，列表逻辑也推荐复用 useTableMixin。

我会让 Codex 先确认这些项目约定，再写列表。

它不能只把 Web 后台里的 current、size 和查询按钮搬过来。移动端要回答的是用户手指怎么触发刷新，触底时怎么判断还能不能加载，刷新和加载更多同时发生时谁优先，失败后列表是保留旧数据还是清空。

这几件事没确认，列表迟早会乱。

反馈方式也要换一套判断

Web 后台里，错误提示、确认弹窗、按钮 loading 常常依附在组件库上。到了 UniApp，项目通常会把提示和加载统一封装成 mess、loading、showModalFn 这些方法。

uni-wx 对这一点写得很清楚。Toast 走 mess，Loading 走 loading，Modal 走 showModalFn，页面跳转走 navigateFn 这类封装。

Codex 如果直接写 uni.showToast 或 uni.navigateTo，功能大概率能跑，可它没有遵守项目入口。以后要统一提示时间、遮罩、跳转前处理、错误文案，这些散落的原生调用就会变成负担。

我给 Codex 的要求会更具体。移动端页面里，提示、加载、确认和跳转先查公共方法；项目已有封装时，页面不直接调用原生 API。这个要求比“代码规范一点”有效得多。

生命周期是移动端最容易混的地方

UniApp 页面还有一个 Web 后台不太一样的点，页面生命周期。

页面文件里可以用 onLoad 接收参数并做首次请求，用 onShow 处理每次显示时的刷新，用 onReachBottom 做触底加载。普通组件里不能写 onLoad、onShow 这些页面级钩子。组件只负责展示、局部状态和事件抛出。

Codex 很容易把这块写混。

它可能把接口请求塞进公共组件，也可能在组件里写页面参数处理。这样短期能看到数据，长期会让组件越来越重。一个列表项组件本来只该展示标题和时间，结果它自己拉接口、自己跳转、自己处理刷新，页面边界就被拆散了。

我会让 Codex 在动手前先说明页面级行为和组件级行为怎么分。接收页面参数、首次请求、再次显示刷新、触底加载、返回前拦截，这些留在页面。列表项、图片、输入框、弹窗内容，尽量做成组件或复用已有 xt- 组件。

交给 Codex 前先改任务说法

我不会这样写移动端任务。

照后台列表做一个 UniApp 列表页。

这句话会把 Codex 带回 Web 后台思路。

我会改成这样。

先按 uni-wx 规范确认页面容器、导航组件、列表刷新触底、反馈封装、页面生命周期和业务文件拆分。
确认当前项目是否具备 xt-page、xt-nav、xt-noData、useTableMixin、mess、loading、navigateFn。
缺失项先记录，不要自己造一套替代实现。
确认后再写页面。

这个任务的重点，是让 Codex 先找项目现有入口。移动端页面不能只换一套标签名，它要接住项目的容器、反馈、生命周期和文件组织。

我最后看什么

验收 UniApp 页面时，我会先看页面有没有走 xt-page 和 xt-nav，列表空状态是否复用 xt-noData，分页是否接入项目的刷新和触底约定，提示和加载是否走公共封装，页面参数和刷新逻辑是否放在页面生命周期里。

这些检查通过以后，我才看页面内容写得是否完整。

uni-wx 对 Codex 的价值，就在于把移动端项目里那些容易被 Web 经验盖住的规则提前亮出来。Codex 可以继续写代码，但它要先知道手机页面的运行方式和后台表格不一样。

下一篇我会把这件事压成一份移动端上下文清单，交给 Codex 前先补齐，再让它开始实现。

本系列持续更新。每次推荐 Skill，我都只问一个问题，这份规则能不能让 Codex 少猜一点，多按项目真实方式工作。