一份代理词，AI改了四版，但最好的那版消失了。
这个场景，你可能经历过，或者，正在经历。
代理词起草完毕，让 Claude 改了一版，逻辑更流畅了；又让它再润色，引用的法条更准了；第三版加了情节，说理有点过头；第四版收回来，但语气又变生硬了。
然后你盯着屏幕，突然想起来——第二版其实是最好的。
但第二版已经不在了。文件只有一份，每次保存都覆盖上一次。
其实最近一次 Claude 的修改你也是可以看到记录的，但是随着改变的增多，就面目全非，再也回不到以前了。
再比如另一种情况：让 AI 改了一段事实陈述，总觉得读起来哪里不对，但又说不清楚。想知道 AI 到底动了哪里——不知道。只能一字一字地对着原稿重新核对。
这两个问题，涉及到重复审核的Dirty Work, Git 都能解。
再也不会让你的电脑里存在v1、v2、v3、v4，修订版、清洁版这种低效的内容，而且能随时回退。
Git 是什么？
很多人听到 Git 就以为是程序员专用的东西。其实它做的事很简单：记住你每一个历史版本，随时让你回退，随时让你看两版之间改了什么。
Word 也有"修订模式" ，能显示哪段话被删了、哪段话被加进来。 Git 做的是同样的事，但更强大 ——Word 修订模式你一旦接受，原版就消失了。Git 记录的是你每次主动存档的状态，每个版本都有时间戳和你写的备注，永远可以翻回去看。
每次"存当前这一版"叫做一次 commit（提交）。 你给这次提交写一句话说明："第一稿——事实陈述部分""Claude 润色后——语气修改版""加入最高院指导案例引用"。之后你随时知道每一步做了什么、改了什么。
Git 和 Markdown 是天生的搭档。
Markdown 是纯文字文件， Git 可以精确到每一行每一个字，显示两个版本之间的差异。 Word 文档是二进制格式，Git 能对比，但看不到清晰的文字差异；Markdown 就是文本，改了哪个字一目了然。
这也是为什么 法律人学Claude｜第八期：法律人的文档革命——你必须学会Markdown 反复提到，要把文书底稿存成 Markdown 的原因——不只是为了喂给 Claude，也是为了用 Git 管理起来。
三个场景，三个操作
场景一：AI 改坏了，想回到上一版
文书改着改着不对劲，想还原。
直接告诉 Claude："请把这份代理词还原到上一次提交的版本。"
Claude 会找到最近一次 commit，把文件还原回去。你什么都不用记，就一句话。
场景二：AI 改了哪里？用 diff 逐字核对
让 Claude 改完之后，你想知道它动了哪里。
告诉 Claude："请对比当前版本和上一次提交，列出所有变化的地方。"
Claude 会调用 Git 的 diff（差异对比）功能，输出两个版本之间的每一处不同。格式大概是这样：
前面带 - 号的行，是被删掉的内容（原版）；前面带 + 号的行，是新加进来的内容（改后）。没有变化的段落照原样显示。
举个例子，Claude 润色之后的 diff 输出可能长这样：
- 被告李四于2023年3月签署合同后，未依约履行付款义务。
+ 被告李四于2023年3月签署《工程承包合同》后，迟迟未依约履行付款义务，经原告多次催告仍无果。
一眼就能看出：AI 在"合同"后面补了合同名称，在后半句加了"迟迟"和"经原告多次催告仍无果"。这是你想要的改动，还是过度演绎了？自己判断。
VSCode 里还有更直观的方式：打开 Source Control 面板（左侧边栏的分叉图标），点击任何一个被修改的文件，右侧就会显示左右两栏对比——左边是改前，右边是改后，删改内容用颜色高亮。不用看 diff 符号，看颜色就行。
场景三：给文书建立清晰的修改历史
代理词从起草到庭审，可能经历"第一稿-证据补充-法条修订-庭前最终版"四个阶段。
每个阶段结束后，告诉 Claude："请帮我提交当前文件，说明是'庭前最终版，加入了最高院2024年第X号指导案例引用'。"
Claude 自动执行。之后任何时候，你都可以查这份文书的完整修改历史，精确到每一次改动。
怎么开始用？三步建立 Git 工作区
第一步：让 Claude 初始化 Git
打开你的案件文件夹，告诉 Claude："请在这个工作区初始化 Git，并把现有文件全部提交，说明是'初始版本——案件材料导入'。"
Claude 会完成所有操作。你不需要记任何命令。
第二步：每次修改完，记得提交
文书改完一个阶段，就告诉 Claude 提交一次。养成这个习惯，版本历史自然就积累起来了。
不需要每次保存都提交。但每次有实质性变化的时候值得提交一次——比如结构调整完、法条修改完、交给当事人审阅之前。
第三步：查看历史或回退时，直接说
"请列出这份代理词的所有修改记录。"
"请把答辩状还原到三天前的XX版本。"
"请对比答辩状当前版本和上周五提交的版本，列出所有改动。"
Claude 会处理好，给你看结果。
进阶：创建一个"提交存档"Skill
如果你每次都要手动说"请帮我提交"，时间久了也嫌麻烦。
可以用 /skill-creator （第九期介绍过 法律人学Claude｜第九期：给自己定制一个审合同Skill——Skill详解 ）创建一个专用的提交 Skill，起名叫 /save-version 。
告诉 skill-creator："我需要一个命令，每次输入 /save-version ，Claude 都会问我这次修改的说明是什么，然后自动把当前工作区的变化提交到 Git，并给我显示提交成功的确认。"
以后每次要存档，输入 /save-version ，写一句说明，搞定。有痕迹，查得到。
下面是我使用 /save-version 修改一份法律文书的示例：
第一稿 ： 事实陈述+基本法律框架
Claude润色版 ： 优化语气，补充合同名称，法条改为引用原文
庭前定稿：加入最高院买卖合同司法解释，反驳违约金过高抗辩
每一个过程都很清晰，每一次commit为什么提交，都能找到记录。
常见问题
Q： Git 会占很多硬盘空间吗？不会。
A： Git 存储的是"差异"，不是每次都把整份文件复制一遍。一份 20 页代理词改了 100 次，也不过多占用几 MB。
Q： 我不需要团队协作，自己用也有必要吗？
A： 有。光是"AI 改坏可以回退"这一条，就够用了。很多人养成这个习惯之后，发现最大的价值其实是心理安全感——可以放心让 Claude 大改，知道随时能回去。
Q： 提交说明一定要写得很详细吗？
A： 不需要。"第一稿""加了违约金部分""庭前定稿"这种级别已经足够。简短，能让未来的你看到这条记录知道那次做了什么就行。
Q： 我已经有的文书，没有 Git 历史，怎么办？
A： 从现在开始初始化就好。第一次提交写"导入现有材料"，从这个时间点往后开始记录。已有的历史追不回来，但从今天起是干净的。
Q： Claude 操作 Git 会不会出错？
A： 偶尔会。Claude 执行 Git 操作前，会告诉你它要做什么，你确认后再执行。遇到不确定的情况，它也会先问你。不用担心它悄悄做了什么你不知道的事。
往期回顾
法律人学Claude｜第一期：桌面版已经很好用了，为什么我还是力推 VSCode 插件版？
法律人学Claude｜第二期：半小时装好 VSCode + Claude Code
法律人学Claude｜第三期：让Claude更高效读懂你的文件
法律人学Claude｜第四期：你的项目助理—CLAUDE.md使用指南
法律人学Claude｜第五期：让Claude用上次抛App——Skills初解
法律人学Claude｜第六期：不做8秒记忆的金鱼——优化记忆Memory
法律人学Claude｜第七期：给Claude装上"外挂"——CLI与MCP工具使用指南
法律人学Claude｜第八期：法律人的文档革命——你必须学会Markdown
法律人学Claude｜第九期：给自己定制一个审合同Skill——Skill详解
对了，我建了一个交流群，有想 进群 的伙伴可以 加我 。