你准备把项目发出去,可可编辑的源文件还在桌面上,定稿的 PDF 躺在“下载”文件夹里,另一份导出文件则埋在一个叫 Final_New 的文件夹深处。你大概还能回忆起事情的经过,但换个人打开这个项目,就一头雾水了。
一套好用的项目文件夹结构,能让这些决定不再依赖你的记忆。它为收到的素材、可编辑的工作文件和交付文件都安排好固定的位置,还能让你在项目结束时归档收尾,而不丢失上下文。在 Mac 上,先把名称和文件夹理顺,等底层的整理方式合理了,再加视觉提示。
复制模板,搭建顶层结构
从下面选一个最接近的模板。它们只是起点,并不是 macOS 强加的要求。
| 项目类型 | 顶层文件夹 | 最终文件放在哪里 |
|---|---|---|
| 设计 | 01_Brief、02_References、03_Source、04_Working、05_Exports、99_Archive | 05_Exports,每种格式一个子文件夹 |
| 软件开发 | docs、src、tests、assets、build、99_Archive | build,不要放进 src,也不要纳入版本控制 |
| 研究 | 01_Admin、02_Data_Raw、03_Data_Clean、04_Analysis、05_Outputs、99_Archive | 05_Outputs,报告按版本管理 |
| 客户项目 | 01_Contract、02_Brief、03_Working、04_Deliverables、05_Invoices、99_Archive | 04_Deliverables,只放已发送的副本 |
关键在于把输入、可编辑的工作文件和输出分开。下载来的参考图不是你的设计稿,导出的 PDF 也代替不了它的可编辑源文件。角色分清楚了,就更容易判断哪些内容可以重新生成,哪些必须妥善保存。
苹果在其《文件系统编程指南》中做了一个更根本的区分:/System 包含运行 macOS 所需的资源,不应修改;/Users 则包含用户的个人文件夹。请把项目根目录放在由用户自己管理的存储位置,别和操作系统的资源混在一起。
按你的工作方式选择模板
对设计项目来说,在大家开始存文件之前,先定义好 03_Source 和 04_Working 的区别。一个实用的约定是:Source 放提供的素材和可复用的母版,Working 放合成稿和正在进行的修改。如果你说不清这两者的区别,就干脆合并,别留下含糊不清的存放位置。
对研究项目来说,把收到的原始数据保存在 02_Data_Raw 里。转换过的数据集放进 03_Data_Clean,并记录你是怎么得到它们的。这样,修正分析时就不用猜是不是有人改动过原始的电子表格。
软件开发是这套编号模式里有意设置的例外。请使用你的代码仓库、框架和构建工具所期望的目录名。把 build 当作生成的输出,并相应配置版本控制的排除规则;不要手动移动那些工具期望放在别处的文件。
对客户项目来说,Deliverables 指的是你实际发出去的东西。一份候选的演示文稿在正式交接之前,都应该留在 Working 里。这样就不会把尚未获批的草稿当成交付记录。
在访达中搭建项目
选一个长期固定的根目录。 在“文稿”或你的个人文件夹里创建一个 Projects 文件夹,把进行中的项目都放在里面。理由很实际:即使赶时间,你也需要一个会去用的存放位置。最常见的失误是先在桌面上干活,还打算“以后再整理”。把文件放在桌面上并非不可以,但这会让临时存放和有意识地归档变得太容易混为一谈。
给项目起一个容易辨认的名字。 把客户代号或有意义的日期,与一个简短的描述组合起来,比如
Acme_Rebrand或YYYY-MM_Acme_Rebrand。选用大家在沟通和交接时真正会用的标识。避免New_Project这类含糊的根目录名,而且除非你经常为同一个客户管理多个项目,否则不要额外加一层客户目录。按你选的那一行创建文件夹。 对编号模板,使用两位数前缀加下划线。把
01当作行政、简报或合同;02当作参考资料或收到的素材;03在合适时当作工作内容;后面的位置则按模板放分析、输出、导出或发票。把99_Archive留给已结束的材料。这些数字只是确定顺序,并不是一套通用的分类体系。在根目录写一份 README。 说明项目的目的、负责人,以及每个文件夹里该放什么。把新来的人可能误解的区别写进去,尤其是 Source 与 Working、Outputs 与 Deliverables 之间的区别。常见的失误是只列出文件夹清单。要把决策讲清楚:原始数据能不能编辑、批准记录放在哪里、哪个目录里存着交接记录。
存一份空白副本作为你的模板。 在留作复用之前,先清除项目专属的素材、私密合同和客户信息。保留文件夹的说明,把负责人和目的换成清晰的提示语。如果直接复制一个旧的在用项目而不清理,过时的文件和假设就会被带进下一个任务。
不要提前把所有可能用到的子文件夹都建好。先从你能解释清楚的位置开始,等真有素材需要时再增加细分。模板的作用是省去重复的决策,而不是逼你在一堆空类别里翻来翻去。
最后,用访达的分栏视图测试收个尾。按名称排序,打开项目根目录,依次读一遍顶层内容。你应该能在不打开每个文件夹的情况下,说清从收到的素材到工作再到交付的整个流程。
让文件夹保持顺序的命名规则
一个名称应该能让你不用打开就分辨出相邻的项目。当它脱离原来的文件夹、出现在搜索结果里时,也得说得通才行。
用一份简短的清单,别在每次存文件时临时发明规则。
- 前缀保持一致。 位数不统一,有序列表就更难维护。不好:
1_Admin、02_References、3_Working。好:01_Admin、02_References、03_Working。 - 选用可预期的分隔符。 有意义的词之间用下划线,日期或代码内部用连字符。不好:
Acme / Brand & Web。好:Acme_Brand_Web。 - 日期从大单位写到小单位。 需要按时间顺序排序时,使用
YYYY-MM-DD。不好的写法:DD-MM-YYYY_Review。好的写法:YYYY-MM-DD_Review。 - 保留能区分彼此的关键词。 去掉废话,而不是硬性规定字符上限。不好:
All_The_Working_Documents_For_The_Acme_Rebrand。好:Acme_Rebrand_Working。 - 避免不必要的标点。 纯字母、数字、下划线和连字符,更便于脚本处理。不好:
Client's Draft (Approved?)。好:Acme_Proposal_v03。 - 一个角色只用一个词。 同一个位置,别一会儿叫 Exports,一会儿叫 Output,一会儿又叫 Rendered。不好:并列的
Exports和Exported_Files两个文件夹。好:一个有文档说明的05_Exports。 - 把版本和批准分开。 不好:
logo FINAL new 2.ai。好:Acme_Logo_v03.ai,放在03_Source里(如果那是你定义的可编辑母版存放处)。批准情况记录在交付记录中,别靠再加一个 Final 来表示。
有意识地重命名
版本号标识的是一次修订,并不能证明它已获批准。同样,一个叫 Old 的文件夹,也说不清里面的内容是被取代了、被否决了,还是留作参考。
好名字描述的是项目本身,好记录说明的是它后来的遭遇。
文件被复制、同步或归档之后,名称依然有意义。而颜色和图标,承担不了这个责任。
对已有的文件,可以参考我们的 Mac 批量重命名指南里介绍的先预览的流程。应用更改之前,检查是否有重复的目标名称和关联文件。
项目文件夹在创建时就起好名,除非项目范围变了,否则保持稳定。任何重命名都要记在 README 里,包括原来的名称和更改的原因。
为什么文件夹、标签和智能文件夹各司其职
文件夹像图书馆的书架。标签像贴在书上的便利贴。智能文件夹则是保存下来的搜索,能把符合某个条件的每一本书都列出来,却不会把它们从书架上拿走。
这个区别很重要,因为你回答的是不同的问题:**这个东西该放哪儿?什么需要我留意?我想把哪些东西放在一起看?**苹果的访达整理指南把嵌套文件夹、标签和智能文件夹描述为相辅相成的整理和检索方式。
| 机制 | 会移动文件吗? | 最适合 | 容易出问题的地方 |
|---|---|---|---|
| 嵌套文件夹 | 会,当你把项目移入其中时 | 稳定的归属,比如客户、阶段或素材类型 | 层级太多,或者用了每周都在变的状态词 |
| 颜色标签 | 不会 | 临时的优先级,比如“审阅”或“紧急” | 给每个文件都打上,标签就失去了意义 |
| 智能文件夹 | 不会 | 保存下来的、基于规则的视图,比如本月编辑过的 PDF | 规则过于宽泛,视图里什么都有 |
创建一个空文件夹并不会移动任何东西。表格里的区别在于:归档会改变项目的实际位置,而打标签和保存搜索则不会。
稳定的“家”,变化的“视图”
假设你正在准备一份客户演示。可编辑的幻灯片属于项目的 Working 文件夹。在反馈尚未收齐时,给它打上“审阅”标签,审阅结束后再去掉。
你不需要把这份幻灯片挪进单独的 Needs_Review 目录树。那样会让它的位置取决于一个临时的状态,还可能让协作者去它原来的位置找不到。
智能文件夹回答的是更宽泛的问题。你可以把所有进行中项目里最近编辑过的 PDF 汇集起来,或者显示带有“工作”标签的文件。不断调整规则,直到结果服务于某个具体任务,而不是把你的整个文件库重现一遍。
想了解支持这些视图的导航技巧,我们的 Mac 访达使用技巧提供了更多背景。按用途选视图:追踪位置用分栏视图,按外观辨认素材则用可视化预览。
让注意力提示保持克制
当什么都标“紧急”,“紧急”就失效了。要明确定义什么情况才配得上每一种行动标签,以及由谁来去掉它;否则,昨天的优先事项就会变成永久的装饰。
如果保持专注本身就是你的难处,Jan Kutschera 为 ADD 创业者写的整理技巧可以作为补充资料,帮你思考个人的整理方式。把你自己的标签词汇表控制得足够小,小到不用纠结该选哪个就能顺手打上。
用这条判断规则: 如果答案会在项目周期内发生变化,就用标签;如果答案在项目结束前都不会变,就用文件夹;如果你想要一个跨越这些位置的可复用视图,就用智能文件夹。
嵌套多深,结构就会崩溃
**深度应当取决于检索的需要,而不是习惯。**只有当一个独立的文件夹能以大家理解的方式缩小查找范围时,它才值得存在。如果它只是多加了一层叫 Project、Files 或 Assets 的容器,价值就很有限了。
论文 Evaluate, Reorganize, and Share 把语义化整理描述为一种帮助用户推理位置、而不是死记确切路径的方式。这正是检验新增一层的合适标准:它的名字是否让剩下的选择变得更清晰?
下面这张图展示了目录树不断变大时累积起来的导航成本。
让每一层都有明确用途
把下面这些当作建议的布局,而不是实测的上限。统计项目根目录之下的层数,只有当新增一层代表一个有用的区分时,才加上它。
| 情形 | 层数 | 新增一层的触发条件 |
|---|---|---|
| 小型个人项目 | 类别,然后是文件 | 某个类别里包含你反复需要单独检索的不同分组 |
| 持续进行的客户或工作室项目 | 类别、素材分组,然后是文件 | 某个阶段或素材类型有自己独立的交付物 |
| 各有负责人的团队共享项目 | 职责、工作类别,然后是文件 | 协作者需要各自管理的区域和权限 |
| 多年期的研究或代码归档 | 时期、项目、类别,然后是文件 | 反复出现的检索困难暴露出缺少某种分组 |
一个以协作者命名的文件夹,本身并不能起到任何保护作用。需要保护时,请另行配置访问权限。
设想一条假想的路径,埋在 Working、Concepts、Campaign、Digital、Social、Approved、Revised 和 Export 之下。把它压平成 04_Working/Social/Acme_Campaign_v03.ai,生成的交付副本则放在指定的导出位置。文件名就能标识出修订版本,不必为每一个决定都建一层文件夹。
用检索测试代替点击次数
请一位同事去找:一份参考素材、一份可编辑文件、一条批准记录、一份已交付的输出,以及一个已归档的修订版本。观察他们在哪里犹豫,并记下他们找到的是不是正确的那一个,而不仅仅是看起来差不多的那个。
- 反复回头,说明类别名称有重叠。
- 把每个同级文件夹都打开看一遍,说明分组方式和检索任务不匹配。
- 找到的是过时的修订版,说明版本或交付记录需要整理。
多余的层级还会让共享交接变得复杂,也让检查备份范围更困难。只在内容确有需要的地方加子文件夹,别为了让目录树看起来整整齐齐的对称就到处乱加。
在不破坏任何东西的前提下加上颜色和图标层
一个彩色的活页夹侧脊,能帮你一眼认出这个活页夹,但里面装什么,还得看标签。文件夹的样式设计也该如此:它是一个一眼可辨的提示,而不是权威的记录。
用实体文件夹来类比,这个区别一目了然。
用一个色系表示生命周期阶段,用一个图标表示内容角色。这两个维度可以并存:一个进行中的视频文件夹,可以用代表“进行中”的颜色加上一个电影图标。
| 含义 | 颜色或图标 | 典型文件夹 |
|---|---|---|
| 进行中的工作 | 一个色系,比如蓝色 | 03_Working、04_Analysis |
| 交付物 | 一个色系,比如绿色 | 04_Deliverables、05_Outputs |
| 归档 | 中性灰色 | 99_Archive |
| 视频素材 | 电影图标 | 视频源文件夹 |
| 设计素材 | 画笔图标 | 02_References、03_Source |
| 代码 | 代码图标 | src、tests |
| 文档 | 页面图标 | 01_Admin、01_Contract |
使用少量、可重复的视觉语汇
别给每个项目都定一套完全不同的视觉语言。把有意义的差异,留给你在访达里快速扫视时确实需要区分的内容。
苹果关于扩展属性的文档指出,文件系统中的项目可以携带相关联的元数据。把文件夹的外观呈现也看作这类辅助信息,它和项目内容、目录位置是分开的。
在 Tintd 里,我们的“文件夹监视器”(Folder Watcher)会检测你所选位置中的新文件夹,并根据名称自动套用匹配的颜色和图标。我们的批量编辑器可以给选中的多个文件夹统一应用图标,而访达的右键菜单则负责单个更改;任何自定义过的文件夹,一键就能恢复为 macOS 原来的图标。
更改文件夹的图标或颜色纯粹是外观上的。它不会影响里面的文件和子文件夹,也不会改变它们的路径。
下面的演示视频可以帮你了解如何应用这层视觉效果。
为其他 Mac 和其他工具做好准备
自定义文件夹图标保存在每台 Mac 本地,所以团队用到的每台 Mac 都要分别设置图标自定义。把这套对应关系写成文字说明发下去,别想当然地认为每个人看到的外观都一样。
关于这种做法的更全面的讲解,可以看我们的可视化文件管理器指南。有一个有用的区分:更快的辨认,不等于可靠的理解。一个熟悉的图标能帮你认出某个目录,但新来的人仍然需要它的名称和有文档记录的用途。
如果用丢失元数据的工具来复制、同步或归档,样式就可能丢失。在依赖外观之前,先测试你实际的交接方式,并把 README 当作这些视觉约定含义的记录。
每季度做一次归档复查,让结构持续有效
项目文件夹结构是一个活的系统。新的协作者、修订过的交付物,以及意料之外的源素材,都可能让一个原本合理的初始安排变得不再好用。
亚利桑那大学的数据整理指南支持把原始文件和工作文件分开,并把整理方式记录成文档。请把这当成一项持续的责任,而不是做完就再也不回头看的设置任务。
把下面这个生命周期当作复查的节奏。
职责变化时,移动项目
- 从收件到进行中的工作: 一旦确认了收到素材的用途和负责人,就把它移到合适的类别里。
- 从进行中的工作到审阅: 阶段结束、有协作者加入,或者大家反复放错位置时,复查一下这套安排。
- 从审阅到交付: 冻结已批准的输出,并保留你交接出去的那份确切副本。
- 从交付到归档: 等负责人确认所有进行中的事项都已完成,再归档。
- 从归档到删除: 只有在相应的保留要求到期、且责任人批准处置之后,才能删除。
归档不等于备份,这两种操作也都不构成删除的许可。请把这些决定分开处理。
在 README 里指定一位整理负责人,写真实的人名,而不是一个含糊的团队称呼。这个人负责批准重新整理,并记录改了什么,这样协作者就不会各自去重新设计共享的路径。
进行季度检查
把当前的顶层结构和模板对照一下,然后检查那些例外情况。
- 解决偏离: 在核对过链接、脚本和协作者的依赖之后,重命名那些含义不清的新增项。
- 清除空的结构: 检查内容后,删除不必要的空文件夹,合并有重叠的类别。
- 让完成的工作退场: 把整个项目移到上一级的
99_Archive或归档卷宗里。 - 保留上下文: 留一份带日期的 README,写明项目的状态、负责人、交付位置和保留说明。
不要把项目移到它自己的归档子文件夹里。生产期间,用项目内部的归档存放被取代的材料;已完成的项目,则放进上一级的归档。
如果你习惯用可视化的方式做规划,可以看看 Walling 的可视化笔记洞见,作为捕捉决策的补充方式。再把得出的决定带回项目记录中。
**一致并不意味着每处深度都相同。**保留有用的例外,去掉不再有帮助的类别。今天就为季度复查设一个重复提醒,为当前项目安排一次完工后的检查,并在本周内存好一份干净的模板,留给下一个项目用。
Tintd 能在你定义好的结构之上,加上自定义的文件夹颜色和图标,既有针对现有文件夹的批量控制,也能给新建的文件夹自动设置样式。前往 Tintd,为你的进行中工作、交付物和归档,配上统一的视觉提示,而不用动里面的任何文件。