修复bug后必须添加回归测试,否则问题会复现;codex需明确上下文和验收标准才能生成可运行、可验证、能进ci的测试用例,且须经复现失败、修复验证、ci集成三步闭环。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜

修复完 Bug 后不加回归测试,等于没修——下次合代码、改配置、升级依赖,问题立刻复现。Codex 本身不会自动补测试,但只要你给它明确的上下文和验收标准,它就能生成可运行、可验证、能进 CI 的回归测试用例。
先确认 Bug 是否已稳定复现
打开终端,执行原始复现命令或脚本,确保错误稳定出现。例如:npm test -- --testNamePattern="checkout duplicate order"。如果测试根本跑不起来或报错路径不对,Codex 生成的回归测试会从根上失准。
这一步不能跳过。Codex 不会帮你猜“原来应该什么样”,它只对【你亲眼看到的失败现象】做响应。没看到失败,它就默认“没问题”,后续所有测试都可能绕开真实路径。
通过本地 Codex 或 OpenClaw OAuth 凭证直接调用 ChatGPT/Codex Responses 的 image_generation 工具来生成或编辑光栅图像,然后保存
告诉 Codex 具体要验证什么
在 Codex 输入框中粘贴三段内容:原始失败日志(含堆栈)、最小复现步骤、预期正确行为。格式如下:
``` 【失败日志】 Error: Duplicate order created on double-submit at createOrder (src/api/order.ts:42:15)
【复现步骤】
- 进入 checkout 页面
- 填写有效表单
- 快速连续点击“提交”按钮两次
- 检查后端订单数 → 实际创建了 2 条
【预期行为】 无论点击几次,只应创建 1 条订单;第二次点击应被忽略或提示“处理中”
相关文章
Muse Wonder Full怎么清理冗余代码并验证结果
GPT-6怎么使用批量处理任务
Codex CLI修改配置后为什么没生效
Codex怎么在接口变更后同步修改页面
Codex怎么测试异常处理是否生效
本站声明:本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系admin@php.cn










