别急着让 agent 修好它：agent 改坏代码后的冻结、分级与逐段抢救

先划界，再讲方法。这篇指南不是本站已有的三篇邻近指南的重复。第一，《一人一 AI 的 Git 工作流》讲的是日常开发里的分支、提交信息和回滚三招，面向的是“正常开发中想回到上一个好状态”；这篇讲的是“agent 已经把工作区改坏了，你要在没提交的改动里抢救好代码”，场景不同。第二，《灰度发布与回滚实战》讲的是“已经发布到线上的版本出问题怎么整版切回去”；这篇讲的是“还没发布、还没提交的本地改动怎么逐段抢救”，对象不同。第三，《独立开发者事故响应 Runbook》讲的是“线上挂了之后 15 分钟内怎么止血、怎么对外沟通”；这篇讲的是“本地工作区被改坏之后、还没惊动用户之前怎么收拾”，阶段不同。还有一篇《一个人指挥四个 Agent 的并行开发工作流》里也提到了 worktree 隔离，但它讲的是“开工之前怎么隔离”，这篇讲的是“改坏之后怎么用隔离区做抢救”，一个是预防，一个是急救。划界说完，下面进入正题。

正题的场景你一定见过：你让 agent“顺手重构一下这个模块”，回来发现它改了 23 个文件，其中 5 个是你根本没让它碰的；测试挂了 4 个，界面上一个按钮不见了，而你已经分不清哪几处改动是好的、哪几处是坏的。最糟糕的反应，是立刻再让 agent“把它修好”。第二次改动会建立在第一次错误改动之上，错误会被越埋越深，最后连“改坏之前是什么样”都找不回来。正确的反应恰恰相反：先停手，先冻结现场，先把好代码和坏代码分开，再决定每一处改动的命运。

第 0 到 5 分钟：停手、冻结、留证

发现改坏的第一分钟，做三件事，而且只做这三件事。第一，停掉 agent。不要让它继续跑，不要让它“先把测试修好再说”，不要让它提交任何东西。一个还在运行的 agent 是现场最大的破坏源，它会在你排查的时候继续改文件。第二，冻结现场：不要执行任何清理命令，不要 git checkout，不要 git clean，不要删除文件。你的目标是保住“改坏之后、抢救之前”这个状态的完整证据。第三，留证：立刻跑 git status 和 git diff --stat，把输出保存到一个文件里；再跑 git diff 把完整差异也存一份。这两份文件就是你的现场照片，后面每一步决策都要对照它们。

留证还有一个容易漏掉的部分：agent 的执行记录。把 agent 本轮的对话记录、它声称改了什么、以及测试失败的完整报错都存下来。很多“改坏”事后复盘时才发现，agent 其实在对话里已经说了它改了某个你不希望它碰的文件，只是当时没人注意。对话记录不是用来追责的，是用来快速定位的：它告诉你应该先看哪几个文件，而不是把 23 个文件从头读一遍。

这 5 分钟里有一个绝对禁令：不要在没有备份的情况下执行任何“还原”操作。git checkout -- .、git reset --hard、git clean -fd 这类命令在平时是常用工具，在抢救现场是破坏证据的工具。一旦执行，未提交的好改动和坏改动会一起消失，你连“哪些是好的”都无从判断。记住顺序：先备份，再动手；没有备份的还原，一律不做。

第 5 到 20 分钟：给改动分级，而不是给文件分级

现场冻结之后，下一步不是逐个文件读代码，而是给改动分级。分级的单位应该是“改动”，不是“文件”，因为同一个文件里可能同时有好的改动和坏的改动。建议用三级分类法，每一级对应不同的处理方式。

A 级是“明显好的改动”：符合你原始意图、测试通过、与本次任务直接相关的改动。比如你让 agent 重构一个函数，它确实把重复代码抽成了公共函数，测试也过了，这就是 A 级。A 级的处理方式是保留，但先不提交，等全部抢救完成后再统一提交。

B 级是“可疑的改动”：你不确定它对不对，或者它超出了你给的任务范围。比如 agent 顺手改了一个你没让它碰的配置文件，或者把一个函数的签名改了但调用方没全改完。B 级的处理方式是隔离：把这部分改动单独拎出来，放到一边先不动，等 A 级和 C 级处理完之后再回头逐一判断。

C 级是“明确坏的改动”：导致测试失败、破坏界面、删除代码、改错逻辑的改动。C 级的处理方式是清除，但清除之前要先确认它没有和 A 级改动交织在同一个代码块里。如果交织了，就不能整块删除，要逐行拆分：保留 A 级的行，删除 C 级的行。这个拆分工作看起来慢，但它是整个抢救过程中最关键的一步，因为整块删除会连好代码一起扔掉，而整块保留会连坏代码一起留下来。

分级的时候还有一个特殊类别要单独拎出来：涉及密钥、token、密码、.env 文件的改动。只要 agent 的改动里出现了任何凭据信息，无论它是有意还是无意，都要立刻按“已泄露”处理：先轮换、再清理，而不是先清理、再考虑要不要轮换。凭据一旦进过 agent 的上下文或 diff，就不能假设它“还没被看到”。这一条没有例外，也没有“先看看再说”。

隔离区：用工作树把抢救和主战场分开

分级完成之后，不要直接在原工作区里动手改。正确的做法是建一个隔离区：用 git worktree 新建一个干净的工作树，指向改坏之前的那个提交，在隔离区里做抢救。这样做的好处是，原工作区保持冻结状态作为证据，隔离区作为手术台，两个地方互不干扰。即使隔离区里的操作做错了，原现场还在，可以重来。

具体步骤是这样的。先确认改坏之前的最后一个好提交是哪一个，通常就是 agent 动手之前的 HEAD。新建工作树指向那个提交，然后把原工作区里分级为 A 级的改动，以补丁的形式应用到隔离区里。应用的时候一次只应用一个文件或一个代码块，应用完立刻跑相关测试，测试通过才算这个 A 级改动真正“抢救成功”。B 级改动暂时不应用，留在清单里；C 级改动直接丢弃，不进入隔离区。

这个方法的关键点在于“一次一处、测过才算”。很多人抢救时图快，把所有 A 级改动一次性全应用过去，结果测试一挂又不知道是哪一处出的问题，等于把原来的混乱原样复制到了隔离区。慢就是快：一次应用一处，挂了就知道挂在哪一处，回退的范围也只有一个改动。隔离区的存在意义，就是让你可以用最小的代价试错，而不是在主战场上继续赌。

隔离区还有一个附带好处：它强迫你把“抢救”变成可复现的操作。隔离区里的每一步都是“应用补丁、跑测试、确认通过”这个循环的重复，整个过程可以被记录、被复查、被另一个人接手。而直接在原工作区里东改西改的过程是不可复现的，改到一半被打断就再也接不上了。

三段回滚：文件级、提交级、分支级，按顺序用

抢救过程中经常需要“回滚”，但回滚有三个级别，级别选错会扩大损失。第一级是文件级回滚：只把某一个文件恢复到改坏之前的状态，用 git checkout <好提交> -- <文件路径> 这类命令。文件级回滚的适用场景是：整个文件都是 C 级改动，或者这个文件里的 A 级改动已经在隔离区里抢救出来了。它的优点是影响范围最小，缺点是处理不了“文件里好坏交织”的情况。

第二级是代码块级回滚，也就是逐段抢救：用 git diff 找到好坏交织的代码块，手动保留好的行、删除坏的行，或者用 git checkout -p 交互式地逐段选择。这是整个抢救过程中最花时间、但也最有价值的一级，因为它决定了你最终能保住多少好代码。做代码块级回滚时，每处理完一个代码块就跑一次相关测试，不要攒到最后一起跑。攒到最后的代价是：测试一挂，你不知道是 20 个代码块里哪一个出的问题。

第三级是分支级回滚：放弃当前整个分支的工作，从好提交上另开一个新分支，把隔离区里抢救出来的 A 级改动 cherry-pick 过去。分支级回滚听起来很极端，但它是最干净的收尾方式，适用场景是：改动已经乱到分级都分不清楚，或者 agent 的改动里混入了大量无关重构，已经不值得逐段抢救。分支级回滚不是失败，它是承认“这批改动抢救成本已经高于重做成本”之后的最理性选择。判断标准很简单：如果逐段抢救预计要花的时间超过了重做 A 级改动的时间，就直接走分支级回滚，不要犹豫。

三个级别的使用顺序是固定的：先文件级，再代码块级，最后分支级。不要一上来就用分支级回滚，那等于把可能抢救的好代码也扔了；也不要在文件级就能解决的问题上用代码块级，那是浪费时间。级别选对，抢救的成本就控制住了；级别选错，抢救本身就会变成第二次破坏。

重新让 agent 进场：先给范围，再给禁区，最后给验收标准

抢救完成之后，你迟早要重新让 agent 进场做剩下的工作。但重新进场不能是“接着刚才的任务继续做”，而应该是“带着新的约束重新开始”。新的约束有三条，缺一不可。第一，范围：明确告诉 agent 本次任务只改哪几个文件、哪几个函数，超出范围的改动一律不许做。第二，禁区：明确列出绝对不许碰的文件和目录，比如配置文件、数据库迁移、认证相关代码、以及任何包含凭据的文件。禁区要写进任务描述里，而不是只写在心里。第三，验收标准：明确告诉 agent 完成的标准是什么，比如“相关测试全部通过”“不改动以下文件的公开接口”“改动文件数不超过 N 个”。没有验收标准的任务，agent 会用自己的标准来判断完成，而它的标准通常是“代码能跑起来”，不是“改动是正确的”。

重新进场时还有一个操作细节：让 agent 在隔离区里先做，做完你检查通过之后再合并到主分支，而不是直接在主分支上做。这样即使第二次又改坏了，损失范围也只在隔离区里，主分支仍然是干净的。这个习惯一旦养成，“agent 改坏”就从灾难降级成麻烦：隔离区里的麻烦可以随时丢弃重来，主分支上的灾难却要花几倍时间抢救。

最后，把这次抢救的经验写进项目的 agent 使用说明里。写什么？写这次 agent 改坏的具体模式：它是超范围改动，还是改错逻辑，还是删了不该删的代码。写你这次用的分级结果：哪些文件是禁区，哪些改动模式是高危。写你这次定的验收标准。下一次 agent 进场之前，先让它读一遍这份说明。Agent 不会自己记住教训，但写进文档的教训，它每次都会读到。

事后：30 分钟演习，把抢救变成肌肉记忆

抢救流程只有演习过才算真正掌握。建议你花 30 分钟做一次演习，不需要真的等一次改坏事故。演习的步骤是：故意在一个临时分支上让 agent 做一次超范围的重构，然后按这篇的流程走一遍——冻结、留证、分级、建隔离区、逐段抢救、重新进场。演习的目标不是把重构做对，而是把流程走熟：你能不能在 5 分钟内完成冻结和留证，能不能在 20 分钟内完成分级，能不能熟练地用工作树建隔离区。

演习结束之后，检查三个指标。第一，你的项目里有没有一份现成的 agent 禁区清单；第二，你的团队（哪怕只有你一个人）知不知道“改坏之后先冻结、再分级、最后动手”这个顺序；第三，你的项目有没有做到“每次 agent 任务之前先提交一次干净状态”，让“改坏之前的最后一个好提交”永远存在。如果这三个指标里有任何一个是否定的，演习就不算完成，补上它再结束。

最后一句话。Agent 改坏代码不是“AI 不靠谱”的证明，而是“工作方式还没跟上工具能力”的信号。工具能一次改 23 个文件，你的工作方式就必须能一次审查 23 个文件的改动；工具能在一分钟内重构一个模块，你的抢救流程就必须能在一分钟内冻结现场。把抢救流程练成习惯，agent 改坏就从“项目停摆的事故”降级成“半小时能收拾的麻烦”。而这半小时，恰恰是你作为开发者不可替代的那部分工作：判断哪些改动值得留，哪些必须扔。

附：分级清单模板，复制过去就能用

抢救时最容易乱的环节是分级，因为分级要靠判断，而判断在慌乱中最容易走样。下面是一份可以直接复制到项目文档里的分级清单模板，抢救时逐项打勾。第一项，原始任务是什么：用一句话写下来，不要写“重构一下”，要写“把某某模块的重复代码抽成公共函数，不改公开接口”。任务描述越具体，分级时判断“超范围”的标准就越清楚。第二项，改动文件清单：从 git diff --stat 里抄下来，每一个文件后面标注 A、B、C 三级中的一级，标注不出来的先标 B，不要勉强标 A 或 C。第三项，测试状态：每一个文件对应的测试是全部通过、部分失败，还是没有测试覆盖。没有测试覆盖的改动一律先标 B，因为你没有证据说它是好的。

第四项，禁区检查：清单里有没有配置文件、数据库迁移、认证代码、凭据文件这四类。只要有，立刻按特殊类别处理：凭据类先轮换再清理，其他三类先隔离再判断。第五项，交织检查：每一个文件里 A 级和 C 级改动是不是在同一个代码块里。如果是，标注“需逐行拆分”，不要整块处理。第六项，抢救顺序：先处理全部 A 级，再处理 C 级的清除，最后回头处理 B 级。这个顺序不能颠倒，因为 B 级最花时间，先处理 B 级会拖垮整个抢救节奏。把这份清单打印出来贴在显示器旁边，下次 agent 改坏时，你不需要重新想流程，只需要照着清单打勾。