WorkBuddy 做文件归档：目录树怎么设计、指令怎么写、索引清单怎么留

2026-08-08

积压两年的资料要归档，很多人第一反应是”先把它整理干净”。但归档真正的失败方式不是没整理完，而是三个月后你想找去年那份合同，翻遍新建的目录都找不到——文件确实都在，只是你想不起当初把它放进了哪个分类。

所以把归档交给 WorkBuddy（Tencent WorkBuddy）这类能读写本地文件的桌面 Agent，重点不在”它移动文件快不快”，而在你有没有让它同时留下一份能反查的索引。这是本文和”用它整理桌面”那类一次性清理最大的区别：清理只要当下变干净，归档要的是半年后还能用。

一、先定目录树，再谈自动化

动手之前必须由你自己拍板一件事：这批资料按什么分。常见的三种分法各有代价：

分法	适合什么资料	主要代价
按项目	一份资料只属于一个项目、项目边界清楚	跨项目的通用材料无处安放，容易到处复制
按年份	财务、票据、归档留存类，查找时你记得起时间	同一个项目的东西被年份切碎，追溯要跨好几个目录
按类型	合同、发票、图片这类形态高度一致的资料	数量一多，单个目录里堆几百个文件，等于没分

实际能用的结构通常是两层组合：第一层挑最稳定的维度，第二层再细分。「年份 / 项目」适合结算类资料，「项目 / 类型」适合还在推进中的工作。第三层别再加了，层级越深越懒得点进去。

WorkBuddy 的官方文档在讲工作目录时给过一条建议：按任务类型分别建目录，文档举的例子是发票整理、周报、待处理照片，理由是便于管理并降低误操作的风险。这条对归档尤其重要——归档要动的文件多，一旦把整块盘丢给它，出问题的范围就是整块盘。所以先建好空的目录骨架，再让它往里搬，而不是让它一边判断一边建。

命名约定也在这一步定死。官方在批量重命名的示例里给的规则是 日期 + 主题 + 类型，并且要求”先展示重命名预览结果”。这个三段式对归档够用了，关键是日期格式统一成 2026-08-08 这种，排序才不会乱。

二、分三轮跑，别指望一句话到位

官方技巧里”小步快跑”那条讲的就是这件事：把大任务拆成独立小目标，一次推进一步，发现方向偏了能及时拉回，而不是最后整份推翻。归档天然适合拆三轮。

第一轮：只盘点，不动手。

先不要移动或重命名任何文件。

【输入】扫描 D:/待归档 目录下的全部文件（含子目录）。

【目标】统计一份现状清单：
1）按扩展名分组，列出每组的文件数量和占用空间；
2）列出所有子目录及各自的文件数；
3）单独标出文件名重复、疑似重复内容、以及扩展名与内容不符的文件。

【输出格式】表格输出，同时保存一份 Markdown 到 D:/待归档/_归档记录/00-现状清单.md。

【约束】只读不写原文件，不做任何删除、移动、改名。

这一轮的作用是让你看清楚”到底有多少东西”，看到真实数字之后，目录树往往要改一版。官方也建议首次使用优先用「问一问」这类只问答、不修改文件的模式，熟悉后再切到会实际改动文件的模式。

第二轮：出待移动清单，你确认后再动。

【输入】D:/待归档/_归档记录/00-现状清单.md 以及 D:/待归档 下的实际文件。

【目标】按以下结构规划归档去向，先出清单，不要执行移动：
- 一层按年份（2024/2025/2026），二层按类型（合同/发票/方案/图片/其他）；
- 无法从文件名或内容判断年份的，一律归入「_待人工确认」，不要猜。

【输出格式】生成对照表，四列：原完整路径、建议新路径、判断依据、置信度（高/中/低）。
保存为 D:/待归档/_归档记录/01-待移动清单.csv。

【约束】本轮不执行任何移动。置信度为「中」和「低」的行集中排在表格前面，便于我优先复核。

把”置信度低的排前面”写进指令，是为了省你的复核时间。归档最容易出错的从来不是那 90% 一眼能判断的文件，而是剩下那些名字含糊、日期缺失的。让它自己把不确定的挑出来，比你从头扫一遍整张表快得多。

官方在讲远程执行时的原则同样适用于本地批量操作：涉及删除、覆盖、批量移动时先要求预览。这一轮就是预览。

第三轮：执行移动，并且必须产出索引。

【输入】我已复核过的 D:/待归档/_归档记录/01-待移动清单.csv。

【目标】按表中「建议新路径」执行移动，目标目录不存在则创建。
执行完成后生成索引文件。

【输出格式】
1）索引表 D:/归档/_归档记录/02-索引.csv，列为：
   原完整路径、新完整路径、文件名、大小、最后修改时间、所属分类、归档日期；
2）执行报告 D:/归档/_归档记录/03-执行报告.md，写明成功数、失败数、
   每条失败的原文件路径与失败原因。

【约束】只移动，不删除、不改写文件内容；同名冲突时在新文件名后追加 -2、-3，
不要覆盖任何已存在的文件；「_待人工确认」目录下的文件不动。

“同名冲突不许覆盖”这句必须写进去。归档场景里同名文件比日常常见得多，两个项目各有一份「方案终版.docx」再正常不过，一旦被覆盖，丢的那份连回收站都进不去。

三、索引表才是这活儿最值钱的交付物

移动完成后你会得到三样东西：整理好的目录树、_归档记录 下的三份过程文件、以及那份 02-索引.csv。前两样是过程，第三样才是资产。

原因很实际：归档改变了文件路径，而你记得的往往是旧路径、旧文件名。索引表把原路径 → 新路径的对应关系固定下来，日后搜一个关键词就能定位，不需要重新回忆分类逻辑；它同时是一份回滚依据，哪天分类方式不合适了，照着表反向重排也有据可依。

所以索引表有两个字段不能省：原完整路径和最后修改时间。前者用于反查，后者用于在文件名都相似时区分版本。

四、交付物长什么样

跑完之后，D:/归档 下应该是这样：年份目录里按类型分好的文件，一个 _待人工确认 装它不敢判断的，一个 _归档记录 装现状清单、待移动清单、索引表和执行报告。用下划线开头是为了让这两个目录排在最前面。

官方文档提到过一条相关的坑：如果任务里没有明确指定输出文件类型，生成的文件可能打不开；给出的做法是下达任务时就说清楚要 Word、Excel、PDF 还是 Markdown。索引表建议直接指定 CSV——纯文本、跨工具能打开、以后写脚本处理也方便。

五、四步验收，别跳

文件总数对账。 拿第一轮现状清单里的总数，减去 _待人工确认 里的数量，跟归档目录下的实际总数对一遍。三个数对不上，先看执行报告里的失败条目。
索引表能不能反查。 随手挑三五个你记得住的旧文件名，在索引表里搜，确认能查到新路径；再按新路径去磁盘上确认文件真的在。这一步是在验证索引本身是不是准的——索引写错了比没有索引更危险。
随机抽查新结构。 不看索引，凭直觉去猜某类文件应该在哪个目录，然后去点。如果连你自己都要找两三次，说明目录树设计得不对，趁文件量还清楚赶紧改。
确认没有跨盘失败。 跨盘（比如 D 盘搬到 E 盘）本质上是复制加删除，比同盘移动更容易中途出错，权限、空间、路径过长都可能中断。执行报告里凡是涉及跨盘的失败条目，都要逐条手工确认原文件是否还在。

关于 AI 最容易在哪一步出错，答案很集中：第二轮的分类判断。文件名含糊时它会倾向于给一个看起来合理的分类，而不是老实说”判断不了”——这正是要在指令里写死「不要猜，一律进 _待人工确认」的原因。

至于执行环节的风险，官方常见问题里有一条记录得很清楚：有用户在下发整理桌面的指令后，执行完成但部分文件疑似丢失；官方给的做法是执行前先备份重要文件，执行后优先检查目标整理目录与回收站，仍有异常就保留生成的脚本和执行结果截图再排查。归档动的文件比整理桌面只多不少，这条照做即可，不必展开。

六、四种情况，别交给它

第一，被程序按固定路径引用的文件。 配置文件、素材库、软件的工作目录，一旦被搬走，引用它的程序就会报找不到文件，而且报错往往滞后好几天才被发现。这类目录在第一轮就该排除在扫描范围之外。

第二，共享盘上多人协作的目录。 你重排的是别人也在用的结构，他们的快捷方式和文档里的相对引用会一起断掉。共享盘的目录调整是要先跟人对齐的事，不是技术问题。

第三，有版本管理的代码目录。 Git 仓库里的文件位置本身就是版本信息的一部分，绕开工具直接搬动，轻则产生一堆无意义的变更记录，重则弄坏工作区状态。要重组就用版本工具自己的命令。

第四，你自己还没想清楚怎么分的资料。 目录树是人的决策，它只能执行。标准没定就开跑，产出的是一套你不认可、还得重排一次的结构，而第二次重排的成本更高——原路径这时候已经变了。

小结

归档能交出去的是搬运和记录，不能交出去的是分类标准。先定两层目录树和命名规则，再分三轮走：只盘点、出待移动清单、执行并产出索引。指令里写死三句话——不确定不许猜、同名不许覆盖、本轮不许执行——就能挡住大部分事故。

整理完的目录树好不好看，三个月后你不会在意；能不能凭一个模糊的旧文件名把东西找回来，才是归档有没有白做的唯一标准。