说实话，干法律这行最烦的就是整理一堆扫描件。判决书 PDF、证据册、银行流水、合同扫描件，客户那边发过来就是一堆乱序 PDF，你想让 AI 帮你做点初步分析，直接把文件拖进聊天框，结果它要么读不出内容，要么把表格识别得七零八落。你怪 AI 没用，其实是材料在交给 AI 之前就卡住了。

我最近把 Claude Code 这个终端里的 AI 工具用在了这条生产链上，专门做一件事：把零散的知识文档、证据材料，批量转换成结构清晰、带索引、AI 能真正读得懂的 Markdown 文件。做完这一步之后再让 AI 去分析、检索、比对，效果完全不一样。这篇文章就是把我踩过的坑、跑通的流程、以及给法律团队落地这套做法的思路，完整拆出来分享。

如果你手里正好有一批法律文档要处理，或者你所在团队正在做知识库、案件材料数字化，这篇文章应该能直接帮你省掉几个晚上的摸索。

1. 法律文档为什么难读：AI 真正需要的不是 PDF，而是结构化内容

1.1 扫描件乱码：AI 收到的是图片，不是文字

法律材料里，扫描件的占比高得惊人。客户拿来一堆纸质合同、聊天记录截图、公证书扫描版，这些文件本质上全是图片，PDF 只是个壳。你直接扔给 AI，它看到的就是“一张张图”，而不是可以被检索和理解的字。

我最早试过用普通的聊天工具直接上传扫描版判决书，问它“这份判决书里违约金怎么算的”，它给我编了一段，理由还挺像那么回事，但关键数字全是错的。根源就在于：扫描件没有被正确识别，模型在努力猜。要解决这个问题，第一步就得做 OCR。但 OCR 只是拆开了外壳，能不能把识别出来的文字组织成 AI 能高效利用的结构，是另一回事。市面上 OCR 工具一堆，大部分输出的都是乱糟糟的纯文本，标题层级丢了，表格变流水账，页码也没了。

1.2 结构丢失：表格、页眉、页码都会变成噪音

法律文件的“结构”是信息的一部分，甚至比正文更重要。一份判决书，案号、当事人、审判程序、判决结果是分层级的；一份证据清单，序号、名称、证据来源、证明目的、页码对应关系，全是表格化的。如果你只是简单地把 PDF 转成文本，这些结构关系全部压扁成一行行长句，AI 读起来就像看一篇没有标点、没有段落的长文。

举个例子，我之前处理一批证据册，里面有一页银行流水，本来是“日期、摘要、收入、支出、余额”五列，转换工具直接输出成一行文本。我在后续问答里问“某年某月某日有一笔多少金额的收入”，AI 完全定位不到，因为它根本分不清哪个数字是金额，哪个是日期。这就是典型的“格式错误导致信息失效”，不是模型的问题，是源材料处理方式的问题。

1.3 上下文失效：一次性塞几百页的代价

法律案件材料动辄几百页，很多 AI 工具根本吃不下这么长的上下文。硬塞，它前面的细节记不住，后面的内容又没读全；拆开分块，又会丢掉整体关联。另一个隐藏的问题是需要回链——你让 AI 分析某个证据，它必须能指出“这个信息来自哪份文件的哪一页”，否则结论无法核验，也就毫无价值。

所以，法律文档的转换目标从来不是“能读就行”，而是：保持原文层级和表格关系、保留页码和引用锚点、生成一份供 AI 快速定位的索引、把长文档拆成可管理的小块。把这些做完，AI 才有机会真正“读懂”你的材料。

2. 选型：Claude Code 在文档转换场景里的独特位置

2.1 传统方案各有各的软肋，不是不能用，是不够用

我先说几个大家常用的方案，以及它们的问题。

第一类是在线 PDF 转 Word、转 Markdown 的免费网站。操作简单，但法律材料保密要求高，你敢把当事人的扫描件传到第三方服务器吗？而且这类网站对复杂表格的还原能力一般，批量处理更是别想。

第二类是传统 OCR 软件。识别准确率还不错，但输出仍然是一堆纯文本，没有结构，没有元数据，用完还是得靠人肉二次整理。等于把“识别”这步做了，把“理解与组织”这步留给了你。

第三类是自己写脚本处理，比如用 Python 加几个库。这条路对会写代码的人是可行的，但对大多数法律人，为了转个文档去学正则表达式，门槛太高。而且 PDF 本身格式就很复杂，没有 AI 辅助调试，光是处理页眉页脚、合并表格单元格就能把人磨疯。

2.2 Claude Code 的 Agent 模式正好补上短板

Claude Code 给我的感觉，和上面这些方案都不太一样。它是一个跑在终端里的 AI Agent，可以读你本地的文件、执行命令行工具、查看结果、再根据结果调整下一步。处理文档时，它不是“一次性把 PDF 拖进去”，而是像一个人那样：先看文件状态，判断需要哪几步，逐步执行，最后输出整理好的 Markdown。

对于法律人来说，这个能力非常关键。它相当于一个懂技术的助手，你说一声“把证据册转成结构化 Markdown”，它能自己想着先 OCR、再清洗、再排版、再生成索引。而普通 AI 聊天工具只能在对话框里帮你转一小段，没有文件系统的读写权限，也不可能对着一整个目录做批量处理。

Claude Code 还支持把整套流程封装成固定的指令模式。比如你把“证据材料转换要求”写进项目说明，它每次进入这个目录都会自动遵循。这一点对团队协作特别实用，相当于把一套文档处理标准变成了可复制的流程。

2.3 它终归是个终端工具，真正厉害的是可编排

当然，如果你完全不碰命令行，初上手会有点不适。但好消息是，你不需要懂编程，只需要能执行几条命令、会用文本编辑器。Claude Code 本身就是那个帮你写命令、改命令、判断命令结果的人。

我会在下一章把安装、初始化和完整流程一步步写出来，照着做就行。你现在只需要记住一个判断：凡是“要批量处理本地文件、要做格式转换、要按规则生成多个文件”的场景，Claude Code 的优势都比对话框式 AI 大得多。这也是为什么我最后选它来做这套法律文档转换工作流。

3. 从零搭一套文档转换工作流：安装、命令与提示词

3.1 环境准备：先把三件套装好

这一节是给完全没接触过终端的法律同事看的。先说结论：你只需要三个东西——一个终端工具、一个安装包管理工具、以及配套的文档处理命令。

第一步，打开系统的终端。苹果电脑搜索“终端”就可以打开；Windows 建议使用 PowerShell 或 WSL 环境；效率最高的还是 Windows 自带的 PowerShell，配合命令行工具使用也很顺手。

第二步，安装 Claude Code 命令行工具。具体安装命令建议以官方文档为准，因为命令行工具更新较快，不同时期的安装方式有差别。装完之后在终端输入：

claude --version

如果能看到版本号，说明安装成功。第一次运行它会要求登录，按照提示完成认证即可。

第三步，安装文档处理配套工具。我这里推荐两个组合：一个是 PDF 文本提取工具包（提供 pdftotext、pdfinfo、pdftoppm 这些命令），一个是 OCR 引擎。macOS 用户可以用系统自带的包管理器直接装，Linux 用户也一样，Windows 用户装完 WSL 之后，在 Linux 环境里操作最省心。

# macOS 示例 brew install poppler tesseract # Linux 示例 apt install poppler-utils tesseract-ocr

OCR 引擎记得装上简体中文语言包，否则扫描版判决书识别不了中文。装完之后，用tesseract --list-langs验证，如果在列表里看到 “chi_sim”，就说明中文字库已就绪。

这一套装完之后，你的终端就具备了“提取文本、识别图片、跑 AI 任务”三件套，后面的事都基于它们展开。

3.2 先摸清材料底细：这一步不能省

拿到一批 PDF 之后，我习惯先建立一个干净的目录结构，把原始文件、中间产物、最终输出分开，避免几十个文件堆在一起分不清谁是谁。

cases/某合同纠纷_001/ ├── source/ # 原始 PDF ├── raw/ # 中间转换出的 txt / OCR 结果 ├── output/ # 最终 Markdown └── index.md # 文件级索引

然后，不要急着转换，先让 Claude Code 检查这批 PDF 是文字版还是扫描版。这一步很重要，因为处理路径完全不同。

# 查看 PDF 页数和基本信息 pdfinfo "source/判决书.pdf" # 提取前几页文本，看看有没有文字层 pdftotext -layout -f 1 -l 3 "source/判决书.pdf" - | wc -m

如果wc -m输出的字符数量少得可怜，比如几十个字符，那基本可以判定这是扫描件，需要走 OCR 流程；如果输出几百上千字符，说明是原生文字版，直接提取即可。为什么要把这步单独拎出来？因为我最开始偷懒，让工具盲目自动处理，结果文字版被强行过了一遍 OCR，原本清晰的字符反而被识别错了好几个。正确的顺序应该是：判断类型，再选处理路径。

3.3 跑通单文件，再上批量：最小可行闭环

我先拿一份单页合同试运行，确保整条链路没问题，再铺开处理整个证据册。

对文字版 PDF，直接用 pdftotext 提取，但要注意加-layout参数，它可以尽量保留原来的排版结构：

pdftotext -layout "source/合同文本.pdf" "raw/合同文本.txt"

对扫描版 PDF，先转成图片，再做 OCR：

# 把 PDF 每一页转成 300dpi 的图片 pdftoppm -r 300 -png "source/证据册.pdf" "raw/page" # 对某页图片做中文 OCR tesseract "raw/page-001.png" "raw/page-001" -l chi_sim --psm 6

这里-r 300是分辨率，300dpi 对一般法律文档足够，太低识别率差，太高文件大且速度慢。--psm 6是告诉 OCR 引擎“把整页当成一个统一的文本块”来识别，适合大部分判决书、合同这种规整排版。

跑完 OCR 之后，得到的还是 txt 文本。真正的重头戏是让 Claude Code 把这些文本变成结构化的 Markdown。我一般是给它一段明确的任务描述，像这样：

claude -p "请阅读 raw/ 目录下的文件，把它们整理成结构化 Markdown： 1. 识别文档类型（判决书、合同、证据清单、公证书等）； 2. 提取关键元数据：案号、当事人、日期、页码； 3. 保留标题层级，用 Markdown 标题表示； 4. 表格必须转成 Markdown 表格，列名不能丢； 5. 金额、日期、编号原样保留，不要自动修正； 6. OCR 识别不确定的字，用 [待复核] 标记； 7. 输出到 output/ 目录，并在 index.md 里汇总所有文件的信息。"

你可能会问，为什么不直接让 Claude Code 一步到位，自己完成 OCR 和转换？其实完全可以，Agent 模式会自动调用系统命令，我就是这样试过，效果不错。但我的习惯是先把 OCR 跑完，这样能保证中间产物留在本地，万一最终结果出问题，我还有原始识别稿可以排查，而不是要重新跑一遍全流程。

单文件跑通之后，批量就是水到渠成的事。只需要把任务描述里的“单个文件”改成“source/ 目录下所有 PDF”，Claude Code 会遍历文件，逐个处理。我实测过，一份 30 页的证据册，从判断类型到输出带索引的 Markdown，大约几分钟到十来分钟，耗时主要取决于扫描件质量。

3.4 提示词里要提醒自己的三个法律文档“死穴”

写转换提示词时，有几个法律文档特有的坑，必须明明白白写进去，否则 AI 会自动“帮你修复”一些不该改的东西。

第一个是金额和编号的原样保留。AI 有个毛病，喜欢帮人“纠错”。当它识别出“100,000”和“100000”不一致时，可能自作主张统一格式。在证据材料里，这绝对不行。所以提示词里必须明确：金额、日期、合同编号、法条编号，一律原样保留，哪怕看起来有问题。需要修正的地方，用标记人工决定。

第二个是 OCR 不确定的地方如何标记。法律文档里的生僻字、印章文字、手写体，OCR 很容易出错。与其让 AI 猜一个错误的字，不如明确要求它用 [待复核] 标出来。这样后续人工复核时，可以快速跳跃到风险点，而不必整份重读。

第三个是表格识别不能掉链子。证据清单、对账单、股权结构表，这些信息的核心价值就在表格关系里。我会在提示词里强调：表格必须还原成 Markdown 表格，列标题不能丢，单元格内容不能跨行串位。

4. 质量校验：表格、金额与法条编号是重灾区

4.1 校验工作要像审合同一样较真

转换完成不是终点。在我看来，校验才是这套流程里最需要人来盯的环节。因为自动转换一定会出错，只是错多错少的问题。我的原则是：可以容忍格式瑕疵，但不能容忍核心信息错位。

最基本的校验分三层。第一层是完整性校验，确认文件数量和页数一致；第二层是抽样对比，我一般从每个批次里随机抽 3 到 5 页，人工对照 PDF 原文，重点看金额和日期；第三层是结构校验，检查 Markdown 表格列数是否统一、标题层级是否完整、索引里的页码引用是否真实存在。

这中间最容易翻车的就是表格。一个典型的症状是：原表格有 5 列，转出来的 Markdown 表格某些行的竖线数量对不上，意味着单元格内容串位了。AI 给出的回答可能依然流畅，但背后的数据是错位的，比数据缺失更危险。

4.2 用两三个正则命令，快速揪出常见错误

人工逐页核对不现实，所以要借助命令行做快速筛查。这里分享几个我常用的检查命令。

第一个是检查法条编号是否断裂。法律文本经常出现“第八条”“第十一条”这类编号，OCR 很容易把“第八条”识别成“第八 条”或“第八*条”。用正则统计一下编号格式是否统一即可：

grep -oE "第[一二三四五六七八九十百零〇0-9]+[条款章节]" "output/判决书.md" | sort | uniq -c | sort -nr | head -20

如果发现某段文本里其他编号格式都正常，突然出现一个离谱的格式，那大概率是识别错误，需要人工回看。

第二个是金额集中检查。法律文书里金额是最不能被改错的。命令如下：

grep -oE "[0-9]+([,，][0-9]{3})*(\.[0-9]+)?(元|万元|亿元)?" "output/对账单.md" | sort -u

它能帮你把文档里所有金额列出来，人工扫一遍，确认没有明显异常的数字，比如多了一个零或小数点错位。

第三个是页码引用完整性检查。如果索引里写了“第 12 页”，那原文的对应位置必须能找到相关信息。这一点很难完全自动化，但如果你的转换流程里保留了页码标记，至少可以抽查几个。

我还会做一个“脏字符”检查，看文档里是否残留乱码、井号堆叠、多余的空白符。这些虽然不致命，但会干扰 AI 后续阅读。命令很简单：

grep -nE "[^\x00-\x7F]{5,}|#{3,}" "output/合同.md" | head -20

建议把这段命令存成一个小脚本，每次转换完自动跑一遍，比人工盯屏幕高效得多。

4.3 长文档切分与 token 预算管理

校验之外，还有一个问题要提前想好：几百页的长文档，后续给 AI 分析时怎么喂？如果不切分，一次对话根本装不下；塞进去也会把大量预算浪费在不重要的页眉页脚上。

我的做法是按“卷”切分。比如一份 200 页的证据册，我会让它按内容逻辑拆成几个部分，每部分不超过 40 页左右，分别输出 Markdown，再生成一个总索引。这里的核心是：明细归明细，索引归索引。AI 先读索引建立全局认知，再按需读取某个具体文件，而不是把整卷一口气读完。

你可以在转换提示词里直接写清楚切分规则，例如“超过 40 页的文件先拆分成多个 Markdown，并在 index.md 用表格列出每个文件的页码范围”。这样后续不管是做问答还是检索，都有据可循，不会出现“读了后面忘了前面”的尴尬。

5. 从“格式正确”到“AI 阅读友好”：给 Markdown 加一层语义

5.1 元数据头：每个文件先交代背景

这一步是很多人容易忽略的。转换出来的 Markdown 如果只有正文，AI 读到时往往缺少背景铺垫，理解效果会差很多。

我的做法是给每个文档加一个 YAML 格式的元数据头，把“这是什么文件、涉及哪些主体、原始来源是谁、属于什么案件”这些背景信息一次性告诉 AI。举个例子，一份判决书转换后，开头看起来是这样：

--- 文件类型: 民事判决书 案号: （模拟）某民初字第001号 当事人: 原告: 甲公司 被告: 乙公司 证据编号: E-2024-001 密级: 内部 转换日期: 2025-06-10 来源页码: 1-36 ---

这个元数据头之所以重要，是因为 AI 在后续阅读时，永远都知道自己在看哪份文件、服务哪个案件。当它回答“根据判决书第 12 页，违约金比例为每日万分之五”，就比凭空给出结论可靠得多。

你不需要手动写这些，只需要在转换提示词中要求“为每个输出文件生成 YAML front matter，内容包含文件类型、案号、当事人、证据编号、页码范围”。Claude Code 会自动填充。

5.2 证据编号化与对话式检索

一个好的转换结果，应该让 AI 能“边读边引用”。我给证据材料转换时，会要求保留原始证据编号，并在 Markdown 中把每个证据项都写成可以引用的锚点，比如“证据编号: E-2024-001”，然后在正文里用段落与之对应。

这样做有什么实际价值？我举一个真实的处理场景。我有一批某买卖合同纠纷案的证据材料，转换完成后，我直接让 Claude Code 基于 output/ 目录回答：“请整理所有涉及逾期付款违约金的证据，列出文件编号、原文位置和金额。”它能检索到相关段落，并且引用证据编号和页码。我要复核的时候，直接翻到对应原件的页码，十分钟内就能确认答案是否可靠。

如果材料没有经过结构化处理，这个检索过程几乎不可行。所以我会说：转换的终点不是生成一份好看的 Markdown，而是让 AI 能够“带着引用去回答问题”。

5.3 把转换流程固化成团队资产

单人用 Claude Code 做转换，价值已经不小；但如果能让整个法律团队共用，收益会更大。关键在于把这套流程固化成“项目模板”。

我会把转换要求写进项目的说明文件里。Claude Code 每次在这个目录里工作时，会自动读取这个说明文件，按照团队约定好的格式处理文档。比如你在项目说明文件里规定了“所有输出的 Markdown 必须有元数据头、所有证据必须保留原始编号、所有表格不得丢失列名”，那么团队里的任何人都可以用同一条命令获得同样规范的结果。

把这个思路再推进一步，就是把转换提示词本身存成文件。以后团队成员只需要执行：

claude -p "$(cat tasks/transform.md)"

就能触发整套转换流程，而不必关心内部细节。这套东西就像是给团队配了一位“格式监理员”，谁交上来的材料都是同一套规范，后续 AI 分析的质量也因此稳定得多。

6. 法律材料的敏感性：本地处理、脱敏与人工复核底线

6.1 优先本地化处理，别让原件满天飞

法律材料不同于普通办公文档，里面装着当事人身份信息、银行账户、商业合同细节。任何一步处理，都要先想过数据安全。我的底线是：原始 PDF 尽量不离开自己可控的设备。

上面介绍的所有命令，包括 pdftotext、pdftoppm、tesseract，都是在本机运行的，处理过程中文件不会上传到任何第三方网站。这是我能放心用这套流程的前提。Claude Code 在终端里执行任务时，理论上会把相关文件内容发送给模型服务端，因此对于高密级材料，我会做额外处理，而不是直接拿原件上。

6.2 脱敏副本：给敏感材料加一道锁

处理高密级案件材料时，我习惯先做一个脱敏副本，再让 AI 处理。具体来说，把当事人姓名替换成“甲某/乙某”，身份证号、手机号、银行账号统一替换成占位符，金额和日期保留原样（因为做法律分析离不开这些数据）。

用命令做一次简单脱敏并不难：

sed -E 's/[0-9]{18}/[身份证号已脱敏]/g; s/1[3-9][0-9]{9}/[手机号已脱敏]/g; s/[0-9]{12,20}/[账号已脱敏]/g' "raw/证据文本.txt" > "raw/证据文本_脱敏.txt"

之后再用脱敏文本做结构化转换。这样做的好处是，即使中间某个环节出了问题，核心敏感信息也已经被遮挡。这个习惯让我在处理多个案件材料时始终睡得安稳。

6.3 转换结果必须标注“辅助整理”，留人工复核环节

最后一条底线：AI 生成的转换结果只能作为辅助材料，不能直接当作正式工作文件。我会在输出文件的元数据里标注“经 AI 辅助整理，内容未经人工复核不得作为正式依据”，并在交接给其他同事前，由承办人对关键页做人工确认。

这不是对 AI 的不信任，而是法律工作本身的严肃性决定的。一个金额的错位，在普通场景里可能只是数据错误；在法律文书里，可能直接改变一个条款的判断方向。所以我的建议是：把 AI 转换当作“质量的起点”，而不是“质量的终点”。它帮你节省了录入、排版、编目等大量重复劳动，但最终的专业判断，永远需要你自己把关。

我在跑完一大批材料之后，还有一个习惯：拿一份已经人工复核过的文件作为“种子样例”，让 Claude Code 照着它的格式风格处理后续文件。有时候，与其反复修改转换提示词，不如给 AI 一个标准答案让它模仿，效果往往更直接。这算是我自己摸索出的一条经验，希望对正在搭建法律文档处理流程的你有用。