我想先帮你调整一个心理预期：Claude Code 一定会犯错。不是「偶尔犯错」，而是「经常犯错」。如果你指望它每次都产出完美代码，你会很痛苦。
但这并不意味着 AI 编程不靠谱。传统开发中你自己写代码也会犯错，只不过那些错误你已经习惯了。AI 编程的真正技能不是「避免所有错误」，而是「快速从错误中恢复」。就像打字速度快的人不是不打错字，而是发现错误和修正的速度也一样快。
我刚开始用 Claude Code 的时候，遇到错误会很沮丧，觉得「这玩意不行啊」。后来用多了才意识到，关键不在于它犯不犯错，而在于我能不能在 30 秒内判断出这个错误属于哪个等级、该用什么策略处理。
不是所有错误都值得同等对待。我把 AI 犯的错分成三个等级，每个等级对应不同的处理策略。
变量名不够好、缺少类型注解、注释写得不清楚、格式不统一。这类问题不影响功能，修起来也快。直接告诉 Claude Code 具体要改什么就行：「把这个变量名从 d 改成 deliveryDate」、「给这个函数加上返回类型」。
不需要纠结，不需要讨论，30 秒搞定，继续往下走。
代码能跑，测试可能也过了一部分，但逻辑不对。比如排序方向反了、日期计算少了一天、条件判断里用了 || 应该用 &&。
这类问题需要你明确指出哪里不对、为什么不对。光说「这个不对，重写」是不够的，AI 可能会改出另一种不对的版本。你得说清楚：「这里的逻辑应该是先检查库存再扣款，你写反了，当库存不足时用户已经被扣钱了。」给出具体的问题描述和预期行为，Claude Code 通常能一次改对。
有一次我让它写一个分页逻辑，它把 offset 算成了 page * size，但我们的分页是从第 1 页开始的，正确的应该是 (page - 1) * size。我只说了「分页不对」，它改成了另一种错误的写法。后来我把具体的输入输出贴给它看——「当 page=1, size=10 时，offset 应该是 0，不是 10」——它立刻就改对了。
这是最棘手的一类。不是某几行代码有问题，而是整体方案选错了。比如你想要一个简单的状态管理，它给你搞了一套完整的 Redux 架构；或者你要做服务端渲染，它给你写了个纯客户端方案。
遇到这种情况，我的建议很明确：不要试图在错误的方案上修修补补。你在错误的地基上盖楼，修到后来会发现越来越多的问题冒出来，总修补时间远超过重来的时间。果断回退，重新开始。
判断好错误等级之后，接下来就是执行回退。根据严重程度不同，我常用三种手段。
如果你一直在按小步快跑的节奏 commit，回退就非常简单：
$ git reset --hard HEAD~1这是最干净的回退方式。回到上一个已验证的状态，然后重新给 Claude Code 下指令。这也是为什么我在上一课反复强调「每步审查后立即 commit」——commit 就是你的存档点，没有存档点的回退是很痛苦的。
有时候问题不在代码本身，而在对话的上下文。Claude Code 产出了一段有问题的代码，你指出了问题，它修了，但修得还是不太对，你又指出来，它又改……几轮下来，对话里充斥着错误信息和修补痕迹，上下文已经被「污染」了。
这时候最好的做法是开一个新对话，从干净的状态重来。在新对话里，你可以把之前踩过的坑直接写进 prompt 里：「注意分页从第 1 页开始，offset = (page - 1) * size」。这样 Claude Code 一上来就知道该避免什么。
我发现大概在第三轮修补之后，如果问题还没解决，继续在同一个对话里纠缠大概率是在浪费时间。开新对话吧。
如果连续两次尝试都不理想，值得停下来想一个更根本的问题：是不是任务拆解方式本身有问题？
举个例子，我曾经让 Claude Code 一步到位地写一个「带权限控制的文件上传模块」，连续试了两次都不满意。后来我重新拆解——先写纯粹的文件上传（不带权限），验证通过后再加权限层。分开处理之后，两步都很顺利。问题出在我把两个关注点耦合在一起了，AI 在同时处理多个关注点时表现会打折扣。
每次 Claude Code 犯的错误都是有价值的信息。第一次遇到某个坑你可能要花十分钟才反应过来，但如果你把这个经验记下来，下次就能在 30 秒内识别。
我的做法是，每当遇到一个有代表性的错误，就在 CLAUDE.md 里加一条记录。比如：
这些记录会在未来的对话中被 Claude Code 读到，从而避免重复犯同样的错误。错误不会消失，但同一个错误不应该出现第二次。
换个角度想，你在和 Claude Code 的协作中踩过的每一个坑，都在帮你构建一份越来越精准的 CLAUDE.md。几周之后回头看，你会发现那些错误并没有白犯——它们变成了你最有价值的开发资产。
每周更新 Claude Code 实战技巧、工具对比、行业动态。回复「模板」获取 CLAUDE.md 模板合集。