用Claude将全球法律搬进Git：语义化版本控制的野心

当法律遇上Git：一个开源项目的疯狂构想

在Hacker News上登顶的"Using Claude to put all Global Law into Git"项目，试图用AI代理将各国法律转化为Git仓库，让每条法律都可追溯、可查询。作者lexifina在Reddit分享了这个想法：让所有法律语义化、版本化、易于归因，并且能被AI代理查询。项目采用CC0协议，代码和數據完全开放。

这个项目的核心逻辑并不复杂：利用Claude为每个国家创建一个代理，读取官方发布网站或API，检查robots.txt和使用条款，然后编写脚本下载每部法律的所有版本，最终以Git历史的形式输出——每次变更对应一个提交，提交日期就是法律生效日期。

技术实现：多代理协作与历史重建

每个国家一个代理

项目为每个国家分配一个Claude代理。代理需要自主完成几件事：访问官方法律发布平台，遵守robots.txt和使用条款，编写下载脚本，并处理各种边界情况。这种"一國一代理"的架构让项目可以并行推进，同时保留各国法律体系的独特性。

代理之间会共享发现。例如，1970年之前的日期处理、夏令时边缘情况等，这些经验会在会话中传播，减少重复踩坑。这相当于让AI代理形成了一个协作网络，共同解决跨法域的复杂问题。

用修正案重建历史版本

很多国家的官方发布渠道只提供修正案，而非法律全文的历史版本。项目采用的方法是：从当前版本出发，逆向应用每一次修正案，从而重建出过去的所有版本。这要求代理准确理解修正案的生效日期和修改内容，技术难度不小，但一旦成功，就能为法律提供完整的版本时间线。

修正案（amendment）是立法机关对现行法律文本作出的局部修改，通常以“删除第X条”“将第Y款改为……”等形式表述，本身并不包含被修改法律的完整上下文。因此，要从仅存修正案的官方渠道还原历史全文，必须沿着时间轴逆向执行每一次修改：先取当前 consolidated 版本，再逆序撤销最近一次修正案，逐步回退到目标日期。这一过程的关键难点在于修正案的生效日期可能与颁布日期不同，且同一条款可能被多次、交叉修改，需要精确的语义解析而非简单的文本替换。

多国法律的交织历史

各国法律最终会组合成一棵统一的树。每个国家作为一个Git子模块，所有历史按生效日期交织在一起。作者还让Claude编写了构建脚本，确保两次独立构建产生完全相同的哈希值——这种可复现性在版本控制系统中至关重要，尽管作者本人也承认这通常被认为是过度设计。

Git 子模块（submodule）允许一个仓库将另一个独立 Git 仓库作为子目录嵌入，并记录其所指向的特定提交。在本项目中，每个国家的法律仓库作为子模块挂载到统一的主仓库下，主仓库只保存各子模块的提交指针，从而在不合并各国庞杂历史的前提下，形成一个可按生效日期统一浏览的“树”。子模块的优点是各法域可独立更新、独立克隆，主仓库保持轻量；代价是主仓库不会自动跟踪子模块的最新提交，需要显式更新指针，这对持续同步各国法律变更提出了额外的运维要求。

为什么是Git？法律版本化的深层需求

法律文本的版本管理一直是个痛点。普通用户很难追溯某条法律在特定时间点的确切表述，律师和法官也需要花费大量时间核对历史版本。Git的提交历史、blame功能和分支模型，恰好能提供一种直观的解决方案：每一次法律变更都是一个提交，谁在什么时候修改了什么一目了然。

更重要的是，Git仓库可以被AI代理直接查询。项目作者明确表示，目标是让法律"可被代理查询"。这意味着未来AI法律助手可以直接读取Git历史，回答"某年某月某条法律是怎么规定的"这类问题，而不需要依赖人工整理的数据库。

Git 的 blame 功能会逐行标注最后一次修改该行的提交、作者与时间，git log 则按提交记录完整变更历史。将法律文本映射到 Git 后，某一条款的每一次修订都对应一个提交，blame 可以直接回答“这一句当前表述是哪次修法引入的”。不过，法律文本的段落结构比代码更不规则，单纯依赖行级 diff 可能在条文重排时产生大量噪声，通常还需要配合语义化的提交信息和标签（tag）来标记法律生效节点，才能让版本历史真正可读、可查询。

挑战与争议：准确性、版权与维护

这个项目面临的挑战同样明显。法律文本的准确性至关重要，AI代理在下载和重建历史版本时可能出错，尤其是当修正案语言模糊或存在多个解释时。虽然作者强调构建脚本的可复现性，但数据源的可靠性仍然是未知数。

版权问题也值得关注。虽然项目采用CC0协议，但各国法律文本的版权状态不同。有些国家的法律文本属于公共领域，有些则可能有特定使用条款。代理在检查robots.txt和使用条款时，需要谨慎处理这些差异。

维护成本是另一个现实问题。法律在不断变化，项目需要持续更新。多代理架构虽然可以并行工作，但长期维护需要稳定的算力支持和人工监督。作者在Reddit上欢迎评论和建议，说明项目仍处于早期阶段。

可复现构建（reproducible build）指在相同输入与环境下，独立执行两次构建应得到逐字节相同、哈希一致的产物。在 AI 代理参与的流水线中，这意味着下载源、解析规则、修正案应用顺序和序列化格式都必须被完全固定，任何随机性或时间戳差异都会破坏哈希一致性。实现可复现构建能有效验证代理输出是否被意外篡改或受模型非确定性影响，是让 AI 生成的法律数据具备可审计性的基础手段，但也显著增加了工程约束与调试成本。

对AI代理工作流的启示

抛开法律领域不谈，这个项目展示了一种值得关注的AI应用模式：让多个Claude代理各自负责一个独立子任务，通过共享发现来提升整体效率。这种"代理集群"的思路可以迁移到其他需要处理大量异构数据的场景，比如学术文献整理、企业合规文档管理等。

项目对可复现构建的坚持也值得借鉴。在AI生成内容越来越普遍的今天，确保输出结果可验证、可复现，是建立信任的关键。作者让Claude编写构建脚本并验证哈希一致性，实际上是在为AI生成的数据建立质量保障机制。

目前项目已在GitHub开源，作者希望获得更多反馈。无论最终成败，这个尝试都为法律技术的开源化提供了一个有趣的样本。