Codeium报错堆栈拆解为排查步骤提示词：让AI先判断再输出完整指南

排查报错堆栈时，真正让人头疼的不是错误本身，而是AI直接丢出一段修复代码，却跳过了所有中间推导过程。另一种更烦人的情况是收到“检查变量”“确认路径”这类正确的废话——道理都懂，但完全没法落地执行。

本文直击这一痛点，交付一套将堆栈拆解为可执行排查步骤的系统方法论。目标清晰：你不是在等一个现成答案，而是在学习一套能自行定位根因的排查流程。

具体路径分为两条：其一是通过精确指令迫使AI按结构化流程推进排查；其二是手动操作，借助“三步锚定法”快速锁定故障根源。

借助/goal指令驱动AI执行结构化排查

在Codeium中粘贴以下指令：/goal 分析以下报错堆栈，按真实开发排障顺序输出3～5个具体排查步骤，直到能准确定位根因；每步必须包含【操作动作】+【验证方式】；过程中不得跳过堆栈中的任一层调用信息。

将完整堆栈（包含异常类型、文件名、行号、方法名、调用链）粘贴后回车。/goal会阻止AI直接输出修复代码，强制它执行“分析→拆解→排序→验证设计”的完整闭环。

【关键前提】堆栈必须包含至少两级调用（例如A→B→C），否则AI可能将步骤压缩至不足。如果你只粘贴了NullPointerException一行，AI会在第一步反馈：“无法判断空指针发生在哪一层对象上，请提供完整堆栈”。

手动拆解堆栈的“三步锚定法”

方法一：从最底层异常向上逆向推导

第一步：定位堆栈末尾的Caused by:或最后一行不以at开头的异常描述，记录异常类型和消息（例如java.lang.NullPointerException: Cannot invoke "String.length()" because "s" is null）。

第二步：找到该异常正上方的第一个at com.example.UserProcessor.process(UserProcessor.java:42)——即实际抛出异常的代码行，标出该行中所有被调用的对象（本例为s）。

第三步：沿调用链向上追溯，确认s是在哪一层传入的：检查UserProcessor.java:42的上级调用者（例如ServiceLayer.java:88），判断s是否由此传入，并查证是否在该处被赋值为null。

方法二：通过关键词锁定高危调用层

扫描堆栈中是否包含Optional.get()、list.get(0)、response.getBody()、jsonNode.get("field")等典型的空值触发模式。一旦命中，该行即为第一排查目标——【别等AI提示，你必须主动标注】。

强制AI输出附带验证动作的排查步骤

在提示词末尾追加硬性约束：每个步骤格式为：“① 执行【xxx】→ 检查【yyy】是否成立→ 若不成立则进入下一步”。

例如正确输出：
① 在UserProcessor.java第42行设置断点，运行并查看变量s的值 → 检查s == null是否为true → 若不成立则进入下一步
② 审查ServiceLayer.java第88行对s的赋值逻辑 → 检查是否调用了optionalUser.getName()且optionalUser为空 → 若不成立则进入下一步

这一步必须明确写出“检查【yyy】是否成立”，否则AI很容易输出“检查s是否为空”这类模糊指令，让你无从下手验证。