如何保障 AI 代码修改的可恢复性，并设计 Git 快照与回滚？

核心回答

可恢复的关键是保存 AI 修改前的真实工作区基线，而不只是记住当前 HEAD。开始时记录提交号、已暂存和未暂存差异、未跟踪文件及本次允许修改范围；恢复时只撤回本次错误，保留原有改动和之后仍有效的工作。

怎样保存基线

先用 git status --short、git diff、git diff --cached 了解三种状态。保存差异时可用 --binary 保留二进制补丁；另存文件清单、原始内容与必要权限信息。未跟踪和被忽略文件不在普通差异里，若任务需要保护，须明确备份范围；敏感文件不应因此被加入公开仓库。

已跟踪文件可以用 git stash create 生成不清空工作区的快照对象，并用 git stash store 保存引用以便后续找回；这不是未跟踪文件的完整备份。普通 git stash push 会保存并移走当前改动，-u 还包含未跟踪文件，不能在不了解现场时直接使用。

按范围恢复，而不是回到一个旧提交

• 文件从基线后只有这次错误改动时，可在核对后从快照恢复该文件的工作区内容。
• 同一文件混有原有或后续有效修改时，逐段恢复或反向应用本次补丁，不能用整文件替换。
• 工作区和暂存区要分别处理。git restore --source=<快照> --worktree -- <文件> 不会同步修改暂存区；--staged 则会修改索引。不能因为恢复正文就顺带清空别人的暂存内容。

例如基线里已经有一处暂存修改和另一处未暂存修改，AI 又误改了第三处，直接恢复到 HEAD 会丢掉前两处。正确目标是撤回第三处，同时保留前两处原来的内容和状态。

已提交、外部状态与恢复验证

若错误已是独立提交，可以评估用 git revert 形成反向提交，保留共享历史；混杂提交先拆清范围。git reset --hard 和 git clean 会影响更广的内容，不适合作为默认恢复操作。

恢复后比对文件内容、暂存与未暂存差异，再运行相关检查。Git 恢复代码并不会回滚已经执行的数据库迁移、发出的消息或线上变更，这些状态需要各自的恢复方案。

参考资料