codeium解析报错堆栈需强制结构化排查：①定位最内层异常行；②找出该行直接依赖的上层调用；③检查该依赖是否正确定义。须锚定具体文件行、禁用模糊词，并依错误类型触发对应溯源模板。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
Codeium解析报错堆栈时只机械贴出错误原文、不拆解执行路径，导致你反复对照源码却找不到哪一行真正出问题。这不是模型没能力，而是提示词没强制它把堆栈当调用流水线来读。
用结构化指令锁住排查逻辑链
在报错信息前插入固定前缀，强制模型按真实执行流重组线索：
“请严格按以下三步处理：① 定位最内层异常发生行（不是第一行堆栈）；② 找出该行直接依赖的上一层变量或函数调用；③ 检查该依赖在调用前是否被正确赋值／初始化。只输出这三步，每步一行，不加解释。”
这一步必须写死序号和动词（定位→找出→检查），否则Codeium会自行拆解为“可能原因1/2/3”，又回到泛泛而谈的老路。
堵住“泛泛而谈”的漏洞
方法一：用文件路径锚定上下文
在报错堆栈粘贴后立刻追加：“所有分析必须基于/src/utils/apiClient.ts第42行展开，忽略其他文件中的同名函数。”
方法二：禁用推测性描述
在提示末尾加一句：“禁止出现‘可能’‘或许’‘一般情况下’等模糊表述，每个步骤必须对应堆栈中明确出现的类名、方法名或行号。”
【Codeium对模糊禁令响应敏感，漏掉这句就会默认启用猜测模式】
让错误类型决定步骤颗粒度
第一步：识别错误大类——看堆栈首行关键词
如果是“TypeError: Cannot read property ‘x’ of undefined”，后续步骤必须包含“检查x属性所属对象的初始化位置”；
如果是“SyntaxError: Unexpected token }”，步骤必须锁定“报错行及上一行的括号／引号配对状态”，不能跳到业务逻辑层。
第二步：用错误关键词触发预设步骤模板
在提示词开头写：“检测到关键词‘undefined’，启用【空值溯源三步法】：1. 找出调用链中最后一个非undefined值来源；2. 检查该值被赋值时的条件分支是否全部覆盖；3. 验证接口返回结构与TS类型定义是否一致。”
