团队成员与部门管理

团队版与个人版最大的区别在于：团队共享的是环境，而不是账号。每位成员使用自己的登录身份进入同一个团队，环境、代理与操作记录都归属于团队，任何一个人的离场都不会让业务停摆。本文按「设置角色 → 邀请成员 → 划分部门 → 分配环境 → 交接与审计」的顺序说明完整的协作流程。

如果团队刚刚建立，建议先用一到两个测试环境跑通下面的流程，确认权限边界符合实际分工，再批量导入正式环境。权限一旦铺开再回收，成本会明显高于事前设计。

两种工作模式与团队主机架构

客户端首次启动时可以选择「本机使用」或「连接主机」，这两种模式决定了环境运行在哪里：

• 本机使用：在本机创建与运行环境，适合个人用户与单机场景；
• 连接主机：作为客户端接入局域网内的团队主机，首次启动时选择该模式并填写主机地址，即可共用主机上的环境、代理与账号资产。

团队主机架构

• 主机模式：由一台性能较好的电脑运行环境与数据，在系统设置中开启共享，局域网内的成员即可连接使用；
• 客户端模式：团队成员在自己电脑安装同款客户端，通过「连接主机」接入，负责操作与查看。

环境始终运行在主机上，客户端只负责操作与查看，硬件资源不重复投入，一套环境池服务整个团队。这也是团队共享环境而不是共享账号的基础：成员各自使用自己的登录身份接入，环境、代理与操作记录归属团队。

连接自检与一键放行

客户端连不上主机时，可以在主机端「团队协作」页运行「连接自检」：逐项检查接入开关、服务状态、Windows 防火墙放行与可达性，并给出对应的处理建议。若提示防火墙未放行，点击「一键放行」并按向导授权，即可自动添加放行规则，无需手动配置。

共享环境与权限、部门、审计的关系

因为共享的是环境而不是账号，环境归属、部门边界与审计记录需要一起设计：环境分配到部门后，成员才能看到并操作；成员的关键操作写入审计日志，可按成员、类型与时间筛选并导出归档。人员变动时回收的是环境授权，而不是交接登录账号，这也是团队环境能够长期稳定交接的原因。

角色与权限矩阵

团队内目前分为所有者、管理员与成员三种角色。角色决定的是「能对团队做什么」，环境权限决定的是「能看到哪些环境」，两者叠加才是成员的最终能力。把角色控制在少数几个人身上，团队规模变大后仍能保持清晰的追责链条。

管理员与所有者的差别集中在账单和成员管理两项，日常协作中两者几乎一致，因此管理员应当按部门设置，而不是给每位资深成员都开放。成员角色默认只能接触被授权的环境，无法修改团队设置，也无法创建或删除环境。

邀请成员

成员由所有者邀请，不使用共享账号登录。流程如下：

1. 所有者进入团队控制台的成员管理页面；
2. 选择邀请成员，填写对方用于登录的邮箱；
3. 为该成员选择初始角色，不确定时一律先给成员角色；
4. 对方接受邀请并登录客户端，即加入团队；
5. 在成员列表中确认角色、所属部门与席位数量是否正确。

邀请发出后长时间未被接受，可以重新发送；已经加入团队的成员不需要重复邀请，直接调整角色或部门即可。席位数量受套餐限制，邀请前先确认还有空余席位。

设计部门结构

部门是环境可见范围的边界。成员加入部门后才能看到部门下的环境，看不到其他部门的任何环境。合理的划分方式是按业务线或平台，而不是按人：按人划分会让部门数量随人员流动不断膨胀，按业务线划分则相对稳定，人员更替只需要换成员。

• 一个成员可以同时属于多个部门，跨部门协作不需要复制环境；
• 一个环境只能归属一个部门，避免两份权限互相覆盖；
• 部门调整后，成员的环境列表按新范围刷新，无需重新登录；
• 保留一个公共测试部门，把试验性质的环境集中放置，避免污染正式业务；
• 部门名称建议与内部称呼一致，减少沟通时的指代混乱。

分配环境权限

环境创建后默认只有团队管理者可见，需要显式分配到部门或授权给成员。操作顺序：

1. 在环境列表中按部门或标签筛选出目标环境；
2. 勾选环境后选择分配到部门，或直接授权给指定成员；
3. 为授权选择档位：只读或可操作；
4. 通知对方刷新环境列表，确认能看到目标环境；
5. 如该环境使用了保险箱凭据，确认成员具备引用权限。

授权遵循最小够用原则：临时协作先给只读，确认需要长期操作后再升级。授权变更即时生效，不需要成员重新登录，也不需要重启客户端。

敏感环境的授权原则

涉及支付、广告账户、店铺后台的环境，一旦被错误操作，损失往往不可逆。这类环境建议单独建部门或单独分组，不要与日常环境混在一起，并遵守以下原则：

• 按岗授权：只授权给岗位职责确实需要的人，不因操作方便而扩大范围；
• 控制人数：同一敏感环境的可操作成员尽量控制在少数固定人员；
• 只读优先：只需核对数据时给只读，不要为了看一眼就给可操作；
• 先回收再转交：人员变动时先收回原成员权限，再授予接手人；
• 保留痕迹：敏感环境的启动与配置变更都应能在审计日志中查到；
• 凭据分离：代理与登录凭据放入保险箱，成员按权限引用，不在群聊中传递。

成员交接

成员离职或转岗时，按下面的顺序处理，可以避免出现「权限还在、人已离开」的空档，也能防止接手人面对一堆无法解释的登录态：

1. 在成员管理中暂停该成员的登录，阻止其继续进入团队；
2. 回收其名下的环境授权，确认其环境列表已清空；
3. 把环境重新分配给接手人，必要时先给只读核对；
4. 如该成员掌握代理凭据，在保险箱中更新对应条目；
5. 在审计日志中确认交接期间没有异常操作；
6. 确认无误后再调整或移除该成员的角色。

不建议直接删除成员账号。删除会连同该成员的历史操作记录一起失去关联，后续排查「某天环境配置为什么变了」时就失去了依据。停用账号既能阻止登录，也保留了完整的审计链路，这是交接时的默认做法。

审计日志与保险箱

审计日志记录团队内的关键操作，包括环境的新建与删除、指纹与代理配置变更、成员与权限调整、保险箱凭据的更新等。它不替代业务侧的账号管理，但能在出现异常时回答两个关键问题：谁、在什么时候、改了什么。

保险箱用于集中存放代理凭据等敏感信息。凭据保存在保险箱后，成员在使用环境时按权限引用，界面上不展示明文。这样做的好处是：凭据更换只需修改一处，不必逐个环境调整；成员离开后无需批量改密；团队成员也不会在聊天工具里传密码。日志的具体字段与保留时长以客户端内展示为准。

常见问题

成员看不到某个环境

按顺序检查三件事：环境是否已归属部门、该成员是否在对应部门内、授权档位是否生效。三者缺一，环境都不会出现在成员的列表中。跨部门协作时，把成员加入部门通常比逐个环境单独授权更易维护。

成员无法创建环境

创建环境属于管理员及以上角色的能力。若成员确实需要创建，先确认是否应该调整角色；如果只是需要更多环境，由管理员统一创建后再分配更稳妥，可避免环境数量无序增长。同时留意套餐并发上限，以及免费版 10 个环境的配额。

交接后接手人登录态异常

让接手人从团队环境列表直接启动环境，不要复制环境目录到其他电脑，也不要让两人同时启动同一环境。若仍异常，检查该环境是否仍绑定原成员的代理凭据。

审计日志里出现了不认识的成员

先在成员管理中核对该账号的角色与所属部门，确认是否为已停用但未移除的旧成员。发现异常操作时，立即暂停该账号登录并回收其环境授权，再核对相关环境的配置变更记录。

相关文档

了解环境的组织方式与批量操作，请阅读环境管理；需要多人同时操作多个窗口，请阅读多窗口同步管理；代理凭据与预检流程见代理配置与预检；团队版能力与配额范围可参考定价页。