【制造·硬件】我用 WorkBuddy 清理 Altium 的 History 自动备份：752MB 是怎么被找出来并安全归档的

一、输入材料：一个"每次保存都在长胖"的磁盘

做硬件设计的人都有个默认习惯：Altium Designer 的工程目录里会自己长出一个 History 文件夹，每次保存 PCB 或原理图，就往里塞一个带时间戳的副本。它不占内存、不影响编译，所以几乎没人管——直到磁盘告警。

我的情况是：D:\项目资料\ 下面躺着 16 个客户的项目，从 NPI（试产）到 MP（量产），跨了 2021 年到 2026 年。这些工程里的 History 从来没清理过。

这不是"随便删几个文件夹"就能解决的事，因为：

• History 目录散落在深处，最深的有 7 层，靠资源管理器手动翻根本翻不完；

• 有的 History 很重要——它是设计变更的追溯记录，客户审计时可能要调；

• 有的 History 就是垃圾——同一个文件被反复保存几十次，最后一次才是有效的；

• 不能误删工程文件本身。History 和工程文件同目录混放，名字相似，一旦手抖就是事故。

所以我要的不是"删除工具"，而是先摸清家底、再按规则处置。输入材料就是这棵真实的磁盘目录树。

二、WorkBuddy 配置：用 Skill 锁死"自动化 + 不误删"

我没有让 AI 上来就删，而是先把约束写进 Skill 里（我自建了 windows-disk-space-forensics 和 safe-recycle-bin-batch-delete 两个技能配合使用）。核心约束四条：

1. 先只读扫描，绝不边扫边删。扫描产出清单，不产出动作。

2. 删除必须走回收站（SHFileOperationW + FOF_ALLOWUNDO），

绝不用 rm / del /F —— 出错必须能还原。

3. 批量删除每 10 个文件一批，每批删完复核，任何异常立即停。

4. 全过程留审计 CSV（路径、体积、动作、时间），可回溯。

第 1 条是最关键的。AI 的天性（也是我的天性）是看到问题就想动手，但在磁盘清理这件事上，"先出清单"能让人在灾难发生前看一眼。

三、操作步骤：从 752MB 到一张可决策的清单

第 1 步 · 全盘定位 History 目录。 用 Python 递归遍历 D:\项目资料\，抓所有名为 History 的目录（大小写不敏感）。这一步要注意 Windows 的坑：路径超过 260 字符时 os.walk 默认会静默跳过整棵子树，统计数字看起来正常但实际漏了东西，必须显式收集 onerror 回调里的异常。

第 2 步 · 逐目录统计体积与文件数。 结果出来了：

| 指标 | 数值 |

|---|---|

| History 目录总数 | 211 个 |

| 内含文件总数 | 1,619 个 |

| 合计体积 | 752.2 MB |

▲ 扫描总览：211 个 History 目录 / 1619 个文件 / 752.2 MB

第 3 步 · 按客户聚合，定位大头。 把 211 个目录按顶层客户归并，一眼看出谁在吃空间：

| 客户 | 体积 | 文件数 |

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

| 06-德赛电池 | 410.6 MB | 625 |

| 14-珠海光宇 | 135.5 MB | 258 |

| 93-参考与预研（练习项目） | 92.8 MB | 391 |

| 10-豪鹏 | 45.7 MB | 121 |

| 01-A | 27.5 MB | 21 |

| 其余 7 个客户 | 40.1 MB | 203 |

▲ 按客户聚合：06-德赛电池一家占 54.6%

单个目录最大的是 06-德赛电池下某个 Layout DCR Simulation 的 History，一个目录就 48.5 MB / 46 个文件。

第 4 步 · 分层给出处置建议，而不是一刀切。 这是 AI 最该帮上忙的地方——它把 211 个目录按"风险 / 收益"分了层：

• 可安全清理：93-参考与预研 下的练习项目 History（92.8 MB）——这是自己的练习文件，不是客户交付物，删了零风险；

• 建议压缩归档：客户项目里的 History 保留但打包（用 zip 压缩后原目录删除），既留追溯能力又省空间；

• 建议保留：最近 6 个月内、或客户正在活跃对接的项目，History 直接不动。

▲ 三层处置规则：只读扫描 → 分档 → 执行约束

第 5 步 · 执行。 清理走回收站通道，每批 10 个、删完复核、出审计 CSV。归档走压缩通道，压缩包命名带日期，原目录删除前先校验压缩包完整性。

过程中有个真实的中途调整：AI 第一版方案想按文件扩展名判断 History 里的内容归属，被我否掉了——在硬件项目里，同一份设计文件在"客户原始资料"和"我们外发版本"里可能是不同阶段的产物，文件位置本身就编码了来源和阶段信息，按扩展名归类会毁掉这个信息。改成"只看目录路径 + 时间 + 体积"三个客观维度来做决策。

四、产出物：可验收的清单与台账

最终交付的是一套可以复查的东西：

1. History 全量清单 CSV——211 行，含完整路径、体积、文件数、所属客户、建议处置（保留/归档/清理）；

2. 审计台账 CSV——实际执行了哪些归档与清理、每项的体积与时间；

3. 可回收的月报——本次释放 752.2 MB 中的可优化部分，并给出"下次检查时间"。

清理不是一劳永逸的：Altium 会继续生成 History，所以我把这件事做成了周期性任务——每月自动扫描一次，超过阈值才提醒我处置。这样它就不会再悄悄长到几 GB。

五、复盘：磁盘清理这类事，AI 的价值在哪

这件事人自己也能做，但代价是：手动翻 211 个目录、逐个右键看属性、心里还一直担心删错。AI 的介入把这件事变成了三句话：扫一遍、给清单、按规则执行。

我认为这里有两条经验值得记下来：

一是"只读扫描"必须和"执行删除"分成两轮。哪怕最终目的是清理，第一轮也永远只出清单。人看一眼清单的成本是 30 秒，而误删的代价可能是几天的返工。

二是业务判断必须由人先写进规则。"客户的 History 要不要保留"这类问题，AI 不会自己知道答案；但一旦你说清"客户活跃项目保留、练习项目可清"，它就能 211 个目录一致地执行。规则的机械性，恰恰是它能被自动化的前提。

---

本文为《WorkBuddy 行业应用指南》有奖征集投稿，讲述一个真实发生的制造业工作流案例。