---
order: 10
date: 2026-08-05
summary: ——普通法是 Git，中国法是 monorepo
---

# 法律的版本控制

**——普通法是 Git，中国法是 monorepo**

《AI 是一位普通法法官吗》的结尾写道：普通法本来就是一个分布式的统计对象——“王国的普遍习惯”，散落在千万个判决里，没有任何单一头脑装得下它的全部；法官是这个对象的活性接口，负责在具体案件中调用它、更新它，并为调用结果签名负责。

分布式存储、多人写作、没有中央母本、历史只增不删、每次修改都署名负责——把这五个特征念给一个程序员听，他不会想到法律，他会想到 Git。这不是俏皮话：逐项检查下去，普通法与版本控制的同构深得惊人。看完普通法，再回头问：中国法院的判决，像不像？

## 一座没有母本的仓库

把修辞剥掉，普通法面对的是一个纯粹的工程问题：**一个庞大的规范性文本语料，由成百上千个作者在几百年里持续修改，没有中央母本，却要维持整体一致性和可追溯性。** 这正是版本控制系统被发明出来要解决的问题。逐项对应摆出来，密度会说明问题：

| Git | 普通法 |
| --- | --- |
| commit（署名、时间戳、必附 message） | 判决（署名、日期、必附理由） |
| commit message | ratio decidendi |
| log（只增不删） | 判例史 |
| HEAD | 现行有效的法 |
| blame / annotate | 引证义务——每条规则可追溯到引入它的判决 |
| branch | distinguishing——不推翻先例，开新路径容纳新事实 |
| revert | overruling——撤销效力不删历史，旧判例仍在 log 里 |
| code review | 上诉审 |
| module maintainer | 法官——排他管辖，凭署名与声誉负责 |
| tag / release | leading case |
| refactor | Restatement、法典化——不改行为，整理接口 |
| docs | 学说与教科书——从代码生成的文档，本身不是代码 |

这张表里最有分量的不是任何单项，而是一个总括的事实：**信任模型的同构**。Git 和普通法都放弃了机械验证：一个 commit 该不该合并，没有哈希可校验，靠的是 maintainer 的判断、review 制度和署名声誉；一次涵摄对不对，同样没有算法可裁定，靠的是上诉审、说理义务和判决书上的落款。**当验证无法机械化时，唯一的出路是把人放进流程里，再用流程约束人。** 两个相隔几百年的系统在这一点上给出了同一份答案。

还有一层对应值得单独说。程序员有一条祖训：在弄清一段代码为什么存在之前，不要删它——它携带着当初作者见过、而你现在看不见的案例信息。这就是切斯特顿栅栏原则，也是遵循先例的程序员表述。**先例的拘束力，本质是“不要无故重写已合并的代码”；推翻它的举证责任，永远在动手的人身上。**

## 中央仓库与影子语料

那么中国法院的判决像不像 Git？答案要分层：**规范层不像，语料层像。准确地说，中国是一座集中式 monorepo——法官没有 commit 权，但留下了互相可见、且被考核约束的构建日志。**

先看规范层。大陆法系的源代码是成文法，对“法”这个仓库有提交权的只有立法机关和最高司法机关：法律、行政法规、司法解释是真正的 commit——有版本号、有生效日期、有废止机制，法规库里“现行有效／已修改／已失效”的字段就是标准的版本状态管理。而地方法院的判决在形式上不进入这个仓库：判决不是法源，没有遵循先例，一份判决对隔壁法院没有拘束力，理论上连对作出它的法院都没有。在这个模型下，个案判决是什么？**是针对特定输入跑了一次源代码的构建日志。** 日志不改源代码。

但只看规范层会严重失真。中国法官事实上大量互相阅读，而且这种阅读被制度化了。类案检索义务要求缺乏明确裁判规则或存在分歧的案件必须检索类案并作出回应——相当于强制要求写新代码前先 grep 代码库，grep 的结果不拘束你，但你得解释为什么不照着写。发改率考核把上诉被改判、被发回的比率做成法官的绩效指标——**这是把 CI 通过率做成了 KPI**，制造出真实的收敛压力：偏离上级口径的判决，会在个人考核上付出代价。再加上“同案同判”作为对司法公信力的政治性要求，三者合力的结果是：虽然没有任何一份判决拘束另一份判决，判决的分布在统计上却是收敛的。**中国的判决是事实上的弱先例——不作为规范引用，但作为实践分布，真实地约束着彼此。**

最有意思的是沟通这两层的中间机制，每一个都能在软件工程里找到准确对应。指导性案例不是社区 commit，是核心团队从海量构建日志里策展出来、打上官方标签的参考实现——“应当参照”的效力恰好介于文档与代码之间：不能作为裁判依据直接引用，但偏离时需要说明。司法解释是核心团队定期阅读 issue tracker——下级请示、审判分歧——然后把散落的社区实践批量 merge 成正式条文；九民纪要之前的对赌裁判史是标准样本：社区在“与公司对赌的效力”上分叉多年，海富案、华工案各领风骚，最后由纪要收编定调。而会议纪要本身的地位——“不能作为裁判依据引用，但可以作为说理依据”——精确对应 release notes：not source, but authoritative documentation。至于请示制度与专业法官会议，那是 pre-merge review：普通法的 review 发生在判决之后（上诉审），中国把相当一部分 review 前置到了判决之前——日志因此更“干净”，但也看不到被前置过滤掉的分歧。

还有一个正在发生的变化必须记下。裁判文书网曾造就全球最大的公开判决语料库，近年上传量断崖式下降；2024 年上线的人民法院案例库走的是策展模式，入库案例经过遴选和编辑。用本文的语言说：**公开的 commit log 正在转为私有，取而代之的是官方 gallery。** 对法教义学，影响也许有限——规范层本来就不在判决里；但对一切依赖统计挖掘的方法，包括类案检索本身，这是语料退化：样本从全量日志退向策展样本，选择偏差随之进入所有建立在它上面的统计推断。可得语料的分布与真实裁判的分布之间，缺口正在变大。

## 谁有 commit 权

把两节合起来，对照可以收得很短：

> **普通法是分布式版本控制：法官是有 commit 权的 maintainer，法本身就是那座仓库。**
> **中国法是集中式 monorepo：法官提 issue、跑 build、写日志，核心团队决定什么被 merge 进源代码——但构建日志互相可见、被考核约束，因此长出了一个有真实统计信号的影子语料层。**

这个对照顺带把两件实务上的事讲清了。其一，在中国语境下使用判决语料的正确姿势：既然它是实践分布而非法源，对它的正确用法就是统计校准——这类争点主流怎么判、支持率多少——而不是规范引用。挖分布，不挖先例。其二，当你打算逆着这个分布主张时发生了什么：那不是违反任何规范——分布不禁止你——而是提交一份不合代码库既有惯例的 PR，惯例会向你收取额外的说理成本；至于逆着共识打不打，取决于和解筹码、商业考量这些库外因素。《断点》说过，这是授权与评价输入，不是推理能替人做的决定——maintainer 之上还有产品决策。

类比到此可以收束。真正值得带走的不是那张对照表，而是表底下的事实：版本控制被发明出来，是因为程序员在二十世纪末撞上了一个法律人几百年前就在解的问题——一个由许多人持续写作、没有谁能整个装下的规范性文本库，如何在无法机械验证的条件下维持一致和可信。两边互不知晓，答案却收敛到同一套结构：署名，留痕，历史不可删，review，声誉负责。趋同进化指向共同的环境压力。所以这场对照里没有谁吞并谁：法律不是被工程语言重新描述的对象，它是这门手艺更早的发明者——**管理重要到不容出错、又庞大到无人全知的文本**，法律人先做了几百年，程序员只是在最近五十年里把它做成了软件。