用 Git 思路给美国法典做版本记录：按日期取生效文本

律师读联邦成文法，往往不像程序员能对任意一行立刻回答「谁写的、哪天生效、某天当时的全文长什么样」——常常要翻脚注里的修改说明和生效日说明。Lexifina 创始人 Alan Yahya 在 2026 年 10 月 28 日的博客里提出：法律检索，尤其是经过大语言模型的「第一遍」问答，同样需要可核对的时间线。

美国法典为什么难「按日回溯」

美国法典（US Code）里，不少标题尚未以成文正法（positive law）形式由国会整体制定；法典文本在与《美国联邦法规汇编》（Statutes at Large）冲突时，以后者为准。法律修订顾问办公室（Office of the Law Revision Counsel）按一系列 release point 发布法典，每个节点对应某部命名的公法。哪部公法写下了哪句话，通常写在修改说明里；何时生效，则可能在单独的生效日说明中，国会未另作规定时，默认自颁布日起生效。

作者举了破产法里「小企业债务人」定义（11 USC § 1182(1)）的例子：限额几经临时上调、届满、再恢复并带有追溯案件范围，再到后续调整。对某一天立案的案件，当时打印出来的 release point 不一定等于后来法律所认定的答案——有用的历史必须同时带上文本、各次变更的生效日，以及是否回溯适用。

慕尼黑工业大学等近年研究还指出：模型回答成文法问题时，会误用训练截止后已废止的规则，或在旧案事实本应适用旧法时仍偏好新条文；仅靠模型「自己生成」旧文本，表面相似度高，精确匹配却远不够，且近失中常有法律上关键的错误。因此时间有效性需要被当成硬约束，历史本身也必须可核查。

Lexifina 做了什么

对自 2017 年以来相邻两份 release point，作者团队取中间颁布的公法，按日期顺序把修改指令施加到旧文本上，再与新版本比对。在九个标题上统计到的 365 处变更中，有 361 处精确复现了下一 release point；其余四处标出了能确认到何种程度。每处变更再附上法律与生效日：261 处按默认自颁布日起生效，72 处依生效日说明，29 处依修改文本中的日期；一处依赖机构后续认定、可能永不作出，则不写入文本以免猜测。

有了这份记录，读者可以：选定一个日期，取出当日生效文本，并把与今日不同的用语标出；按写入该短语的法案着色；对定义术语变更，列出引用该术语的其他条文；也可跟踪某一节自上次查看以来改过什么。

明确局限

作者写清了边界，不宜理解成「已覆盖全部美国法典」或可替代专业检索：

• 复现实验覆盖的是文中所述九个标题、自 2017 年起相邻 release point 间的变更，不是全美法典全集。

• 尚不完全展示后来法律对更早日期的回溯适用；例如 2022 年空档期立案的案件，界面会显示较低限额，却未必警告同年 6 月法案已改变答案。

• 生效日说明靠模式解析，措辞异常时回退到颁布日。

• 每处变更链回法律原文；事关利害时仍应阅读原文。产品形态也仍在斟酌。

说明：以上据 Alan Yahya / Lexifina 2026年10月28日博文转述；变更复现比例与局限以原文为准，不构成法律意见，也不替代律师检索或官方文本。

来源

[1] Git for the US Code，Alan Yahya / Lexifina，2026年10月28日。查询日：2026年10月28日。

[2] Hacker News 讨论：Git for US Legislation，2026年10月28日。

#Lexifina #美国法典 #法律科技 #版本控制 #LLM #时间有效性