article_image

本文脱胎于我在 UNTAG 会员栏目中撰写的一系列文章《法律工作中的……》。连载时囿于篇幅,每次只展示一个用例;此番集结发表,掺入一些私货,并添补些许案例。

法典和代码的英文单词同为“Code”,这一历史——或者说巧合——常被人当作有趣的引子。但是在法律工作中,我确实体会到:将法律条文和契约等内容当作代码去处理,将节省多么可观的人力。

使用 Word 这类主流文档处理工具时,常常遇到太多惊喜,以至于这些惊喜早就变成了惊吓:你可能删除一个数字,结果整个文档的结构都翻天覆地;有时只是加了一个空格,接下来却凭空多出好几个空白页面;而另一些时候,空格、空行或者空白页面无论如何都无法删除……难度绝对不亚于圣经诠释学的法律解释学已经足够让人眉头紧蹙青筋暴起,苟还要和这些围绕在文档周围的符号苍蝇作战,那这碗饭未免也吃得太艰难了。

相比 Word,我更倾向于使用代码编辑器,即便我最后要导出 Word 格式的文件。这并非沿袭学生时代的技术至上主义,也不是用另一款可疑的工具掩盖常规办公技能之生疏1,而是一种根本上不同的处理方式:法典也罢,章程也罢,合同也罢,只要没有图表——没有图表的文件在法律工作中可能占了十之八九——那就可以视作平实的纯文本,而不是沟壑横生的富文本。用代码编辑器处理法律文档,胜在从来没有惊喜(no surprise),你看到什么东西,然后拿一个工具去处理,一定能获得想要的结果,没有什么隐藏字符,没有什么遗留下来的特殊格式,更不可能出现被当作病毒删除的特殊数据(如宏)。

法律文件多为文本,而举凡不涉及与他人协作的文档,或私下的操作,我都交予轻代码编辑器,如处理代码符号般处理法律文件。

何为轻代码编辑器

“轻代码编辑器”是 Hum 提出的概念,至少我只见过他如此明确。简单来说,它们看上去就像未经设计师斧凿的 Markdown 编辑器2,或者大幅简化的代码编辑器,你基本上可以把它们当普通文本编辑器使,而不会被IDE(集成式开发环境)中那一堆明显为工程师设计的按钮搞晕。3

Alt text
XCode 和 CotEditor 界面对比

但既然是代码编辑器,它们当然继承了一些特殊功能:正则表达式搜索(我猜绝大多数同行都不知道这个词是什么意思),多文件搜索,文件内容对比,修订记录对比……乍一看,似乎都是程序员才用得上的冷门——对于一般人和法律工作者而言——功能。可一旦转换视角,无视法典、合同、协议、章程等名字,把文档全部视作字符的集合,那么这些原本用来处理代码的利器,收拾起法律文件来同样得心应手。

典型的轻代码编辑器有 BBEdit、CotEditor 和 SublimeText 等,我同时使用前两者,不用 Sublime Text 只是因为它并非 macOS 原生软件,我很难以自己熟悉的自动化方式控制它——当然,BBEdit 和 CotEditor 的组合也足够完成工作,遂不再折腾新编辑器。轻代码编辑器就像是不同品牌和型号的瑞士军刀,绝大多数功能都有重叠4,但又有微妙差别,你最好多下载几个,并且请做好抛弃极简主义的准备:最后可能要同时使用多款。

就我的经验来说,需要注意:BBEdit 开发历史悠久,总体上功能更多,但它丝毫不考虑东亚用户,迄今不能正常换行,而 CotEditor 是日本人开发的,中日韩三国文字显示正常。此外,BBEdit 通常无法读取太大的文件,而最高人民法院公布的多个工作指南均有数十万字,此时我一般换上 CotEditor。

批量搜索,一次找全法律依据

干法律工作,或许一般时间都在检索资料,如果不是更久的话。而传统的 Word 文档格式几乎无法批量检索,如果以这种格式存储法律条文或者合同范本,恐怕资料还没找全,案子就先黄了。有人说,何不把要查的资料全存在同一个 Word 文档?有此问者,显然不熟悉法律。详言之,法律分类固然规整,然而实际使用时却往往牵连好几部文件,此番可能用到法律A、B和C,下次则是B、D和E,再次则是C、E和F,如此重叠穿插,单独的 Word 文档无法胜任。

我转而使用纯文本存储法律条文,一部文件对应一个文档——例如《中华人民共和国民法典》就存为一个 Markdown 文件,可参阅《为什么,以及如何制作 Markdown 版民法典》——检索时批量探之。

最基础的批量搜索,拾起 BBEdit 或 CotEditor 便是。BBEdit 有多种搜索模式,包括带详细设置窗口的 Search、和一般编辑器类似的 Live Search 以及同时搜索多个文件的 Multi-File Search,本文介绍最后一种。快捷是 ⇧Shift-⌘Command-F,默认会搜索当前打开的全部文档,也可以更改搜索范围;其余选项和一般的 Search 类似,同样支持正则表达式等进阶选项。以最简单的搜索为例,点击“Find All”,即可列出目标范围内的全部搜索结果。

Alt text
用 BBEdit 搜索多个文件

或许有读者会感到不可思议:几乎任何笔记软件都可以全文检索多个文件(笔记)呀!确实如此,但 BBEdit 会列出所有带关键词的行,同时在下方呈现原文;点击任一搜索结果,可以在下方原文栏中浏览其上下文,既不用离开搜索结果页面就能透视文件,也可联系前后文,避免断章取义。惟需注意,关键词检索用处有限,盖法律概念很可能在不同文件中表述有别5,不宜认为搜索结果就是一切;不过,借用多文件搜索、粗粗扫视,已足以大大缩小进一步的检索范围,省去不少力气。

若再配上一些正则表达式语法,则搜索会更简单,例如 国企央企政府出资企业国有企业 这几个概念,相当程度上有重叠,检索时可凭表达式 国企|央企|政府出资企业|国有企业 一以贯之,免得反复检索。Word 倒是也有类似的机制(通配符),但过于晦涩且不通用,基本就是一种死语言,就连 GPT 也经常答错。而正则表达式则是代码编辑领域的普通话,即便 BBEdit 宣布不开发了——这种机率当然很小——我也可以带着过去掌握的技能,正向迁移到其他代码编辑器。

除了搜索本身,还有一个前置问题:如何将要检索的文件快速交给 BBEdit?最通用的做法,当然是先在 Finder 里找好,然后用 BBEdit 打开(BBEdit 提供了一个“Search Here in BBEdit”的服务,在右键上下文菜单中可找到)。但目标文件可能分散于多个文件夹,例如关于劳动法上所谓“经济补偿”的规定,就散见于《劳动合同法》《劳动合同法实施条例》以及几部司法解释和部门规章,很不好统一处置,为此,我编写了一个 LaunchBar 搜索动作,在其结果列表中可挑选文件,再按 ⇥Tab 键发送给 BBEdit,也是一条捷径。

Alt text
将待搜索的文件批量发送给 BBEdit

拓展阅读:让 LaunchBar 支持中文文件搜索

另一种批量搜索同样基于纯文本,不过用到了命令行工 grep,还需要配合 DEVONthink 中的文件清单使用,若有读者愿意手动维护文件索引,则此方案可能更有效。参见《为什么,以及如何深度搜索 DEVONthink 文件清单内的所有文件》

注:尽管有不少法律数据库(我也购买了一些),但仍然需要自己维护一个,一方面当然为了离线使用,另一方面,不要指望这些数据库是齐全的,很多地方的文件没有公开。

对比修改,剖析法律或合同变更细节

魔鬼在细节中,无论是法律法规的修订,还是合同的修改,一字之差,可能就会丢饭碗。我日常需要引用或审查的文件非常多,可算是在刀尖上蹦达,不得不使用文档对比工具。在此只谈纯文本的比对,不过未来我也会另外撰文,解释如何快速调用 Word 内置文档比对功能。

以 BBEdit 为例,其内置可视化的文档对比功能——比更硬核的 diff 命令要浅白得多——在 Finder 中选中两个文本文档,点击右键上下文菜单中的“Compare Using BBEdit”,就能看到所有被改动过的行,包括新增、删除和字词修改。

Alt text
比较法律规定修改了哪些部分

合同自不待言,肯定要自己一字一句看过去,而对比工具的功劳,主要是指出文字上的变动,不怕遗漏,也不必浪费时间查看大篇幅相同的内容。例如建设工程施工合同中,通常会在行业范本基础上修修改改,一般通用条款不会有人动,只是在专用条款部分就各方情况作专门约定——然而,偏偏有人有意无意改动通用条款的个别字词,导致歧义甚至颠倒权利义务比重,如果未加注意,将来吃官司时就只能认栽。而借助,哪怕是一位数字——通常是利率——的变动也不可能藏住,同时那些完全一样的内容也可以的放心忽略。在这个意义上,轻代码编辑器可谓排雷利器。

法律也需比对。每次新法律法规颁布,除非有关部门已经发文列出所有修改项,否则我都会用 BBEdit 检查一遍有何改动(同时更新 Anki 中的卡片,免得再背诵过时条文)。有人喜欢看各路专家的解读,但我更倾向于原始文本,从最原汁原味的东西开始理解法律修订,每一个细节都要问,而非人云亦云——更何况,为数众多的部门规章还入不了专家们的眼,最后肯定要靠自己。去年年末新《中华人民共和国公司法》出台,

此外,我自己写的东西也需要前后比对,以示不同版本之间的差异。起诉状、答辩状和各类申请书自然是三易其稿,只可惜此处不便展示;好在我也有专业相关的闲杂著作,不涉及客户隐私,可以大方示人。下图是我的杂文草稿,其归纳了一些法律检索的心得,前前后后写了半年——目前还在继续拉锯——有时感觉某个段落“还是不如最初版本”,有时想看揭示想法的变化,就需要比对不同时期的草稿。

Alt text
用 BBEdit 对比当前版本和历史版本

在 BBEdit 中启用这一功能也非常简单,点一下窗口右上角的时钟图标,即可按时间列出各个修订版本,以供比对。

Alt text
在 BBEdit 中找到一个需要对比的历史版本

多栏视图,透视冗长文档

阅读纸质书时,如果需要前后对照两段文本,一个人会很自然地用手指夹一下,以便快速翻回去。这种基于物理属性的阅读方式,在电子媒介上就要画一些功夫才能实现;而我习惯用纯文本存储法律法规,就避不开这一问题。 我最初在 Sublime TextCotEditor 官网看到分屏浏览特性广告,宣布可以打开两个甚至更多个窗口,但浏览的文件还是同一份,这就相当于同时翻开书本的不同页面,很方便比对阅读。前述两款编辑器口碑都很好,但我平时主要用 BBEdit,遂摸索了一番,很幸运,BBEdit 也有分屏浏览功能,就在菜单栏中:“View - Text Display - Split Text View”。

Alt text
在 BBEdit 的分屏视图中浏览同一份文件的不同部分

工作中时不时遇到一些文件,喜欢前后文交叉引用——最能引起同行共鸣的,大概就是《中华人民共和国劳动合同法》——非常难读,我甚至把它们打印出来以便翻页,总好过拼命前后滚动、把鼠标滚轮磨得油光锃亮。而分屏浏览则开启了另一种思路,不再把屏幕当成一个固定的页面,而是一个浏览内容的窗口——既然是窗口,当然可以分割一下、在一个物理屏幕上塞下多个窗口了。用分屏模式看法条,就可以把罚则(如何处罚)固定在一侧,另一侧放置处罚依据;或者把一般性、原则性的规定置顶,在下面浏览细分场景下的具体规定。

诚然,直接用两个不同的编辑器打开同一份文档,也是一种方法,但在其中任意一处修改文件都可能造成损坏,尤其是 iCloud 云备份、iCloud 本机进程、软件历史版本备份七七八八一大堆进程在读取文件的当下,多打开一个软件,风险过大。最严重的情况下,可以烧毁质量中下的U盘——经本人亲自测试。

用正则表达式清理文件

正则表达式除了用于检索,也可用于较为机械的文本格式清理。例如,网上复制来的法律条文常常排版不佳,甚至连用四个空格充作缩进者也不少见6,而不可见的多余空白符号(比如软回车)也不少,这些杂质不仅有碍观感,也影响检索的精度:精心构建的正则表达式,可能被一个从天而降的空格毁掉了。

吃过几次苦头后,我养成了习惯:入库文件必先清理格式。好在法律文件也有相对通行的篇章布局,逃不出编、章、节几个层级,条款项目之间则不区分,细心者至多再加粗条款序号。种种细节,我都写成两段正则表达式,一查找、一替换,多数大陆的法律法规即变得清清爽爽。

Alt text
用 BBEdit 清理前后的文本

这样收拾后的文件,日后无论逐篇精读还是批量检索,显然都胜过版式粗糙、符号滥用的版本。

种种技巧,大概还可以说上三天三夜,但继续下去或许就要让人同情起律师了。且容我就此打住。


  1. 我的办公技能至少不算差,除了常规技能,我也研究过办公软件自动化,参见用 Keyboard Maestro 为 Word 打造个性化批注工具箱一键填写 Microsoft Word 表单的半自动化方法用 Keyboard Maestro 快速设置 Word 样式,并自动生成目录用 Keyboard Maestro 快速设置 Word 字体格式(纯 AppleScript 方案)等文章。
  2. 一般的 Markdown 编辑器都在颜值上较劲,不过,轻代码编辑器通常也支持 Markdown。
  3. 在技术上,不少 IDE 也可以收起部分功能,提供一个类似轻代码编辑器的界面。
  4. 大多数瑞士军刀都有主刀、小刀、开瓶器、一字螺丝刀和锥子几项功能。
  5. 在技术上,此问题也在一定程度上有解,即使用 关键词A|关键词B 的正则表达式(请在 BBEdit 搜索界面勾选“grep”选项以启用正则表达式)。
  6. 如果你不懂这句话,那么糟糕了,你可能也是敲空格的人。

author_avatar

Lawyer, macOS/iOS Automation Amateur