这不是方不方便的问题——这是确定性和推测之间的鸿沟。

同样的差异贯穿整个文档结构。你在一份判决书里看到"经审理查明"下面那段文字——你知道那是法院认定的事实。但 PDF 只知道那是一段加粗的 16px 宋体字。AI 要自己在那段文字周围的视觉信号里找线索：字号有没有变大？前后有没有换行？有没有编号？然后猜：这大概是个小标题。

HTML 只有一个

标签。它不猜。

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 600 300">
  <defs>
    <marker id="arrow" markerWidth="8" markerHeight="6" refX="8" refY="3" orient="auto">
      <path d="M0,0 L8,3 L0,6" fill="#999"/>
    </marker>
  </defs>
  <rect width="600" height="300" fill="#fff" rx="6"/>

  <!-- Left: PDF -->
  <text x="30" y="30" font-size="14" font-weight="700" fill="#333" font-family="sans-serif">PDF 的方式：坐标 + 视觉格式</text>
  <rect x="30" y="42" width="250" height="220" fill="#f5f5f5" rx="4"/>
  <text x="45" y="68" font-size="11" fill="#666" font-family="monospace">x=72, y=100 "经审理查明"</text>
  <text x="45" y="88" font-size="11" fill="#666" font-family="monospace">  字号：16px，加粗</text>
  <text x="45" y="118" font-size="11" fill="#666" font-family="monospace">x=72, y=140 "原告主张..."</text>
  <text x="45" y="138" font-size="11" fill="#666" font-family="monospace">  字号：14px，常规</text>
  <text x="100" y="175" font-size="12" fill="#c41e3a" font-family="sans-serif">↓ AI 反推</text>
  <text x="60" y="200" font-size="11" fill="#c41e3a" font-family="sans-serif">"字号变大+加粗+换行"</text>
  <text x="60" y="218" font-size="11" fill="#c41e3a" font-family="sans-serif">→ 大概是小标题？</text>

  <!-- Right: HTML -->
  <text x="320" y="30" font-size="14" font-weight="700" fill="#333" font-family="sans-serif">HTML 的方式：语义标签</text>
  <rect x="320" y="42" width="250" height="220" fill="#f0f7f0" rx="4"/>
  <text x="335" y="68" font-size="11" fill="#2d6a2d" font-family="monospace">&lt;h2&gt;经审理查明&lt;/h2&gt;</text>
  <text x="335" y="98" font-size="11" fill="#666" font-family="monospace">&lt;p&gt;原告主张...&lt;/p&gt;</text>
  <text x="380" y="175" font-size="12" fill="#2d6a2d" font-family="sans-serif">↓ AI 直接读取</text>
  <text x="350" y="200" font-size="11" fill="#2d6a2d" font-family="sans-serif">"h2 = 二级标题"</text>
  <text x="350" y="218" font-size="11" fill="#2d6a2d" font-family="sans-serif">→ 确定</text>

  <!-- Divider -->
  <line x1="295" y1="50" x2="295" y2="255" stroke="#ddd" stroke-width="1"/>
</svg>

这意味着什么？一份结构完整的判决书，用 HTML 标记后，AI 可以瞬间定位到"本院认为"段落，提取裁判理由，不需要先把整份文件解析一遍再猜测哪个部分是哪个。一份合同法审稿，用 HTML 标记后，AI 可以精确识别条款层级——哪条是第几条、哪款是第几款——不会被"仿宋还是楷体""缩进几个字符"这些视觉信号干扰。

语义标签给的是确定性。而确定性，是 AI 处理信息时最稀缺的资源。

---

JSON：给数据装上字段名

HTML 解决的是"文档里有什么"。JSON 解决的是"数据里每一样东西叫什么"。

一份合同里的付款节点信息，放在 Excel 里大概长这样：

| 付款节点 | 比例 | 付款条件 |

|---------|------|---------|

| 第一期 | 30% | 合同签订后 |

| 第二期 | 40% | 主体结构封顶 |

| 第三期 | 30% | 竣工验收备案 |

人看这个表，一眼就懂。但 AI 看这个表，先要处理合并单元格（如果比例是合并的）、判断颜色标注（有没有用红底标注了风险节点）、分析公式（30% 可能是公式算出来的而非硬编码值），才能把数据提取出来。

同样的信息，用 JSON 表达：

{
  "付款计划": [
    {"节点": "第一期", "比例": 0.3, "条件": "合同签订后"},
    {"节点": "第二期", "比例": 0.4, "条件": "主体结构封顶"},
    {"节点": "第三期", "比例": 0.3, "条件": "竣工验收备案"}
  ]
}

每一个值都有一个明确的字段名。比例是数字类型，不是字符串——AI 可以直接求和验证 0.3 + 0.4 + 0.3 = 1.0，不需要先把"30%"转成数字。条件是字符串，可以直接做关键词匹配。整个数组可以直接遍历，不需要先判断哪一行是表头、哪一行是数据。

Excel 用视觉编码数据——颜色、字号、合并单元格、公式——这些对人友好，对机器是噪音。JSON 用字段名编码数据——key 就是定义，类型就是规则——对机器友好，对人看就显得啰嗦。

这是两种完全不同的编码思路。前者面向人眼，后者面向程序。AI 恰好站在程序那一边。

法律数据天然适合 JSON 这件事，不需要想象。案件信息（案号、当事人、案由、标的额）、证据清单（证据名称、证据类型、证明目的）、主体信息（名称、统一社会信用代码、法定代表人），每一种都是"键值对"结构。写下来就是 JSON。

为什么 AI 喜欢标签和字段？

标签和字段，本质上在做同一件事：把需要推断的变成已经标注的。

AI 处理一个文件，最消耗计算资源的不是读，是猜。

"这段文字是大标题还是加粗的正文？"——猜。"这个单元格是表头还是数据？"——猜。"这个数字是金额还是编号？"——猜。每猜一次，就引入一次错误概率。猜得越多，链式放大的误差就越明显。

HTML 的

不需要猜。JSON 的 "比例": 0.3 不需要猜。不是 AI 变聪明了，是问题变简单了——输入本身的歧义被消掉了。

这里有个反直觉的结论：提升 AI 输出质量最有效的方法，不是优化提示词，是优化输入格式。一个精心设计的 JSON Schema，比一段礼貌周全的提示词更管用。提示词是在教 AI 怎么猜，JSON Schema 是让 AI 不需要猜。

推到极端来看：你想让 AI 审一份 200 页的合同。给一个 PDF 让它自己解析，还是一份带语义标签的 HTML 加一个结构化的 JSON 条款清单？前一种方案，AI 可能漏掉条款、误读条件、搞错数据。后一种方案，它能直接定位具体条款、精确提取字段内容。差距不在 AI 能力，在输入质量。

---

法律场景里已经发生的转变

说点已经落地的事。

法律知识库的底层，越来越多系统选择用 HTML 做结构化存储。法规的条、款、项有明确的层级关系，用