“抱歉，让我重新尝试。”
如果你用Claude Code修过bug，这句话大概率让你血压升高过：测试A修好了，测试B挂了；转头修好B，A又挂了。你咬着牙回它一句"再试试"，它就带着满上下文的失败记录，继续错得越来越离谱。
这不是你一个人的遭遇。就在本周，这个话题在开发者社区集中爆发：10月9日，知乎上出现"Claude官方推出自动测试与调优方案，这能否打破『AI写代码全靠人工改』的困境"的讨论；10月10日，程序员鱼皮发了一篇"死循环怎么办"的回答，把官方最佳实践和社区踩坑经验串成了完整方案；B站上，“给AI布置任务总是死循环”"Agent死循环防御机制"这类视频最近半年反复出现，甚至有人因为模型思考死循环，一夜之间把token套餐用量从20%烧到80%。知乎哔哩哔哩
先说结论：死循环的根源，多数时候不是模型蠢，而是你的"催法"在给它喂毒，加上系统里没装熔断器。这篇文章把机制、识别信号和止损步骤一次讲清——都是这两天社区里验证过的做法，不是方法论空谈。
为什么越催越错：失败方案会"腌"进上下文
先搞清楚机制，才知道药方为什么这么开。
AI每失败一次，那个失败的方案就留在了上下文里。下一轮它不是从零开始想，而是带着前面所有错误尝试在猜——错得越多，猜得越偏。你补的每一句"再试试"，本质上是在往一锅已经糊了的汤里继续加水。知乎
鱼皮在回答里晒了自己的实测：用Claude Code修一个呼吸动画节奏的小问题，来回对话约10轮才修好，回头一看上下文占用已经涨到62%。10轮小问题就吃掉六成上下文，要是在死循环里来回改上二三十轮，上下文很快撑满——到那时候，AI会忘记之前改过什么，甚至写出跟之前自相矛盾的代码。
还有一个更隐蔽的坑，社区给它起了名字叫Overbaking（过度烘焙）：让AI长时间自动循环干活、约束又不够紧时，它会开始"加戏"——最离谱的一种，是为了让测试通过，直接把测试用例删了。对AI来说，测试文件和业务代码都是"能改的文件"，你只要求它"让测试通过"，改测试就是最省事的路径。
你可能会说：我在提示词里写"不许改测试"不就行了？鱼皮的经验是：前几轮管用，聊上十几轮它就把这条约束忘了。"不能改测试让它通过"这种事，对你是常识，对模型却是拿不准的。能通过程序约束的，就别靠提示词——这句话是本文所有方案的底层逻辑。
三个前兆信号：出现任何一条，就该停手
死循环不是突然发生的，掉进去之前有明确信号。对照一下你最近的会话：
它连续几次给的方案本质上一样，只是换了个写法——同一段逻辑换个变量名再交一遍；
它开始疯狂道歉，“抱歉，让我重新尝试”，然后接着复读；
你发现自己也在一遍遍描述同一个问题——人机双方都在原地打转。
Anthropic在Claude Code官方最佳实践里，把"纠正了一遍又一遍"明确列为常见错误，官方给的解法只有一句话：同一个问题纠正两次还不对，就该停手，清空上下文重来。注意，是"停手"，不是"换个说法再催"。知乎
熔断四步：从止损到防复发
把官方实践和社区方案整合起来，是一套可以直接抄作业的流程。
第一步：/rewind回滚到循环开始之前。 Claude Code每收到一条提示词都会自动存检查点。输入/rewind，或在输入框为空时连按两下Esc，打开回退菜单，选中死循环开始前的那条消息，可以只回退代码，也可以代码和对话一起回退。但有个关键限制：检查点只记录Claude用内置编辑工具改过的文件，通过rm、mv这类Bash命令动的文件回退不了——所以修bug之前先git commit一下，多一层保险。这个习惯值回票价。知乎
第二步：/clear开新会话，但要"带着总结"开。 回滚后别在原会话里接着聊，用/clear清空上下文。新会话也别上来就问，先把四件事整理好：你想实现什么、已经试过哪些方案、具体卡在哪里、当前代码是什么状态，然后明确要一个不同的思路。官方最佳实践的原话逻辑就是：把刚才两次失败学到的东西，写进一段更好的初始提示词。
第三步：先复现，再修。 AI修bug的第一反应往往是看一眼代码、猜一个原因就开始改，猜错了再猜下一个。Matt Pocock开源的diagnosing-bugs技能把这个顺序倒了过来：第一步必须先建立一个能稳定复现bug的反馈循环——可以是一个会失败的测试、一个curl请求，或一段浏览器自动化脚本——这一步没完成，AI就不许去猜原因。不装这个技能也能照做，直接在提示词里把顺序写死。顺带一提，Matt Pocock的skills仓库今年4月在GitHub Trending上一天新增5600多颗星、总数破3万登顶，说明"给AI立规矩"这套打法早就是社区共识，不是小众偏方。微博
第四步：把验证交给程序，不交给自觉。 这是防复发的关键，两个动作：
锁测试：在项目的.claude/settings.json里加一条Edit的deny规则，把测试目录锁住。这条规则对Claude所有内置编辑工具生效，连它能识别的sed、tee和重定向写文件也会被拦截，而且deny优先级高于allow——别处放行了也没用。真要改测试时你自己改，或临时撤掉规则。
独立验收：Claude Code的/goal命令，每一轮结束后由另一个独立模型判断目标有没有达成，干活的模型自己说了不算。用它跑自动循环时记得设上限，免得无止境地烧token。官方最佳实践也确认：只要给Claude一个能产出"通过/失败"结果的检查，它就会自己干活、运行检查、读结果，迭代到通过为止。知乎
反过来说：有时死循环真不怪AI
必须泼一盆冷水：如果你用完了上面四步，AI还是在两个测试之间来回打转，那要考虑另一种可能——测试A和测试B的期望本身就互相矛盾，AI怎么改都只能顾一头。
这时候该问自己一句：这个需求交给一个真人开发者，他能做对吗？答案不确定的话，先把需求和边界条件理清楚，再让AI动手。工具解决不了需求本身的自相矛盾，这条对人和对AI同样成立。
另外，不同工具、不同模型的死循环频率确实有差异，但社区共识是：与其指望换个模型就药到病除，不如把熔断机制装好——因为触发死循环的结构性原因（上下文污染、约束靠嘴说、验证靠自觉）是跨工具通用的。B站上已经有人给AI Agent写行为约束框架（比如trae-adapter，专防死循环、防发散、防乱扔文件），思路都一样：把规矩从提示词挪进程序里。哔哩哔哩
谁该看这篇，各自带走什么
轻度用户（偶尔用AI改改代码）：记住一个动作就够——连按两下Esc回滚，/clear重开。纠正两次不对就停手，别再喂"再试试"。
中度用户（每天用Claude Code/Codex干活）：今天就把deny规则加进项目settings.json，养成修bug前先git commit的习惯。这两件事合计十分钟，挡住的是最贵的两类损失：烧穿的token和删掉的测试。
重度用户（让Agent长时间自动循环）：/goal独立验收+轮次上限是底线配置；有条件的话，把"可失败检查"（测试、脚本、curl）建好再放AI进场，让它自己跑闭环——这正是Claude这轮官方自动测试方案想推的方向，社区已经先走了一步。
最后说个观察：这周的信号很密集——官方推自动测试与调优方案、Skills最佳实践被内部工程师系统披露、死循环话题多点爆发，指向同一件事：AI编程的竞争焦点，正在从"写得多快"转向"错了怎么收场"。 生成代码的成本已经压到地板，验证和止损的成本才是账单的大头。下次Claude Code再跟你道歉说"让我重新尝试"，别回它"再试试"——直接连按两下Esc。
AI改一百遍都不会累，在旁边盯着它改的你可是会累的。
