你拿回的 Markdown，以及如何清理它
最后核对
转换给你的是一个 Markdown 文件，不是一份成品文档。这里简要说明会得到什么、哪些部分可信，以及在文件进入代码仓库、wiki 或笔记库之前，值得做的少数几处编辑。
阅读约 5 分钟
输出究竟是什么
本转换器输出 GitHub Flavored Markdown，也就是 GitHub、GitLab、Obsidian、Notion 导入以及多数静态站点生成器使用的方言。它是 CommonMark 加上若干扩展，其中在这里真正要紧的是竖线表格。
这个选择是有意的。纯 CommonMark 完全没有表格语法，因此以它为目标的转换器要么丢掉表格，要么吐出原始 HTML。GFM 表格即使作为纯文本也可读，并且在几乎所有能识别 Markdown 的地方都被理解。
哪些能挺过这趟旅程
| 标题 | 能 — 由相对字号转为 #、##、### |
|---|---|
| 段落 | 能 — 由纵向间距得出 |
| 粗体与斜体 | 能 — 由字体自身的字重与倾斜得出 |
| 无序列表 | 能 — 由行首的项目符号得出 |
| 有序列表 | 能 — 由行首的数字得出 |
| 表格 | 简单矩形的那些，转为 GFM 竖线表格 |
| 行内 code | 能 — 由等宽片段得出 |
| 链接 | 能，前提是 PDF 里带有真正的链接注释 |
| 图片 | 不能 — 输出只有文字和结构 |
| 脚注 | 作为页末正文出现，不带链接 |
| 数学公式 | 作为组成它的字符出现，不会转成 LaTeX |
| 颜色与字体 | 不能 — Markdown 没有表达它们的手段 |
每次都值得做的五处编辑
大多数转换后的文件都需要同一小组清理。它们花不了几分钟，却是「能搜索的文件」和「能阅读的文件」之间的差别。
- 修好标题层级。字号阈值给出的级别局部正确、整体参差——一份文档可能出现三个 H1 而一个 H2 都没有。只扫一遍标题，重新编号，使嵌套关系符合文档真实的大纲。
- 把被拆开的段落接回去。行距宽松的文档会在软换行处断开段落，读起来像一摞短行；把它们接上，删掉多余空行。
- 修复连字符断词。右对齐并启用连字的文本会把词拆到两行。在文件里搜索紧跟换行的连字符。
- 检查每一张表。把 Markdown 里的列数与原文对照，并检查最后一行——末行是最常见的牺牲品。已经变形的表格，通常重打一遍比修复更快。
- 删掉页面家具。重复的页眉页脚会被检测并移除，但如果文档让它们逐页变化——每页一个不同的章节标题——就可能留下残片。
关于表格的一点说明
GFM 竖线表格要求每一行的单元格数量相同，而表头下的分隔行决定了整张表的列数。只要转换器把某一行数错，这张表就是无效的，会以带竖线的字面文本呈现。
这是一种看得见的失败，反倒是好事：你会立刻发现，而不是事后才察觉。下面这张表是坏的：
| 区域 | Q1 | Q2 |
| --- | --- | --- |
| 北区 | 120 | 140 |
| 南区 | 95 |
| 东区 | 88 | 102 |怎么修
补上缺失的单元格；若源单元格本就是空的，留空即可。每一行的竖线数量都必须与分隔行相同。
| 区域 | Q1 | Q2 |
| --- | --- | --- |
| 北区 | 120 | 140 |
| 南区 | 95 | |
| 东区 | 88 | 102 |转义，以及输出里为何偶尔出现反斜杠
Markdown 给一些在普通行文中也会出现的字符赋予了含义。星号表示强调，下划线表示强调，行首的井号表示标题，行首的数字加句点表示列表项。
当这些字符在你的文档里就是它们本身时——一个脚注标记、一个带下划线的变量名、一行确实以「1985.」开头的文字——就必须用反斜杠转义，否则它们会悄悄改变文档的呈现方式。输出里的反斜杠通常是转换器在谨慎行事，而不是出错。
如果某个反斜杠碍事，删掉它是安全的，只要你随后确认那一行的呈现效果。
文件接下来去哪儿
Markdown 是纯文本，而这正是当初要转换的理由：可以 grep 搜索，可以 diff 比对，五十年后任何能打开文本文件的东西都还能读它。
进代码仓库，就放进目录树，交给代码评审处理。进笔记库，先检查标题层级，因为多数笔记库据此生成大纲。做静态站点，补上你的生成器需要的 front matter——没有任何转换器能凭空造出它，因为它本就不在 PDF 里。要喂给语言模型，请看为检索准备 PDF 的那篇指南，那是另一件事，优先级也不同。