先定角色、再定目录、最后才去自建 Doory 实例，顺序反过来就会遇到同一个麻烦：模板被谁改乱了说不清，素材越堆越多，找一张历史图要翻半天。比较稳的做法是，先用两条线切人——对模板有没有写权限、对素材有没有删除权限；再用两个维度切目录——一级按项目、二级按用途。角色和目录定下来之后，Doory 里的账号组、目录挂载和可见范围只是把已经想清楚的东西落成配置。下面给出一份可以直接照抄再改的划分方式，具体字段名和角色名需要结合你部署的版本确认。

团队共用设计工具后出现的“模板被改乱、素材找不到”，通常不是工具能力问题，而是角色边界和目录结构没在部署前定好。建议先划改稿、审稿、只读三类角色，把模板原文件设为只读、改稿只动副本；素材按“项目/用途”两级目录建，用途决定谁能写。落地后用一次真实改稿走完提交、审稿、返工全流程，记录提交人、审稿人、返工原因三项，再据此微调权限。

先把参与设计的人分成改稿、审稿、只读三类

划分依据不是职位高低，而是两个可验证的动作：谁能让模板文件的内容发生变化，谁能删除素材文件。把这两条线写进账号组，后面所有争议都能回到配置上对账。

在自建实例的账号设置里落成时，建议建三个用户组（例如 design-editor、design-reviewer、design-viewer），把组映射到目录权限，而不是逐个账号授角色；人员变动时只改组归属。模板目录对改稿组只给读，写权限只留给审稿组；副本工作区对改稿组给读写；项目素材目录用 setgid 保持组继承，避免新人建的文件落到别人组下。

# 目录属组与继承（示例，路径按实际部署替换）
chgrp -R design-reviewer /mnt/design/templates
chmod -R 2755 /mnt/design/templates
chgrp -R design-editor /mnt/design/work
chmod -R 2775 /mnt/design/work
# 校验：用改稿账号试写模板目录，应被拒绝
sudo -u editor_test touch /mnt/design/templates/_probe.fig

校验方式就是上面最后一条：用对应角色的测试账号做一次写操作，被拒绝说明边界成立。如果实例内部还有独立的资源权限页，需要把同一套角色再映射一遍，两边保持一致，否则会出现文件系统挡住、应用内仍能改的情况。

按项目与用途建两级素材目录

一级用项目，是因为项目天然有起止：结项后整棵子树可以归档或清理，不会牵动别的项目。二级用用途，是因为用途决定谁写、写进去的东西要不要留：原图和导出图的责任人不同，参考图往往来源不明、版权待确认，混在一起后既难清理也难追责。

/mnt/design/
├── projects/
│   ├── brand-refresh/
│   │   ├── originals/     原图：相机原片、矢量源、设计源文件
│   │   ├── exports/       导出图：对外发出的成品
│   │   └── refs/          参考图：收集来的、非自制
│   └── campaign-spring/
│       ├── originals/
│       ├── exports/
│       └── refs/
├── templates/             模板原文件，只读
│   ├── poster_a4_src.fig
│   └── social_square_src.fig
└── work/                  改稿副本区
    └── poster_a4_zhangsan_20250612_wip.fig

命名上保持小写、无空格、用途词固定，避免同一个项目里出现“素材”“素材2”“新建文件夹”。找历史图时先定位项目、再定位用途，通常两三次点击就能收敛到目标目录，比全局搜索文件名更可靠。

模板文件与源文件分开放，改稿只动副本

模板原文件和改稿副本用后缀区分：原文件带 _src，副本带 _wip，定稿后可另存为带 _final 的版本，但仍然放在 work 目录里，不回写 templates。这样“哪份是标准”永远只有一个答案。

复制流程建议固定成三步：先读原文件确认版本，再复制到 work 并按“模板名_改稿人_日期_wip”命名，最后只在副本上编辑。原文件的更新由审稿角色统一做，改稿角色不需要写权限。

cp /mnt/design/templates/poster_a4_src.fig \
   /mnt/design/work/poster_a4_zhangsan_20250612_wip.fig
ls -l /mnt/design/work/poster_a4_zhangsan_20250612_wip.fig

验证方式很直接：查看 templates 目录下文件的修改时间和属主，正常状态下应只有审稿角色的账号动过；出现其他属主就说明有人绕过了副本区，需要回到权限配置检查。

用一次真实改稿走通审批路径并记录卡点

权限划得对不对，不能靠讨论，要拿一个真实需求跑一遍：从改稿人接单、复制副本、提交审稿，到审稿通过或退回，全程不动用管理员账号。这次试跑只记录三项内容，够用且好核对。

• 提交人：哪个账号提交了哪份副本文件（记录账号名与文件名）。
• 审稿人：实际做出通过或退回决定的账号，不能是同一个人。
• 返工原因：退回时写清属于哪一类，例如改错位置（动了非指定区域）、素材版本不对（引用了 refs 里的旧图）、命名不合规（缺项目或日期）。

跑完之后回看这三项：如果返工原因集中在命名，说明目录规则要写进模板说明；如果集中在素材版本，说明 originals 和 refs 的边界还需要在文件名上体现。同时用文件修改时间或实例日志核对一遍，确认模板原文件在整条流程里没有被改稿账号写过，这一步能直接说明角色划分是否成立。

定期清理废弃目录前先导出文件清单

清理动作的风险在于“看着像废弃”。建议每次删除前先把目录清单导出成文本，作为判断依据和事后追溯的凭据。

find /mnt/design/projects/campaign-spring -type f -ls \
  | sort -k11 > /tmp/campaign-spring-filelist.txt
wc -l /tmp/campaign-spring-filelist.txt

删除前的确认步骤可以按这个顺序走：先看清单里最近修改时间靠后的文件，确认是否仍有在用；再在 work 和 exports 目录里按文件名搜一遍引用；把待删目录整体移到隔离区（例如 mv 到 /mnt/design/_quarantine/），通知团队一段时间；隔离期内无人反馈再执行删除。整个过程先移不删，重复的目录名和相似的项目名最容易误判，隔离期就是留给这类误判的缓冲。若实例自带回收站，清空回收站同样属于删除，仍应先导出清单。