分页错位讲的是状态错位。换到接口失败，麻烦会落在另一个地方。
页面坏了以后，Codex 很容易马上补一个错误提示。这个动作太快了。列表接口失败后页面空白，可能是错误没有被捕获，可能是空状态和失败状态混在一起，也可能是旧数据被清空以后没有恢复。只补一个提示，最多让用户知道坏了，不能说明页面为什么退不回来。
所以我会继续让 systematic-debugging 接管启动阶段。
这篇还是方法演示，不把它写成某个项目已经发生过的事故。任务载体很常见。列表页首屏请求失败，页面只有空表格，没有重试入口，也看不出是没有数据还是接口失败。
任务只描述现象
我给 Codex 的第一段，不带修复方案。
当前任务
列表页首屏接口失败后，页面显示为空表格。用户无法判断是没有数据，还是接口请求失败。当前页面没有明显重试入口。
请先启动任务，不要修改代码，不要直接补错误提示。
按 bug 任务启动模板输出
- 任务身份
- 复现信息
- 错误信息
- 请求与响应检查计划
- 页面状态检查计划
- GitHub Skill 选择
- 未覆盖项我特意写了"不要直接补错误提示"。接口异常问题里，提示只说明用户看到了什么，根因调查还要继续往前走。
如果 Codex 启动回复里第一句就是"我会在 catch 中调用 message.error"，我会让它重写。它还没查清页面为什么空，也没查旧数据有没有被清掉。
启动回复要先抓四类证据
这类 bug 的启动回复，我最看四类证据。
复现信息
- 动作：打开列表页
- 条件：接口返回错误、超时或网络不可用
- 结果：页面显示为空表格
- 预期：页面应区分空数据和请求失败，并给出恢复路径
错误信息
- 控制台是否有异常
- 请求状态码和响应体是什么
- 项目请求封装是否吞掉错误
- 页面层是否捕获失败结果
页面状态
- list 是否被清空
- loading 是否关闭
- errorState 是否存在
- noData 是否只按 list.length 判断
未覆盖项
- 能否模拟接口 500
- 能否模拟超时
- 能否验证登录失效这四类证据写出来，任务才像 bug 修复。否则它只是一次 UI 补丁。
我尤其关心 noData。很多列表页只用 list.length === 0 判断空状态。接口失败后列表也可能是空数组，页面就把失败误认成"暂无数据"。用户看到的是空，开发者看代码也容易以为空状态处理过了。
这里要先调查，不要直接改。
Skill 选择和分页错位相似，但证据不同
换到这个任务，主 Skill 仍然是 systematic-debugging。
但调查证据变了。分页错位查的是页码、请求参数和响应提交。这里要查错误传播、失败状态和页面退化。
GitHub Skill 选择
- 主 Skill：systematic-debugging
- 选择原因：当前是无明确根因的失败路径问题，需要先查错误如何从请求层传到页面层
- 后备 Skill：webapp-testing
- 触发条件：修复后走首屏失败、重试成功、正常空数据三条路径
- 暂不采用 test-driven-development：根因未确定前不先写实现测试
- 排除 web-artifacts-builder：不涉及独立页面生成这里的后备 Skill 我会选 webapp-testing。接口异常最终要回到页面路径。失败怎么显示，重试能不能恢复，正常空数据有没有被误伤，这些都要看页面。
TDD 可以等根因明确以后再进来。比如最后定位到状态转换函数把失败和空数据混在一起，那时再补一个小测试也可以。
我会让 Codex 先画失败路径
这类失败要看路径。
失败路径
- 页面发起列表请求
- 请求封装收到失败响应
- 失败结果传给页面
- 页面关闭 loading
- 页面保留旧数据或设置错误状态
- 页面展示失败说明和重试入口
- 用户点击重试
- 请求成功后恢复列表这条路径里任何一步断了，页面都会退化得不自然。请求层吞错，页面不知道失败。页面一失败就清空 list，旧数据丢了。loading 没关，用户一直等。失败状态和空状态混用，用户以为没有数据。
Codex 要先沿路径查，不要跳到最后一步改文案。
修复前我会要求单一根因假设
启动阶段最后，我会让它给出一个最小验证。
根因假设
- 当前只允许提出一个最可能根因
- 说明证据来自哪里
- 给出最小验证动作
- 验证通过后再提出修复方案比如它可以说，当前最可能根因是页面只用 list.length 区分空状态，没有失败状态。证据来自接口失败后 list 被置空，页面仍展示空表格。最小验证动作是模拟失败响应，观察 noData 和 errorState 的变化。
这比直接写 catch 更稳。它先证明哪一步断了，再动代码。
写在最后
这类 bug 只补提示远远不够。提示只是用户看到的结果，根因可能在请求封装、错误传播、页面状态或退化路径上。
我会让 Codex 先走调试 Skill，把复现信息、错误信息、请求响应、页面状态和未覆盖项交出来。根因没有压到一个假设前，不改代码。
下一篇可以接着这条接口异常任务写收口。修完以后，我会要求 Codex 同时验证首屏失败、重试成功和正常空数据，避免把失败状态修好了，又把真实空状态弄坏。
本系列持续更新，继续围绕 Codex 和 GitHub Skills，把前端 bug 修复从"猜一个补丁"拉回到可验证的路径上。