大家好呀，我是 Lazy熊。今天想跟大家分享一下AI编程报错时，最值得直接复制的 Prompt 清单。

如果你部署篇还没看，可以先补下下面的内容，看完基本就会用：

Codex 怎么安装？新手最省事的一套流程

Codex 装好了却还是报错？我把最常见的问题，整理成了一份排查清单。

一个万能模板：如何描述你的功能需求

Codex改完代码后，新手应该怎么验收？

Codex 常见提示词模版，看这一篇就够了

很多人用 AI编程时，一旦遇到报错，第一反应通常都差不多：

把那一段错误直接复制过去， 然后来一句：

“这是什么问题？”

这当然也不是完全不能用。

但问题在于，光丢一段报错，很多时候信息其实是不够的。

因为真正影响排查效率的，往往不是那一行错误本身，

而是：

• 你是在什么场景下报的
• 前面执行了什么
• 这是安装问题、配置问题，还是代码逻辑问题
• 你已经试过哪些方法
• 你是想先判断层级，还是直接求解法

这些你不说，Codex 也只能猜。

一、先说结论：排查报错时，最重要的不是“立刻求答案”，而是“先判断问题属于哪一层”

很多人一看到报错，就想立刻问：

“怎么修？”

但我自己现在越来越觉得，排错时最稳的第一步，不是立刻求修法，

而是先判断：

这到底是哪一层的问题。

比如：

• 安装没生效
• 认证没配对
• 配置写错了
• 权限或工具调用有问题
• 代码逻辑本身有问题

如果层级一开始就判断错了，

后面越排，通常越乱。

所以我自己现在更习惯一个顺序：

1. 先给错误场景
2. 先给执行动作
3. 先给错误原文
4. 先让 Codex 判断问题层
5. 再让它给最小排查步骤

这样通常会稳很多。

二、排查报错时，新手最值得先存的 6 类 Prompt

我建议你先把下面这 6 类存下来：

1. 先判断问题层模版
2. 补充报错上下文模版
3. 先给最小排查步骤模版
4. 不要直接重装模版
5. 让它列出还缺哪些信息模版
6. 排查完后总结根因模版

下面我一条条展开。

---

三、模版一：先判断这属于哪一层问题

这是我最建议你先记住的一条。

我现在遇到一个报错，请先不要直接给最终修复方案。

请先判断，这个问题更可能属于哪一层：
1. 安装问题
2. 认证问题
3. 配置问题
4. 权限 / 工具调用问题
5. 代码逻辑问题

然后告诉我，你为什么这样判断。

适合什么时候用

• 刚看到报错，还没开始排
• 你不知道自己应该先查哪一层
• 你怕自己直接走错方向

这条的价值

先定层，

再往下排。

---

四、模版二：把报错上下文一次说清楚

很多人只贴错误原文，

但真正高价值的信息通常还包括：

• 执行了什么命令
• 在什么环境里执行
• 当前工具是什么
• 错误是在什么时候出现的

更稳的写法是：

我现在遇到一个报错，先帮我判断方向。

补充信息：
- 我使用的工具：
- 我执行的命令：
- 报错原文：
- 我的系统环境：
- 这是第一次执行就报错，还是之前正常现在突然报错：
- 我已经尝试过的步骤：

请先告诉我：
1. 你判断最可能是哪一层问题
2. 你最想先检查什么
3. 为什么

适合什么时候用

• 安装报错
• CLI 报错
• 启动时报错
• 配置后还是不生效

这条模版的价值

让 Codex 不是只看一行错误，

而是带着上下文判断。

---

五、模版三：先给我一个最小排查步骤，不要一口气给太多方案

很多 AI 一排错就容易一次给很多可能性，

结果你越看越乱。

这时候更稳的方式是，让它先给一个最小排查步骤。

请不要一次给我很多可能性。

先根据当前信息，给我一个最小排查步骤。
要求：
1. 先做最可能有效的第一步
2. 每一步都说明目的
3. 不要超过 3 步
4. 如果这 3 步不够，再继续往下排

适合什么时候用

• 你不想看一堆分支可能
• 你只想先走最短路径
• 你怕越排越乱

这条的价值

把排错从“信息轰炸”，

变成“可执行步骤”。

---

六、模版四：先不要让我重装，先判断有没有必要

新手一遇到报错，最容易走向两个极端：

一个是立刻重装， 一个是立刻删配置。

但很多时候，问题根本没严重到那一步。

所以你可以直接这样写：

请先判断有没有必要重装、重置配置或删除本地文件。

如果没有必要，请优先给我更小范围的排查方法。
如果你认为必须重装，请明确告诉我原因，不要默认把重装当第一步。

适合什么时候用

• 安装或配置相关报错
• 你已经有点想重装了
• 但又怕把局面弄更乱

这条模版的价值

拦住那种“先全推倒再说”的冲动。

---

七、模版五：让它先告诉我还缺哪些信息

有些报错不是不能排，

而是信息不够。

这时候最稳的方式，不是让它硬猜，

而是先让它把缺的信息讲出来。

如果你觉得当前信息还不够，请不要直接猜答案。

请先告诉我：
1. 你还缺哪些关键信息
2. 我应该补哪一段日志、配置或命令输出
3. 为什么这些信息最关键

适合什么时候用

• 你贴了报错，但它开始泛泛而谈
• 你感觉它还没抓到重点
• 日志和配置比较复杂

这条的价值

避免它硬猜，

也避免你盲目补一堆无关信息。

---

八、模版六：排查完成后，让它总结根因和以后怎么避免

这一条也很值得存。

因为排错最怕的不是这次没修，

而是：

这次修好了，下次还在同一个地方再踩一遍。

你可以这样写：

如果问题已经基本定位，请再帮我补充：
1. 这次报错的根因是什么
2. 它属于哪一层问题
3. 下次为了避免再踩这个坑，我最该记住什么

适合什么时候用

• 你已经快排完了
• 你想把这次排错变成长期经验

这条的价值

让一次排错，不只是“这次能过”，

而是：

下次更容易少踩坑。

---

九、如果你只想先记一条“排查报错综合版”，可以直接存这个

我现在遇到一个报错，请先不要直接给最终答案。

补充信息：
- 我使用的工具：
- 我执行的命令：
- 报错原文：
- 系统环境：
- 我已经尝试过的步骤：

请按下面顺序帮我处理：
1. 先判断问题更可能属于安装、认证、配置、权限还是代码逻辑
2. 告诉我你为什么这样判断
3. 如果信息不够，先告诉我还缺什么
4. 先给我一个最小排查步骤，不要超过 3 步
5. 如果问题基本定位，再总结根因和后续避免方式

这一条很适合做你的排错母版。

后面你每次只要把具体信息填进去，就能直接用。

十、再补一个：如果你怀疑是配置问题，可以用这个版本

配置类报错很常见，

而且最容易出现“我明明改了，怎么还是不对”这种情况。

这时候你可以用更定向的版本：

我怀疑这个问题和配置有关，请先不要默认是代码逻辑问题。

当前信息：
- 使用工具：
- 配置文件位置：
- 我改过的配置项：
- 当前报错：

请先帮我判断：
1. 最可能是哪一项配置出了问题
2. 这是不是配置层级或覆盖顺序的问题
3. 我应该先检查哪几个地方

这条特别适合：

• Base URL 写错
• 模型名不对
• settings 改了不生效
• 本地配置和项目配置打架

十一、最后说句最实在的话

很多人排查报错时，总想直接追求“修复答案”。

但我自己越来越觉得，真正更稳的顺序不是：

“立刻问怎么修。”

而是：

先判断问题层，再走最小排查步骤。

只要你把这个顺序建立起来，很多报错问题其实都会比想象中更清晰。

说白了就是一句话：

排错时，不要先求答案，先求定位。