北京
你大概见过这一幕：用AI编程助手做的应用出了故障，你让它修，它说修好了，可bug还在，或者又冒出第二个。你说"还是不行"，它再试一次。二十分钟后，代码更烂，额度更少，你找不到回到可用状态的路。
有人用"AI把bug越改越多""助手卡在修复循环里"这样的词去搜。这不是某一款产品的怪癖。Lovable、Replit、Cursor、Claude Code、Base44这些工具都会掉进同一个模式，因为问题出在结构上，不在工具本身。
循环长什么样
把产品品牌去掉，循环在哪都一样：运行中的应用出了问题，你用一句短消息让助手去修，比如"坏了""再试一次"，或者点一下"尝试修复"。助手给出一个听起来很自信的改动。原来的问题还在，或者旁边的东西坏了。你用同样模糊的反馈再试。每一次失败的尝试都留在对话上下文里，下一次就在噪音上推理。
不同工具用不同界面暴露这件事。有的有实打实的重试按钮，有的卡在"思考中"，有的悄悄回滚一个你已经确认过的改动。表面不同，机制相同。
四个坑，按顺序叠加
第一，上下文会随着会话变长而退化。每条消息、每个diff、每句"不对，不是这个"，都在往助手要记住的东西里加token。会话早期，它对应用的模型还比较清晰；二十轮对话之后，它是在所有发生过的事情——包括那些走错的路——的模糊平均值上工作。
第二，模糊的重试加的是噪音，不是信息。"还是坏的""再试一次""不是这个"。对你来说这像反馈，对助手来说，这是几乎没有新信号的指令。它没说哪里还坏、涉及哪个文件、"对"是什么样。助手通常会把上一次的猜测稍微变一变。所以循环经常在两个几乎一样的错误修复之间来回跳，而不是收敛。
第三，助手看不到你看到的那个应用。你在看渲染出来的页面，点着流程走。助手是在代码和你对所见之物的文字描述上推理。用文字描述界面bug是有损的。当描述和真实界面对不上，助手会为一个错误的问题去优化出一个看似合理的修复。
第四，失败的尝试会毒化下一次尝试。这才是把一次错误变成循环的原因。第二次尝试不是从零开始，它从一个已经包含第一次错误diff、你沮丧的纠正、以及助手解释自己修了什么的上下文窗口开始。第三次继承了所有这些噪音。循环是复利的，不是随机的。
合在一起看：长会话降低了精度，而你的提示恰恰在这时变得更模糊，偏偏这又是助手最需要一个干净、具体信号的时候。
五步打断循环
这些步骤都不需要换工具，它们针对的是机制本身。
- 停止喂循环。不要连续两次发"再试一次"或"还是坏的"。如果第一次重试失败了，问题不是助手需要再一次盲试，而是你的指令没带够能改变它答案的信息。第三次低信息量的提示只会加更多噪音。当你发现自己要再打一遍同样的抱怨时，停下，进入第二步。
- 回滚到最后一个已知可用的状态。在再次尝试之前，撤销失败的修复，如果循环已经跑了一阵，就撤销最近几次。不要把新尝试叠在一个坏掉的东西上，那是一个bug变成三个的方式。用工具给你的能力：Git可以checkout或restore文件、重置到可信的提交；Cursor这类IDE有本地历史或时间线；Replit、Lovable这类构建器有检查点或版本历史，恢复到最后一个好状态。只有应用回到你认得的状态，才输入新的修复请求。
- 从头重述问题，范围要精确。这是杠杆最大的一步。工具允许的话，优先开一个全新的对话或干净的线程。写一个包含这三样的提示：确切的文件或组件名，要字面路径，不是视觉描述；哪里错了，作为一个具体的可观察事实；"对"是什么样，同样要具体。弱的提示是"还是坏的，修一下提交按钮"。强的提示是：在CheckoutForm.tsx里，提交按钮调用handleSubmit，但请求失败时loading状态从不重置，提交失败后按钮一直禁用，也不显示错误信息，它应该重新启用并在按钮下方显示服务器错误字符串。第二个提示给了助手一个文件、一个行为、一个成功条件，足够它不用猜就能动手。
- 一次只改一件事。不要把"顺便把页头也修了"塞进一个修bug的提示里。那等于给助手两个问题、一份上下文预算。
这套顺序的核心不是让助手更聪明，而是别让它在噪音里继续猜。停、回滚、重述、隔离、验证，每一步都在减少它需要同时处理的东西。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
