【ima知识库】WorkBuddy+印前 https://ima.qq.com/wiki/?shareId=cfc23f6e54f850b8199b30024de01c5f7e1c39a8f7faa6c8ad216230d519bb97

上期回顾：

【图文0860期】AI工作流01：字体类——找字体、全网抓取、定时整理

AI工作流：微信/QQ接收文件自动整理入库

冰月制版 · 印前AI工作流系列 · 【图文0861期】

一、每天收一堆字体文件，怎么管？

前面那篇讲了群员找字体的工作流——有人@机器人，机器人从本地库、网盘、全网、求字体网四步去找。这一篇讲另一头：这些字体是怎么进到本地库的。

我们每天在微信、QQ 上收几十个字体文件。学员发来的、同行分享的、网上扒下来的压缩包、客户给的设计稿里嵌的字体……全堆在微信和 QQ 的下载目录里。那个目录长什么样？按日期分文件夹——2026-07、2026-08，每个文件夹里字体、压缩包、图片、PDF、exe 全混在一起，文件名乱七八糟，重名的、带乱码的、改过名的什么都有。

更麻烦的是，微信下载目录不是给你长期存东西的地方。它随着聊天记录走，文件名是一串看不懂的哈希，原始字体名早丢了。你不整理，这些字体就等于"收了但用不了"——下次要找某款字体，翻遍下载目录也翻不到，因为名字早就对不上了。

手工整理？一天几十个文件，逐个解压、逐个改名字、逐个搬进主库——光想想就头大。而且手工容易出错：漏解压一个包、漏删一个垃圾文件、重名覆盖了正确版本、同名不同内容搞混……这些问题平时看不出来，等群员问"帮我找某某字体"的时候才暴露——要么找不到，要么发过去是坏的。

所以我们把整条链路做成了自动化：五个阶段串起来，从"微信下载目录里一坨乱文件"变成"主字体库里干净的 BYZB- 前缀字体"。脚本跑一遍，几十个文件半小时理完，比手工快十倍，还不出错。这篇就把这套流水线拆开讲。

二、先讲一条铁律：破坏性操作必须预览确认

自动化整理说白了就是一连串"移动、删除、覆盖"。这些操作有一个共同点：做错了不可逆。删掉的压缩包找不回来，覆盖的字体找不回来。

所以整条流水线的设计原则就一条：任何破坏性步骤，必须先"预览"再"执行"。脚本分两种模式——--dry-run 只列出"我要做什么、动哪些文件"，不改任何东西；你看了清单确认没问题，再带 --exec 真正动手。

这套"预览—确认—执行"三板斧，看着多一步，实际省的是后面救火的时间。我们之前手工整理偶尔手滑删错一个包，要花大半天从网盘重新下回来。现在预览一看清单，不对就喊停，零代价。多花的三十秒，值。

这不是多余的谨慎。我们踩过坑——中文文件名直接在控制台打印会静默崩溃（进程退出但前面的删除已经生效了），结果你以为没跑、其实东西已经被删了。所以从那以后，所有脚本必须带 UTF-8 环境跑、输出写进日志再看，绝不直接管道到屏幕。宁可多一步确认，不冒一次险。

三、五阶段流水线总览

顺序不能乱。先归位，解压才有统一入口；解压完才能只留字体；只留字体才能干净重命名；重命名完才能放心入库。一步错，后面全乱。

四、阶段一：归位

微信下载目录是按年月分文件夹的。字体、压缩包散在好几个日期文件夹里。第一步就是把这些文件"捞"出来，平铺到根目录，不建新的分类文件夹——保持平铺，后面脚本好处理。

重名怎么处理？两个文件 md5 一样（内容完全相同），说明是重复，移到「_重复文件」目录里先留着，不删；md5 不同只是名字撞了，加 _1 序号区分。

这一步只移动不删除，空目录默认保留。安全。它的作用是为后面阶段提供"一个干净的统一入口"——所有待处理的字体和压缩包都在根目录，脚本不用再递归钻各个日期文件夹，处理效率高，也不容易漏。

有人问：为什么不顺便把文件分类？比如字体放一个文件夹、压缩包放一个文件夹？因为后面阶段二要解压、阶段三要删非字体，分类反而增加脚本的复杂度。整理流水线讲究"先平铺、后提纯"，平铺阶段只管把东西捞出来，分类的事留给后面阶段用规则处理。过早分类是很多手工整理流程效率低的根本原因。

五、阶段二：解压平铺 + 彻底删包

压缩包解出来，内容平铺到根目录，然后原压缩包删掉、空的残留目录删掉。这一步是破坏性的——解压软件包（exe/dll）打散之后就失效了。所以执行前必须问一句：全部平铺，还是软件包保留文件夹？

重点说嵌套包。包里套包的情况很常见——一个 rar 里还有个 zip。解出来落到根目录后，根目录又多了一个压缩包，得再解一轮。所以脚本是循环跑的，一直跑到"根目录压缩包数 = 0"为止。我们一般跑四轮兜底，确保没有漏网之包。

本机解压器只有 Bandizip，脚本已经内置调用，不用另装。重名处理跟阶段一一致：md5 相同丢副本，不同加 _1。

解压这一步是整个流水线里最"重"的环节——压缩包可能很大、嵌套很深、数量很多。循环解压到无包为止，意味着脚本要反复扫描、反复解压、反复删包。一轮下来根目录可能多出来几百个文件，再扫一轮还有包就继续解。四轮一般够用，极少出现四轮还解不干净的极端情况。如果真遇到了，手动再补一轮就行，不影响已完成的部分。

六、阶段三：只留字体（破坏性，必确认）

解压完，根目录里除了字体，还有图片、PDF、说明文档、色卡文件等等。这一步只保留字体，其他的删掉，空目录清空。

字体判定有两道保险：先看扩展名白名单（ttf/otf/ttc/otc/woff/woff2/fon/fnt），没有扩展名的文件再查"魔术字"（文件开头的特征字节）确认是不是字体，防止把改了名字的字体误删。

但有个坑要特别提醒：印前素材不能当垃圾删。像色卡文件（.acb/.ase）、矢量文件（.ai/.cdr）、PSD、PDF、GMS 宏脚本这些——它们不是字体，但也不是垃圾。脚本会把这类文件单列出来、加粗警告给你看，由你拍板留不留。这一步永远先 --dry-run 导出一份"待删除清单"给你确认，明确说"可以删"了才 --exec。

七、阶段四：按内部名重命名 + 前缀 + 去重

这一步在入库之前做，是字体清理的核心。每个字体文件内部都藏着一张"name 表"，里面记着它的真实字体名。我们读这张表，用真实名字给文件改名，前面统一加 BYZB- 前缀。

命名规则：中文名优先于英文名。语言优先级是 简中 = 英文(US) > 繁中 > 日文 > 韩文。比如一个字体同时有简中名和日文名，用简中名。

去重也在这步：先删 md5 完全相同的重复；再处理同名但内容不同的——保留体积较大的那个（通常更完整）。

为什么这些细节重要？因为字体市场水太深。同一款字体，有人存成 "FZHTJT.ttf"（方正的拼音简写），有人存成 "方正黑体简.ttf"，有人存成乱码名。不统一命名，库里就是一锅粥，后面找字体永远命中不了。统一成"BYZB-方正黑体简"这种规范命名，第一次找就能命中。

这一步会删重复文件，不可逆。所以同样：先 --dry-run 看中文名、日文名是否干净、去重清单是否合理，确认后再 --exec。

还有个解码细节值得提：字体内部名有时是拉丁-1 编码的重音字符（比如「Félkövér」这种带重音的匈牙利字体名），以前会误判成乱码；Mac 平台导出的字体偶尔是日文 Shift-JIS 编码。这些编码问题我们都已经修过，现在能正确解码显示，不会因为编码错乱而错删或错命名。坑是踩过一次才补上的。

八、阶段五：剪切入库主字体库

前面四步把 SRC（微信下载目录）整理干净了，最后一步把字体剪切到 DST（主字体库 J:\02、字体合集）。

同名冲突三种情况：

· 同名且 md5 相同 → 源是重复，只删源、留主库

· 同名且 md5 不同 → 覆盖主库（用户要求"如有重复则覆盖"）

· 主库没有 → 新增入库

这里有个 Windows 特有坑：主库很多字体设了"只读"属性，直接覆盖会报权限错误（err=13）。所以复制前先把目标文件的只读属性清掉，再覆盖。

源文件偶尔会被微信或系统锁住（err=5 删不掉）。脚本会清掉只读、重试 8 次；还删不掉就排一个"下次重启删除"的兜底——主库已经有副本，源删不掉也不影响入库，重启后自动消失。

为什么用"剪切"而不是"复制完手动删"？因为剪切把"复制成功"作为"删源"的前提。只要主库没成功收到副本，源文件就不会被删。这条逻辑保证了一个底线：主库永远不丢字体，源目录最多留点没清干净的残余。残余重启就消失，损失为零。

九、踩过的坑都记下来了

· 删除被拦截：系统有安全删除机制会拦 os.remove。解决方法是用底层 API 直接调 Windows 内核删文件，绕过拦截。

· 中文文件名静默崩溃：控制台默认 GBK 编码，中文文件名打印到管道直接崩、还没输出，但前面的删除已生效。必须带 UTF-8 环境、输出写日志再读。

· .lnk 快捷方式删不掉：沙箱专项拦截，报错跳过并注明，不影响其他文件。

· 解压器只有 Bandizip：没有 7-Zip 和 WinRAR，脚本只能调 Bandizip 的命令行。

· 只读属性：主库字体多为只读，覆盖前必须清只读，否则报 err=13。

· 文件被锁：微信/系统持锁时删不掉，清只读+重试仍失败就排重启删除，主库已有副本无损失。

十、收尾核对，不是跑完就完

流水线跑完，还要做三件事确认没出问题：

① 主库文件数应净增（比如本次净增 110 个）

② 源目录字体基本清空，剩的锁定副本重启后自动消失

③ 各阶段日志留在源目录（重命名日志、入库日志、待删除清单），出问题可回溯

日志不是摆设。哪天发现某批字体命名不对、某文件误删了，翻日志能定位到是哪一轮、哪条命令动的。我们一般把三类日志留在源目录：重命名日志（记录每个文件改成了什么名）、入库日志（记录每个文件去了主库哪个位置）、待删除清单（阶段三的预览导出）。三个文件合起来，这批字体从哪来、经过什么处理、最后去哪了，全程可追溯。

这跟印前生产一个道理：印厂出活要留样、留工单，出问题能倒查。文件整理也是生产——只不过产品是"干净的字体库"而不是印刷品。没有日志意识的整理流程，跑了一段时间出问题你都不知道哪批坏的。

十一、常见问题

Q：这套流水线要手动跑几遍？

五个阶段顺序跑一遍。每个阶段内部脚本自己处理循环（比如解压跑到无包），你只要在每阶段的"预览"和"执行"两步之间确认一次就行。

Q：万一预览看漏了，exec 把重要文件删了怎么办？

所以预览清单要逐条看。特别是阶段三的"待删除清单"，印前素材会单列加粗，那是给你最后一道把关的。养成"看清单—确认—再执行"的习惯，风险可控。

Q：主库是只读的，入库会覆盖坏吗？

脚本会先清只读属性再覆盖，不会报 err=13。这也是踩坑后补的修复逻辑。

Q：为什么不直接删源文件，要剪切？

剪切本质是先复制再删源。复制成功、主库已有副本之后才删源，中途任何失败都不会丢数据。比直接删稳。

十二、这套流水线的价值

回看整条链路：微信/QQ 下载目录一坨乱文件 → 归位 → 解压 → 只留字体 → 规范命名 → 入库主库 → 群员@机器人几秒命中。

前面 1093 那篇讲的"四步找字体"，第一步就是本地库命中。本地库为什么能秒命中？因为背后有这套整理流水线在持续把收来的字体洗干净、规范好、入库。没有这套后端，前端找字体不可能那么快。

自动化不是把活丢给机器就完事。恰恰相反，自动化要求你把每个环节想清楚——什么能删、什么不能删、重名怎么判、锁了怎么办。想不清楚就写不出稳的脚本，写不出稳的脚本就容易删错东西。所以我们用"预览—确认—执行"三板斧，把风险挡在动手之前。

这套整理流水线和前面讲的"找字体工作流""全网抓取字体"是配套的。找字体负责把库用起来，全网抓取负责把库变大，而这条整理流水线负责把库维护干净。三条线合在一起：库大、库干净、找得快。缺了哪一条，前面建的再多也白搭——库脏了，找字体第一步就命中不了，后面全得走网上，效率直接崩。

印前04群，群号718443409，每天免费帮找字体、免费画刀模、免费查印前资源。感兴趣的同行欢迎加入。有问题也可以直接在公众号提问，AI客服基于知识库回答，比到处搜靠谱。

这套整理流水线，配合前面讲的找字体工作流、全网抓取工作流，再加上每天定时整理，就是我们字体库能稳定运转的底子。下篇讲刀模类工作流，敬请关注。

本文章为冰月制版原创图文教程 【图文0861期】📱 微信/QQ群：印前04群 群号718443409🔍 公众号搜「冰月制版」→ 私信 → AI问答，基于ima知识库的专业解答💻 每天免费帮找字体、免费画刀模、免费查印前资源