AI编程助手越改越错？四步走出修复死循环

不少开发者都经历过这样的时刻：让AI编程助手修一个bug，改完A处，B处又出了问题；接着修B处，A处却悄悄复发了。测试红了又绿、绿了又红，你一遍遍地说“再试一次”，半小时过去，代码比开始时更乱。这不是个例，而是AI辅助开发中一种高频出现的失效模式——修复死循环。本文给出一套可以直接照做的止损流程：判断信号、立即中断、留好退路、重开会话、测试先行，帮你把失控的修复过程拉回正轨。

一、先学会判断：什么才算“死循环”

止损的前提是识别。出现下面任何一个信号，就该警觉，而不是继续催促：

• 同一处代码被反复修改，改法来回摇摆；
• 测试结果在通过与失败之间反复横跳，始终无法稳定；
• 它的改动离你最初描述的问题越来越远，开始“顺手”重构无关模块；
• 它重复提出已经被你否决过的方案，明显在兜圈子；
• 你已经发出第三次以上的“再试一次”。

这个现象的机理并不复杂：模型每一轮生成都以当前会话上下文为输入。一旦上下文被大量失败尝试填满，这些“失败噪声”会持续带偏后续输出；而缺少测试这类客观反馈时，它只能沿着噪声继续猜测，自然越改越偏。

值得说明的是，随着模型能力迭代，这种死循环比早期已经明显减少，但在长会话、模块强耦合、测试覆盖薄弱的项目里依然常见。会话越长，越要保持警惕。

二、第一步：立即中断，别让它继续跑

处理死循环的第一原则是“停”。主流智能编程工具普遍支持中途打断——终端形态的工具多用 Esc 或 Ctrl+C，图形界面的工具则提供停止按钮——中断不会丢弃会话上下文，随时可以接着继续。

停下来之后，别急着发新指令，先花两分钟看清它刚才做了什么：

• 哪些文件被改动；
• 改动是否波及了任务范围之外的代码；
• 有没有为了“让测试通过”而弱化断言、吞掉异常之类的危险操作。

此时最不该做的事，就是再发一条“再试一次”。那等于让它带着同样的错误假设和同样的上下文噪声继续猜，结果大概率只是死循环的下一轮。

三、第二步：用版本控制留好退路

看清现场之后，先把现场固化。无论使用哪种版本控制系统，这一步的动作都是固定的三件事：

1. 查看状态：列出所有被改动的文件，确认改动范围；
2. 逐行比对差异：认真检查每一处改动，判断其价值；
3. 分类处置：有价值的改动分块暂存后立即提交；价值存疑的临时贮藏起来；明显破坏性的，直接回退到上一个健康提交。

原则很简单——让任何一个时刻的代码，都能退回到已知的良好状态。

如今不少智能编程工具还内置了会话级回退能力：每轮对话自动生成检查点，可以按需回退代码、回退对话，或两者同时回退。这类功能很好用，但三个局限必须心里有数：

1. 通过命令行方式产生的文件变动（删除、移动、覆盖等）通常不在检查点追踪范围内，退不回去；
2. 子任务代理代为修改的文件，往往也难以回退；
3. 各家工具的官方说明基本一致：检查点不能替代版本控制。

结论：版本控制兜底，工具回退只当辅助。真正可靠的退路，永远是你自己维护的提交历史。

四、第三步：清理上下文，带着结论重开会话

一条被反复验证的经验法则：同一个问题纠正超过两次，会话里就堆满了失败尝试，此时继续纠正的边际收益趋近于零。正确做法是清空上下文、重开会话，用一份吸收了教训、信息更具体的新提示重新描述任务。绝大多数场景下，“干净会话＋更准确的提示”都优于“堆满纠正的长会话”。

具体操作分三个层次：

• 彻底重开：新建会话。旧对话不会丢，主流工具都提供历史会话列表，随时可以找回；
• 只压缩、不重开：如果上下文只是偏长、还没开始绕晕，可以使用工具提供的上下文压缩能力，并附上需要保留的重点，例如“保留与接口改动相关的结论，其余从简”；
• 无论哪种方式，重开时都不要把聊天记录整段贴回去，只带结论。

下面这份提示模板可以直接套用：

问题：<症状描述 + 报错原文>
复现：<具体命令或操作步骤>，当前可稳定复现
期望：<修复后的正确行为>
已试过：<只写结论，如"修改模块X后接口Y会超时">
约束：
- 只允许修改 <指定文件或模块>
- 不允许修改已有测试
- 不允许吞掉异常或跳过测试步骤
执行步骤：
1. 先写一个能复现该问题的失败测试，运行并展示它失败
2. 先不要改代码，说明根因、影响范围、准备修改哪几个文件
3. 经我确认后再动手，改完运行全部测试

这份模板把模型最容易犯的几类错误——擅自扩大改动范围、重复失败路径、掩盖问题——用“约束”和“步骤”两个字段逐一封死。

五、第四步：先写失败测试，再让它动手

这是整套流程里分量最重的一步，也是打破死循环的支点。

道理在于：死循环的本质是缺少客观反馈，模型只能靠猜来逼近答案。而一个能复现bug的失败测试，恰好提供了最可靠的外部信号——修复前它是红的，修复后变绿，问题是否解决一目了然，不再依赖任何人的口头判断。

执行上有一条硬性标准：测试必须先跑红。如果新写的“复现测试”直接就是绿的，说明复现根本没成立，此时它动手修的多半是另一个问题，一切努力都是无效功。

示意代码（以优惠券与会员折扣叠加导致应付金额为负为例）：

def test_payable_amount_should_not_be_negative():
    # 复现：优惠叠加后，应付金额出现负数
    order = Order(amount=100, coupon=COUPON_50_OFF, vip_level=3)
    assert order.payable() >= 0   # 修复前：断言失败（红）；修复后：通过（绿）

失败测试之外还有一层长期价值：修复合入后，它会沉淀为回归防护，防止同一个bug在未来的重构中再次出现。很多“改一个坏一个”的项目，根源恰恰是回归防护缺失——每次修复都不留护栏，旧问题自然反复爬回来。

六、修完之后：别省收尾动作

测试转绿不等于可以直接合入，收尾三件事省不得：

• 跑全量测试，而不是只跑相关模块，确认没有跨模块的连带破坏；
• 亲自逐行审查本次差异，重点检查有没有“顺手”改动无关代码、有没有静默吞异常、有没有为了过测试而放宽断言；
• 提交信息写清“根因是什么、怎么修的”，为下一次排查留路。

团队协作场景下，还可以把这道防线前移到云端：借助百度智能云等云平台的容器平台与持续集成能力，把全量测试接入提交触发的流水线，让“修一个引入一个”的问题在合入主分支之前就被自动化测试拦下，而不是流到线上再返工。

七、从源头减少死循环

四步止损之外，日常习惯决定了死循环出现的频率：

1. 任务拆小。一次只让它做一件事，一个会话只追一个目标；
2. 约束前置。在最初的提示里写明改动范围与验收标准，而不是等它跑偏后再纠正；
3. 小步提交。每完成一个小步骤就提交一次，任何时刻坏状态的影响半径都只有一个提交；
4. 会话卫生。长会话定期总结沉淀、及时重开，别让上下文变成失败尝试的坟场；
5. 补齐测试覆盖。测试越可靠，AI得到的反馈越准确，死循环天然减少。

写在最后

AI编程助手陷入“改一个坏一个”的死循环，表面看是模型不给力，本质上是反馈回路的缺失：没有版本控制留退路，没有干净的上下文做输入，没有测试做裁决，模型只能在噪声里打转。立即中断、固化现场、重开会话、失败测试先行——这套流程的核心，是在AI与你的代码之间重新建立可靠的反馈回路。回路一旦建立，死循环自然就断了。