MasterGo

MasterGo是在线 UI 设计、原型和产设研协作平台。团队真正需要验证的不是“能否画出页面”，而是组件变更能否受控地传到业务文件，研发能否拿到准确标注与资源，外部协作者是否只看到必要文件，以及既有 Sketch/Figma 资产迁入或导出后会损失什么。

从设计稿进入研发要有明确交付状态

设计师完成页面后，应把准备交付的区域或图层标记为可开发状态，再由研发人员切换到研发模式查看。官方帮助说明，研发模式可查看评论与标注、盒子模型和样式属性，复制 CSS、iOS 或 Android 代码，并导出 PNG、JPG、PDF、WebP、SVG 等资源。快捷入口可以减少反复截图，但自动生成代码仍是实现参考，不等于项目组件已经满足响应式、状态管理和无障碍要求。

一轮可验收的交付应回答四个问题：这是哪个需求和版本；组件处于默认、悬停、禁用还是错误状态；资源采用什么倍率与格式；实现结果在哪里回看。若只把文件链接发给研发，设计更新后缺少变更说明，很容易出现“标注是新的、实现仍按旧稿”的错位。

团队库发布之前先确定谁负责变更

团队库用于跨文件共享样式和组件。MasterGo 官方文档明确指出，只有团队项目中的文件可以发布为团队库，个人草稿箱文件需要先移动到团队项目。组件或样式更新后，使用方可以查看并接收团队库更新；企业版还可控制发布范围及发布、取消发布和接收更新的权限。

1. 把基础样式、通用组件和业务组件分层，指定文件所有者与维护人。
2. 为组件写清名称、属性、状态、使用限制和弃用计划，再发布团队库。
3. 在真实业务文件中订阅并验证实例，避免只在组件展示页测试。
4. 发布更新时附变更说明；破坏性修改先建立替代组件和迁移窗口。

团队库的收益来自稳定引用关系，而不是组件数量。无人负责的全局组件一旦被随意修改，影响范围会比复制粘贴的局部图层更大。

席位、团队角色和文件权限不是同一层

官方团队资源说明强调，席位与文件编辑权限相互独立；成员有编辑席位但文件只有查看权限时，仍需申请编辑。外部协作者通常只获得被指定文件的权限。客户评审、外包协作和离职交接应分别检查文件所有权、公开链接、外部成员与团队库发布权限，不能只从成员列表删除账号就结束。

迁移测试要用复杂样本，不用空白页面

团队文件迁移支持批量导入 Sketch/Figma 文件并保留文件间关联，团队库文件与业务设计稿需要先分类。导入后，团队库还要重新发布并在业务文件中启用；含组件实例、变量、字体、蒙版和复杂原型的文件更适合用作验证样本。

MasterGo 也支持将整个文件导出为 Sketch，但官方说明给出了两种取舍：默认方式保留组件实例引用，却可能丢失颜色、文字等实例覆盖；“保留实例覆盖”会把相关实例转成组，视觉还原更高，但会失去组件关联。Sketch 不支持的 MasterGo 属性也可能无法还原。因此导出适合作为交换或阶段备份之一，不应未经恢复测试就当作完整可逆迁移。

• 迁移前统计团队、项目、文件、团队库、字体和外部协作者。
• 迁移后逐项比较组件引用、文本样式、约束、蒙版、原型连接与切图。
• 保留源文件和迁移日志，抽样让设计与研发共同验收。
• 企业采用前再核对数据存储、SSO、审计、备份恢复与私有化条件。

当团队库更新可追踪、研发交付能回到明确版本、权限按文件收紧，而且迁移样本通过还原测试时，MasterGo 才真正改善产设研协作，而不只是把设计文件换到另一个浏览器标签页。