用 Claude Code 搞开发时如何避免陷入代码污染的死循环

最近在深度使用 Claude Code 之后，我发现很多开发者最头疼的其实不是 AI 写不出代码，而是它在“错误的路径上疯狂输出”。最糟糕的体验就是你下达一个指令，它看似在高效工作，结果改了十几个文件，最后你发现逻辑全错了，还得花整个下午手动回滚和清理垃圾代码。

这种“AI 乱搞”的情况，本质上是由于指令模糊导致的上下文偏移。如果你不建立一套严格的约束习惯，很容易陷入“改好一个 Bug 引入三个新 Bug”的死循环。分享几个我实操下来的避坑习惯，希望能帮大家提升单次 Session 的有效产出。

首先，也是最关键的一点：强制要求 AI 在写代码前必须先出计划。

很多人的习惯是直接下令“实现 XX 功能”，这在小型脚本中没问题，但在复杂的 codebase 里是极大的风险。因为 Claude Code 拥有直接修改文件的权限，一旦它对某个逻辑点理解偏差，它会迅速地在多个文件间产生连锁反应。我现在的标准操作流程是：禁止它直接写代码，必须先输出 Plan。

我建议在 Prompt 中加入这段强制约束：Before writing any code, please provide a step-by-step implementation plan. Wait for my confirmation before applying changes.

这样做的目的在于将“逻辑确认”与“代码执行”解耦。如果它的计划里包含了错误的依赖关系或不合理的架构选择，你可以在它动笔之前就把它拦下来。这种确认机制虽然多花了一分钟，但能避免后续几个小时的重构成本。

其次，要精细化控制文件的上下文范围。

虽然 Claude Code 具备强大的目录扫描能力，但“全量扫描”并不总是好事。在处理复杂重构时，如果你不限制范围，它有时会过度分析一些无关的配置文件或旧的遗留代码，这不仅会浪费 Token，更容易诱发 AI 产生幻觉，把不相关的逻辑强行关联到当前任务中。建议在执行任务前，明确告知它只关注哪些特定的文件路径，将它的注意力强行锁定在核心链路上。

另外，必须建立极强的“快照”意识。

在使用 AI 驱动开发时，Git 就不再仅仅是版本管理工具，而成了你的“救命稻草”。在让 Claude Code 进行任何大规模重构之前，必须确保当前的 git 工作区是干净的（Clean State）。

最怕的情况是 AI 陷入某种逻辑死循环：它尝试修复 Bug A → 引入 Bug B → 尝试修复 Bug B → 导致 Bug A 回归。当你意识到它在反复修改同一个文件且无法自拔时，不要试图通过对话去纠正它，因为此时上下文可能已经污染。最快的方法是直接执行 git checkout . 强制重置所有更改，然后重新审视你的 Prompt，从一个更清晰的切入点重新开始。

最后，在处理 Bug 时，坚决杜绝模糊描述，采用“报错驱动”模式。

很多开发者习惯说“运行不起来”或“页面报错了”，这种描述对 AI 来说是无效信息。最有效的方式是将终端的原始报错信息完整地喂给它，并要求它先分析根因，而不是直接给出补丁。

比如，当你运行 npm run dev 失败时，不要说“启动报错”，而是直接贴出类似 Error: Cannot find module 'xxx' in /path/to/project 这样具体的路径和错误码。要求它在给出代码之前，先解释为什么会出现这个错误。只有根因分析正确了，它给出的补丁才具有可靠性。

总结下来，用好 Claude Code 的核心不在于你掌握了多少高级指令，而在于你如何通过“计划确认 → 范围锁定 → 状态快照 → 报错驱动”这套流程，把 AI 限制在可控的范围内。