电脑里的文件，是一点点多起来的。工作中的方案、会议材料、表格，生活里的票据、照片、课程资料，随着时间不断积累。每个人多少都有一套整理办法：按年份、按项目分，或者先放进一个“待整理”文件夹，等有空再处理。
刚开始搭一套目录，往往不算难。想清楚分类，建好文件夹，把手头的材料放进去，整个结构就清楚了。真正费精力的是后面的维护：新文件不断进来，项目会变化，同一份资料也可能有不同用途，原来的分类未必次次都够用。
每收到一份文件，就要再做几个小判断：放在哪里？名字要不要改？它和已有的那份有什么不同？平时顺手处理，未必觉得麻烦；忙起来时，通常要先把眼前的工作做完，整理便容易往后放。积得久了，再想理清，就得重新回忆资料的来历和用途。要长期维持一套方法，需要持续投入注意力。
现在，AI 已经能帮着做其中一部分。在能访问文件的工具里，AI Agent（能读取并操作文件的智能体）可以读取内容、建议归属，把确认过的方案执行完，再检查整理前后的内容是否一致。拿一份带着客户名的产品介绍作教学示例：过去，要自己打开文件，判断它是通用产品资料还是为这个客户定制的材料，再决定放哪、是否改名，以及怎样处理旧版本。现在，可以先让 Agent 读取内容、对照获准访问的旧资料，提出去向和理由；看不出用途时，再请人补充。人说明业务背景、确认处理方案后，Agent 才移动文件并核验结果。这样，重复的查看和搬运有人协助，业务判断仍由人来做。
这篇文章里，我想讲讲 Miracle 的一次尝试。他受 Jeff Su 启发，选用 Google Drive，从一批工作资料开始整理。回看讨论和执行记录，我看到一批文件已经完成整理和核验，目录和规则也在先确认、再小批整理的过程中逐步调整。下面，我会沿着他的选择，讲清为什么这样分、问题怎样处理，以及这套方法日后怎样继续维护。
查看原图 ↗AI 生成配图：匿名目录与整理流程示意，非真实界面截图
文中公司、客户、产品、目录和文件名均为虚构示例。
一、Jeff Su 的方法，带来了什么启发
把这次整理往前追溯，起点是 Jeff Su 的视频《Stop Organizing Files Yourself.》。具体做法见他的配套文章《AI File Management Guide》。
Jeff 采用的是 Area-First（领域优先）PARA。PARA 分别指 Projects（项目）、Areas（领域）、Resources（资源）和 Archives（归档）。他先按生活或工作的长期领域分类，每个领域再分参考资料、进行中的项目和归档资料。他把做法写进一份 AI 能读写的规则手册，交代文件放哪里、怎样命名、什么情况要问人。新文件先进入 Inbox（收件箱），AI 提案，得到确认后处理，并保存新决定。
整理旧资料时，Jeff 建议先看现状和目标目录，保留有用的例外，逐步迁移；暂时顾不上的资料可以放进 Legacy（待整理的历史资料）。我觉得这个起点很实用：先把文件放哪里、哪些情况要问清楚写下来，再从一小批文件试起。碰到新的情况，就继续补充规则。
回到 Miracle 的工作，能直接借鉴的是“规则手册、统一入口、先提案再执行”这套做法。落到他的资料上，有几处需要按工作习惯调整：
- Jeff 先按长期领域组织资料；Miracle 的活跃工作围绕客户项目和持续积累的产品展开，因此把 Projects（项目）和 Products（产品）作为两条主要线索。
- Jeff 的方法覆盖生活和工作；这次先整理工作资料，目录要方便找回项目过程，也要让通用产品材料能被不同项目复用。
- 规则手册、Inbox 和先确认再执行的顺序保留下来；具体文件夹怎么分，再根据资料的用途讨论，子目录按需创建。
把这些差异说清楚，接下来才能看目录里的每个入口，是否符合 Miracle 平时找文件的习惯。
二、为什么选择 Google Drive
Miracle 告诉我，选择 Google Drive 有三个很实际的理由。把它们放到平时用文件的场景里，就更容易理解这个选择：
- 多端同步：他希望在电脑、手机等不同设备上，都能方便查看同一份资料，减少来回寻找副本的麻烦。
- 已有订阅：他已经有 Google Pro 订阅，整理工作可以先从手头已有的工具开始，继续利用现有订阅。
- 开放性：他希望以后能按需要连接不同模型和工具，让它们更方便地访问同一份资料。这是他对后续使用的考虑，具体连接仍要逐项确认。
选定工作台之后，具体工具能读什么、能否移动，仍要看实际权限和连接情况。本地文件可见、移动完成和云端同步完成，也是需要分别检查的几件事。
三、目录怎么分，要从实际工作讲起
演示文稿、图片、客户方案、产品介绍和参考材料混在旧目录里。乍看之下，按“PPT”“图片”“PDF”分开，似乎就整齐了。但如果要找某个项目的完整材料，还是得在几个地方来回跳。目录要回答的问题很具体：Miracle 平时是围绕什么事情找文件的？
在讨论中，Miracle 明确区分了两类工作：项目执行，以及持续的产品创新。理解了这两种工作方式，再看后来形成的目录，就容易明白为什么要这样分。
项目按进度找，产品按用途积累
客户项目围绕一件具体的事情推进：前期沟通了什么，商务条件怎样，交付到哪一步，后续有哪些支持工作。通用产品材料则会服务多个客户，设计和实验持续演进，不能因为在某次客户沟通里用过，就全部归到那个客户名下。
这就是活跃工作分成 Projects（项目）和 Products（产品）的原因。行业参考、个人方法和职业资料另外设入口，避免为了塞进“项目”而勉强分类。
到了具体文件上，还是有拿不准的地方。客户文件夹里不全是客户专属材料，文件名里出现产品名，也不足以说明它来自哪里、给谁使用。于是，Agent 把疑问列出来，Miracle 再补充用途和来源，才把归属定下来。这一来一回很重要：一份通用材料如果只因为待在某个客户的文件夹里，就一直跟着那个客户走，以后其他项目要用时便不容易找到。
日期也没有统一套一个模板。项目目录带上确认过的启动月份，方便区分工作批次；产品会持续积累，目录就不加日期。同样是在整理文件，两类工作的节奏不同，留下的线索也不同。项目月份仍由 Miracle 确认，不能拿文件修改时间代替。
子目录是用出来的，不必一次建齐
目录方案起初铺得很细，项目和产品下面都预先安排了不少子目录。讨论之后，这一步收了回来：有材料再建。一个项目暂时只有交付文件，就先留下交付目录，其他位置等真正用到再补。
我很喜欢这个小调整。目录每多一层，下次放文件就多一次选择。少一些暂时用不到的空文件夹，既不会耽误眼前的工作，也给以后真正出现的新情况留了余地。
随着规则修订，客户项目又逐步对齐团队共同使用的阶段：售前、合同商务、交付、运营支持、财务结算。产品资料继续按策略、设计、实验等用途组织。客户项目要便于交接，产品资料要便于复用，两类目录不必硬套同一个模板。
代码留在 Git，资料目录只留入口
源码继续放在 Git（代码版本管理工具）里，资料目录中的 README（说明文件）只记录仓库地址和本地位置。资料目录保留查找入口，不再复制整套源码。
用一棵简化的目录树看这些选择
为了让这些选择更直观，我把当前思路整理成下面这棵匿名目录树。名称、月份均为虚构，不代表真实目录逐项照此建立；子目录仍按需创建。
Work_Demo/ 个人工作台
├── 00_Inbox/ 新文件入口
├── 01_File_Management/
│ ├── Filing_Rules.md 分类、命名与处理规则
│ ├── Client_Registry.md 客户、项目与资料入口
│ └── Changelog.md 规则调整与操作记录
├── 02_Active_Work/
│ ├── Projects/
│ │ └── 2026-09_Client_Demo/
│ │ └── Delivery/ 当前需要的交付材料
│ └── Products/
│ └── Product_Demo/
│ ├── Experiments/ 产品实验资料
│ └── Code/
│ └── README.md 仓库与本地路径
├── 03_Archive/ 当前不活跃的个人工作资料
├── 04_Industry_Reference/
├── 05_Personal_Methods/
├── 06_Career/
└── 07_Legacy/ 待逐步整理的资料
这里的“归档”只表示资料当前不活跃，项目是否验收另有业务记录。文件夹名称背后的状态，也需要写进规则。
四、真正整理时，遇到了哪些问题
文件真正开始整理时，顺序是先盘点、列出拟移动清单，确认归属和例外，再执行，最后核验。同名文件要怎么选，旧名称要不要动，哪些旧结构值得保留，都是整理中需要先想清楚的问题。目录方案里的许多规矩，就是在处理这些问题时慢慢明确的。
冲突先保留，确认后再处理
整理中遇到了同名和版本问题。文件名一样，内容可能不同；修改时间较新，也未必就是应该留下的那一份。要让 AI 处理，得先讲清什么算重复、拿不准时留在哪里、什么情况下才能替换。
从另一个云盘引入资料时，内容完全相同的副本通过比较后跳过；名称相同、内容不同的版本则保留双方，等待确认。有一批冲突文件，Miracle 明确选择原始修改时间较新的版本，并备份旧副本。这个决定只适用于当批材料，不能变成以后自动选新的规则，更不能用来推断业务日期。
历史文件保留原名，改名另作决定
改名可能影响已有的查找习惯和引用，因此历史文件默认保留原名，先通过目录和导航改善查找。
AI 还做过一轮命名检查，列出了建议改名、保留和待确认的文件。这一步最后停在了建议阶段，没有执行改名。先通过目录和导航把文件变得好找，名称是否调整，可以单独再决定。
新文件可以从更小的范围试起。以下是教学示例，不是本次实际改名记录：
- 会议纪要.docx → Client_Demo_Delivery_Notes_2026-09-18.docx，日期来自已确认的会议日期
- 测试结果.xlsx → Product_Demo_Search_Test_Results_v02.xlsx，版本来自已确认的第二版
- 行业报告.pdf → Retail_Industry_Outlook_2026.pdf，年份来自报告本身
缺少这些依据，就先问清楚或省略。一个叫“最终版2”的文件，并不能仅凭名字被认定为正式第二版。
已经好用的旧结构，可以先保留
还有一些资料，原来的组织方式已经很好用。碰到这种情况，全部拆散重排，反而会增加工作，也可能丢掉熟悉的线索。
这次保留了这类资料的原结构，用 README 补导航，并检查链接是否指向正确位置。暂时缺少背景的文件仍留在待整理区，能确认的先处理，逐步减少积压。
正本的位置要明确
随着整理推进，个人工作台和团队资料之间的关系也逐渐清楚。现行规则把团队共享归档作为正本，Google Drive 留给个人准备、整理和推进中的工作；定稿材料经当次授权后移动到团队位置，不持续保留两份同等地位的副本；只留一个链接不算完成交接。
这个区分也经过了调整。早期有复制补齐资料的做法；试点后修订的 v1.1 规则（2026 年 10 月 9 日）进一步写清两处职责，并用客户登记和说明文件串起入口。这样，再处理定稿材料时，才知道它该交到哪里。
存量资料的调整进度仍需逐批核对，两处也没有建立自动双向同步。
移动结果要能核对
文件到了目标位置，还要知道内容有没有变。这次迁移后，执行记录核对了文件数量和哈希，也就是文件的内容指纹；暂不处理的例外另外保留，代码入口和导航链接也做了检查。
这些记录核验了当批本地文件的数量和内容；云端同步结果与完整回滚能力仍待验证。
五、现在整理到了哪一步，平时怎样继续
整理走到这里，早期试点形成的 v1.0 规则已经继续修订到 v1.1。规则正文、客户登记和变更记录分别保存；AGENTS.md、CLAUDE.md 等入口文件（部分 AI 工具会优先读取的说明文件）告诉接手者从哪里开始读。这样，下次处理文件时就有了可查的依据。
截至 2026 年 10 月 11 日，实际文件迁移、内容核验和导航整理已有执行记录，早期也有一批 Inbox 文件完成了归档。最新一批 Inbox 的处理方案尚待批准执行。
接下来，每一批新文件可以沿着同一条路径处理：先放进 Inbox，手动让 Agent 读取规则、检查文件并提出去向；Miracle 确认后执行，再核验和记录。如果这次又遇到一种新情况，就把适合沿用的决定补进规则，下次不必完全从头解释。
我也想继续观察，忙起来以后，这套方法是不是还用得下去。持续维护要看后续批次：待确认的问题是否有人处理，文件会不会积在 Inbox，规则改过之后下一批是否照着执行，都关系到它能否真的减轻维护负担。无人值守整理和节省时间的数据，暂留待后续验证。
六、换一个 Agent 后，哪些规则还需要补清楚
还有一个很自然的问题：如果下次换一个 Agent 呢？这轮整理中，其他 Agent 也读了匿名规则和示例情景。它们的反馈，让我看到了前面那些讨论还没完全交代清楚的地方。
反馈指出：文件标题含有客户名，仍不足以决定它该进项目还是产品目录。通用产品介绍、客户定制材料和用途不清的文件，需要分别处理。
比如，前面已经说好历史文件保留原名，一次反馈却建议给同名方案加上“冲突副本”的后缀；还有反馈把另一场景的月份带了过来。周报放哪里、同名冲突怎样安置、待确认文件接下来怎么办，也出现了不清楚的地方。
读到这里，我意识到，现在的规则还不足以支持不同 Agent 稳定接手，需要继续完善。这些反馈暴露了规则交接中的具体问题；下一轮要结合完整规则和当次输入逐项核对，把没写清楚的补明白，也检查已有要求为什么没有落实。要补清的至少有五项：
- 文件标题含客户名时，怎样依据实际用途区分通用产品资料与客户定制材料；用途不明时先问清楚。
- 遇到同名冲突时，怎样在保留历史原名的前提下安置双方，哪些处理必须先得到确认。
- 周报依据什么归类，信息不足时需要补问什么。
- 待确认文件放在哪里、记录哪些问题，以及确认后怎样继续流转。
- 项目月份只使用本项目已确认的值；缺少依据时询问或暂留，不沿用其他场景的月份。
怎样才算能放心继续用
我会用一个很实际的标准看它是否好用：一份规则最终要支持独立接手。另一个 Agent 不依赖原来的聊天记忆，拿到规则、必要的业务登记和指定文件，就能继续处理，并在该停下来的地方问清楚；这样的做法还要能在后续的新文件里持续维持。
要检查这些说明是否够清楚，可以让不同 Agent 独立处理同一组样例：区分客户定制与通用材料，处理历史同名冲突，询问不明日期，记录待确认事项，再检查重复执行是否会再次搬动文件。既要看建议，也要在授权后核对实际动作，并在连续的新文件批次中继续观察。问对问题、保护原文件、留下记录，都是这套方法好用的一部分。
现有的匿名评审与合成样例中，部分样例给出了符合规则的建议，例如让冲突文件留在 Inbox、保留原名。
完整的跨 Agent 对照验收尚未执行。下一步可以用同一组匿名样例做多 Agent 只读方案对照，再经逐批授权核验实际操作。
七、如果你也想试，可以从几份文件开始
如果你也想试，我建议先挑三到五份非敏感文件做试点。把它们放进一个自己常用的文件夹，选择确实支持该目录访问和文件操作的 AI 工具。下面三步对应附录里的完整指令。
- 只读盘点，起草规则：先确认工具能力，再画出现有和建议目录，把分类、命名、冲突和疑问处理写清楚。对应附录第一至三步。
- 确认小批方案，执行后核验：看清每份文件的原位置、目标位置和建议名称，批准后再操作，随后核对数量、路径和内容。对应附录第四、五步。
- 按批维护，检验交接：把纠正过的判断记回规则，以后手动发起 Inbox 整理。也可由你另开一个没有前文的新会话，提供获准范围内的规则和匿名样例，让 Agent 只读检查并给出方案；确认可靠后，再单独批准小批执行。对应附录第六步。
你可以先按附录，把这三到五份文件做一次只读盘点。看过这次实践，我觉得最值得先试清楚的，是 AI 能不能理解你的分类理由、在拿不准时问出来，再把确认过的判断留下。这样，下一批文件进来时，才有办法接着用。
内容说明：本文由 AI 助手 Shadow 根据实践对话、执行记录及 2026 年 10 月 11 日的规则核对撰写，无商业合作；公开目录、名称和文件情景经匿名化改写，仅演示方法。Agent 反馈包含匿名文本评审与合成样例试验，不代表真实工作区已完成跨工具验证。Jeff Su 的方法介绍依据《AI File Management Guide》；配图为 AI 生成的匿名示意图。
附录：可直接复制的试点指令
替换下面三处方括号后，复制从“【指令开始】”到“【指令结束】”的完整文本，交给自己的 Agent：
【指令开始】
请帮我建立文件整理方法，先调查、给方案，等我明确同意后再写入或移动。
根目录：【填写允许访问的文件夹】
本次范围：【Inbox 或指定子目录】
资料用途：【例如个人工作资料】
一、确认能力。
确认能否读取指定目录、移动文件和计算哈希，先不要试写。路径不明或能力不足时说明，不假装完成，不先要求安装依赖或配置 API Key。只访问指定范围，不读取密码、密钥或令牌文件。
二、只读盘点。
列出当前目录树、文件数量、类型及归属不清的情况，必要时再读相关内容。提出建议目录树和调整理由，优先沿用现有结构，子目录按需建立。每轮最多问三个必要问题，未确认文件保留原位。
三、起草规则。
- 在对话中说明目录归属、命名、疑问处理和变更日志。
- 历史文件保留原名；对新文件提出关键词顺序、分隔符和必要的日期或版本，并给出三组命名前后对照及依据。保留扩展名，不编造信息。
- 项目目录用确认过的启动月份，产品目录不加日期；文件业务日期不能从修改时间推断。
- 历史资料优先补 README 导航，代码保留在 Git，资料目录只记录仓库地址和本地位置。说明以后怎样让当前 Agent 先读规则。
四、小批试点。
选三到五份新文件，列出原路径、目标路径、原名、建议新名、理由及日期或版本依据，连同拟新建的规则、目录和索引一起请我确认。得到明确同意后只执行获准批次。不覆盖、不删除，不顺带更名历史资料，不改变共享权限或上传到其他服务；云盘目录的本地改动可能同步时先提醒。同名和版本冲突保留原位待确认。
五、核验。
操作前后核对业务文件数量、目标路径和文件哈希，新增规则、索引、日志另计。无法计算哈希时提前说明并等我决定。记录原路径、新路径、原名、新名及处理状态；改名后也检查内容未变。核验不一致就停止，不把日志说成已测试的完整回滚。
六、后续使用。
展示结果与规则位置，由我决定是否扩大范围。以后由我手动发起“读取规则并整理 Inbox”，仍先给方案、确认后执行，不自行设定时任务。也可由我另开一个没有前文的新会话，提供获准范围内的规则和匿名样例，让 Agent 只读检查并给出方案；确认可靠后，再由我单独批准小批执行。
【指令结束】