团队共享的是环境，不是账号：权限、部门与审计的落地方式

团队版与个人版最大的区别在于：团队共享的是环境，而不是账号。每位成员使用自己的登录身份进入同一个团队，环境、代理与操作记录都归属于团队，任何一个人的离场都不会让业务停摆。

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

环境运行在哪里

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

• 本机使用：在本机创建与运行环境，适合个人与单机场景；
• 连接主机：作为客户端接入局域网内的团队主机，共用主机上的环境、代理与账号资产。

主机模式由一台性能较好的电脑运行环境与数据，局域网内的成员通过客户端接入，只负责操作与查看。硬件资源不重复投入，一套环境池服务整个团队，这也是团队共享环境而不是共享账号的基础。

客户端连不上主机时，可以在主机端「团队协作」页运行连接自检，逐项检查接入开关、服务状态、防火墙放行与可达性；提示防火墙未放行时，一键放行即可自动添加规则。

三种角色决定「能做什么」

团队内分为所有者、管理员与成员三种角色。角色决定「能对团队做什么」，环境权限决定「能看到哪些环境」，两者叠加才是成员的最终能力。

• 所有者：账单与套餐、成员管理、创建与删除环境、分配环境与部门、代理配置与保险箱、审计日志、团队设置均可操作；
• 管理员：可创建与删除环境、分配环境与部门、配置代理与保险箱、查看审计日志；不能管理成员与账单；
• 成员：默认只能接触被授权的环境，可按授权引用保险箱凭据，不能创建或删除环境、不能修改团队设置、不能查看审计日志。

管理员与所有者的差别集中在账单和成员管理两项，因此管理员应当按部门设置，而不是给每位资深成员都开放。

邀请成员，不要共享账号

成员由所有者邀请，填写对方用于登录的邮箱并选择初始角色，不确定时一律先给成员角色。对方接受邀请并登录客户端即加入团队。

不要通过截图、聊天工具或共享文档传递账号密码。共用账号会让审计日志里的操作者全部变成同一个人，环境配置被改动时无法判断是谁操作的，也无法在交接时准确回收权限。

部门是环境可见范围的边界

成员加入部门后才能看到部门下的环境，看不到其他部门的任何环境。合理的划分方式是按业务线或平台，而不是按人：按人划分会让部门数量随人员流动不断膨胀。

• 一个成员可以同时属于多个部门，跨部门协作不需要复制环境；
• 一个环境只能归属一个部门，避免两份权限互相覆盖；
• 部门调整后，成员的环境列表按新范围刷新，无需重新登录；
• 保留一个公共测试部门，把试验性质的环境集中放置。

环境创建后默认只有团队管理者可见，需要显式分配到部门或授权给成员。授权分只读与可操作两档：只读用于巡检与跨部门核对，可操作用于一线运营。授权遵循最小够用原则，变更即时生效，不需要成员重新登录。

敏感环境单独管理

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

• 按岗授权：只授权给岗位职责确实需要的人；
• 控制人数：同一敏感环境的可操作成员尽量控制在少数固定人员；
• 只读优先：只需核对数据时不要给可操作；
• 先回收再转交：人员变动时先收回原成员权限，再授予接手人。

审计日志：还原「谁在什么时候做了什么」

审计日志把环境启停、代理与模板变更、定时任务、备份恢复等关键动作按时间线记录下来，配合筛选、搜索与导出，用来复盘异常、交接工作与应对审计。日志保存在本机，不上传云端。

一条记录包含时间、类型、对象、操作者与结果。改名后旧记录保留旧名，搜索时两个名字都要试；排查时先看失败记录，再看同一时段的成功记录。

定位一条记录通常按三步收窄：先选操作大类，把范围从几千条缩到几十条；再选时间范围，围绕异常时点前后各留余量；最后用环境名或成员名搜索。

把人走茶凉变成可交接

人员流动时，回收的是环境授权，而不是交接登录账号。环境、代理与操作记录始终归属于团队，新成员加入部门、获得授权就能接手，旧成员离开后权限即时失效，审计日志仍然保留完整的过程记录。这才是团队环境能够长期稳定交接的原因。