报错循环：把错误信息原样喂回去

先给答案：AI 编程报错怎么办？把报错原文原样复制、喂回给 AI。 这是 vibe coding 祖师爷 Karpathy 在那条开创性推文里的原版玩法，英文原话是「When I get error messages I just copy paste them in with no comment, usually that fixes it」——遇到报错直接复制粘贴回去，不加任何评论，通常就能修好。

但他自己也承认这条路的局限：「AI 工具不一定能理解出现的错误，也不一定可以修正。」所以这一课不只教你怎么喂报错，还教修不动时怎么止损。工作流导读立的第三条纪律「报错原样喂回去」，防的坑就是在同一个错上无限循环，烧时间烧 token。

四款工具（Claude Code、Codex、OpenCode、WorkBuddy）通用——这一课就是 vibe coding 的调试课，零基础 10 分钟走完。

学完你能做什么

• 把报错原文完整喂回给 AI，让它引用具体文件和行号定位问题，而不是凭你的转述瞎猜
• 给 AI 一个「能过 / 不过」的检查（测试、构建、lint），让它自己走完「改—跑—读输出—再修」的循环，直到通过
• 同一个错修两轮还卡着时果断止损：打断、回滚、清空重写提示词，不在死胡同里打转
• 分清「代码报错」和「工具本身坏了」，后者走自检命令和排错页，别让 AI 白改代码
• 说得出修不好的 bug 什么时候可以绕过、什么时候不能绕

你现在的困境

• 屏幕上蹦出一大片红字，你看不懂，跟 AI 说「报错了，帮我修」——它修的方向和真正的错差着十万八千里
• AI 说「已修复」，你一跑还是同一个错；再贴一次，它再改一版，来回五六轮，越修越乱
• 修到第 N 轮你开始怀疑：到底是代码有 bug，还是工具本身坏了？没人告诉你该走哪条路

什么时候用这一招

当你需要：

• 让 AI 修 bug 一轮命中，少走弯路
• 把「AI 说修好了」升级成「检查真的跑过了」
• 卡死的时候及时止损，不在同一个错上烧时间烧 token

而且不想：

• 自己啃报错原文的每一行（这一课不要求你读懂报错）
• 在同一个错上贴第三遍、第四遍
• 把工具故障当成代码 bug，让 AI 瞎改一晚上

🎒 开始前的准备

• 读完 提示词写法：让 AI 一次写对的魔法模板——报错原文就是上一课说的「原件」之一，这一课是它的实战主场
• 装好并用过至少一款工具：Claude Code、Codex、OpenCode 或 WorkBuddy
• 手头有一个跑起来会报错的真实小项目——拿真报错练，比看例子记得牢
• 10 分钟和一杯水 ☕

核心思路

报错是喂给 AI 的体检报告，不是发给你本人的考卷。 报错原文里装着 AI 定位问题需要的全部线索：哪个文件、哪一行、什么类型的错、缺了什么。你一转述，线索就开始丢。「AI 写代码报错」这件事不丢人——工具越自动，报错越常见；真正贵的是在同一个错上打转。

所以第一个动作是「原样」两个字，四种常见递法对比如下：

常见做法	丢在哪
「报错了，帮我修」	AI 只知道「有错」，不知道错在哪、什么错
只贴报错最后一行	定位线索在完整输出里；哪一行关键由 AI 判断，不是你
口头转述「好像是找不到某个变量」	「好像」两个字够 AI 猜三条街
完整复制报错原文喂回去	不丢——这就是 Karpathy 说的 usually that fixes it

「原样喂回去」只解决一半问题，另一半靠循环本身。Claude Code 官方最佳实践给了一个关键机制：给 AI 一个能跑的、结果非过即不过的检查，它就能自己把循环转起来——改代码、跑检查、读输出、再修，直到通过，你不用盯着。

而当循环转不动——同一个错修了两轮还在——上一课的纠偏法则在这里升级生效：对话里已经躺着两条失败记录，第三轮大概率是在教 AI 更用力地往错的方向走。止损，重写。

一句话记住这一课：报错原样喂回去，循环交给检查跑，两轮不行就重写。

跟我做

（拿你手头那个会报错的小项目当素材，四步走完：从贴对报错，到 AI 自己转起修复循环，到修不动时换路。）

第 1 步：报错怎么办？把原文原样喂回去

为什么：转述必丢信息，原件不会。上一课讲过「有现成的材料直接递过去别描述」——报错原文就是最典型的原件，也是 Karpathy 原版玩法里被验证最有效的部分。

操作只有一个动作：从报错的第一行复制到最后一行，整段粘进对话，配一句话说明这是什么时候报的（本页第一个魔法模板，直接复制去填）：

跑 <什么命令 / 做什么操作> 时报了这个错，帮我定位并修好：

<完整报错原文，从第一行到最后一行>

两种更省事的递法（用 Claude Code 修 bug 时）：

cat error.log | claude -p "这是怎么回事"

报错躺在日志文件里时，不用打开复制，一条管道直接喂。界面上弹的错也可以直接截图贴进提示词——官方明确支持把报错截图贴进 prompt。WorkBuddy 这类对话式工具同理：报错原文直接贴进任务对话就行。

💡 原样 ≠ 只有一段报错

「什么时候报的、当时在做什么」这一句背景要写——它不在报错里，AI 读不出来。但背景一句就够，别把你的猜测也塞进去；猜错了等于亲手把 AI 带偏。

你应该看到：AI 的回复里出现报错原文里的具体文件名、行号或错误类型——说明它在顺着线索查，而不是反问你「具体是什么错？」。如果反问你，就是信息没递够。

• 小检查：我贴的是完整原文，AI 引用了里面的文件名或行号，而不是让我补充信息

第 2 步：给 AI 一个能过/不过的检查，让它自己走完修复循环

为什么：只贴报错，AI 修完会说「应该修好了」。官方最佳实践把这层窗户纸捅破了：没有可跑的检查时，「看起来做完了」就是它收工的全部依据——实际上你成了它的测试套件，每个问题都要等你亲自运行的那一刻才炸出来。

给它一个结果非过即不过的检查，它就能自己把循环转起来：改代码 → 跑检查 → 读输出 → 再修，直到通过。

检查可以是这些里的任何一个（官方清单）：

检查	例子
测试	项目里已有的测试文件，或让 AI 先写一个能复现 bug 的失败测试
构建	构建命令的退出码
Lint	代码检查工具通过
对比脚本	输出和预期文件逐行比对
页面截图	浏览器里跑起来的实际样子，和设计稿对比

提示词里把检查和「修到通过为止」一起说（官方例句的中文版，本页第二个魔法模板）：

修完之后跑 <测试/构建命令>，一直修到它通过为止。
最后把你跑过的命令和输出贴给我。

最后那句「贴给我」是官方专门强调的要证据——原话是「"All tests pass" 单独一句说明不了什么」。命令加输出，才是「修好了」的证据；读它的输出，也比你自己重跑一遍快。

WorkBuddy 用户：上一课说过，任务描述的补充说明里写明目标、范围、约束和预期输出——「怎么验证修好了」就写在预期输出那一栏，让任务从创建起就带着验收标准。

你应该看到：AI 自己跑检查、自己读输出、自己改下一版，中途不需要你喂第二次报错；最后交回来的是命令和输出，不是一句「修好了」。

• 小检查：我的提示词里有「跑什么检查」和「修到通过为止」两件事

第 3 步：同一个错修两轮不行，打断重写

为什么：报错循环最烧钱的姿势是「同一个错，贴第三遍」。官方说法很直白：同一件事纠正两次还不对，第三次基本没用——对话里已经躺着两条失败记录，AI 每一轮都在重读它们。报错循环里这更狠：每一轮失败都在教它「往错误方向使劲」。

操作按跑偏程度升级，上一课的纠偏三档照搬：

1. 当场打断：Claude Code 里按 Esc 停下当前动作，已做的保留，然后发纠偏消息
2. 回滚重来：/rewind（或在空输入框连按两次 Esc）打开回滚菜单，把代码、对话或两者一起退回更早的提示词——试错成本低了，敢试更大胆的修法
3. 清空重写：/clear 清空会话，把两轮学到的教训并进一条新提示词——官方原话：这几乎总是比第三轮纠正更好

重写的提示词别从零开始。在上一课三要素模板的基础上加一行「已知排除」（本页第三个魔法模板）：

症状或目标：<还是那个错，原样贴>
相关位置：<文件 / 报错原文>
完成标准：<第 2 步的检查跑通>
已知排除：<前两轮试过什么、确认不是什么的问题——别再往那个方向改>

Codex 用户对号入座：官方给的卡住恢复三步是——先看它是不是在等你审批、在终端跑个 git status 之类的基础命令确认环境正常、然后开个新会话，用更小更聚焦的提示词重新说。跟「清空重写」是同一个思路。误取消了运行、提示词丢了？按输入框的上方向键能找回上一条。

你应该看到：新提示词一轮命中，或者至少 AI 的排查方向变了——不再重复前两轮的动作。

• 小检查：重写的新提示词里写了「前两轮试过什么、确认不是什么的问题」

第 4 步：AI 修不好怎么办？先查工具，再决定绕不绕

为什么：有一种循环 AI 永远修不好——错根本不在你的代码里。安装、登录、网络、额度这类工具故障，让 AI 改代码是白烧时间。修不动时先花 60 秒分辨走哪条路：

报错里出现	大概率是	走哪条路
你的文件名 + 行号	代码 bug	前三步的报错循环
command not found、装不上、PATH、登录失败	工具/安装问题	起步排错 60 秒速查
API Error: 5xx、429、529 Overloaded、磁盘满	服务端/环境问题	不是你代码的错，别让 AI 改代码；用下面的自检命令查工具状态

工具自检命令（各家的「体检按钮」）：

工具	自检
Claude Code	会话里跑 /doctor，自动检查安装、设置和上下文；claude 都起不来时，在终端跑 claude doctor
OpenCode	opencode service status 看后台服务状态；opencode api get /api/info 验证 API 健康
Codex	卡住时官方三步：查审批 → 终端跑基础命令 → 新会话小提示词

还有一招很多人不知道：让工具修它自己。 OpenCode 官方排错文档开篇就写：你可以让 OpenCode 自己调试自己——描述问题，让它读排错文档、查自己的服务和日志。Claude Code 官方同样说，可以直接问 Claude 它自己的能力和特性——它内置了自己的文档。

最后一层：真修不好，可以绕吗？Karpathy 的原版答案是可以——「Sometimes the LLMs can't fix a bug so I just work around it」，LLM 修不好的 bug 他就绕过去，或随便改点什么直到问题消失。但记住他自己划的边界：这套玩法用在周末一次性小项目上还不错。

⚠️ 绕过的边界

给自己用的小玩意，绕过是止损；要给别人用的东西，绕过去的 bug 不会消失，只会变成 验收检查 里要拦的雷——AI 参与的代码安全漏洞比人写的多 2.74 倍，这个数字背后就是一个个「先绕过去再说」。

你应该看到：60 秒分辨后你走对了门——代码错进循环，工具错进排错，不再让 AI 对着环境问题改一晚上代码。

• 小检查：报错原文里出现的是我的文件名，还是 command not found、磁盘满这类系统词？

检查点 ✅

• 我完整贴过一次报错原文，AI 的回复引用了里面的文件名或行号
• 我的修复提示词里有「跑什么检查、修到通过为止、贴出命令和输出」三件事
• 同一个错修两轮还在时，我打断/清空重写了，新提示词带上了已知排除
• 我能分辨代码报错和工具故障，后者走的是自检命令和排错页
• 我说得出绕过 bug 的边界：自己玩的可以绕，给别人用的不能绕

踩坑提醒

❌ 「报错了，帮我修」

AI 只知道「有错」，不知道错在哪、什么类型、缺什么，只能猜——猜错方向后，你俩开始互相带偏，一轮比一轮远。正确做法：完整复制报错原文喂回去（第 1 步）；日志文件用管道 cat error.log | claude -p "这是怎么回事"，界面报错直接截图贴。

❌ 把「AI 说修好了」当「修好了」

没有可跑的检查时，AI 停在「看起来做完了」——官方原话，这种模式下你成了它的测试套件，每个问题都躺到你亲自运行时才炸。正确做法：给一个非过即不过的检查，并要证据（跑过的命令和输出）；用 Claude Code 的话，还可以在它说做完后跑 /verify，让它自己构建运行应用看结果。

❌ 同一个错，贴第三遍

对话里已经躺着两条失败记录，第三轮是在教 AI 更用力地往错的方向走，烧的是你的时间和 token。正确做法：两轮法则——Esc 打断、/rewind 回滚、/clear 清空重写，新提示词带上「已知排除」。

❌ 工具坏了也让 AI 改代码

command not found、登录失败、429、磁盘满——这些错不在你的代码里，AI 改一万遍也没用。正确做法：第 4 步的分辨表——工具问题走自检（/doctor、opencode service status）和 起步排错，别让 AI 对着环境问题空转。

进阶技巧（可选）

修不动的错，升一档思考强度再试一次。 Claude Code 官方建议：错在你没写过的代码里、时好时坏的测试这类「容易漏掉边角情况」的活，用 /effort high 或 /effort xhigh 升档；只是单条消息想让它想深一点，把 ultrathink 放进那条提示词，不动全局设置。

说做完了？让它自己跑一遍。 Claude Code 里 /verify 会让它构建并运行应用、看实际结果——专抓测试和类型检查抓不住的问题。

同一个坑踩两次，写进项目说明书。 上一课的 AGENTS.md / CLAUDE.md 机制在这里接力：修过的坑（要设的环境变量、容易误判的目录）记进去，下个会话自动带上——这是把报错循环的学费变成资产的唯一办法。

做浏览器插件的读者：插件的日志和报错有专门的藏身处（service worker 的 Inspect views、宿主页面的控制台），详见 插件调不出来：日志去哪找、报错怎么读。

本课小结

✅ AI 编程报错怎么办的完整链条你走通了：原样喂回（完整报错原文 / 管道 / 截图）→ 交给检查（非过即不过 + 修到通过 + 要证据）→ 两轮止损（打断 → 回滚 → 清空重写）→ 换路分辨（代码错进循环，工具错走自检，修不好看情况绕）。

✅ 你知道了 Karpathy 原版玩法「复制粘贴回去通常就修好」为什么有效——报错原文就是 AI 缺的全部线索；也知道了它的边界——他自己承认 AI 不一定能理解或修正错误，所以要有止损纪律。

✅ 你分清了两种「修不好」：代码修不好，两轮止损重写；根本不是代码的错，自检加排错页。

关键概念回顾：

概念	一句话	在哪深入
原样喂回	完整报错原文，不转述、不挑行	本页第 1 步
修复循环	给非过即不过的检查，AI 自己改—跑—读—修	本页第 2 步
要证据	命令 + 输出，不是「修好了」三个字	本页第 2 步
两轮止损	同一个错修两轮 → 打断 / 回滚 / 清空重写	本页第 3 步
修不好的分流	代码错 / 工具错 / 可绕的错	本页第 4 步

下一课预告

报错循环转顺了，AI 交回来的东西「能跑」了——但能跑不等于能上线。下一课：验收检查：AI 写的代码怎么检查再上线。

你会学到：

• 用一份能过/不过的清单验收 AI 交付的代码，把「看着没问题」变成「检查过了」
• 量化研究说 AI 参与的代码安全漏洞比人写的多 2.74 倍——哪些风险必须上线前拦住
• 为什么给别人用的东西，发布前要找有经验的人把把关
• 验收查出来的问题，怎么接回这一课的报错循环里修