人走了，权限不能还留着：vibe 项目团队离职交接与权限回收实战

先划清边界：这篇讲“人走之后怎么收尾”

这篇指南讲的是 vibe 项目里一个经常被拖到出事才补的环节：团队成员离开之后，怎样把交接做完、把权限收干净。与 cycle135 刚发的团队邀请与入职指南方向正好相反：那篇讲“人来怎么接进来”，这篇讲“人走怎么送出去”，两篇互补，不重复。同样要划清的还有另外三篇已发内容：账号注销讲的是用户自己关掉自己的账号，RBAC 讲的是权限模型怎么设计，审计日志讲的是日志怎么记、怎么查；这篇不重复讲模型和日志格式，只讲内部协作者离场时那一串必须有人动手、按顺序做完的操作。

下面所有示例产品与人物均为虚构，只是为了把流程讲具体而编的例子，请不要对号入座到任何真实项目或真实人物。核心观点先说一句：离职交接最怕的不是“少做了一件”，而是“以为做完了，其实还剩一个能进系统的口子”。所以这篇不给你一张“看着很全”的清单就结束，而是给你一个顺序：先断外部访问，再收内部权限，最后做审计复核。顺序错了，清单再长也可能白做。

虚构示例：一个三人小团队的离场，哪里最容易漏

假设有一个虚构的三人 vibe 项目“灯塔记账”（纯属虚构）：负责人阿南（虚构人物）管产品和上线，协作者小北（虚构人物）管后端和部署，另一位协作者小西（虚构人物）管前端和设计稿。某天小北决定退出，理由很体面：时间不够，想专注自己的事。团队的第一反应往往是“把 GitHub 仓库权限撤掉就好了”，然后继续赶功能。两周后问题才冒出来：部署用的云服务器还能用小北的个人密钥登录，第三方邮件服务的 API 密钥还躺在小北本地的环境变量文件里，域名解析后台的管理员还是小北的个人邮箱，某个没合并的分支里还藏着一个只有小北知道的临时接口。

这个虚构例子想说明的不是“小北不可信”，恰恰相反：绝大多数权限残留都不是恶意造成的，而是“当时图方便”造成的。个人邮箱注册的服务、个人账号绑定的密钥、只存在某个人电脑里的配置文件、口头约定但没有写下来的联系人，这些东西在合作愉快的时候都看不见，等到人走了才变成风险。离职交接的目标也不是防着离开的人，而是把项目从“依赖某个人记得住”变成“不依赖任何一个人也转得动”。这个心态转变很重要：交接做得体面、彻底，对离开的人也是一种保护——以后出任何问题，都不会有人回头怀疑“是不是你还留着权限”。

第一步：离职清单，先按“人能从哪里进来”分类

清单不要按服务商名字想到哪写到哪，要按“入口”分类，这样才不容易漏。第一类是身份与账号：项目邮箱、协作工具账号、代码托管账号、设计工具账号、文档与知识库账号。第二类是密钥与凭证：API 密钥、云厂商访问密钥、数据库密码、部署密钥、CI 持续集成里的机密变量、第三方服务的 webhook 密钥。第三类是仓库与代码权限：主仓库、附属仓库、私有依赖包、部署脚本仓库、基础设施即代码仓库。第四类是第三方服务：邮件发送、短信、支付、统计分析、错误监控、域名与 DNS、SSL 证书、云存储桶、数据库托管。第五类是钱与账单：云账单管理员、支付平台管理员、订阅服务付款人、发票接收邮箱。

每一项后面都要写三样东西：现在是谁持有、要转给谁、转完之后怎么验证。只写“已处理”是不够的，必须写“验证方法”。比如域名管理权：转给谁、对方能不能登录后台改一条测试记录、改完能不能恢复，这才叫处理完。再比如 API 密钥：是直接作废重发，还是只把旧密钥从代码里删掉？只删代码不作废密钥，等于门锁换了钥匙孔、旧钥匙还能开另一扇门。密钥类一律按“作废旧的、发新的、验证旧的确实失效”三步走，缺一步都不算完。

还有一类最容易漏：离开的人“个人名义”办的东西。很多 vibe 小团队起步时图快，用某个人的个人邮箱注册域名、用某个人的个人云账号建第一台服务器、用某个人的手机号收验证码。这些东西名义上是项目资产，实际上挂在个人名下，离场时最难交接。处理原则是：能过户的过户，不能过户的迁移——把服务迁到团队共用邮箱、团队云账号下，再把旧的个人绑定解掉。如果某个服务实在迁不动，至少要把管理员换成在职成员，并把恢复邮箱、备用验证码、账单联系人全部换掉，留下书面记录。

第二步：交接包，离开的人要留下什么

交接包不是一份“工作总结”，而是一份“下一个人能接着干活的地图”。它至少包括五样东西。第一，在跑的任务：每个进行中任务的现状、下一步、卡在哪里、找谁能推进。第二，未合并分支：每个分支是干什么的、能不能直接合、合之前要补什么测试、哪些分支可以直接删。第三，未公开密钥的位置：不是把密钥明文写进文档，而是写清楚“哪些密钥存在、存在哪个密钥管理工具或哪个环境里、轮换流程是什么”，让接手的人知道去哪里找、怎么换，而不是拿到一串明文密码。第四，外部联系人：域名商客服、云厂商支持、合作方对接人、付费服务的账单联系人，以及历史上出过问题的供应商。第五，已知坑位：那些“只有当事人知道”的地方，比如某个定时任务为什么设在凌晨三点、某个接口为什么要多等两秒、某个配置为什么不能改默认值。

交接包的交付方式也有讲究。最好安排一次面对面的交接会（线上也可以），由离开的人带着接手的人过一遍：打开部署后台、跑一次发布流程、看一次监控面板、模拟一次回滚。只发文档不演示，等于只给了地图没带路；演示一遍，很多文档里没写的东西会在操作时自然冒出来。交接会之后，接手的人要在 48 小时内独立做一次关键操作——比如独立发布一次小改动、独立轮换一个测试密钥——能独立做完，交接才算真正落地。

时间安排上，不要把交接压缩到最后一天。理想节奏是：离职确定后先列清单，中间留至少一周做交接和权限迁移，最后一天只做复核和确认。如果离开的人是突然走的、没有缓冲期，那就反过来：先做权限回收（见下一步），再慢慢补交接包。顺序不能反——人已经走了，你再慢慢写文档的时候，权限口子还开着。

第三步：权限回收的顺序，为什么先断外部、再收内部

这是整篇最关键的一段。推荐顺序是：先断外部访问，再收内部权限，最后处理账单与所有权。理由很简单：外部访问是风险最大的口子，也是最难事后追溯的口子。所谓外部访问，包括部署服务器的 SSH 密钥、云控制台的外部登录、暴露在公网的管理后台、第三方服务的公开 API 密钥、以及任何不需要内网或 VPN 就能直接访问的入口。这些入口一旦被滥用，影响是公开的、即时的，而且离开团队的人即使没有恶意，也可能因为个人设备丢失、账号被盗而被连带利用。

先断外部的具体做法是：作废并轮换所有面向公网的密钥，吊销个人 SSH 密钥和个人访问令牌，关闭或转移公网管理后台的个人账号，把面向外部的 webhook 密钥全部换掉。这一步要快，理想情况下在离职当天就完成，不要等交接包写完。很多人会觉得“先断外部显得不信任人”，但换个角度想：先断外部恰恰是对双方都好的做法——它把“人走之后出问题会不会赖到你头上”的可能性提前清零了。

外部断干净之后，再收内部权限：代码仓库的写入权限、内部文档的编辑权限、协作工具的管理权限、CI 的部署权限、数据库的读写账号。内部权限回收可以配合交接节奏慢慢做，因为内部系统通常有日志、有审批、有内网隔离，风险相对可控。最后处理账单与所有权：云账单管理员、支付平台管理员、域名所有权、组织所有权。这些东西改动影响大、容易误操作，所以放在最后，等前面都稳了再动，而且每改一项都要验证一项。

还有一个顺序细节：轮换密钥时，先发新的、再废旧的，中间留一个短暂的重叠期。如果先废旧的、再发新的，正在跑的服务会立刻断掉，等于用一次线上事故来换安全。正确做法是：新密钥先部署到服务里、验证服务正常，再把旧密钥作废，最后验证旧密钥确实已经失效。这个“先立后破”的节奏，在数据库密码、API 密钥、部署密钥上都适用。

第四步：审计与复核，怎样证明“真的收干净了”

权限回收不能只靠“我觉得都处理了”，必须靠证据。审计至少查四样东西。第一，登录记录：过去 30 天里，离开的人的账号在哪些系统登录过、登录时间是不是都在离职之前、有没有离职之后的异常登录。第二，残留令牌扫描：用工具或人工方式扫一遍代码仓库、CI 变量、部署脚本、文档，找找有没有硬编码的密钥、过期的令牌、测试用的万能密码。特别注意那些“临时写一下、后来忘了删”的地方：测试脚本、示例配置文件、旧分支、聊天记录里贴过的密钥片段。

第三，权限清单复核：拿着第一步的清单逐项打勾，每一项都要有“处理人、处理时间、验证方法、验证结果”四个字段。没有验证结果的项，一律算未完成。第四，外部暴露面检查：公网端口、公开存储桶、公开管理后台、公开的 API 文档，确认没有哪个入口还挂着离开的人的个人凭证。这一项最好由接手的人、而不是离开的人来做，换一双眼睛更容易发现盲点。

审计结果要留一份书面记录，存在团队内部文档里，写明“某年某月某日，某人离场，清单共多少项、完成多少项、剩余风险是什么”。如果确实有某一项因为客观原因暂时处理不了（比如某个老服务商不支持过户），不要假装它不存在，要把残留风险写下来、写明缓解措施和计划处理时间。诚实记录残留风险，比假装清零要安全得多——因为假装清零会让所有人放松警惕，而写下来的风险至少会有人盯着。

小团队简化版：一人兼多角时，怎样不被流程压垮

上面这套流程听起来很完整，但对两三个人的 vibe 小团队来说，全套照搬会压垮人。所以这里给一个简化版，原则是“保住关键项、砍掉形式项”。简化版只保四件事：第一，作废并轮换所有密钥和令牌，这是底线，一件都不能省；第二，转移代码仓库、域名、云账单三个所有权，这三个丢了项目就没了；第三，留一份一页纸的交接备忘，写清在跑的任务、未合并分支、密钥位置、联系人，不用写成长篇文档；第四，做一次登录记录抽查，确认离职后没有异常登录。其他项可以先记下来、后面慢慢补，但这四件要在离职一周内做完。

一人兼多角的小团队还有一个特殊风险：离开的人可能同时是“唯一懂部署的人”和“唯一有云账单权限的人”。这种情况下，交接的第一优先级不是写文档，而是“把唯一性打破”：在人走之前，必须至少有两个人能独立完成部署、能登录云控制台、能处理账单。如果实在找不到第二个人，至少要把操作步骤录屏、把恢复流程写下来、把备用管理员账号准备好。一个人就是单点故障，人走了，单点故障就变成了项目停摆。

还有一个小团队常犯的错误：用“口头说好”代替“系统里改掉”。比如大家口头约定“你以后别登录了”，但账号权限还在、密钥还没轮换。这种约定在合作愉快时没问题，但在账号被盗、设备丢失、或者日后产生纠纷时，口头约定没有任何保护作用。规则很简单：权限状态以系统里看到的为准，不以口头约定为准。改了系统，才算改了权限。

常见翻车清单：这六种情况最容易复发

最后列六种最常见的复发情况，复核时可以逐项对照。第一，CI 里的机密变量忘了轮换：代码里的密钥换了，但持续集成配置里的旧密钥还在，部署时照样用旧的。第二，个人访问令牌没吊销：仓库权限撤了，但当事人之前生成的个人令牌还能用，等于后门还在。第三，共享账号没改密码：团队共用一个管理员账号，离职后密码没改，所有人都还知道。第四，第三方服务的子账号没清：主账号权限收了，但某个第三方服务里的子账号、API 密钥、webhook 还在。第五，本地配置文件没处理：离开的人电脑里还存着生产环境配置文件，虽然团队管不了别人的电脑，但至少要把那些文件里涉及的密钥全部轮换掉，让旧文件失效。第六，域名和 DNS 的恢复邮箱没换：域名管理权转了，但找回密码的邮箱还是离开的人的个人邮箱，等于留了一把备用钥匙。

收尾再说一句心态上的话。离职交接做得好，不是因为团队“防人”，而是因为团队“不依赖人”。一个健康的 vibe 项目，应该做到任何一个人离开，项目都能继续转；任何一个人回来帮忙，也能很快找回上下文。把交接和权限回收做成固定流程，而不是每次临时想起来才补，是小团队从“几个人凑在一起做东西”走向“一个能持续运转的项目”的标志。流程不用一开始就完美，先从这篇的简化版开始，做一次、复盘一次，下一次就会比这一次干净。