Macro 的文件夹和标签到底该怎么分工：一个是文档的字段，一个是跨类型的属性

2026-08-17

在 Macro（macro.com）里待上一段时间，几乎所有人都会撞上同一个问题：文件夹和标签看起来都能”把东西归到一起”，那到底该用哪个？于是常见的结局是两套都建了一半——文件夹里塞了一堆 PDF，标签也打了十几个，过了两周谁也想不起来当初的分界线在哪。

这个纠结其实不是使用习惯问题，是没看清两者在数据模型上根本不是同一层东西。官方文档里有一句很容易被跳过的话：Documents 这个 block 的内置系统属性包括 Owner、Folder、创建与更新时间戳，以及可指派的关联任务和紧急程度。也就是说，Folder 本身就是文档的一个属性字段。而标签那一页开门见山：a tag is a property——标签也是一种属性，只不过它不绑定在某一类 block 上。

搞清楚这一点，后面的取舍就都有依据了：文件夹是”文档这类实体身上的一个字段”，标签是”整个工作区共用的一个属性命名空间”。两者不是竞争关系，是不同粒度。

文件夹管的是文件本体，而且自带共享语义

文档写得很清楚，文件夹组织的是工作区里的文档和文件：markdown 文档、PDF、图片、视频、代码文件和 canvas。它的边界就是这些”有文件实体”的东西——你没法把一封邮件线程或者一次通话录音塞进文件夹。

两个和机制相关的细节值得记：

第一，文件是会自动流进来的。频道里分享的附件会被导入文件存储，邮件附件会被自动抽取。这意味着文件夹不是一个你从零手工搭建的目录树，它更像一个”承接自动落地物”的容器——你不主动管，东西照样会进来。文档同时说明，文件夹里的所有内容在统一搜索里保持完全可搜索，所以放进文件夹不等于沉底。

第二，文件夹沿用和其它 block 一样的共享模型：owner、editor、commenter、viewer 四种角色；并且有未读通知的文件夹会出现在 inbox 里。这条是文件夹相对标签最实质的差异——文件夹是一个带权限主体的容器，标签那一页通篇没有给标签配这套角色。关于四种角色具体怎么落到协作场景，可以看权限模型那篇。

操作层面文档只给了两个快捷键：c + f 新建文件夹；在列表里选中某一项后按 m 把它移动到文件夹。

标签跨越所有 block 类型，共用一个命名空间

标签的逻辑完全相反。因为属性系统是全工作区共享的，所以标签只有一个命名空间，横跨所有 block 类型。文档举的例子很直白：给一封邮件打 marketing，再给一个任务打 marketing，这就是同一个 marketing——同一个颜色、同一个过滤器，一次点击就能看到所有带它的东西。

按文档列举，可以打标签的对象包括：

文档——PDF、其它文件，以及 snippets
任务——把一个任务和相关工作归到一组
邮件——给整条线程打标签
AI 会话——给一段与 agent 的对话打标签
通话——给录音或转写打标签

一个条目可以带任意多个标签，所以同一封邮件或任务可以同时挂在 marketing 和 q3-launch 下面。这一条和文件夹形成鲜明对照：文件夹是文档的一个字段，标签是可以叠加的多值归类。

创建方式上，文档里在正文中输入 # 会打开标签菜单，选已有的或新建一个；其它地方则通过属性窗口里的标签面板来选择或新建。多选/取消多选时按住 Shift 点击。

一张表把差别摆平

维度	文件夹（Folder）	标签（Tag）
在数据模型里的身份	Documents 的内置系统属性之一	一种 property，全工作区共享命名空间
适用对象	markdown 文档、PDF、图片、视频、代码文件、canvas	文档/文件与 snippets、任务、邮件线程、AI 会话、通话录音与转写
一个条目能挂几个	文档属性里的 Folder 字段	想挂多少挂多少，可叠加
权限	沿用 block 共享模型：owner / editor / commenter / viewer	文档只说明标签有个人与团队两种范围
通知	有未读通知的文件夹进 inbox	文档未说明
范围控制	靠共享角色	创建时选 Personal（仅自己可见）或 Team（需要属于某个团队）
检索	内容在统一搜索里保持可搜索	Filter → Tags，或搜索里的 Tags 筛选片跨全工作区

标签不用来记状态，这是最容易踩的坑

文档里有一句是明确的规定性表述：标签是用来按项目、团队或领域组织工作的，比如 marketing、hiring、q3-launch；它们不是用来跟踪状态的。状态、优先级、负责人这些是描述单个条目的属性，而标签是把相关条目横向串起来的属性。

这个区分对应到系统里是有落点的。任务的内置属性本来就有 Status、Priority、Assignees、Due Date、父任务/子任务、Depends On、Effort、Story Points 和 Relevant Documents；CRM 的公司实体有 Stage（Lead、Qualified、Demo、Trial、Negotiation、Customer、Churned）、Owner、Revenue，还有一个会随同步邮件自动更新的 Last Interaction 时间戳。这些状态字段已经有人管了，你再造一套 进行中 / 已完成 的标签，等于在同一个命名空间里放两套互相打架的真值。

属性系统本身支持的类型是固定的一组：

STRING          文本，如电话、职位、部门、备注
NUMBER          营收、员工数、ARR
BOOLEAN         开关
DATE            最后联系时间、合同/续约日期
SELECT_STRING   字符串选项的单选/多选，选项可自定义颜色与图标
SELECT_NUMBER   数字选项的单选/多选
ENTITY          指向另一个实体（User、Company、Contact、Document、
                Project、Channel、Chat、Task、Thread）
LINK            URL，如官网、LinkedIn

要表达”这份文档属于哪个项目”，用 SELECT_STRING 或者 ENTITY 引用往往比生造标签更贴。属性还能被标为 metadata 把它挡在主视图之外，也能 pin 到右侧卡片或统一列表里——细节可以看属性机制那篇，这里不展开。

过滤路径不同：Any 与 All

标签的检索规则文档写得比较细。在任意 block 里走 Filter → Tags 只显示带某个标签的条目；要一次性跨整个工作区过滤，用搜索筛选菜单里的同一个 Tags 片。选中两个及以上标签时会出现匹配模式开关：

Any——带任一所选标签的条目（默认）
All——同时带全部所选标签的条目，比如既是 marketing 又是 q3-launch 的东西

这个 Any/All 决定了标签体系该怎么设计。既然 All 模式存在，就不需要造 marketing-q3launch 这种复合标签——拆成两个正交的维度，靠 All 组合出来即可。文件夹这边没有对应的交叉检索机制，它的定位是”东西放在哪儿”，而不是”东西同时满足哪几个条件”。

命名和治理：12 色调色板是个硬约束

标签的颜色来自一个固定调色板，一共 12 种：Red、Tomato、Orange、Amber、Yellow、Green、Teal、Blue、Indigo、Purple、Pink、Gray。这个数字本身就是一条设计提示——颜色不够分配就说明标签开太多了，靠颜色区分的辨识度会迅速失效。标签总数控制在什么量级文档没说，但调色板的容量摆在这儿。

治理上有三条必须记住的规则：

创建时选范围，Personal 只有自己看得到，谁都能建；Team 是团队共享，创建团队标签的前提是你属于某个团队。
重命名或改颜色不改变标签的身份，改动会流到所有已经带它的条目上。所以命名不必一次到位，后面可以改。
删除标签是破坏性的，它会从所有东西上一次性移除，且不可撤销。这一条和改名的宽容度正好相反。

集中管理入口是 Settings → Tags，个人和团队标签分列，带编辑与删除操作和一个新建标签按钮——不用去翻某个用到它的条目。

还有一个容易混淆的地方文档专门做了说明：Macro 的标签不是邮件标签。Gmail 的标签（Inbox、Starred、Important 以及你自己建的）照常同步，并且驱动归档、加星这类收件箱动作；Macro 标签是叠在上面的另一层跨工作区结构，一条邮件线程可以同时带两者。想再往下看 block 之间是怎么统一的，可以读数据模型那篇。

交给 agent 来打

两套归类都能让 agent 代劳，但走的接口不一样。标签这边，文档说的是对接了 MCP server 的 AI 客户端（Claude Code、Cursor）可以直接被指使”给这条线程打上 marketing”或者”建一个 q3-launch 标签并加到这些任务上”。属性这边给出的是具体工具名：

GetEntityProperties   读取实体属性
SetEntityProperty     更新（状态、负责人、日期、自定义字段）
ListEntities          浏览实体

既然标签本身就是属性，把打标签这件事纳进属性工具的心智模型是顺的。需要注意的是，文档在文件夹那一节没有给出对应的 agent 操作说明——移动文件到文件夹这件事，文档提供的是快捷键 m，agent 侧怎么做官方文档未说明。

什么时候这套分工不成立，以及还没解决的

先说不适用的情况。如果你的团队 90% 的内容是文件（合同、素材、交付物），标签能带来的横向串联价值不大，老老实实用文件夹加统一搜索就够了；反过来，如果工作重心在任务、邮件和 AI 会话上，文件夹基本用不上，因为它压根装不下这些类型。真正需要两套并用的，是”文件与流程各占一半”的团队——文件夹解决存放和权限，标签解决跨类型串联。

再说文档没有覆盖、这篇也不打算替它猜的部分：

文件夹是否支持嵌套、层级深度有没有限制，folders 那一页没有说明。
标签总量上限、单个条目标签数的实际上限（文档只说”想挂多少挂多少”），没有给数字。
团队标签的编辑权限归谁（是否任何团队成员都能改名/删除一个团队标签），文档未说明。而删除是不可撤销的，这个空白在多人协作时值得先在团队内部约定好。
文件夹与标签之间有没有联动（比如按文件夹自动打标签），文档里没有相关机制。

所以落地时一个比较稳的起手式是：文件夹只按”归属与可见范围”划，一层一层别搞太深；标签只按项目/团队/领域这三类正交维度开，坚决不碰状态；状态一律交给内置属性。等真正跑起来了，再用 Settings → Tags 定期清一遍没人用的标签——记住删除不可撤销，清之前先用 Tags 过滤看一眼还挂着多少东西。

延伸阅读

从头读起：Macro 是什么：邮件、任务、文档、CRM 共用一个双向数据库的开源工作区
本专题共 40 篇，完整分组目录见专题页
Macro 的片段（snippets）怎么用：分号唤起、团队共享，以及官方文档没写的那部分
Macro 的 GitHub 集成到底做了什么：分支、PR 合并与任务状态自动同步的边界在哪

本文依据 Macro 官方仓库（github.com/macro-inc/macro，AGPL-3.0 协议）的 apps/docs/ 产品文档、 MCP 工具参考与自托管说明整理，核对日 2026-08-17。 我们没有注册或运行过 Macro，因此不涉及界面外观与操作手感；官方标注为计划中的能力文中已如实标明，不代表当前可用。价格与额度以官网 macro.com 最新页面为准；许可证相关问题请咨询专业人士并以官方许可证原文为准。