用WorkBuddy跑一次批量重命名：先干跑，再执行

批量操作最让人紧张的地方，是按下执行之前不知道会发生什么。这次要给一批资料文件统一命名，我用 WorkBuddy 把流程拆成“干跑—核对—执行—复核”四步，全程没有出现误改。

为什么要干跑

重命名规则看起来简单：按日期前缀 + 主题 + 序号。但真实文件里混着括号、空格、重复日期、已经改过一半的名字。规则一旦直接执行，错的就是一批，不是一个。

所以第一步只生成一张对照表，不动任何文件：

风险标记只标三种：目标名已存在、原名无法解析出日期、改名后可能与另一条重名。这三种正是后来真正出问题的地方。

四步怎么走

1. 干跑：只输出对照表，逐行带判定依据。
2. 人工核对：只看风险标记非空的行。这次 80 多个文件里，需要人看的只有 7 行。
3. 执行：确认后按表执行，并把对照表存成日志。
4. 复核：执行完再扫一遍，确认没有残留旧名、没有重名。

第 3 步的日志是回退保险。万一规则有问题，照着表能反向改回去——没有日志的批量操作，等于把自己逼到只能重来。

任务编排的做法可以参考 WorkBuddy 官方文档；而“参数、默认值、异常分支要写清楚”这一点，和 BackendWiki 里的接口文档写法 是相通的。

复盘

真正省时间的不是自动改名，是把需要人判断的 7 行挑出来。以前逐个人工改要半小时，现在核对两分钟、执行几秒。

这条经验适用于所有批量操作：先干跑、留对照表、只复核风险行、执行后回扫。工具负责把规则稳定地跑一遍，判断留在人手里，顺序反了就容易出事。