企业官网建设流程全解析

前阵子接了一个看着特别不起眼的活儿：一份八十多页的 PDF，前二十来页是给A组的，后面六十多页是给B组的，需要拆成两个文件分别发出去。我一开始觉得这事儿五分钟就能搞定，结果第一次交付就被退了回来——A组说他们收到的文件少了一页，B组说里面有张附件的编号跟正文对不上。那次之后我才把这件事当成一个正经流程来对待：一份 PDF 要分成两组人发，拆分本身不是难点，难点在于拆完之后怎么证明"发出去的两份都是对的"。

这篇东西讲的是一套可复现的操作方法：怎么按页码把一份 PDF 拆成两份（或多份）、怎么在拆分前把原件的底摸清楚、怎么在第一道核对里确认文件页数、怎么在第二道核对里确认内容编号和顺序。它解决的问题很具体——拆分后的文件不能靠"我感觉应该没错"来交付。适合经常处理资料分发的人看：做项目文档归档的、做投标资料分册的、做培训材料按学员分组发放的、做合同附件按签署方拆分的，哪怕你完全不会写代码，前面几节的思路和核对表格照样能用；会一点 Python 的，后面有可以直接抄的脚本。全文没有高深的东西，都是被退回来几次之后磨出来的流程。

1. 先把"拆"这件事想明白：需求拆解与方案选型

1.1 两组人的页码规则从来不是简单的"一刀切"

绝大多数人听到"按页码拆开"，第一反应是找一个中间页，前面一份后面一份。但真实需求往往比这个复杂。我遇到过的情况至少有四种：第一种是最简单的连续区间，A组拿第1到20页，B组拿第21到85页；第二种是交错分配，A组要第1到10页和第50到60页，因为那部分是他们的职责范围，中间夹着的是B组的内容；第三种是封面和目录要两边都带一份，正文才分开；第四种是某几页是双方共用的通则，需要复制进两份文件里。

这四种情况的处理方式完全不同。连续区间用任何工具都能做，交错分配就必须支持任意页码集合，共用页则意味着同一个物理页会出现在两个输出文件里，页数之和会大于原件页数——如果你的核对逻辑还停留在"两份加起来等于原件"，就会误判成出错。所以动手之前，先把"谁要哪些页"写成明确的页码表达式，比如1-10,50-60和11-49,61-85，而不是一句"前后分开"。这个表达式就是后面所有操作的唯一依据，也是核对时的对照标准。

我现在的习惯是把这个表达式直接写进一个文本文件或者表格里，作为这次任务的"配置"。原因很实际：拆分过程中一旦需要重来，你不需要重新回忆当时是怎么想的，照着配置再跑一遍就行。人在处理这种机械任务时最容易犯的错就是"第二次凭印象做"，而印象和第一次往往不一致。

1.2 为什么核对顺序必须是"先文件页、再编号"

标题里那句"先核对文件页再核对编号"，不是随口排的顺序，背后是两层考虑。

第一层是检查成本。核对文件页数是最便宜的检查——一条命令、一个属性面板就能看到，几秒钟出结果；核对内容编号是贵的检查，要么写脚本抽文本，要么一页页翻。把便宜的检查放前面，能在一秒钟内筛掉大部分低级错误，避免你在一个页数都不对的文件上辛辛苦苦核对编号。这跟修东西先看电源通不通是一个道理。

第二层是逻辑依赖。文件页是"容器层"，编号是"内容层"。如果容器本身就错了——少了一页、多了一页、顺序乱了——那么容器里的编号必然跟着错位，这时候你去核对编号，得到的任何结论都不可信。反过来，页数对了，编号仍然可能错，比如某页内容被重复复制、某个条目跨页导致编号被切到另一份文件里。所以这两道核对不是二选一，是有先后、有依赖的两道关卡，顺序反了就是白做功。

我在实际项目里把这两道关卡固化成了两个动作：拆分脚本跑完之后立刻打印每个输出文件的页数和页码区间，这是第一道；确认无误后再跑编号抽取和比对，这是第二道。中间任何一道不过，就回到配置环节改，而不是在输出文件上手工修补——手工修补出来的文件和配置对不上，下次复现就是灾难。

1.3 三条技术路线的取舍：图形工具、命令行、脚本

工具选型这件事，我的原则是"任务做几次"决定用什么。只做一次、页数不多，用图形界面的 PDF 阅读器就够了，拖拽拆分、手动选页，五分钟完事，学工具的时间比干活的时间还长就不划算。但如果这个任务每周都要来一次，或者一次要拆十几份，那手工操作的边际成本会迅速超过学习成本，这时候就该上命令行或者脚本。

三条路线的差异我整理成了下面这张表，选型的时候直接对照自己的情况看：

我自己的默认选择是脚本，理由不是"脚本更高级"，而是脚本能把核对这件事一起做掉。图形工具拆完，你还得另开一个窗口去看页数；命令行拆完，你还得再敲一条命令去看页数；脚本拆完，它自己就把页数、页码区间、编号数量打出来了，一个动作完成拆分和第一道核对。这个差别在拆十几份文件的时候特别明显。

不过要提醒一句：如果你完全不会写代码，不要为了这个任务去学。用命令行工具配合一个手工核对的表格，同样能达到目的，只是慢一点。工具是为人服务的，流程对了，用什么工具都能交付。

2. 动手之前：把原件的底摸清楚

2.1 原件三体检：页数、加密、是否扫描件

拆分之前必须对原件做三项检查，这三项任何一项没查清楚，后面都可能白干。

第一项是页数。这个数字是所有核对的基准，必须先拿到而且必须准确。用命令行可以直接看，qpdf --show-npages input.pdf返回的就是物理页数；用 Python 打开文件读len(reader.pages)也一样。这里要特别注意：有些阅读器界面上显示的页数包含了尚未渲染的空白页，有些在线预览工具统计的是"内容页"而不是"物理页"，以命令行或者脚本读出来的物理页数为准，不要相信截图。

第二项是加密状态。带打开密码的文件，脚本读取会直接抛异常；带权限密码（可以打开但不能编辑）的文件，有的工具能正常读，有的工具会拒绝，行为不一致。我的做法是先试着读一次，如果报权限相关的错，就先用有权限的账号另存一份干净的副本再处理。这一步不做，到拆分那一步才报错，前面的准备工作全废。

第三项是判断这是"文本型 PDF"还是"扫描型 PDF"。判断方法很简单：随便抽一页抽文本，能抽出成段的文字就是文本型；抽出来是空字符串或者一堆乱码，就是扫描件。这个判断直接决定了第二道核对能不能自动化——文本型可以写脚本抽编号，扫描件只能靠人工目视。我吃过这个亏，一份两百页的扫描件我按文本型写了抽取脚本，跑了半天抽出来零个编号，还以为是自己正则写错了。

2.2 页码口径对齐：物理页、标注页、纸面页码

这是整个流程里最容易出岔子的地方，也是我建议每个人都重视的一节。同一份文件里，"第几页"至少有三种含义，而且它们经常不一致。

物理页，就是 PDF 文件里从第一页开始数，第 1 页、第 2 页……这是拆分工具认识的页码。标注页，是 PDF 阅读器软件额外标出来的页码，有的软件从封面开始算，有的软件会自动跳过前言部分，所以在某些文件里软件显示的"第 12 页"其实是物理第 15 页。纸面页码，是印在纸上的那个数字，可能从正文才开始编号，前面封面目录用罗马数字，正文从 1 重新开始。

三种口径混用的后果非常典型：需求方说"从第 15 页开始分"，他看的是纸面页码，你按物理页去切，结果切出来的位置差了七八页，而且因为页数看着差不多，第一道核对还发现不了。我现在的做法是，在任何操作之前，先找出三个"锚点页"来对齐口径：封面是物理第 1 页，这个确定；随便找一个纸面上印着数字的页，记录下它的物理页号和纸面页码，算出偏移量；再找正文第一页，确认它是不是重新从 1 开始编号。

把偏移量写进配置里，之后所有沟通和核对都用同一套口径，并且在页码账本里明确标注"本表页码均为物理页"。这句话看着小题大做，但它能省掉之后一半的来回确认。

2.3 建一本页码账本

前面说过要把页码表达式写下来，具体形式就是这本账本。它不用多复杂，一个表格就够，但字段要齐。我一般用这几个列：

预期页数这一列必须自己算出来，不能空着。算法很简单：把页码表达式展开成列表，列表长度就是预期页数。上面第一行1-10是 10 页，50-60是 11 页，加起来 21 页。这一步手算也就几秒钟，但它的价值在于后面核对时你有一个明确的对照数字，而不是"打开看看差不多就行"。

编号范围这一列，取决于文档本身的编号规则。有的文档每个条目一个编号，页数和编号数可能一致；有的文档一页里有多个条目，编号数远大于页数；有的条目跨页，编号只出现在起始页。所以在填这一列之前，得先搞清楚这份文件的编号是怎么排的，这件事在下一节会具体讲。

账本建好之后，它就是这次任务的"合同"。拆分脚本从里面读页码，核对脚本拿它当预期值，交付的时候发出去的文件名也按它的命名列来。改需求可以，改账本，然后重跑，不要在输出文件上直接动手改。

3. 按页码拆分的三种落地方式

3.1 图形界面：页数少、一次性任务的最快路径

如果你一年也就遇上这么一两次，而且页数在百页以内，图形界面是最省事的路。常见 PDF 阅读器的"页面管理"或者"组织页面"功能都支持选中若干页后另存为新文件，有的还支持按区间拆分。操作逻辑基本一致：打开原件，进入页面缩略图视图，按页码表达式选出需要的页，右键导出或者另存为，然后在保存对话框里改文件名。

这里有几个细节值得注意。第一，选集的时候用缩略图视图比列表视图可靠，因为缩略图能让你看见页面内容，选到一半能发现"这页明显不是给甲组的"。第二，选页时按住 Shift 点首尾可以连续选，按住 Ctrl 或 Cmd 点选是追加，但交错区间（比如 1-10 加 50-60）必须分两次操作或者多次追加，这种时候特别容易漏掉几页，选完一定要看工具栏上显示的"已选 N 页"是否等于账本里的预期页数。第三，另存的时候不要覆盖原文件，输出到单独的目录里，而且文件名按账本里的命名列来写，带接收方标识和版本号。

图形界面最大的风险是"看不见的漏选"。缩略图滚动到几百页之外，很容易漏掉一两页，而眼睛扫一遍是发现不了的。所以就算用图形界面，拆完也必须做第一道核对——回到账本，看页数对不对。这一条没有例外，不管用什么工具。

3.2 命令行：qpdf 与 pdftk 的稳定输出

命令行工具的好处是结果确定，同样的命令跑一百次结果都一样，而且能写进批处理脚本。常用的有两个：qpdf 和 pdftk，前者更新更活跃，后者语法更直观但有些环境里不好装。

qpdf 的拆页语法是这样的：

# 拆分：从原件中抽取指定页码，输出到新文件 qpdf input.pdf --pages . 1-10,50-60 -- out_a.pdf qpdf input.pdf --pages . 11-49,61-85 -- out_b.pdf # 看页数 qpdf --show-npages out_a.pdf

--pages后面的那个.代表"输入文件本身"，这个写法有点怪，但它是必要的占位，不能省。页码表达式支持逗号分隔的多段区间，正好对应交错分配的情况。输出文件如果已存在，qpdf 默认会覆盖，所以命令里加不加都行，但我习惯先清理输出目录再跑。

pdftk 的语法更接近自然语言：

pdftk input.pdf cat 1-10 50-60 output out_a.pdf pdftk input.pdf cat 11-49 61-85 output out_b.pdf

注意 pdftk 的区间之间用空格分隔，不是逗号，写错了会直接报错，这点比 qpdf 友好，因为它不会静默地只处理第一段。

命令行最容易犯的错是把页码写错而自己不知道。qpdf 如果给了一个超出总页数的页码，通常会报错，但如果给的是范围内的错页码，它一声不吭就照做了。所以命令跑完，第一件事是qpdf --show-npages看输出页数，跟账本对一遍。这个动作我只花三秒钟，但救过我很多次。

还有一个容易被忽略的点：qpdf 默认会保留原件的文档信息字典和书签（outline），pdftk 一般也会保留，但如果书签指向的页码超出了输出文件的范围，阅读器里点书签可能会跳错位置或者无响应。如果这份文件是要给人正经阅读的，拆完之后检查一下书签，把指向不存在页面的条目清掉。这个细节很少有人提，但收件人点开目录发现跳转失灵，对你的印象分会掉得很厉害。

3.3 脚本：可复现、可批量、可自校验的拆法

到了需要重复执行、需要自校验的阶段，脚本就是唯一合理的选择。下面这段用 pypdf 写，逻辑很直白：读原件，按页码列表取页，写新文件，然后打印页数。

from pypdf import PdfReader, PdfWriter def parse_ranges(expr: str): """把 '1-10,50-60' 解析成 [1,2,...,10,50,...,60]""" pages = [] for part in expr.split(","): part = part.strip() if not part: continue if "-" in part: a, b = part.split("-") pages.extend(range(int(a), int(b) + 1)) else: pages.append(int(part)) return pages def extract(src: str, pages_1based, dst: str): reader = PdfReader(src) total = len(reader.pages) bad = [p for p in pages_1based if p < 1 or p > total] if bad: raise ValueError(f"页码越界: {bad}，原件共 {total} 页") writer = PdfWriter() for p in pages_1based: writer.add_page(reader.pages[p - 1]) # pypdf 内部是 0 基 with open(dst, "wb") as f: writer.write(f) return total if __name__ == "__main__": src = "input.pdf" jobs = [ ("1-10,50-60", "out_a.pdf"), ("11-49,61-85", "out_b.pdf"), ] total = None for expr, dst in jobs: pages = parse_ranges(expr) total = extract(src, pages, dst) print(f"{dst}: 预期 {len(pages)} 页，已写入") print(f"原件共 {total} 页")

这段代码里有三个设计是有意为之的。第一，页码解析函数单独抽出来，因为"把区间表达式变成页码列表"这个动作在拆分和核对里都要用，抽出来才能保证两边口径一致。第二，加了越界检查，页码超出总页数直接抛异常而不是默默跳过——默默跳过的后果是页数少了你还不一定发现。第三，add_page的入参是 0 基索引，所以这里写了p - 1，这个转换是最经典的出错点，写反了会导致整体偏移一页。

如果你更在意抽取文本做核对，用 PyMuPDF（导入名是 fitz）会更顺手，它的insert_pdf支持按页区间插入，文本抽取也比 pypdf 强：

import fitz def extract_range(src: str, start: int, end: int, dst: str): doc = fitz.open(src) out = fitz.open() out.insert_pdf(doc, from_page=start - 1, to_page=end - 1) out.save(dst) out.close() doc.close()

注意insert_pdf的to_page是包含在内的，所以end - 1对应物理第end页。这种"包含端点"和"不包含端点"的差异在不同库里不一致，pypdf 的切片是左闭右开，fitz 的是双闭，混用必错。我的做法是每个项目只用一套库，不在同一个脚本里混着调，省得记混。

4. 第一道核对：文件页数校验

4.1 三条必须成立的等式

拆分完成后，第一道核对要验证三条等式，这三条不等式任何一条不成立，都说明操作有问题。

第一条：每个输出文件的页数，等于账本里的预期页数。这条是最直接的，但它只能发现"多拆少拆"，发现不了"拆错了位置"。比如甲组要 1-10 和 50-60，你错拆成了 1-11 和 49-60，页数刚好也是 21 页，这条就查不出来。所以还需要第二条。

第二条：所有输出文件的页数之和，等于原件总页数（前提是页码不重叠）。这条能发现"漏页"。比如原件 85 页，输出 21 加 63，和是 84，说明有一页谁都没拿到。反过来和大于总数，说明有页被重复分配了——但注意，如果需求本来就有共用页（比如封面两边都带），那这条等式要改成"总页数减去共用页数"，不能硬套。

第三条：页码表达式的并集必须覆盖 1 到总页数，交集必须为空（或恰好等于共用页集合）。这条是最严格的，它能查出"拆错位置但页数刚好"的情况。实现方法是把两边的页码集合算出来，做并集和差集，看有没有漏的、重的。

这三条我写成了一个小校验函数，跟拆分脚本放在一起跑：

def check(total, expr_a, expr_b, pages_a, pages_b, shared=0): set_a, set_b = set(parse_ranges(expr_a)), set(parse_ranges(expr_b)) full = set(range(1, total + 1)) print("A 页数:", len(set_a), "预期:", pages_a, "一致:", len(set_a) == pages_a) print("B 页数:", len(set_b), "预期:", pages_b, "一致:", len(set_b) == pages_b) print("并集缺失:", sorted(full - (set_a | set_b))) print("重复页:", sorted(set_a & set_b)) print("总页数核:", len(set_a) + len(set_b) - len(set_a & set_b) + shared, "应为", total)

跑一遍看输出，全是 True 和空列表才算过。这种"打印一堆布尔值"的土办法看着不优雅，但在一堆文件的时候特别管用——你不用点开每一个文件，扫一眼输出就知道哪一批有问题。

4.2 自动化校验脚本

光比对配置还不够，因为你比对的是"我以为切了什么"，而不是"实际切出了什么"。真正可靠的做法是打开输出文件，读它实际的页数，再拿来对照。这一步是防止工具行为异常（比如某些工具有页数上限、某些文件有个别页无法解析被跳过）。

from pypdf import PdfReader def actual_pages(path: str) -> int: return len(PdfReader(path).pages) for expr, dst in jobs: expected = len(parse_ranges(expr)) got = actual_pages(dst) flag = "OK" if got == expected else "!! 不一致" print(f"{dst}\t预期 {expected}\t实际 {got}\t{flag}")

我在实际使用中还会加一步：把每个输出文件的首页和末页各抽一小段文本打印出来。原因很实际——页数一致但内容错位的低级错误（比如把乙组的区间切给了甲组）靠页数是查不出来的，但看一眼首页标题就能发现。这个动作成本极低，收益极高。

另外，如果原件有文件大小异常的情况，我也会顺手比对一下大小。不是说大小必须成比例，而是如果拆分出来的文件大小是 0 或者小得离谱，那基本可以确定是空文件或者只有空白页，一眼就该看出来。

4.3 抽样目视：抽哪几页最有效

自动化核对过一遍之后，还有一步人工确认不能省，尤其是要发给别人的文件。但人工确认不是从头翻到尾，那是浪费时间，正确做法是抽有代表性的页。

我一般抽这四个位置：第一页，确认封面和抬头对不对；切割点前的那一页，确认它属于这一组而不是另一组；切割点后的那一页，确认它归到了另一组；最后一页，确认结尾完整，没有截断在半句话上。如果文档有目录，还要翻一下目录页，看目录里列的内容和实际页是否对得上。

为什么切割点前后最重要？因为按页码硬切，最容易出问题的地方就在边界。有时一个完整的章节横跨两页，你按页码一刀下去，前半段在甲组，后半段在乙组，两边都拿着半截内容去找人问。这种情况页数核对完全正常，编号核对也可能正常（如果编号在首页），只有目视抽查切割点才能发现。我在标题里强调"先核对文件页再核对编号"，但这两道核对之外，切割点目视是我一定会加的一步。

5. 第二道核对：编号与顺序的一致性

5.1 编号抽取的三种可靠度

第一道核对过了，说明容器没错。第二道核对要确认容器里的内容编号是连续的、没有缺漏、没有跑到别组去。这一步的可靠度完全取决于原件类型，我把三种情况列出来，你对号入座。

第三类情况我必须说得直白一点：扫描件的编号核对没有捷径。OCR 能帮你把文本抽出来，但对A-01这种带连字符、带前导零的编号，识别率并不理想，A-01被识别成A-O1或者A-0l是常有的事。这种时候把 OCR 结果当"辅助线索"可以，当"核对依据"不行。我的做法是扫描件走人工，把账本打印出来，一页一页勾。

5.2 编号集合的差集比对

对于文本型文件，用集合做差集是最干脆的办法。思路是：先算出这一组应该有哪些编号（从账本里的编号范围生成），再从实际的 PDF 里抽出所有编号，两边做差。多出来的说明混进了不该有的内容，少了的说明有内容丢失。

import re import fitz PAT = re.compile(r"\b[A-Z]{1,2}-\d{2,4}\b") def collect_ids(path: str): doc = fitz.open(path) ids = [] for page in doc: ids.extend(PAT.findall(page.get_text())) doc.close() return ids ids_a = collect_ids("out_a.pdf") print("A 组编号数量:", len(ids_a)) print("去重后:", len(set(ids_a))) print("首尾:", ids_a[0] if ids_a else None, ids_a[-1] if ids_a else None)

实际用的时候，正则要按你文档里的编号格式来写。这里有个坑：如果正文里也会出现形如A-01的文字（比如交叉引用"详见 A-01"），那么抽出来的编号会包含这些引用，数量会多于实际条目。处理办法是限制抽取范围，只从页眉或者条目开头的固定位置抽，而不是全文扫。fitz 的get_text("dict")可以拿到每段文字的坐标，按 y 坐标过滤页眉区就行。

还有一种情况是编号跨页。一个条目占了三页，编号只印在第一页，那么按页统计编号数量会远小于页数，这是正常的，不要一看到"编号数不等于页数"就以为出错了。判断方法很简单：让编号数等于账本里的条目数，而不是页数。

5.3 切割点前后的衔接检查

编号核对里最容易被忽略的一环，是切割点附近的内容衔接。我遇到过这么一次：一个条目的标题在物理第 20 页最后一行，正文在第 21 页。按 1-20 和 21-85 拆分，结果甲组拿到一个光有标题没有正文的条目，乙组拿到一段不知道属于哪个条目的正文。两边的编号核对都是"通过"的，因为编号在标题那页，属于甲组；但内容实质上是断的。

检查方法是把切割点前后各一页的文本抽出来，看最后一行的句子是否完整、下一份文件的第一行是否是一个自然的开头。如果第一行是半句话、是一个孤零零的数字、或者直接就是正文中间，那就说明切错了位置，需要把切割点往前或往后挪一页。

这个检查不一定要写脚本，把两页的文本打出来看一眼就行：

def peek(path: str, page_no: int, chars: int = 300): doc = fitz.open(path) text = doc[page_no - 1].get_text().strip() doc.close() return text[-chars:] if page_no > 1 else text[:chars]

看输出的结尾和开头，接得上就没问题。接不上，就调页码表达式，从头再跑一遍。这个动作在整个流程里花不了一分钟，但能避免"发出去之后被对方指出内容不完整"这种最难堪的情况。

5.4 交付前的一张放行单

两道核对都过了，还不算完，交付环节本身也会出错。我现在固定用一张放行单，五个问题全答"是"才发出去：

• 文件命名是否包含接收方标识、内容范围、版本号？
• 每个文件的页数是否与账本一致，且已在文件属性里复核过？
• 编号集合的差集是否为空，首尾编号是否在预期范围内？
• 切割点前后各一页是否目视确认过衔接完整？
• 发送渠道是否只发给了对应的接收方，有没有把两个文件放进同一封邮件？

最后一条尤其重要。我见过一次事故：两个文件都做好了，核对也全对，但因为放在同一个聊天窗口里发出去，甲组顺手点开了乙组的文件。这不是文件本身的问题，是分发环节的问题。解决办法很土但有效：分组发，不要图省事合并发送；文件名前缀带接收方标识；邮件正文里明确写一句"本文件共 N 页，对应条目 X 至 Y"。

6. 踩过的坑与排查速查表

6.1 页数对不上的五类原因

页数不对是最常见的问题，但原因不止一种。我把遇到过的整理成表，下次遇到直接对号：

第二行那个"区间重叠"值得多说一句。交错分配的时候，人很容易把边界页写进两段里，比如甲组1-10,50-60，乙组10-49,61-85，第 10 页两边都有。这时候两份文件的页数都比预期多一页，而总数又刚好对得上（因为重叠部分被算了两次），非常隐蔽。用集合交集一查就出来了。

6.2 编号错位的典型场景

编号错位比页数错位更难发现，因为文件能正常打开、页数也对。我总结了三类高频场景。

第一类是编号跨页导致归属错误。前面提过，一个条目跨两页，编号在首页，切在中间就把内容劈开了。处理办法是切之前先扫一遍每个条目的起止页，尽量让切割点落在条目边界上。

第二类是编号规则不统一。有的章节用A-01，有的用A-1，还有的用附件一，正则只写了一种，抽出来自然对不上。这种情况别急着改脚本，先把原件里的编号格式摸清楚，该合并正则就合并，该分模式匹配就分模式。

第三类是编号重复。原件本身就有重复编号（比如不同章节各自从 01 开始），你去重之后数量变少，误判成丢失。这种情况要在编号里加上章节前缀再比，或者干脆放弃全量比对，改成按章节分段核对。

6.3 交付环节的坑：命名、大小、误发

最后说几个交付环节的问题，都是吃过亏才记住的。

命名混乱是第一位的。out_a.pdf、新建文件夹(2).pdf、最终版.pdf这种名字发出去，收件人根本不知道自己拿到的是什么。我的命名规则是"主题_接收方_内容范围_版本_日期"，比如"资料汇编_甲组_第1-10及50-60页_v1_20240115.pdf"。名字长一点没关系，清楚最重要。

文件大小是第二位。几十兆的文件通过聊天工具发，经常被压缩或者直接发不出去。如果原件里图片多，可以先看看能不能降采样再发，但降采样之后必须重新核对页数——压缩工具有时会合并或者丢弃页面。这个坑我踩过一次，压完没核对就发了，对方说少了三页，回头一看压缩工具把空白页给删了。

第三位是误发，前面说过，分组发，别合并。还有一个细节：如果两个文件内容是分级的（甲组能看的乙组不能看），那文件名和邮件正文里就别把另一组的信息写进去，避免"文件名暴露了另一组的存在"这种尴尬。

我在实际使用中发现，这套流程真正花时间的不是拆分，而是把页码表达式和编号范围确认清楚。一旦这两个东西落到纸面上，剩下的都是机械动作，跑脚本、看输出、勾表格，十几分钟就能完整走一遍，而且心里踏实。踩过几次坑之后我的体会是：这类任务的正确率不取决于你手有多快，取决于你在动手之前愿不愿意花五分钟把账本写出来。下次再遇上要拆分的资料，你可以先别急着打开文件，先把那张页码表格填了，后面会顺很多。