Codex 实战二：从需求到可验收的订单筛选

以订单列表筛选为例，把功能需求拆成实现步骤、边界状态和可验证的交付。

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

返回教程库

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

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

“帮我加一个搜索功能”很容易得到一个能输入文字的界面，却没有约定搜索范围、分页和清空行为。这一课用订单列表筛选，演示怎样把业务需求变成 Codex 可以实现、你可以验收的任务。

把行为写清楚

本例约定按订单号和状态筛选。关键词去掉首尾空格；纯空格视为无关键词；点击查询或按回车提交；改变筛选条件后回到第一页；清空后恢复默认列表。实际业务若要求模糊搜索或实时搜索，应先写明规则。

还要确认筛选发生在服务端还是前端。服务端分页只把当前页交给浏览器，在当前页过滤会漏掉其他页的匹配订单。不要让 Codex 根据界面自行猜测数据来源。

第一步：调查现有实现

先发送下面的提示词。此阶段的产出是一份短方案，便于你发现业务约定与现有接口是否冲突。

请调查订单列表页面、请求封装、后端查询和已有测试。
暂不修改文件。找出分页由前端还是服务端执行，
现有接口支持哪些筛选参数，是否有可复用的表单组件。
阅读项目说明与检查配置，给出实际可用的验证命令。
按“需要修改的文件、实现步骤、需要确认的接口限制”输出短方案。

如果只有前端源码、接口又不支持筛选，先明确这个限制。可以补齐后端能力，也可以调整需求；不能把当前页筛选当作全量搜索交付。

第二步：给出完整任务

确认方案后，把目标、约束和验收条件合并成一次实现请求。以下示例假设项目已有对应接口能力。

请实现订单号和状态筛选，使用项目现有接口参数与组件。
规则：关键词去掉首尾空格，空字符串不作为筛选条件；
点击查询或按回车提交；新查询回到第一页；
清空时移除关键词和状态，恢复默认列表及第一页；
翻页继续携带已提交的筛选条件。
沿用加载、错误、空结果反馈，不新增依赖，不改变公开接口结构。
保留已有修改，不提交、推送或部署。
完成后执行相关检查，并给出行为验证结果与未验证项。

这里特意区分“输入中的内容”和“已提交的条件”。如果用户改了一半关键词就点击下一页，页面应按约定处理，不能让输入框与请求条件无意混在一起。

第三步：检查状态组合

筛选不是单个输入框的问题。它会同时影响列表数据、总数、当前页和空状态。用少量具体场景验证，比只看截图更容易发现遗漏。

操作	预期结果
第三页输入订单号并查询	请求第一页，返回匹配订单
输入纯空格并查询	按无关键词处理
筛选状态后翻页	后续请求保留同一状态条件
点击清空	条件清除，回到默认列表第一页
查询不存在的订单号	展示空结果，总数和分页一致

如果页面允许快速连续查询，还要考虑响应顺序：先发的慢请求不能覆盖后发查询的结果。让 Codex 先检查项目是否已有处理方式，再决定是否需要改动。

请按上表验证本次功能，重点检查请求参数、列表总数和页码。
发现问题时先解释触发条件，再做必要修复。
有现成测试设施时补充能捕获这些行为的测试；
没有设施时完成可复现的手工检查，不额外引入测试框架。

验收清单

订单号与状态可以组合使用，规则与需求一致。
查询重置页码，翻页保留筛选，清空恢复默认状态。
加载失败与空结果有不同反馈，列表总数正确。
检查命令确实存在并已执行，手工验证记录了操作和结果。
改动范围集中，没有无关重构或新增依赖。

常见问题

页面显示正常，为什么还要检查请求

少量测试数据可能掩盖分页错误。检查请求中的页码和筛选参数，才能确认行为对多页数据也成立。

需求中途变了怎么办

明确告诉 Codex 哪条规则被替换，并要求同步更新实现与验收条件。例如从“点击查询”改为“输入后延迟查询”，就要重新检查请求频率与响应顺序。

可选分析设置