Codex 实战三：从复现问题到验证修复

从复现步骤找到根因，实施最小修复并通过回归检查验证结果。

适用范围：涉及账户、Key、模型、计费或接口的内容，请以 GPT88 当前控制台和对应 API 文档为准。

GPT88 使用说明 模型名、版本、默认值和平台入口可能随客户端版本变化，请按 GPT88 当前模型目录和客户端显示核对。

快速开始 · 模型导航 · GPT88 API Key 管理

“搜索不好用了”不足以定位问题。有效的排错材料需要说明操作、实际结果和期望结果。这一课以订单列表的空搜索和分页异常为例，走完复现、定位、最小修复、回归四步。

准备一个稳定的复现

假设默认列表有三页以上订单。进入第三页，搜索一个只匹配两条订单的关键词，页面却显示没有结果；清空后又没有恢复默认列表。这是两个可观察的行为，可能相关，也可能分别来自不同原因。

记录浏览器地址、测试账号权限、筛选条件、操作顺序和报错。不要粘贴登录凭证或真实客户资料。网络请求只需保留与问题有关的参数、状态码和脱敏后的响应。

问题：订单列表在第三页发起新搜索后显示空结果。
前提：默认列表至少三页，关键词 DEMO-42 在第一页应匹配两条。
复现：进入订单列表 → 翻到第三页 → 搜索 DEMO-42。
实际：结果为空。期望：新查询回到第一页并显示两条订单。
另一个现象：清空关键词后默认列表没有恢复。
请先复现并调查原因，暂不改代码；记录请求参数与相关调用位置。

上面的关键词只是示例，应替换为本地测试数据中确实存在的订单号。如果无法准备数据，就说明限制，避免把未经验证的推测写成根因。

第一步：定位数据在哪里变化

让 Codex 沿着“表单提交、查询状态、请求参数、服务端分页、响应渲染”逐层检查。重点看新查询是否仍携带第三页，以及清空时是否遗留旧条件。

请分别调查两个现象，不要先假设它们来自同一个错误。
指出条件与页码在哪里更新、请求参数如何构造，
空字符串、缺省参数和纯空格在现有接口中的含义。
每个结论附相关文件位置、请求记录或可重复的检查结果。
证据不足的地方标为待确认，并说明下一步怎样验证。

如果服务端正确返回了空数组，错误仍可能在前端请求了错误页码。相反，如果参数已经正确，就要继续检查服务端过滤顺序、总数计算和缓存条件。

第二步：修复已确认的原因

假设已确认“新查询沿用旧页码”和“清空未移除条件”，可以发出明确的修改请求。让 Codex 改调用链中真正负责这两个行为的位置。

请修复已确认的问题：新查询从第一页开始；
清空操作移除关键词与状态，重新加载默认第一页。
纯空格按无关键词处理，翻页保留已提交条件。
沿用项目当前的参数约定，不修改接口结构，不进行无关重构。
保留其他未提交改动。修复后重跑原复现步骤，
优先使用已有测试设施补充能够捕获本次问题的回归测试。

“最小修复”指改动与根因直接相关，不是盲目追求行数少。只在界面强行显示第一页、实际请求仍用旧页码，并不算修好。

第三步：回归相邻行为

原来的复现通过后，再检查容易被影响的场景。检查应覆盖实际业务行为，而不是只断言某个内部函数被调用。

场景	应检查的内容
第三页搜索少量结果	请求页码为第一页，结果可见
空字符串、纯空格查询	参数符合无关键词约定
清空已组合的筛选	旧条件消失，总数恢复
带筛选翻到下一页	条件保留，页码正确
接口失败后重试	不把失败当空结果，可恢复

先从项目说明、依赖清单或持续集成配置发现验证命令，再运行最相关的检查。不要默认任何项目都有 npm test，也不要把未运行的测试列为通过。

验收清单

原问题有明确复现步骤，修复后同样步骤通过。
根因有代码位置和行为证据，两个现象分别得到解释。
空搜索、清空、分页和失败重试没有回归。
验证报告区分已执行、未执行和受环境限制的项目。

常见问题

Codex 说无法复现，应该继续改吗

先补齐环境、数据和操作顺序。若只能根据代码提出疑点，应把结论标为假设，再用针对性检查确认。

修复后另一个页面坏了怎么办

检查是否修改了共用请求函数或分页组件。把新问题的复现提供给 Codex，要求评估受影响调用方，再决定局部修复还是完善公共逻辑。

可选分析设置