1. 文档目标
这份文档解决的是一个真实工程里特别高频的问题：
- 只靠日志能不能让 Codex 帮忙 Debug
- 日志不够时还应该补什么上下文
- 找到根因后，怎样继续让 Codex 帮你补验证和回归
- 怎样把“问题定位 -> 修复建议 -> 回归检查”串成一个完整闭环
读完后，你应该能够：
- 用日志快速启动问题分析
- 在关键位置补齐上下文，减少盲猜
- 让 Codex 从日志走到代码、SQL、事务和配置层
- 让它继续输出修复建议、验证步骤和回归清单
2. 为什么这三件事必须连起来看
很多人现在的使用方式是：
- 先贴一段报错
- 让 Codex 猜问题
- 猜完就结束
这样的问题是：
- 日志可能不完整
- 代码位置可能不明确
- 约束和风险可能没说
- 修复后缺少回归思路
所以更好的方式是：
- 先用日志启动判断
- 再补关键上下文让判断更稳
- 最后继续补测试回归，形成闭环
3. 三件事分别解决什么问题
3.1 日志 Debug
解决：
- 快速判断问题发生在哪一步
- 快速缩小排查范围
3.2 上下文补齐
解决：
- 让 Codex 不只是“看报错”，而是真正理解问题场景
3.3 测试回归
解决：
- 防止“修了当前 bug，但引入新问题”
- 帮你把修复结果走到验证完成
4. 推荐的完整闭环
5. 第一步：先用日志让 Codex 快速进入问题现场
日志是最快的入口，但不要只丢一行报错。
推荐至少一起给：
- 问题目标
- 复现步骤
- 请求参数或输入数据
- 返回结果
- 完整堆栈或关键 SQL
示例提示词
请帮我定位一个问题。 目标： 修复订单分页接口手机号筛选失效问题。 复现步骤： 1. 打开订单列表页 2. 输入手机号 3. 点击查询 4. 返回空列表 请求参数： phone=13800000000 pageNo=1 pageSize=10 当前现象： 带手机号时返回空数据，不带手机号时正常。 日志 / 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. 返回空列表 请求参数： phone=13800000000 日志 / 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 判断方向
- 再让它给修复建议
- 最后补验证步骤和回归清单
