1. 文档目标这份文档解决的是一个真实工程里特别高频的问题只靠日志能不能让 Codex 帮忙 Debug日志不够时还应该补什么上下文找到根因后怎样继续让 Codex 帮你补验证和回归怎样把“问题定位 - 修复建议 - 回归检查”串成一个完整闭环读完后你应该能够用日志快速启动问题分析在关键位置补齐上下文减少盲猜让 Codex 从日志走到代码、SQL、事务和配置层让它继续输出修复建议、验证步骤和回归清单2. 为什么这三件事必须连起来看很多人现在的使用方式是先贴一段报错让 Codex 猜问题猜完就结束这样的问题是日志可能不完整代码位置可能不明确约束和风险可能没说修复后缺少回归思路所以更好的方式是先用日志启动判断再补关键上下文让判断更稳最后继续补测试回归形成闭环3. 三件事分别解决什么问题3.1 日志 Debug解决快速判断问题发生在哪一步快速缩小排查范围3.2 上下文补齐解决让 Codex 不只是“看报错”而是真正理解问题场景3.3 测试回归解决防止“修了当前 bug但引入新问题”帮你把修复结果走到验证完成4. 推荐的完整闭环1. 提供问题现象与日志2. 让 Codex 判断根因方向3. 补关键上下文4. 再定位代码 / SQL / 配置5. 输出最小修复建议6. 生成验证步骤7. 补回归测试清单8. 最终收口5. 第一步先用日志让 Codex 快速进入问题现场日志是最快的入口但不要只丢一行报错。推荐至少一起给问题目标复现步骤请求参数或输入数据返回结果完整堆栈或关键 SQL示例提示词请帮我定位一个问题。 目标 修复订单分页接口手机号筛选失效问题。 复现步骤 1. 打开订单列表页 2. 输入手机号 3. 点击查询 4. 返回空列表 请求参数 phone13800000000 pageNo1 pageSize10 当前现象 带手机号时返回空数据不带手机号时正常。 日志 / SQL [贴完整日志]6. 第二步先让 Codex 判断问题方向不急着修改在复杂问题上更稳的方式是先让 Codex 判断更可能是哪一层问题排查顺序是什么当前日志还缺什么示例提示词先不要改代码先判断问题方向。 请输出 1. 更可能是参数、Java 逻辑、SQL 条件、事务还是环境问题 2. 最值得优先排查的 3 个位置 3. 如果当前信息还不够请列出还缺什么7. 第三步补关键上下文而不是盲目补更多日志这一步是闭环里的关键转折。如果 Codex 说信息还不够不要继续乱贴而要补高价值上下文相关文件位置典型调用链关键配置约束和风险推荐补法补充上下文 1. 相关文件OrderController、OrderServiceImpl、OrderMapper、OrderMapper.xml 2. 当前项目Spring Boot MyBatis 3. 约束不改接口路径、不改入参结构、不做无关重构 4. 风险SQL 动态条件和分页逻辑不能被破坏8. 第四步让 Codex 从日志继续追到代码和链路这时就不只是“看日志”而是要让它把日志和代码真正连起来。可以让它输出Controller 入口Service 调用链Mapper / XML 位置SQL 条件处理位置示例提示词请基于日志和当前上下文继续把问题追到代码层。 输出 1. 最可能相关的 Controller 2. Service 调用链 3. Mapper / XML 位置 4. 当前问题更可能发生在哪一层9. 第五步让 Codex 输出最小修复建议当问题方向基本清楚后才进入修复建议阶段。推荐要求优先最小修改不做无关优化说明影响范围示例提示词请基于刚才的日志分析和代码定位结果输出最小修复建议。 要求 1. 优先最小改动 2. 不做无关重构 3. 说明影响范围10. 第六步让 Codex 补验证步骤修复建议不是结束还需要验证。推荐验证内容当前问题是否消失关键主路径是否恢复正常相关旧功能是否受影响示例提示词请基于这个修复建议输出验证步骤。 要求覆盖 1. 当前问题验证 2. 正常场景验证 3. 异常场景验证11. 第七步让 Codex 补回归测试清单这是闭环的最后一环。很多时候 bug 修掉了但没有回归后面又会出新问题。推荐让它输出哪些类似场景要回归哪些组合条件要回归哪些公共逻辑可能受影响示例提示词请基于当前问题和修复建议补回归测试清单。 要求 1. 列出必须回归的旧功能 2. 列出相似场景 3. 列出边界和组合场景12. 最推荐的组合输入模板请帮我处理一个问题并按“日志分析 - 上下文补齐 - 修复建议 - 测试回归”的方式推进。 目标 复现步骤 请求参数 / 输入数据 当前现象 返回结果 日志 / 堆栈 / SQL 相关文件 项目背景 约束 风险提示 输出要求 1. 先判断根因方向 2. 如果信息不够明确列出缺失上下文 3. 再给最小修复建议 4. 最后给验证步骤和回归清单13. Java / Spring Boot 项目实战实例场景订单分页接口在带手机号筛选时返回空数据。推荐组合方式第一步先用日志启动分析请帮我定位订单分页手机号筛选失效问题。 复现步骤 1. 打开订单列表 2. 输入手机号 3. 点击查询 4. 返回空列表 请求参数 phone13800000000 日志 / SQL [贴完整异常日志和 SQL]第二步补上下文补充上下文 1. 项目是 Spring Boot MyBatis 2. 相关文件OrderController、OrderServiceImpl、OrderMapper、OrderMapper.xml 3. 不允许修改接口路径和入参结构 4. 不影响其他筛选条件第三步继续要修复和回归请基于当前日志分析结果继续输出 1. 最小修复建议 2. 验证步骤 3. 回归测试清单这样做的价值日志先给方向上下文再给准确性回归清单保证修复闭环14. 事务问题实战实例场景订单提交时库存扣减成功但订单主表偶发保存失败。推荐组合方式先给异常堆栈和关键业务日志再补事务相关代码位置和调用链再让 Codex 判断事务边界、异常吞掉还是调用顺序问题最后补回归验证正常下单异常下单重复提交回滚是否生效15. 联调问题实战实例场景前端联调时新增接口返回 500本地单测正常。推荐组合方式一起给前端操作步骤请求 JSON后端错误日志返回体Controller / ReqVO / Service 位置然后让 Codex 输出更可能是哪一层问题需要补哪些上下文最小修复建议联调验证与回归建议16. 常见误区16.1 误区一只做日志分析不补上下文问题很容易停留在猜测层16.2 误区二只修当前问题不补回归问题可能引入副作用16.3 误区三日志很多但没有结构问题信息噪声太大16.4 误区四问题方向还没判断清楚就直接大改问题风险很高17. 注意事项先用日志启动问题分析信息不够时优先补结构化上下文先判断方向再考虑修改修复建议一定要配验证步骤最后一定补回归清单18. 高质量提示词模板18.1 通用闭环模板请按“日志分析 - 上下文补齐 - 修复建议 - 测试回归”的方式帮我推进这个问题。 目标 复现步骤 请求参数 / 输入数据 当前现象 返回结果 日志 / 堆栈 / SQL 相关文件 项目背景 约束 输出要求 1. 先判断根因方向 2. 如信息不足明确列出缺失项 3. 再给修复建议 4. 最后给验证和回归清单18.2 事务问题模板请按“日志分析 上下文补齐 回归验证”的方式处理这个事务问题。 输出要求 1. 判断更像哪类事务问题 2. 列出还缺哪些上下文 3. 给修复建议 4. 给回滚验证和回归清单18.3 联调问题模板请按闭环方式处理这个联调问题。 要求 1. 先判断更可能是哪一层问题 2. 再指出还缺哪些上下文 3. 再给最小修复建议 4. 最后给联调验证和回归建议19. 团队落地建议如果你想把这套方法推广到团队里建议这样做固化一份“日志 上下文 回归”输入模板让开发和测试统一使用同一套结构把高频问题的闭环案例沉淀成团队示例在 AI 协作规范里明确高风险问题必须补回归清单20. 一句话总结“日志 Debug 上下文 测试回归”的组合版本质上是在把一次性的故障定位动作升级成一套完整的问题分析、修复和验证闭环。21. 快速上手清单先给问题目标和复现步骤再给请求参数、返回结果和完整日志再补项目背景、代码位置、约束和风险先让 Codex 判断方向再让它给修复建议最后补验证步骤和回归清单
Codex 日志 Debug + 上下文 + 测试回归组合版
发布时间：2026/5/19 6:24:49
1. 文档目标这份文档解决的是一个真实工程里特别高频的问题只靠日志能不能让 Codex 帮忙 Debug日志不够时还应该补什么上下文找到根因后怎样继续让 Codex 帮你补验证和回归怎样把“问题定位 - 修复建议 - 回归检查”串成一个完整闭环读完后你应该能够用日志快速启动问题分析在关键位置补齐上下文减少盲猜让 Codex 从日志走到代码、SQL、事务和配置层让它继续输出修复建议、验证步骤和回归清单2. 为什么这三件事必须连起来看很多人现在的使用方式是先贴一段报错让 Codex 猜问题猜完就结束这样的问题是日志可能不完整代码位置可能不明确约束和风险可能没说修复后缺少回归思路所以更好的方式是先用日志启动判断再补关键上下文让判断更稳最后继续补测试回归形成闭环3. 三件事分别解决什么问题3.1 日志 Debug解决快速判断问题发生在哪一步快速缩小排查范围3.2 上下文补齐解决让 Codex 不只是“看报错”而是真正理解问题场景3.3 测试回归解决防止“修了当前 bug但引入新问题”帮你把修复结果走到验证完成4. 推荐的完整闭环1. 提供问题现象与日志2. 让 Codex 判断根因方向3. 补关键上下文4. 再定位代码 / SQL / 配置5. 输出最小修复建议6. 生成验证步骤7. 补回归测试清单8. 最终收口5. 第一步先用日志让 Codex 快速进入问题现场日志是最快的入口但不要只丢一行报错。推荐至少一起给问题目标复现步骤请求参数或输入数据返回结果完整堆栈或关键 SQL示例提示词请帮我定位一个问题。 目标 修复订单分页接口手机号筛选失效问题。 复现步骤 1. 打开订单列表页 2. 输入手机号 3. 点击查询 4. 返回空列表 请求参数 phone13800000000 pageNo1 pageSize10 当前现象 带手机号时返回空数据不带手机号时正常。 日志 / SQL [贴完整日志]6. 第二步先让 Codex 判断问题方向不急着修改在复杂问题上更稳的方式是先让 Codex 判断更可能是哪一层问题排查顺序是什么当前日志还缺什么示例提示词先不要改代码先判断问题方向。 请输出 1. 更可能是参数、Java 逻辑、SQL 条件、事务还是环境问题 2. 最值得优先排查的 3 个位置 3. 如果当前信息还不够请列出还缺什么7. 第三步补关键上下文而不是盲目补更多日志这一步是闭环里的关键转折。如果 Codex 说信息还不够不要继续乱贴而要补高价值上下文相关文件位置典型调用链关键配置约束和风险推荐补法补充上下文 1. 相关文件OrderController、OrderServiceImpl、OrderMapper、OrderMapper.xml 2. 当前项目Spring Boot MyBatis 3. 约束不改接口路径、不改入参结构、不做无关重构 4. 风险SQL 动态条件和分页逻辑不能被破坏8. 第四步让 Codex 从日志继续追到代码和链路这时就不只是“看日志”而是要让它把日志和代码真正连起来。可以让它输出Controller 入口Service 调用链Mapper / XML 位置SQL 条件处理位置示例提示词请基于日志和当前上下文继续把问题追到代码层。 输出 1. 最可能相关的 Controller 2. Service 调用链 3. Mapper / XML 位置 4. 当前问题更可能发生在哪一层9. 第五步让 Codex 输出最小修复建议当问题方向基本清楚后才进入修复建议阶段。推荐要求优先最小修改不做无关优化说明影响范围示例提示词请基于刚才的日志分析和代码定位结果输出最小修复建议。 要求 1. 优先最小改动 2. 不做无关重构 3. 说明影响范围10. 第六步让 Codex 补验证步骤修复建议不是结束还需要验证。推荐验证内容当前问题是否消失关键主路径是否恢复正常相关旧功能是否受影响示例提示词请基于这个修复建议输出验证步骤。 要求覆盖 1. 当前问题验证 2. 正常场景验证 3. 异常场景验证11. 第七步让 Codex 补回归测试清单这是闭环的最后一环。很多时候 bug 修掉了但没有回归后面又会出新问题。推荐让它输出哪些类似场景要回归哪些组合条件要回归哪些公共逻辑可能受影响示例提示词请基于当前问题和修复建议补回归测试清单。 要求 1. 列出必须回归的旧功能 2. 列出相似场景 3. 列出边界和组合场景12. 最推荐的组合输入模板请帮我处理一个问题并按“日志分析 - 上下文补齐 - 修复建议 - 测试回归”的方式推进。 目标 复现步骤 请求参数 / 输入数据 当前现象 返回结果 日志 / 堆栈 / SQL 相关文件 项目背景 约束 风险提示 输出要求 1. 先判断根因方向 2. 如果信息不够明确列出缺失上下文 3. 再给最小修复建议 4. 最后给验证步骤和回归清单13. Java / Spring Boot 项目实战实例场景订单分页接口在带手机号筛选时返回空数据。推荐组合方式第一步先用日志启动分析请帮我定位订单分页手机号筛选失效问题。 复现步骤 1. 打开订单列表 2. 输入手机号 3. 点击查询 4. 返回空列表 请求参数 phone13800000000 日志 / SQL [贴完整异常日志和 SQL]第二步补上下文补充上下文 1. 项目是 Spring Boot MyBatis 2. 相关文件OrderController、OrderServiceImpl、OrderMapper、OrderMapper.xml 3. 不允许修改接口路径和入参结构 4. 不影响其他筛选条件第三步继续要修复和回归请基于当前日志分析结果继续输出 1. 最小修复建议 2. 验证步骤 3. 回归测试清单这样做的价值日志先给方向上下文再给准确性回归清单保证修复闭环14. 事务问题实战实例场景订单提交时库存扣减成功但订单主表偶发保存失败。推荐组合方式先给异常堆栈和关键业务日志再补事务相关代码位置和调用链再让 Codex 判断事务边界、异常吞掉还是调用顺序问题最后补回归验证正常下单异常下单重复提交回滚是否生效15. 联调问题实战实例场景前端联调时新增接口返回 500本地单测正常。推荐组合方式一起给前端操作步骤请求 JSON后端错误日志返回体Controller / ReqVO / Service 位置然后让 Codex 输出更可能是哪一层问题需要补哪些上下文最小修复建议联调验证与回归建议16. 常见误区16.1 误区一只做日志分析不补上下文问题很容易停留在猜测层16.2 误区二只修当前问题不补回归问题可能引入副作用16.3 误区三日志很多但没有结构问题信息噪声太大16.4 误区四问题方向还没判断清楚就直接大改问题风险很高17. 注意事项先用日志启动问题分析信息不够时优先补结构化上下文先判断方向再考虑修改修复建议一定要配验证步骤最后一定补回归清单18. 高质量提示词模板18.1 通用闭环模板请按“日志分析 - 上下文补齐 - 修复建议 - 测试回归”的方式帮我推进这个问题。 目标 复现步骤 请求参数 / 输入数据 当前现象 返回结果 日志 / 堆栈 / SQL 相关文件 项目背景 约束 输出要求 1. 先判断根因方向 2. 如信息不足明确列出缺失项 3. 再给修复建议 4. 最后给验证和回归清单18.2 事务问题模板请按“日志分析 上下文补齐 回归验证”的方式处理这个事务问题。 输出要求 1. 判断更像哪类事务问题 2. 列出还缺哪些上下文 3. 给修复建议 4. 给回滚验证和回归清单18.3 联调问题模板请按闭环方式处理这个联调问题。 要求 1. 先判断更可能是哪一层问题 2. 再指出还缺哪些上下文 3. 再给最小修复建议 4. 最后给联调验证和回归建议19. 团队落地建议如果你想把这套方法推广到团队里建议这样做固化一份“日志 上下文 回归”输入模板让开发和测试统一使用同一套结构把高频问题的闭环案例沉淀成团队示例在 AI 协作规范里明确高风险问题必须补回归清单20. 一句话总结“日志 Debug 上下文 测试回归”的组合版本质上是在把一次性的故障定位动作升级成一套完整的问题分析、修复和验证闭环。21. 快速上手清单先给问题目标和复现步骤再给请求参数、返回结果和完整日志再补项目背景、代码位置、约束和风险先让 Codex 判断方向再让它给修复建议最后补验证步骤和回归清单
