Interview AiBoxInterview AiBox 实时 AI 助手，让你自信应答每一场面试
Agent 把代码改坏后，强候选人如何止损、回滚和重做
Agent 改坏代码怎么回滚，才能在 AI 编程面试里真正止损？面对 Diff 膨胀、连续故障和脏工作树，本文教你及时叫停、保存失败证据，区分工作区恢复、提交反转与干净分支，再把原任务缩成一个可证伪的小实验，同时说明本地回退无法消除的外部副作用。
- sellAI 洞察
- sell面试技巧
第一版 Patch 测试失败，Agent 又补一版，结果另一个用例也红了。Diff 越来越大，你对代码的理解却越来越少。此时最危险的不是失败，而是继续让 Agent “再试一次”，直到碰巧出现绿色。
强候选人的恢复不是手速，而是控制：先阻止错误继续扩散，保留失败证据，回到已知好边界，再把下一步缩成可证伪的小实验。Git 对恢复工作树内容和反转已提交变更提供不同机制，GitHub 也把 branch 作为隔离开发线；真正的难点不是背命令，而是先认清你要恢复哪种状态。
越修越坏的三个现场信号
第一个信号是范围失控。原本只改一个状态判断，Diff 却开始触碰配置、依赖、公共 helper 或无关测试。
第二个信号是故障漂移。每次修复都让原错误消失，却制造一个新的不相关错误。此时代码和假设同时变化，已经无法建立因果关系。
第三个信号是证据即将被破坏。Agent 想清日志、删生成文件、批量恢复或重写测试，而这些内容恰好是定位问题需要的线索。
题目规模暗中升级也应叫停。局部 Bug 突然需要 schema、API contract、新依赖或远程副作用，已经不是继续补 Prompt 能解决的同一任务。AI Debugging Framework 适合更广的诊断，而这里先解决的是如何阻止 Agent 继续扩大仓库损坏。
先留证据，再决定回到哪里
不要立刻把屏幕“清干净”。回退前至少留下失败命令与第一条相关错误、当前 status 与被触碰文件、聚焦 Diff 或提交引用、最近一次已知好行为，以及 Agent 输出里仍有价值的诊断。
若怀疑环境问题，再补依赖、端口、fixture、生成文件和开场已有失败。涉及联网或外部服务时，还要承认本地日志可能看不到全部副作用。
这张失败现场收据的作用，是让后续恢复有因果依据。可以借鉴 面试错题恢复循环 的思路：先承认当前路径没有带来可靠学习，再重建问题，而不是用更快的操作掩盖失控。
工作区回退与提交回滚为什么不能混用
先给当前状态命名，再选动作。
未提交本地改动。 分清哪些属于本次失败，哪些在面试开始前就存在。只恢复明确归属本轮的文件或 hunk，不能默认整个 worktree 都可丢弃。
已经提交的坏改动。 某些流程中，用新的反向提交保留历史更可审查；是否合适取决于题目流程和仓库规则。
被试验污染的分支。 回到干净 branch 或 checkpoint，再只重放有证据支持的部分，通常比在大量猜测修改里逐行拆除更安全。
正确恢复不是选择最快的命令，而是最小范围地回到已知状态，同时不毁掉他人工作和诊断证据。不要把 restore、revert、切分支和丢弃全部改动当成同义词。
脏工作树里尤其要按归属恢复。假设开场已有一个用户修改，而 Agent 又改了同一文件的另一段；整文件回退会误删前者。此时应先审聚焦 Diff，只处理本轮明确拥有的 hunk。归属无法确认，就停下来询问，而不是猜整个文件都可丢弃。
把失败转成一次更小的验证实验
回到已知好状态后，不要让 Agent “更努力”，而要同时缩小假设与写入范围。
不要再说“修复提交问题”。改成：“我怀疑重复事件从 pending 分支进入。先加一个复现；只有复现证实后，才修改这一处 guard。”第二次写入前再用调用点确认入口，点名预期文件，指定修复前应红、修复后应绿的第一条检查，并设置假设不成立就暂停的条件。
例如 Agent 为修复缓存失效扩大到公共 helper，导致三个无关模块失败。恢复后先用一个测试证明特定 key 更新后仍返回旧值，再只修改目标模块的失效调用。复现不成立，就停止这个假设，不再用更大 Patch 换偶然绿色。
这才是与第一次不同的尝试：不是要求模型再猜一次，而是设计一个能推翻自己判断的小实验。
最小实验还要限制观察窗口。一次只改变一个 guard 或一个调用参数，只运行能回答当前假设的检查，并在开始前写明失败后回到哪里。若复现没有出现，不要马上换第二个实现；先确认输入、状态与调用路径是否真的进入目标分支，否则所谓“重新规划”仍是在未知基线上碰运气。
本地代码回滚，为什么不等于外部事故恢复
部署、消息、数据库写入、缓存失效请求和密钥泄露，不会被本地文件回退自动撤销。Git 只能改变仓库状态，不能召回已经发出的数据或取消远端副作用。
失败步骤若调用过远端 API，现场至少要点名外部动作、查询实际状态，并说明可能需要补偿请求、数据修正、凭证轮换或人工升级。无法执行时，就把它列为未关闭风险，不能用“代码已回滚”替代事件结论。
如果外部动作可能重复，恢复计划还要考虑幂等性。不要在状态未知时再次发送同一请求来“确认是否好了”；先查询服务端记录或使用已有请求标识，避免恢复动作本身制造第二次副作用。
仓库重新变绿也不代表需求完成。可能仍有 untracked 生成文件、后台进程、缓存或原始 Bug。回滚的价值是恢复稳定与可解释状态，为下一次安全尝试创造条件。
为什么主动叫停反而是强信号
面试官需要的是因果故事，不是整洁表面。保留错误、说明变更归属、回到已知边界，比迅速把屏幕清成绿色更可信。
他们会特别看你是否保护脏工作树里的他人改动。一个能删掉 Agent Patch 的宽泛命令，也可能删掉用户自己的工作；这不是速度问题，而是所有权问题。
他们还会比较第二版计划是否真的缩小。只是把同一要求写得更强硬不算恢复；新的假设必须能被一个小测试证伪。准备时可以用 Interview AiBox 回放一次 Agentic mock，把最早遗漏的叫停信号变成下次清单，但真实恢复仍要依据当前仓库与实际证据。
恢复速度当然重要，但顺序更重要。先停、留证据、定边界，再回退和重做，通常比连续发三条修复 Prompt 更快得到可信结果，因为每一步都减少变量，而不是把新的猜测叠在旧失败上。
一段失败后重新开工的现场话术
叫停时可以说：
“最新 Patch 已超出我理解的行为范围，并引入第二个故障，所以我先停止修改。我会保留失败命令和 Diff，确认哪些文件属于本次尝试，只把这些内容带回上一个已知好状态。随后用定向测试复现原问题，再围绕被确认的分支重新规划。”
恢复后可以说：
“无关改动已移除，基线测试回到原结果，失败输出也保留了。下一次实验只触碰一个 guard 和一个测试；如果测试不能证实假设，我会再次停下，而不是扩大 Patch。远端副作用尚未被本地回退验证，我会单独列为残余风险。”
这段话不需要背诵，关键是按顺序交代失败信号、叫停理由、保留证据、恢复边界与更小实验。面试结束后，可用 面试复盘指南 把它整理成下轮可复用的停止条件。
常见问题
主动叫停 Agent 会不会显得我失败了？
不会。没有可靠学习还继续扩大改动，才是失控。及时叫停、保留证据并给出更小实验，反而展示判断力。
Restore 和 Revert 有什么区别？
概念上，restore 常用于调整工作树内容，revert 会记录一个新的反向提交。具体行为受状态和参数影响，执行前必须看当前仓库与官方文档。
仓库开场就不干净怎么办？
先标记已有改动，只触碰失败尝试明确拥有的文件和 hunk。归属不清就暂停询问，不要自行丢弃。
回滚后还要继续做原题吗？
只有时间和证据支持更小安全尝试时才继续。一次干净、诚实的恢复加精确下一步，优于赶出无法验证的第二版 Patch。
参考来源
下一步
- 查看 Interview AiBox 功能全景
- 关注 产品路线图 中的工作流改进
- 用 现场 Agent Patch 测试指南 选择恢复后的证据
- 下载 Interview AiBox
Interview AiBoxInterview AiBox — 面试搭档
不只是准备，更是实时陪练
Interview AiBox 在面试过程中提供实时屏幕提示、AI 模拟面试和智能复盘，让你每一次回答都更有信心。
AI 助读
一键发送到常用 AI
智能总结
深度解读
考点定位
思路启发
分享文章
复制链接，或一键分享到常用平台
