全是无意义的图片文件名？WorkBuddy 批量重命名 28 张，文件名从此会说话

javy21

212人浏览 · 2026-07-27 16:46:39

javy21 · 2026-07-27 16:46:39 发布

🏭导航收藏不迷路—>制造业数据与AI践行者老蒋的技术博客全系列文章汇总（持续更新）

摘要： 写专栏有个扎心的痛点——截图越来越多，文件名全是"屏幕截图 2026-06-30 151206.png"，根本不知道哪张是哪张。每次找配图都像在垃圾堆里翻东西。我用WorkBuddy写了个批量重命名工具，28张截图按"日期+主题"自动归档，文件名从此会说话。本文记录完整开发过程，排坑内容后续在A3专栏单独发布，欢迎关注。

一、开篇：一个老IT的素材管理噩梦

兄弟们，先问你们一个扎心的问题：

你的电脑桌面上，有多少个叫"新建文件夹"的文件夹？

作为一个写了20年代码的老家伙，我自认为对"文件管理"有点心得。直到我开始写这个WorkBuddy专栏——每篇文章都要配图，每张配图都是截图，每个截图的名字都是这样的：

屏幕截图 2026-06-30 151206.png
屏幕截图 2026-06-30 151222.png
屏幕截图 2026-07-04 151010.png
屏幕截图 2026-07-04 151051.png
屏幕截图 2026-07-05 192339.png
屏幕截图 2026-07-05 214321.png
...（省略23张）

一共28张。

每次想找一张"智能客服"的配图，我得一张一张点开看。每次想找"物料变更"的截图，我又得一张一张翻。

这不科学啊......

我决定干一件事：把这28张截图，按"日期+内容主题"批量重命名。

作为一个老IT人，我本可以手动一个个改——但28个文件，一个个右键→重命名→复制粘贴→回车，估计得20分钟。而且下次再有新截图，又得重复一遍。

于是我把这个需求丢给了WorkBuddy。

二、我的需求：简单、安全、可追溯

我跟WorkBuddy说：

把 屏幕截图 2026-06-30 151206.png 这种无意义文件名
改成 20260630_智能客服_图片_01.png 这种自解释文件名
重命名之前先整目录备份——万一翻车了能恢复
记录操作日志——改了哪些文件、成功没、失败没
追加工作记忆——让下次操作知道"上次干过什么"

说白了就是：让文件名自己说话，同时保证安全可回滚。

三、WorkBuddy的输出

WorkBuddy直接给我生成了一个完整的工具包，目录结构是这样的：

case02_photo_file_analysis/
├── 20260630_智能客服_图片_01.png      # 重命名后的素材（共28张）
├── 20260630_智能客服_图片_02.png
├── 20260704_物料变更_图片_01.png
├── 20260705_项目结构_图片_01.png
├── 20260705_B站视频_图片_01.png
├── 20260711_AI助手_图片_01.png
├── 20260711_翻转卡_图片_01.png
├── 20260718_代码终端_图片_01.png
├── 20260718_浏览器控制台_图片_01.png
├── 20260718_市场情报_图片_01.png
├── 20260719_代码报错_图片_01.png
├── 20260719_AI对话_图片_01.png
├── 20260719_制造AI助手_图片_01.png
├── 20260725_博客数据_图片_01.png
├── 20260725_专栏列表_图片_01.png
├── scripts/
│   ├── config.py           # 统一配置：路径+主题映射
│   └── rename_execute.py   # 核心脚本：备份→重命名→日志→记忆
├── logs/               # 操作日志（JSON格式）
├── memory/             # 工作区记忆（每日摘要）
├── README.md
└── debug.md            # 排坑记录（后续在A3专栏单独发布）

最核心的是 config.py 里的主题映射表——我把28张截图按内容分成了13个主题：

SUBJECT_MAP = {
    "屏幕截图 2026-06-30 151206.png": "智能客服",
    "屏幕截图 2026-06-30 151222.png": "智能客服",
    "屏幕截图 2026-07-04 151010.png": "物料变更",
    "屏幕截图 2026-07-04 151051.png": "物料变更",
    "屏幕截图 2026-07-05 192339.png": "项目结构",
    "屏幕截图 2026-07-05 214321.png": "B站视频",
    "屏幕截图 2026-07-11 160006.png": "AI助手",
    "屏幕截图 2026-07-11 161639.png": "AI课程",
    "屏幕截图 2026-07-11 173731.png": "翻转卡",
    "屏幕截图 2026-07-11 224157.png": "翻转卡",
    "屏幕截图 2026-07-11 225931.png": "翻转卡",
    "屏幕截图 2026-07-18 105838.png": "代码终端",
    "屏幕截图 2026-07-18 113536.png": "浏览器控制台",
    "屏幕截图 2026-07-18 113641.png": "浏览器控制台",
    "屏幕截图 2026-07-18 114516.png": "浏览器控制台",
    "屏幕截图 2026-07-18 150421.png": "代码终端",
    "屏幕截图 2026-07-18 150539.png": "市场情报",
    "屏幕截图 2026-07-19 113130.png": "代码报错",
    "屏幕截图 2026-07-19 122324.png": "AI对话",
    "屏幕截图 2026-07-19 122601.png": "制造AI助手",
    "屏幕截图 2026-07-19 135139.png": "制造AI助手",
    "屏幕截图 2026-07-19 135158.png": "制造AI助手",
    "屏幕截图 2026-07-25 142840.png": "AI对话",
    "屏幕截图 2026-07-25 143153.png": "AI对话",
    "屏幕截图 2026-07-25 155854.png": "AI对话",
    "屏幕截图 2026-07-25 171756.png": "博客数据",
    "屏幕截图 2026-07-25 171907.png": "专栏列表",
    "屏幕截图 2026-07-25 171913.png": "专栏列表",
}

这就是"让文件名说话"的底牌。

四、核心机制：批量重命名不是"蛮干"

WorkBuddy生成的脚本，核心逻辑是这样的：

4.1 重命名规则

每个新文件名的格式是：YYYYMMDD_主题_图片[_NN].ext

片段	来源	示例
`YYYYMMDD`	文件修改时间	`20260630`
`主题`	SUBJECT_MAP映射	`智能客服`
`图片`	固定类型	`图片`
`_NN`	同组序号（自动追加）	`_01`、`_02`
`.ext`	原扩展名	`.png`

关键设计：同一天、同一主题的多个文件，自动追加序号。

比如"智能客服"主题有两张截图（日期都是2026-06-30），自动变成：

20260630_智能客服_图片_01.png
20260630_智能客服_图片_02.png

不用手动编号，脚本自动处理。

4.2 执行流程（流水线）


① 生成计划：读SUBJECT_MAP + 源目录 → 按(日期,主题,类型)分组 → 产出"旧名→新名"列表
         ↓
② 整目录备份：shutil.copytree → 带时间戳的备份目录
         ↓
③ 执行重命名：逐个os.rename → 单文件异常局部捕获 → 不中断整体
         ↓
④ 写操作日志：rename_*.json（计划数/成功/失败/备份路径）
         ↓
⑤ 追加记忆：memory/YYYY-MM-DD.md（一行操作摘要）

4.3 四个防护机制（保证安全）

防护	实现方式
备份	重命名前整目录备份，误操作可恢复
局部容错	单文件失败不影响整体，汇总报告
结构化返回	顶层返回 `{ok, error, suggestion}`，不抛堆栈
操作审计	JSON日志 + 工作区记忆，可追溯

我执行完重命名后，日志里记录的是：

{
  "timestamp": "2026-07-26T10:30:00",
  "source_folder": "C:/Users/xxx/Pictures/Screenshots",
  "backup_folder": "C:/Users/xxx/Pictures/Screenshots_backup_20260726_103000",
  "total_planned": 28,
  "renamed_count": 28,
  "error_count": 0
}

安全、干净、可追溯。

五、排坑记录

开发过程中遇到了几个真实问题，包括Windows下venv的Scripts目录与bin的差异、git-bash路径传递问题、一次性脚本的备份与结构化返回设计等。

具体的排坑内容已整理到 debug.md 中，后续会在 A3《数据与AI工程排坑笔记》专栏 单独发布，欢迎关注我的CSDN动态，第一时间获取更新。

六、实际效果

重命名前：

屏幕截图 2026-06-30 151206.png
屏幕截图 2026-06-30 151222.png
屏幕截图 2026-07-04 151010.png
屏幕截图 2026-07-19 122601.png
屏幕截图 2026-07-25 171907.png

（看到文件名不知道内容）

重命名后：

20260630_智能客服_图片_01.png
20260630_智能客服_图片_02.png
20260704_物料变更_图片_01.png
20260719_制造AI助手_图片_01.png
20260725_专栏列表_图片_01.png

（一眼就知道是什么、哪天、哪个主题）

七、实在人总结

怕你忘了，我再啰嗦一遍：

批量重命名的核心不是"改名"，是"建规则"。 规则建好了，文件名自己会说话。
任何有副作用的工具，必须先做好防护。 前置备份 + 操作日志 + 可回滚，缺一不可。这是23年IT老兵的职业操守。
WorkBuddy生成的不只是代码，是完整的工程化方案。 从配置分离到结构化返回，从日志审计到记忆追加，这是一个"能上生产"的工具。
28张截图，一次跑通，0报错。 这不是运气，是WorkBuddy生成的代码质量过关。

八、关联信息

上一篇：源码首发-WorkBuddy实战：CSDN后台数据分析系统完整代码（离线H5看板·双击即用）

下一篇：还在翻 git log 写周报？WorkBuddy 一键生成结构化周报，附可复用 Prompt

兄弟们，我这篇处理了这批无名图片。

现在轮到你们了：

你的电脑里有多少个"新建文件夹"？有多少张截图文件名是"屏幕截图"开头的？

评论区晒出你"最乱的一个文件夹"截图，点赞最高的3位兄弟，我帮你定制一套重命名规则。 不用你写代码，你把文件列表发我，我帮你设计规则+生成脚本。

够意思吧？评论区见！👇

📎 系列导航

专栏	WorkBuddy工作场景应用实践
上一篇	#01 制造业IT老兵用WorkBuddy扒了自己CSDN后台
下一篇	#03 《Git提交记录像天书？WorkBuddy帮我自动生成项目周报》