Figma文件怎么转到另一个团队？移动与复制

Figma 文件转到另一个团队，先确认你已加入两个团队并具有相应编辑权限，再在文件列表中右键文件，选择 Move file…，找到目标文件夹后移动。如果双方属于不同账号或组织，普通移动不适用，应由管理员办理文件夹转移，或在允许复制的情况下交付副本。移动原文件与复制新文件的结果不同，尤其要先确认是否需要保留评论和版本历史。

文件放在哪里，会影响谁能继续编辑、评审和调用组件。团队刚开始整理这些关系时，可以结合 Figma 文件与协作使用指南理解团队、文件夹和设计文件的层级，再处理下面这次具体移交。

先拿一个文件试移，不要直接搬走整个项目

假设“商城改版”由体验设计团队完成，现在交给零售业务团队持续维护。文件里有商品列表、详情、购物车和结算页面；按钮与输入框来自另一份“商城基础组件”，评审意见留在文件评论中。真正要交接的至少有三类对象：设计文件、它引用的组件库，以及参与者对这些对象的访问权限。

开始前由交接双方确认：业务团队需要接管原文件，还是只要一份可独立修改的设计？体验团队是否还要继续维护其他使用同一组件库的业务？这两句话不明确，直接移动可能把公共库一并带走；直接复制又可能让接收方失去讨论来龙去脉。

这里的交付基线是双方约定的工作范围，例如“结算流程已确认，优惠券弹窗待评审”，并不是要求额外导出一堆文件。原链接和待办集中放在同一份记录中，后面就能逐项验收，而不用凭记忆判断。

双方在同一协作范围内：按文件执行移动

先让接收方建立目标文件夹，并给实际操作人编辑权限。只拿到一个可查看的设计文件链接，并不意味着你能往目标文件夹放文件。跨团队移动还要求操作人加入两个团队，并具有双方所需的编辑权限；从草稿移入共享位置时，另需满足该文件类型对应的席位条件。

1. 进入文件列表，找到“商城改版”，检查缩略图、所在团队和最后修改内容，排除同名副本。
2. 右键该文件，选择 Move file…。
3. 在选择窗口中搜索目标文件夹，核对其所属团队，再点击 Move。
4. 从接收方的目标位置重新打开文件，并让一名接收方成员用自己的账号访问。

Figma 也支持从画布文件名旁的菜单执行 Move；批量移动则在文件列表多选后操作，但每个选中文件都必须满足权限条件。当前界面使用 folder（文件夹）组织文件，不能只照旧教程寻找 project（项目）入口。具体权限与入口可查 Figma 移动文件说明。

第一次只移动“商城改版”这一份设计，先不移动公共库。接收方能够编辑、评审者能够查看之后，再决定其余文件如何处理。若正在进行多人评审，提前约定操作时间，并让双方停止在同名副本上继续修改。

移动与复制，最容易混淆的是交付的究竟是哪份文件

移动改变文件的所在位置；复制则产生一份新的文件。若只是为另一条业务线保留一个起点，复制通常更符合“各自迭代”的目的；若要继续同一个项目，应先考虑保留原文件的移交方式，而不是给所有人重新发一个名字相同的副本。

Figma 的普通 Duplicate 副本不包含原文件的评论和版本历史。因此，不能把“已经复制成功”当成“评审过程已经完整交接”。只有查看权限时，副本通常进入自己的草稿；具有编辑权限时，副本可出现在原位置。若复制选项不可用，可能是文件内容复制或导出被限制，应联系有权限的人安排交付，不要尝试绕过限制。依据见 Figma 文件复制说明。

商城案例中，如果业务团队接下来还要处理“优惠券弹窗”的未决评论，直接复制会割断这段讨论。若只是拿商品卡片做另一套活动页，副本可以独立使用，但新文件名应明确业务归属，并给原文件保留可查的来源说明。

跨账号或组织：改走文件夹转移，不反复尝试 Move

外包公司向甲方交付、个人账号向企业组织移交，常常已经超出普通跨团队移动的范围。这时可以把要交付的文件整理到专用文件夹，由管理员发起 Transfer；接收方需使用能够接收文件夹的 Professional、Organization 或 Enterprise 方案，并由相应管理员处理请求。

办理时先由接收方提供目标团队地址，发送方在文件夹设置中发起转移，接收方检查资源范围和协作者保留选项后接受。不要把所有历史资料临时塞进交付文件夹：转移会以整个文件夹及其下级内容为单位处理，发送人未逐个打开的下级文件也可能在范围内。

文件夹转移与 Send a copy 仍有区别。转移可以携带评论和版本历史；发送副本则把这些记录留在原处。文件和原型链接可以延续，但文件夹和团队入口可能变化；随行资源还存在共享字体、私有插件等边界。应按 Figma 文件夹与团队转移说明选择操作，而不要把跨组织转移当作一次普通拖拽。

如果只交付少量文件，而且接收方不具备合适的接收条件，可在权限允许时用本地副本重新导入。这个方案应被明确记录为“交付副本”：不要许诺保留完整云端协作过程，也不要把本地导出当成改变原文件的所有权。

移完之后，按角色检查访问，再检查组件更新

先检查权限继承，再看设计内容。让业务设计师尝试修改测试文字，让产品经理打开原型并查看评论，让研发同事从日常入口进入文件。不要用管理员自己的账号做完全部验收：管理员能看到，不代表其他角色也能看到。

• 原团队同事打不开：检查他原先是通过团队或文件夹继承权限，还是直接获邀访问文件。位置变化后，不应假定原来的继承关系仍然成立。
• 不该看到的人能看到：检查目标团队、文件夹以及适用的组织或工作区访问范围，及时收窄；不要只看文件上直接邀请了谁。
• 找不到目标文件夹：先核对当前登录账号、团队成员身份和目标编辑权限，再判断是否跨组织。反复重新导出通常不能解决权限问题。
• 部分文件不能批量移动：把失败文件单独核查，避免为了批量完成而复制所有文件，制造两套正式稿。

接着检查“商城基础组件”。文件里按钮仍然显示正常，只能说明当前实例有可见内容，不能证明将来还能收到库更新。跨组织转移时，依赖库未一并转移的组件可能保留最后状态而不再接收更新；反过来，若把公共库转走，原团队其他文件也可能失去后续更新。因此先列出库的使用方，再决定随项目移交、继续由原团队维护，还是在目标空间建立经过批准的独立维护方案。

可以选一个不影响交付的测试组件，验证接收团队是否能找到来源、获得预期访问并处理更新。测试后还原该变更。不要为证明“组件可编辑”而把全部实例分离：那会消除后续维护所需要的关联。

交接完成后，留下可读的文件首页

把“谁维护、哪个版本、从哪里开始”写在设计文件首页，比在群里重复发一串链接更容易长期维护。商城改版首页可以保留四个区块：正式页面入口、组件来源、待办评论、接管负责人。标明“旧团队保留评审访问”或“交接完成后撤销临时访问”，让新成员能判断自己的工作边界。

如果团队后续转到 Pixso 协作，可以在实际设计画布上保留相同的交接首页，把商城关键页面、组件检查点和待办说明放在一起，再安排接收人逐项检查。画面里的交接说明是团队编写的项目内容，成员权限仍应在实际的共享设置中配置。跨产品导入是下一项任务，可继续查看 Figma 文件导入 Pixso 的操作方法，不要把这一步与 Figma 内部移动混在同一次验收里。

这次移交可以在三个结果都明确后关闭：目标团队接手了约定的文件，原参与人的访问符合安排，后续组件维护不会依赖一个无人负责的位置。到这里再更新项目文档中的入口，并处理临时访问与多余副本。