1. 文档目标这份文档专门解决下面几个问题怎么把日志正确交给 Codex什么样的日志最有价值Codex 能从日志里帮你做什么怎样从日志一路追到代码、SQL、配置和根因怎样让日志分析结果最终落到修复和回归验证读完后你应该能够用更高质量的方式把日志交给 Codex让 Codex 更快判断问题是参数、逻辑、SQL 还是环境导致让 Codex 帮你输出更靠谱的根因分析和修复路径在 Java / Spring Boot、接口联调、分页查询、事务问题等场景中稳定使用这套方法2. 为什么日志对 Codex Debug 特别重要日志本质上是系统运行时留下的“现场证据”。相比只给一段代码日志更能告诉 Codex问题在哪一步发生哪个类、方法、SQL、线程、请求出了问题问题是偶发、稳定复现还是环境相关系统已经执行到了哪个阶段一句话理解日志不是附属信息很多时候它本身就是 Debug 的主线索。3. Codex 能从日志里帮你做什么3.1 判断问题大类例如判断更像是参数问题Java 逻辑问题SQL 条件问题事务问题配置或环境问题权限或调用顺序问题3.2 帮你定位关键代码范围日志通常能暴露类名方法名行号调用链SQL 片段这些信息可以帮助 Codex 迅速缩小范围。3.3 帮你梳理问题发生路径如果你给了复现步骤请求参数返回结果日志堆栈Codex 很擅长把这些串成一条问题链路。3.4 帮你给出修复优先级它可以帮你判断先查参数还是先查 SQL先看事务还是先看异常处理先看 Controller 还是先看 Service / Mapper3.5 帮你补验证和回归清单日志分析不是终点Codex 还可以继续帮你输出修复后怎么验证哪些类似场景要回归哪些日志点值得补充4. 哪些日志最有价值不是所有日志都一样有用。下面这些信息最值得优先给 Codex。4.1 完整异常堆栈最好不要只截一两行报错而是给尽量完整的堆栈。4.2 请求参数和返回结果尤其是接口问题、联调问题、分页筛选问题。4.3 SQL 日志对于查询错误、空数据、分页异常、动态条件问题特别重要。4.4 关键业务日志例如进入方法关键分支判断外部调用结果异常捕获点4.5 复现步骤日志单独看不一定完整和复现步骤结合才更有价值。5. 日志不够时最常见的问题如果日志信息不完整Codex 很容易出现这些情况只能给泛化猜测不能稳定判断根因无法区分是参数问题还是代码问题无法确认问题发生在哪一层所以给日志时不只是贴报错而是尽量给出“报错 请求 场景 代码位置”。6. 推荐的日志 Debug 输入结构问题目标复现步骤请求参数 / 输入数据返回结果 / 现象完整日志 / 堆栈 / SQL相关代码位置约束与输出要求7. 最推荐的日志 Debug 输入模板请帮我定位一个问题。 目标 [要解决什么问题] 复现步骤 1. ... 2. ... 3. ... 请求参数 / 输入数据 [关键参数] 当前现象 [报错、空数据、行为异常] 返回结果 [接口返回或页面表现] 日志 / 堆栈 / SQL [完整日志] 相关文件 [Controller / Service / Mapper / XML / 配置] 约束 [不能改什么 / 先不要直接修改 / 不做无关重构] 输出要求 1. 先判断根因 2. 再给排查优先级 3. 最后给最小修复建议和验证步骤8. 标准操作流程1. 收集复现步骤与日志2. 提供请求参数和返回结果3. 提供相关代码位置4. 让 Codex 判断根因方向5. 如有需要补充日志或链路信息6. 再让 Codex 给修复建议7. 最后补验证与回归清单9. 第一步先说清楚“这是个什么问题”不要一上来就只贴日志。先说清楚问题发生在哪个功能预期是什么当前错成了什么样示例目标修复订单分页接口手机号筛选失效问题。 预期带手机号时能筛出正确数据。 现象带手机号时返回空数据不带手机号时正常。10. 第二步把复现步骤和日志绑在一起给只给日志不给触发路径Codex 有时难以判断问题上下文。推荐一起提供用户做了什么操作第几步出现问题请求发向哪个接口接口返回了什么示例提示词复现步骤 1. 打开订单列表 2. 输入手机号筛选条件 3. 点击查询 4. 返回空列表 请结合下面日志一起分析。11. 第三步尽量给完整堆栈和关键 SQL很多定位失败不是因为 Codex 不会而是只给了半截日志。推荐做法异常堆栈尽量完整SQL 日志尽量带条件参数不要只截最上面一行报错原因因为真正的线索可能藏在嵌套异常SQL 绑定参数调用链深处12. 第四步让 Codex 先判断问题方向不急着让它改对于复杂问题更稳的做法是先让它判断更可能是哪一层出问题排查顺序是什么还缺哪些信息示例提示词先不要改代码先基于日志和现象判断问题方向。 请输出 1. 更可能是参数、Java 逻辑、SQL 条件、事务还是环境问题 2. 最值得优先检查的 3 个位置 3. 如果仍然不够判断还缺哪些日志或代码上下文13. 第五步如果信息不够让 Codex 明确列出还缺什么这是非常实用的一步。可以直接问如果你还不能稳定判断根因请明确列出你还需要哪些额外日志、参数或代码位置。这样你补的就不是“更多信息”而是“更有针对性的关键信息”。14. 第六步让日志分析结果继续落到修复和回归日志分析不能停留在“猜测根因”还要继续推进最小修复建议验证步骤回归清单示例提示词请基于你刚才的日志分析结果继续输出 1. 最小修复建议 2. 验证步骤 3. 回归测试建议15. Java / Spring Boot 项目实战实例场景订单分页接口在带手机号筛选时返回空数据。低质量输入示例订单接口有问题帮我看下日志。问题在于没有目标没有现象说明没有复现步骤没有相关代码位置高质量输入示例请帮我定位一个 bug。 目标 修复订单分页接口手机号筛选失效问题。 复现步骤 1. 打开订单列表页 2. 输入手机号 3. 点击查询 4. 返回空列表 请求参数 phone13800000000 pageNo1 pageSize10 当前现象 带手机号时返回空数据不带手机号时正常。 日志 / SQL [这里贴完整异常堆栈和 SQL 日志] 相关文件 1. OrderController 2. OrderServiceImpl 3. OrderMapper 4. OrderMapper.xml 约束 1. 不修改接口路径 2. 不改变入参结构 3. 不做无关重构 输出要求 1. 先判断更可能是参数、Java 逻辑还是 SQL 条件问题 2. 再给最小修复建议 3. 最后给验证与回归步骤为什么这个输入更有效因为它把日志真正放进了问题上下文而不是孤立地扔一段报错。16. 事务问题实战实例场景订单提交时偶发“库存扣减成功但订单保存失败”。推荐日志分析思路先给复现步骤关键业务日志异常堆栈事务相关代码位置示例提示词请帮我基于日志分析一个事务问题。 现象 订单提交后库存被扣减但订单主表没有成功落库。 复现步骤 1. 用户提交订单 2. 系统执行库存扣减 3. 订单保存失败 日志 [贴事务相关异常日志] 相关代码 1. OrderServiceImpl.submitOrder 2. 库存扣减方法 3. 订单保存方法 输出要求 1. 判断更像是事务边界问题、异常吞掉问题还是调用顺序问题 2. 给排查优先级 3. 给修复建议和回归验证点17. 联调问题实战实例场景前后端联调时前端收到 500但本地单测看起来正常。推荐输入方式一起给前端操作步骤请求体后端日志返回体接口定义示例提示词请帮我分析一个联调问题。 现象 前端调用新增接口返回 500。 请求体 [请求 JSON] 返回体 [错误返回] 日志 [后端异常日志] 相关接口 [Controller / ReqVO / Service] 请输出 1. 更可能是前端参数问题、后端校验问题还是业务逻辑问题 2. 最值得优先检查的字段或方法 3. 最小修复建议18. Codex 还能帮你做哪些日志增强工作除了分析已有日志Codex 还可以帮你识别当前日志是否不足建议在哪些关键位置补日志帮你设计更可追踪的日志结构提醒哪些日志不应打印敏感信息示例提示词请基于这个问题和当前日志判断日志是否足够定位问题。 如果不够请告诉我 1. 哪些位置应该补日志 2. 每条日志要记录什么信息 3. 哪些信息不能打印19. 常见误区19.1 误区一只给一行报错问题线索不够容易误判19.2 误区二只给日志不给复现步骤问题Codex 不知道问题发生在哪个业务动作里19.3 误区三只给日志不给代码位置问题很难从现象快速落到实现19.4 误区四日志很多但没有筛出关键段问题信息噪声太大影响判断19.5 误区五一上来就让它直接修问题在复杂问题上容易跳过关键分析阶段20. 注意事项优先给完整堆栈而不是半截报错日志最好和复现步骤一起给SQL 问题优先补 SQL 日志和参数高风险问题先让 Codex 判断方向再考虑修改信息不够时主动让 Codex 列出缺失项日志里注意脱敏不要直接贴敏感数据21. 高质量提示词模板21.1 通用日志 Debug 模板请帮我定位一个问题。 目标 复现步骤 请求参数 / 输入数据 当前现象 返回结果 日志 / 堆栈 / SQL 相关文件 约束 输出要求 1. 先判断根因方向 2. 再给排查优先级 3. 最后给修复与验证建议21.2 事务问题模板请帮我基于日志分析一个事务问题。 现象 复现步骤 日志 相关代码 输出要求 1. 判断更像哪类事务问题 2. 给排查顺序 3. 给修复和回归建议21.3 联调问题模板请帮我分析一个联调问题。 现象 请求体 返回体 日志 相关接口 输出要求 1. 判断问题更可能在哪一层 2. 给最值得优先检查的字段或方法 3. 给最小修复建议22. 团队落地建议如果你想把这套方法推广到团队里建议这样做统一一份“日志 Debug 输入模板”在团队规范里要求高风险问题优先提供完整日志沉淀几个高频问题的日志分析示例把“日志不够先补日志和上下文”写进 AI 协作规范让开发和测试都复用同一套日志分析输入结构23. 一句话总结Codex 用日志帮忙 Debug 的关键不是把报错扔给它而是把“复现步骤、请求参数、返回结果、完整日志、相关代码和约束”一起组织成一套可判断的上下文。24. 快速上手清单先说清问题目标再给复现步骤再给请求参数和返回结果再给完整日志、堆栈和 SQL再给相关代码位置先让 Codex 判断方向再让它给修复建议
Codex 用日志辅助 Debug 详解与操作指南
1. 文档目标这份文档专门解决下面几个问题怎么把日志正确交给 Codex什么样的日志最有价值Codex 能从日志里帮你做什么怎样从日志一路追到代码、SQL、配置和根因怎样让日志分析结果最终落到修复和回归验证读完后你应该能够用更高质量的方式把日志交给 Codex让 Codex 更快判断问题是参数、逻辑、SQL 还是环境导致让 Codex 帮你输出更靠谱的根因分析和修复路径在 Java / Spring Boot、接口联调、分页查询、事务问题等场景中稳定使用这套方法2. 为什么日志对 Codex Debug 特别重要日志本质上是系统运行时留下的“现场证据”。相比只给一段代码日志更能告诉 Codex问题在哪一步发生哪个类、方法、SQL、线程、请求出了问题问题是偶发、稳定复现还是环境相关系统已经执行到了哪个阶段一句话理解日志不是附属信息很多时候它本身就是 Debug 的主线索。3. Codex 能从日志里帮你做什么3.1 判断问题大类例如判断更像是参数问题Java 逻辑问题SQL 条件问题事务问题配置或环境问题权限或调用顺序问题3.2 帮你定位关键代码范围日志通常能暴露类名方法名行号调用链SQL 片段这些信息可以帮助 Codex 迅速缩小范围。3.3 帮你梳理问题发生路径如果你给了复现步骤请求参数返回结果日志堆栈Codex 很擅长把这些串成一条问题链路。3.4 帮你给出修复优先级它可以帮你判断先查参数还是先查 SQL先看事务还是先看异常处理先看 Controller 还是先看 Service / Mapper3.5 帮你补验证和回归清单日志分析不是终点Codex 还可以继续帮你输出修复后怎么验证哪些类似场景要回归哪些日志点值得补充4. 哪些日志最有价值不是所有日志都一样有用。下面这些信息最值得优先给 Codex。4.1 完整异常堆栈最好不要只截一两行报错而是给尽量完整的堆栈。4.2 请求参数和返回结果尤其是接口问题、联调问题、分页筛选问题。4.3 SQL 日志对于查询错误、空数据、分页异常、动态条件问题特别重要。4.4 关键业务日志例如进入方法关键分支判断外部调用结果异常捕获点4.5 复现步骤日志单独看不一定完整和复现步骤结合才更有价值。5. 日志不够时最常见的问题如果日志信息不完整Codex 很容易出现这些情况只能给泛化猜测不能稳定判断根因无法区分是参数问题还是代码问题无法确认问题发生在哪一层所以给日志时不只是贴报错而是尽量给出“报错 请求 场景 代码位置”。6. 推荐的日志 Debug 输入结构问题目标复现步骤请求参数 / 输入数据返回结果 / 现象完整日志 / 堆栈 / SQL相关代码位置约束与输出要求7. 最推荐的日志 Debug 输入模板请帮我定位一个问题。 目标 [要解决什么问题] 复现步骤 1. ... 2. ... 3. ... 请求参数 / 输入数据 [关键参数] 当前现象 [报错、空数据、行为异常] 返回结果 [接口返回或页面表现] 日志 / 堆栈 / SQL [完整日志] 相关文件 [Controller / Service / Mapper / XML / 配置] 约束 [不能改什么 / 先不要直接修改 / 不做无关重构] 输出要求 1. 先判断根因 2. 再给排查优先级 3. 最后给最小修复建议和验证步骤8. 标准操作流程1. 收集复现步骤与日志2. 提供请求参数和返回结果3. 提供相关代码位置4. 让 Codex 判断根因方向5. 如有需要补充日志或链路信息6. 再让 Codex 给修复建议7. 最后补验证与回归清单9. 第一步先说清楚“这是个什么问题”不要一上来就只贴日志。先说清楚问题发生在哪个功能预期是什么当前错成了什么样示例目标修复订单分页接口手机号筛选失效问题。 预期带手机号时能筛出正确数据。 现象带手机号时返回空数据不带手机号时正常。10. 第二步把复现步骤和日志绑在一起给只给日志不给触发路径Codex 有时难以判断问题上下文。推荐一起提供用户做了什么操作第几步出现问题请求发向哪个接口接口返回了什么示例提示词复现步骤 1. 打开订单列表 2. 输入手机号筛选条件 3. 点击查询 4. 返回空列表 请结合下面日志一起分析。11. 第三步尽量给完整堆栈和关键 SQL很多定位失败不是因为 Codex 不会而是只给了半截日志。推荐做法异常堆栈尽量完整SQL 日志尽量带条件参数不要只截最上面一行报错原因因为真正的线索可能藏在嵌套异常SQL 绑定参数调用链深处12. 第四步让 Codex 先判断问题方向不急着让它改对于复杂问题更稳的做法是先让它判断更可能是哪一层出问题排查顺序是什么还缺哪些信息示例提示词先不要改代码先基于日志和现象判断问题方向。 请输出 1. 更可能是参数、Java 逻辑、SQL 条件、事务还是环境问题 2. 最值得优先检查的 3 个位置 3. 如果仍然不够判断还缺哪些日志或代码上下文13. 第五步如果信息不够让 Codex 明确列出还缺什么这是非常实用的一步。可以直接问如果你还不能稳定判断根因请明确列出你还需要哪些额外日志、参数或代码位置。这样你补的就不是“更多信息”而是“更有针对性的关键信息”。14. 第六步让日志分析结果继续落到修复和回归日志分析不能停留在“猜测根因”还要继续推进最小修复建议验证步骤回归清单示例提示词请基于你刚才的日志分析结果继续输出 1. 最小修复建议 2. 验证步骤 3. 回归测试建议15. Java / Spring Boot 项目实战实例场景订单分页接口在带手机号筛选时返回空数据。低质量输入示例订单接口有问题帮我看下日志。问题在于没有目标没有现象说明没有复现步骤没有相关代码位置高质量输入示例请帮我定位一个 bug。 目标 修复订单分页接口手机号筛选失效问题。 复现步骤 1. 打开订单列表页 2. 输入手机号 3. 点击查询 4. 返回空列表 请求参数 phone13800000000 pageNo1 pageSize10 当前现象 带手机号时返回空数据不带手机号时正常。 日志 / SQL [这里贴完整异常堆栈和 SQL 日志] 相关文件 1. OrderController 2. OrderServiceImpl 3. OrderMapper 4. OrderMapper.xml 约束 1. 不修改接口路径 2. 不改变入参结构 3. 不做无关重构 输出要求 1. 先判断更可能是参数、Java 逻辑还是 SQL 条件问题 2. 再给最小修复建议 3. 最后给验证与回归步骤为什么这个输入更有效因为它把日志真正放进了问题上下文而不是孤立地扔一段报错。16. 事务问题实战实例场景订单提交时偶发“库存扣减成功但订单保存失败”。推荐日志分析思路先给复现步骤关键业务日志异常堆栈事务相关代码位置示例提示词请帮我基于日志分析一个事务问题。 现象 订单提交后库存被扣减但订单主表没有成功落库。 复现步骤 1. 用户提交订单 2. 系统执行库存扣减 3. 订单保存失败 日志 [贴事务相关异常日志] 相关代码 1. OrderServiceImpl.submitOrder 2. 库存扣减方法 3. 订单保存方法 输出要求 1. 判断更像是事务边界问题、异常吞掉问题还是调用顺序问题 2. 给排查优先级 3. 给修复建议和回归验证点17. 联调问题实战实例场景前后端联调时前端收到 500但本地单测看起来正常。推荐输入方式一起给前端操作步骤请求体后端日志返回体接口定义示例提示词请帮我分析一个联调问题。 现象 前端调用新增接口返回 500。 请求体 [请求 JSON] 返回体 [错误返回] 日志 [后端异常日志] 相关接口 [Controller / ReqVO / Service] 请输出 1. 更可能是前端参数问题、后端校验问题还是业务逻辑问题 2. 最值得优先检查的字段或方法 3. 最小修复建议18. Codex 还能帮你做哪些日志增强工作除了分析已有日志Codex 还可以帮你识别当前日志是否不足建议在哪些关键位置补日志帮你设计更可追踪的日志结构提醒哪些日志不应打印敏感信息示例提示词请基于这个问题和当前日志判断日志是否足够定位问题。 如果不够请告诉我 1. 哪些位置应该补日志 2. 每条日志要记录什么信息 3. 哪些信息不能打印19. 常见误区19.1 误区一只给一行报错问题线索不够容易误判19.2 误区二只给日志不给复现步骤问题Codex 不知道问题发生在哪个业务动作里19.3 误区三只给日志不给代码位置问题很难从现象快速落到实现19.4 误区四日志很多但没有筛出关键段问题信息噪声太大影响判断19.5 误区五一上来就让它直接修问题在复杂问题上容易跳过关键分析阶段20. 注意事项优先给完整堆栈而不是半截报错日志最好和复现步骤一起给SQL 问题优先补 SQL 日志和参数高风险问题先让 Codex 判断方向再考虑修改信息不够时主动让 Codex 列出缺失项日志里注意脱敏不要直接贴敏感数据21. 高质量提示词模板21.1 通用日志 Debug 模板请帮我定位一个问题。 目标 复现步骤 请求参数 / 输入数据 当前现象 返回结果 日志 / 堆栈 / SQL 相关文件 约束 输出要求 1. 先判断根因方向 2. 再给排查优先级 3. 最后给修复与验证建议21.2 事务问题模板请帮我基于日志分析一个事务问题。 现象 复现步骤 日志 相关代码 输出要求 1. 判断更像哪类事务问题 2. 给排查顺序 3. 给修复和回归建议21.3 联调问题模板请帮我分析一个联调问题。 现象 请求体 返回体 日志 相关接口 输出要求 1. 判断问题更可能在哪一层 2. 给最值得优先检查的字段或方法 3. 给最小修复建议22. 团队落地建议如果你想把这套方法推广到团队里建议这样做统一一份“日志 Debug 输入模板”在团队规范里要求高风险问题优先提供完整日志沉淀几个高频问题的日志分析示例把“日志不够先补日志和上下文”写进 AI 协作规范让开发和测试都复用同一套日志分析输入结构23. 一句话总结Codex 用日志帮忙 Debug 的关键不是把报错扔给它而是把“复现步骤、请求参数、返回结果、完整日志、相关代码和约束”一起组织成一套可判断的上下文。24. 快速上手清单先说清问题目标再给复现步骤再给请求参数和返回结果再给完整日志、堆栈和 SQL再给相关代码位置先让 Codex 判断方向再让它给修复建议
