为什么 AI 喜欢版本可追溯？

"AI 喜欢系列"写到第七篇，一个被反复触及但从未单独展开的线索浮了出来。

先说"不喜欢"那边。.docx——Git 看到它只会说 Binary files differ。PDF——同上。.xlsx——同上。.pptx——还是同上。四个格式，一个毛病：改了一个字，机器看不出来哪里变了。你问 Git"这次改了什么"，它答"变了"——然后沉默。

再看"喜欢"那边。Markdown——改一个字就是一行 diff。HTML + JSON——同样。CSV——- 1034 变成 + 1035，精确到单元格。三个格式，一个共性：每次修改都是可定位、可理解、可回滚的。

这几篇文章表面在讨论格式，实质在讨论同一个东西：信息的可计算性。内容可检索是第一根支柱。结构可解析是第二根。版本可追溯是第三根——也是这篇文章要单独展开的那一根。

一句话：AI 喜欢的不是某个格式，而是"可审计的修改记录"。

为什么 AI 需要知道"什么变了"

AI 处理信息的方式和人不完全一样。人打开一份合同，扫一眼就能判断"第三页第五条改了两个字"——在人的感知里，文件是一个空间结构，"那里"和"这里"是不同的位置。AI 没有这个直觉。AI 读文件，文件就是一串字节。

一字节之差，在二进制格式（.docx、.xlsx、.pptx）里，"改了一个字"和"重写了一遍"对于 AI 来说没有区别。整份文件的哈希值全变了，AI 只能重新解析、重新理解全部内容。这不仅是效率问题，更根本的是：AI 无法做增量理解。

纯文本格式就完全不同。Git diff 会精确告诉 AI："第 47 行，'甲方承担全部责任' 改成了 '甲方承担主要责任'"。AI 不需要重新理解整份合同，只需要分析这两个字差了什么——从"全部"到"主要"，责任边界变了。增量理解的意思就在这儿：只处理变化的部分，把计算力花在判断变化的影响上。

落到法律工作里，至少三个高频场景绕不开这个能力。

合同修改追踪——对方发回来的修订版，AI 需要知道改了哪里，才能帮你分析改完之后的影响。法律条文修订对比——新法改了旧法的哪几个字，AI 需要精确到行，才能帮你判断实务变化。案件材料版本管理——多份证据的多个版本，AI 需要知道版本之间差了什么，才能帮你梳理证据链条。

一个判断标准就够了：文件能不能用 git diff 精确展示变化。能，AI 就能做增量理解。不能，AI 就得每次从头来过。

为什么法律人比程序员更需要版本可追溯

程序员谈版本控制，通常谈的是协作——多人改同一份代码怎么不打架。法律人对版本追溯的需求，更根本。

合同谈判：对方改了什么，决定你的回应

律师收到对方发回的修订版，第一步永远是找出"对方改了什么"。在 Word 里开修订模式，一行一行比对——这是日常。但对方如果关了修订模式，直接发一个新版本过来，你就只能人肉比对。两三百页的合同，对方只改了一处关键词，能不能发现全靠眼力。

合同用 Markdown 写、用 Git 管，一个 git diff 就解决了。- 甲方承担全部责任，+ 甲方承担主要责任——两个字露出来，责任边界变了。在二进制格式的世界里，你需要逐字比对才能发现这个变化；在纯文本的世界里，机器帮你标记好了，你只需要做法律判断。

我见过太多因为"没发现对方悄悄改了那一句"而留下后患的案子。不是律师不仔细，是二进制格式把"发现变化"本身变成了一件需要专门工具和专门注意力的工作。这件事本不该由人来做——机器做更快、更准、更不累。

证据管理：文件版本链条本身就是证据

证据有一个容易被忽略的维度：时间线。文件是什么时候产生的、谁在什么时候改了什么——这个链条在某些案件中本身就是争议焦点。

传统的文件管理，版本信息全部压在文件名上："尽调报告_v1""尽调报告_v2""尽调报告_v3_final""尽调报告_v3_final_真的final"。文件名里的数字是唯一线索，而且不可信——你不知道"v3"和"v2"之间到底改了什么。

Git 管文件是另一个办法。每条修改记录精确到行、精确到人、精确到时间。git log 给你完整历史，git diff 给你任意两个版本之间的精确差异，git blame 告诉你每一行是谁写的。三个命令凑出一条完整的、可验证的文件产生链条。

合规审查与团队协作：每一步都可审计

监管机构、客户内部审计、上市公司信息披露——越来越多的场景要求"每一步都有记录"。这个结论怎么得出来的、这个修改是谁做的、基于什么理由做的，需要能说清楚。

一个版本可追溯的工作流天然就是审计记录。谁在什么时候基于什么理由做了修改——在 commit message 里。修改了什么——在 diff 里。整个文件的演进过程——在 git log 里。不需要额外写文档，版本管理本身就是合规记录。

还有一个更日常的好处：多人协作时谁改了什么一清二楚。"我以为你改了那条""我没改啊"——律师团队里这种对话太常见了，版本追溯可以直接把它消灭掉。

Git diff：被低估的法律工具

一说 Git，很多律师的第一反应是"程序员用的，跟我没关系"。这个印象本身就有问题。

Git 不是代码管理工具，是版本控制系统。它不挑文件类型——合同、法律意见书、尽调报告、诉讼文书、法规汇编、案例摘要，都可以用 Git 管。前提只有一个：文件是纯文本。

模拟一个场景。一份合同从 v1 到 v5 用 Git 管理，git log 会告诉你：

v1→v2：增加了违约责任条款（2024-06-01，张律师）
v2→v3：修改了付款节点，从"签约后 30 日"改为"签约后 45 日"（2024-06-03，陈律师，理由：客户资金安排需要）
v3→v4：对方律师反馈，将管辖从"甲方所在地"改为"合同签订地"（2024-06-05，王律师）
v4→v5：定稿，双方确认（2024-06-07，张律师）

每一步做了什么、为什么做、谁做的——全自动记录，不用额外写任何工作日志。如果事后发现 v4 到 v5 之间某处被误删了，git diff v4 v5 瞬间定位。

对比现在的通行做法：文件名越来越长——"合同_20240604_v3_final_修改版_真的final（3）.docx"。版本一多就分不清哪个是最新版。律师还得单独维护一份"版本说明"来记录每次修改的内容，而这份说明本身也会有版本问题——无限套娃。

Git 不是要取代 Word。打印、签署、归档——这些环节仍然需要 .docx 或 PDF。但工作过程中的文件——草稿、审阅稿、反馈稿、修订稿——用 Markdown + Git 管理，效率跟可追溯性都远比传统方式高。

附带一个好处：备份天然是分布式的。每个合作者本地都有一份完整历史，不依赖某个共享文件夹或云盘。

边界在哪里

版本可追溯不是万能药。扫描件和盖章件，物理签章有不可替代的法律效力，不需要也不应该被版本追溯替代——它们本身就是"原版"，不存在版本问题。

最终归档件同理。一份已经签署盖章的合同，归档后就应该是固定的、不可变动的。归档要的是确定性和稳定性，不是可追溯性。

但工作过程中的文件——合同草稿、法律意见书初稿、尽调报告的每一轮迭代、谈判要点记录、诉讼策略备忘录——天然需要版本追溯。它们在被反复修改、审阅、反馈，每一步修改都有法律意义。

一条简单标准：如果未来某一天可能有人追问"这个条款是什么时候加上去的""这个结论是基于哪个版本的数据得出的"——那就应该用可追溯的方式管。如果改了之后旧版本彻底废弃、不产生任何法律后果，那就不需要。

回到主线

"AI 喜欢系列"七篇文章不是散点。四篇说不喜欢，三篇说喜欢，每一篇都在讲同一件事：信息对 AI 来说是不是可计算的。

内容可检索——Markdown 和 CSV 做到的事。信息如果藏在 .docx 或 PDF 里，AI 找不出来。就像你把合同锁在保险柜里却让律师审阅——文件在手，内容不可触达。

结构可解析——HTML+JSON 做到的事。表格、层级、嵌套关系能被机器解析，AI 就能理解"这是条款标题""这是正文""这是例外"——而不只是看到一串字符。

变化可追踪——版本可追溯解决的事。每一步修改都可定位、可理解、可回滚。不是"文件变了"，是"这里变了，从 X 变成 Y，原因是 Z"。

可检索、可解析、可追踪——三根支柱搭起了 AI 理解法律信息的基础框架。框架之上能搭出什么，是下一篇要聊的。

作者简介： 陈石律师，浙江海泰律师事务所副主任、高级合伙人、房地产与建设工程部主任，宁波市律师协会副秘书长、第七届宁波仲裁委员会仲裁员，聚焦建筑房地产、投融资、并购重组及商事争议解决。曾获多家法律媒体与专业机构认可，荣登 LegalOne 2025 中国区建工及房地产实务先锋 45 强、律新社 2025 年度管理合伙人 20 佳（华东），入选《商法》The A-List 法律精英，获评 ALB China 区域市场十五佳长三角地区律师新星，并获律新社 2024 年度并购领域品牌之星。长期为万科、华润置地、信达地产、保利置业、招商蛇口、中海地产等企业提供法律服务，承办"首宗百亿地王""长春第一高楼""台州第一高楼"等代表性项目，累计服务项目投资额超千亿。近年来持续推动 AI 与法律实务融合，强调以结构化方法打通技术逻辑、法律判断与商业场景；著有《赋能法律人：AI 底层思维与应用范式》，并在多地开展相关主题讲座与分享。四明山法师 AI 夜校（legalAGI.cn）发起人。