回滚演练：改错了怎么退回去

真实项目里使用 Claude Code，必须知道改错了怎么收敛和回滚。先学会看状态、保留成果、放弃越界改动，再继续下一步。

会让 Claude Code 改代码，只是第一步。真正进入真实项目之前，还要会处理“改错了怎么办”。

回滚不是失败，而是工程安全的一部分。能安全回滚，才敢放心试小步改动。

不懂 Git 状态、不看 diff、不会回滚时，不建议让 CC 在真实项目里做大范围修改。

先暂停，不要继续补救

发现 CC 改错时，最忌讳继续让它“再帮我修一下”。如果上下文已经乱了，继续补救可能越改越大。

先这样说：

先暂停，不要继续修改文件。

请只读汇总当前状态：
1. 原始任务目标是什么。
2. 当前已经修改了哪些文件。
3. 哪些改动看起来符合目标。
4. 哪些改动可能越界或错误。
5. 是否建议回滚部分或全部改动。

这一步的目标是把局面说清楚。

不是所有问题都要全部退回。

可以让 CC 先判断：

请判断应该局部回滚、阶段回滚还是全部回滚。

要求：
1. 不要执行回滚。
2. 先说明依据。
3. 列出建议保留的文件。
4. 列出建议退回的文件。
5. 给出回滚后的下一步计划。

先判断，再操作。

有些任务虽然失败，但可能有部分成果值得保留：

可以这样让 CC 分类：

请把当前改动分成三类：
1. 建议保留。
2. 建议回滚。
3. 需要人工确认。

每一项都要说明理由，不要直接操作。

这能避免把有价值的成果一起丢掉。

回滚前应该先留下任务现场，方便复盘。

在回滚前，请先生成一份复盘记录：
1. 原始目标。
2. 为什么当前方案不合适。
3. 已经确认的事实。
4. 要保留的经验。
5. 下一次应该如何重新开始。

这份记录可以放在当前对话里，不一定写进项目文件。

如果不熟悉 Git，先不要让 CC 自动执行回滚。可以让它只给建议：

请只给回滚方案，不要执行命令。

请说明：
1. 哪些文件建议回滚。
2. 哪些文件建议保留。
3. 如果手动处理，应该先看哪几个 diff。
4. 回滚后如何重新验证项目状态。

等用户确认后，再进行下一步。

回滚后不要原样重复同一个任务。应该重新进入 Plan Mode，缩小范围。

已经回滚到安全状态。

请重新进入 Plan Mode：
1. 复述原始目标。
2. 只选择最小可行的一步。
3. 明确不做哪些事情。
4. 给出本步验收方式。
5. 等确认后再修改。

失败后的第二次计划，应该比第一次更小。

出现下面情况，建议全部回滚本轮修改：

看不懂 diff 时，不要硬着头皮继续。

回滚阶段最怕“边退边改”。这会让状态更难判断。

不要做这些事：

更稳的方式是：先把当前状态冻结，确认要保留和要回退的部分，再进入下一轮计划。

回滚完成后，也要验证项目是否回到安全状态。

回滚后请做安全状态检查。

请确认：
1. 当前还有哪些文件处于修改状态。
2. 是否还有无关改动残留。
3. 是否还有构建、测试或格式化问题。
4. 是否还有临时文件。
5. 是否可以重新开始一个更小的任务。

回滚不是把问题藏起来，而是把项目恢复到能继续工作的状态。

可以在练习项目里专门做一次演练：

请帮我做一次回滚演练。

要求：
1. 先说明当前 Git 状态。
2. 假设刚才有一处越界改动。
3. 演示如何识别应该保留和回滚的文件。
4. 不要真正执行破坏性操作。
5. 最后总结真实项目里应该怎么处理。

练习过一次，真实项目里就不会慌。