ThinkLink 项目怎样交给运维：角色、组织与实际账号验收

从人员任务开始设计

值班人员可能只需查看状态和记录事件，维护人员需要调试设备，组织管理员负责用户与配置。先列出每类人员需要完成的动作、涉及对象和负责人，再选择角色权限，不要直接把所有人设为 admin。当前文档中 admin 拥有当前组织完整功能权限且不可删除，但这不意味着它适合所有日常人员。菜单访问、数据范围与具体操作能力需要分别确认，不能把一个菜单勾选框推导成所有接口的同等授权。本文给出交付方法，不宣称任何未经验证的按钮级限制已经内置实现。

组织成员与角色要同时成立

能登录平台和加入目标组织不是同一件事。通过正式用户管理创建或邀请用户，并核对其目标组织与角色。邀请流程还需要受邀者接受，发送邀请不能当作已经加入。新建用户时按当前表单填写名称、账号、初始密码和角色，不要沿用旧说明猜测账号格式或漏掉必填名称。部门归属用于组织管理，但不能单凭部门显示推断已经获得对应设备范围。使用独立测试账号验证时，不要借用管理员会话，也不要把共享管理员密码写进操作手册。

新菜单需要进入角色配置

如果项目增加了动态菜单，除了菜单本身启用并设置为显示，还要让自定义角色在权限树中获得对应入口。保存后让目标用户重新进入组织或刷新页面，确认入口出现并可以打开。检查页面的数据加载与实际对象，不要只验证侧栏多了一个名称。若入口可见但访问失败，分别检查菜单配置、角色分配、组织成员身份和后端响应。不要为了让演示通过就临时授予全部权限而不记录，这会使交付结果与原本的最小职责设计不一致。

按账号执行验收清单

为每种角色准备一份业务步骤，例如进入正确组织、查看指定设备、打开历史数据，以及执行明确获准的维护操作。需要验证限制时，使用无害读取或界面状态检查，不要通过实际危险动作测试拒绝。记录成功、拒绝、加载失败与尚未验证，不能把隐藏按钮等同于服务端权限已验证。若接口或数据范围有缺口，应先记录并解决，再决定是否交付该职责。验收结束后取消临时测试授权，确认正式账号仍能完成其应有任务，并保留使用者视角的证据。

1. 按职责列出必要业务动作。
2. 确认成员身份、角色和菜单配置。
3. 用实际交付账号完成业务步骤。
4. 撤销临时授权并交接维护责任。

把人员变化和长期凭据纳入交接

交付资料应列出角色用途、用户负责人、组织范围、日常操作入口和权限调整方式。人员调岗或退出时，按正式流程重新评估角色、成员身份及相关凭据；不要只改显示名称。个人 API Key 与系统 API Key 的创建入口和权限边界不同，应按当前官方文档选择，不在网页、截图或公开手册里保存密钥。组织所有权转移是独立管理操作，不是普通角色变更的替代。最终交付记录应注明实际验证的账号和范围，让后续接手人员能够重复完成同样的业务任务。