现实里更扎心的问题是：表还没贴热，新同学已经用三台机器、三套默认设置把组织又拆散了；等人走了才发现，密钥和多 MCP 连接器还挂在旧身份上。本文把人的进场、退场当成一次小型「安全 + 协同」项目——不抄产品手册，只给你能放进 Wiki 的决策顺序和一张检查表。工具名偶尔出现，主线仍是团队怎么少翻车。
「当代码生成不再是瓶颈，谁占着席位、连着哪条外网、默认可不可自动跑命令才是雷区。」
—— 依然是这句话的另一面：秩序要在人身上落地，否则表只是纸本。
人走了，智能体还在——两个常见开场
画面一： 新人到岗第一天，自己配了 MCP、读了生产只读库，智能体自动生成了一份「看起来很专业的」环境变量 patch。周五评审里混进几行没人说得清来源的配置——问就是「AI 顺手改的，本地过了」。
画面二： 核心开发离职两周后，行政账号早关了，可财务对账时才发现：团队 AI 工具里还有一个占席的默认角色、某台旧笔记本仍登录着组织；更要命的是，群公告里传过的 MCP 安装链接和 API Key，根本没进你们的白名单表，自然也没进离职 checklist。
第 1 篇解决的是：团队当下对 AI 的约定写什么。本篇解决：人进场、退场时，约定怎么装进人，又怎么从系统里拆干净。多出来的一层，可以叫数字身份资产：组织成员与计费、模型用量、自动执行默认值、MCP 授权、仓库规则与个人技能包——它们和工牌一样，需要入职发、离职收。
和三把椅子怎么对齐
沿用第 1 篇的三维：
| 维度 | 入职在做什么 | 离职在拆什么 |
|---|---|---|
| 上下文 | 拉齐「事实从哪来」：公共规则、文档索引、个人禁区 | 收走只存在个人机上的「真相」：私藏规则、群文件里的 Skill、未入库的 prompt |
| 行为 | 默认是手动还是自动：终端、MCP、外网、企业访问路径 | 断开连接器与 Token：MCP、云 API、CI 里的个人令牌 |
| 产出 | 约定谁审批 MCP、谁 Review 配置类 PR | 更新 owner：Wiki、值班表、长跑任务验收人 |
搞清楚这一格，你就不用在「入职培训」里堆快捷键——先身份与默认值，再谈模型多强。
一、入职三件事（建议顺序）
1）身份与组织边界：谁先占席、谁能管控制台
在团队级 AI Coding 工具里（例如企业版的 组织 / 成员 / 邀请 / SSO 一类能力），入职第一天建议明文四件事：
- 进哪个组织、占什么角色：谁有管理控制台（成员、邀请、用量、域名/SSO），谁是纯使用席。避免「大家都以为是 Member，其实某人能改全员策略」的灰色地带。
- 邀请制还是 SSO 自动加入：若走域名自动加入，** domains 范围是不是过大**、默认角色会不会一进组就占席计费——这一条要 Tech Lead 和行政/财务对一眼字，别交给新人自己Signup。
- 审核：邀请链接是否有人批；外包/实习生是否单独组织，避免和正式库同一套 MCP 策略。
这一步填的是第 1 篇表里**「谁说了算」**的行政层，不是友谊赛。
2）上下文安装包：规则进库，别先进聊天记录
个人有效 ≠ 团队可复现。 入职第二件事应该是：pull 仓库、看见团队级规则与文档索引，而不是先学会「我这样问就对了」。
工程上常见做法是：项目规则放在仓库里、跟代码一起 Review（例如 .qoder/rules 一类目录），团队共享；仅个人的偏好要么不写进主干，要么写进 .gitignore，避免「只有某台电脑的 AI 懂我们」。若同时使用 AGENTS.md 与项目规则，要约定冲突时谁优先——否则新人和老人的 AI 会对同一条规范给出不同答案。
把「事实源优先级 / 禁区清单」指给新人看一遍，相当于告诉他：哪些目录智能体可以批量读、哪些永远只能人肉申请。这比发十个视频教程管用。
3）行为出厂设置：自动执行默认关小，再按需开大
Tech Lead 最容易跳过、安全团队最关心的，是「默认能不能自动跑」。
一类典型配置是：自动运行 MCP、自动运行终端命令——可以设置成始终手动、白名单自动、黑名单拦截，或「全盘自动」（高风险，适合极少数隔离环境）。实务上建议新人从「终端命令偏手动」起步；确需白名单时，逐条过一遍前缀与场景，别图省事开到「始终自动」。同时要直说风险：外部提示词、不可信 MCP、可被绕过的白名单——入职培训里用两分钟念完，比出事写复盘短。
企业侧若对办公网、专线有要求，访问路径（公网 IP 白名单、私网接入等）也应写进入职 IT checklist：同一套 AI 控制台，从家里直连和从 VPC 直连，不是同一句「能上就行」。
二、第四件事：MCP 和 Token 别当作「自己电脑上的插件」
MCP 的本质是标准化外挂能力：接上一次，模型就能多一组工具和上下文。团队要写清：
- 白名单：允许哪些 MCP、谁评估、有无审批单号；
- 密钥放哪：密钥管理工具里还是个人 env；禁止群聊明文；
- 使用场景：是否仅在智能体模式下启用；同时挂载的 MCP 数量往往有上限（别让「每人各装一打小工具」成为协作噪声）。
Token / 用量 上，新人不是「无限试错券」。和直属 lead 对齐一句：组织席 + Credits 大致预算、哪些行为烧得快（长跑任务、大图、自动重试）。不必写成报价单，只要避免默认全开最贵档位 + 无人看板。
三、离职三件事
1）组织身份先收口
移出成员、撤销未用邀请链接、确认 SSO 自动加入范围是否仍合理；占用席位与计费是否同步下降。只关 Git 不关掉 AI 组织成员，是常见漏项。
2）密钥与连接器
轮换或作废：个人签发的 MCP 凭据、云厂商 key、数据库只读账号、CI/CD 里绑的个人 Token。追问一句：TA 的 IDE / 智能体里曾「一键授权」过哪些外部系统？ 没有登记表，就只能赌运气。
3）上下文与自动化遗产
全局 Skill、只在本机的规则片段、传到群里的「万能 prompt」、远程 / WSL / SSH 开发机上的代理——不要求 HR 懂技术，但 Tech Lead 要问：有没有文档 owner、长跑任务验收人要换人。为后续「多环境上下文对齐」专篇埋一句即可。
反模式： 人走了才听说「某个 MCP 还能打公司内网」；或离职清单只勾 Git/GitLab，从不勾 AI 工具组织与 API Key——这是把供应链风险留给下一任。
四、（轻量）复杂交付给新人的「肌肉记忆」
在多模块、低代码或强规范实践里，有一种与工具无关的教法是：先分层、再分批；先跑通环境，再让 AI 大规模读代码。大任务拆成「骨架 → 增量 → 规范扫尾」——例如业务主体先落地，规范类、异常类检查放在后面当验收，避免一上来就用「全套规则」把模型拖进上下文泥潭。新人若懂这套顺序，和 AI 结对时会少做大量无效重试（环境没稳就扫全仓库，人和模型都崩溃——这点和「等传统项目先装好依赖再跑分析」是同一逻辑）。
顺手对齐团队内部一句分工即可：规则偏「常驻共识」，技能包偏「按需加载的场景 SOP」，MCP 是「外接工具」——三者别混成一大坨私货。新人问清「哪些必须写进仓库规则、哪些用共享 Skill」，比每人复制一份万行 prompt 要强。
本节不对任何单一框架展开，只借复杂交付里 顺序与分层 这一点，给入职培训一个技术以外的抓手。
五、入职 / 离职半页 Checklist
| 事项 | 责任人 | 完成标准 | 对应第 1 篇 |
|---|---|---|---|
| 组织成员 / 角色 / 邀请或 SSO 范围 | Tech Lead + IT/行政 | 无游离占席；管理员明确 | 产出 / 行为 |
| 仓库规则与文档入口已拉取 | 本人 + Mentor | 能指出禁区与事实源优先级 | 上下文 |
| 自动执行默认策略已确认（终端 / MCP） | Tech Lead | 书面或截图进 wiki；新人签字知悉风险 | 行为 |
| MCP 白名单与审批记录在案 | 安全或 Tech Lead | 无群聊密钥；有独号或工单 | 行为 |
| 用量与席位预期沟通过 | Tech Lead | 新人知道「找谁加席、何时算异常」 | 产出 |
| （离职） 移出 AI 组织 / 撤销链接 | 管理员 | 与 Git 权限回收同日或更早 | 行为 |
| （离职） MCP / 云 / CI 个人 Token 轮换 | Tech Lead + 本人 | 检查清单打勾；可疑项有记录 | 行为 |
| （离职） 文档与长跑任务 owner 更新 | 直属 lead | 无悬挂验收人 | 产出 |
六、三条可执行结论
- 入职先收紧「身份 + 默认行为」，再放开模型能力——否则快在个人，乱在组织。
- 离职按「组织 → 密钥 → 上下文」镜像拆，漏一步就是隐性供应链。
- 规则 / 技能 / MCP 分层教一遍，新人少踩「全量私货 + 自动执行全开」。
下周最小一步： 把上表印成半页，下一个新人到岗日用一次、下一个老人离场日用一次——走完两轮，你们就会有真实增删项，而不是我替你们写的标准答案。
七、结语与下一篇
这一篇把「什么时候写进人、什么时候从系统拆走」说清了。AI Coding 实战里，人的生命周期和 Token 生命周期绑在同一张表上，团队才谈得上可审计、可接力。
如果你希望我按你们行业（金融 / SaaS / 政企等）把 MCP 白名单字段或离职排查话术 再压成一页，欢迎私信我，我按常见模版回一版可粘贴的——时间有限，优先回信息写清角色的 Tech Lead / 负责人。
我们不赌「人走了会不会良心发现删 Key」，只赌清单有没有进迭代纪律。> 现实里更扎心的问题是：表还没贴热，新同学已经用三台机器、三套默认设置把组织又拆散了；等人走了才发现，密钥和多 MCP 连接器还挂在旧身份上。本文把人的进场、退场当成一次小型「安全 + 协同」项目——不抄产品手册，只给你能放进 Wiki 的决策顺序和一张检查表。工具名偶尔出现，主线仍是团队怎么少翻车。
「当代码生成不再是瓶颈，谁占着席位、连着哪条外网、默认可不可自动跑命令才是雷区。」
—— 依然是这句话的另一面：秩序要在人身上落地，否则表只是纸本。
人走了，智能体还在——两个常见开场
画面一： 新人到岗第一天，自己配了 MCP、读了生产只读库，智能体自动生成了一份「看起来很专业的」环境变量 patch。周五评审里混进几行没人说得清来源的配置——问就是「AI 顺手改的，本地过了」。
画面二： 核心开发离职两周后，行政账号早关了，可财务对账时才发现：团队 AI 工具里还有一个占席的默认角色、某台旧笔记本仍登录着组织；更要命的是，群公告里传过的 MCP 安装链接和 API Key，根本没进你们的白名单表，自然也没进离职 checklist。
第 1 篇解决的是：团队当下对 AI 的约定写什么。本篇解决：人进场、退场时，约定怎么装进人，又怎么从系统里拆干净。多出来的一层，可以叫数字身份资产：组织成员与计费、模型用量、自动执行默认值、MCP 授权、仓库规则与个人技能包——它们和工牌一样，需要入职发、离职收。
和三把椅子怎么对齐
沿用第 1 篇的三维：
| 维度 | 入职在做什么 | 离职在拆什么 |
|---|---|---|
| 上下文 | 拉齐「事实从哪来」：公共规则、文档索引、个人禁区 | 收走只存在个人机上的「真相」：私藏规则、群文件里的 Skill、未入库的 prompt |
| 行为 | 默认是手动还是自动：终端、MCP、外网、企业访问路径 | 断开连接器与 Token：MCP、云 API、CI 里的个人令牌 |
| 产出 | 约定谁审批 MCP、谁 Review 配置类 PR | 更新 owner：Wiki、值班表、长跑任务验收人 |
搞清楚这一格，你就不用在「入职培训」里堆快捷键——先身份与默认值，再谈模型多强。
一、入职三件事（建议顺序）
1）身份与组织边界：谁先占席、谁能管控制台
在团队级 AI Coding 工具里（例如企业版的 组织 / 成员 / 邀请 / SSO 一类能力），入职第一天建议明文四件事：
- 进哪个组织、占什么角色：谁有管理控制台（成员、邀请、用量、域名/SSO），谁是纯使用席。避免「大家都以为是 Member，其实某人能改全员策略」的灰色地带。
- 邀请制还是 SSO 自动加入：若走域名自动加入，** domains 范围是不是过大**、默认角色会不会一进组就占席计费——这一条要 Tech Lead 和行政/财务对一眼字，别交给新人自己Signup。
- 审核：邀请链接是否有人批；外包/实习生是否单独组织，避免和正式库同一套 MCP 策略。
这一步填的是第 1 篇表里**「谁说了算」**的行政层，不是友谊赛。
2）上下文安装包：规则进库，别先进聊天记录
个人有效 ≠ 团队可复现。 入职第二件事应该是：pull 仓库、看见团队级规则与文档索引，而不是先学会「我这样问就对了」。
工程上常见做法是：项目规则放在仓库里、跟代码一起 Review（例如 .qoder/rules 一类目录），团队共享；仅个人的偏好要么不写进主干，要么写进 .gitignore，避免「只有某台电脑的 AI 懂我们」。若同时使用 AGENTS.md 与项目规则，要约定冲突时谁优先——否则新人和老人的 AI 会对同一条规范给出不同答案。
把「事实源优先级 / 禁区清单」指给新人看一遍，相当于告诉他：哪些目录智能体可以批量读、哪些永远只能人肉申请。这比发十个视频教程管用。
3）行为出厂设置：自动执行默认关小，再按需开大
Tech Lead 最容易跳过、安全团队最关心的，是「默认能不能自动跑」。
一类典型配置是：自动运行 MCP、自动运行终端命令——可以设置成始终手动、白名单自动、黑名单拦截，或「全盘自动」（高风险，适合极少数隔离环境）。实务上建议新人从「终端命令偏手动」起步；确需白名单时，逐条过一遍前缀与场景，别图省事开到「始终自动」。同时要直说风险：外部提示词、不可信 MCP、可被绕过的白名单——入职培训里用两分钟念完，比出事写复盘短。
企业侧若对办公网、专线有要求，访问路径（公网 IP 白名单、私网接入等）也应写进入职 IT checklist：同一套 AI 控制台，从家里直连和从 VPC 直连，不是同一句「能上就行」。
二、第四件事：MCP 和 Token 别当作「自己电脑上的插件」
MCP 的本质是标准化外挂能力：接上一次，模型就能多一组工具和上下文。团队要写清：
- 白名单：允许哪些 MCP、谁评估、有无审批单号；
- 密钥放哪：密钥管理工具里还是个人 env；禁止群聊明文；
- 使用场景：是否仅在智能体模式下启用；同时挂载的 MCP 数量往往有上限（别让「每人各装一打小工具」成为协作噪声）。
Token / 用量 上，新人不是「无限试错券」。和直属 lead 对齐一句：组织席 + Credits 大致预算、哪些行为烧得快（长跑任务、大图、自动重试）。不必写成报价单，只要避免默认全开最贵档位 + 无人看板。
三、离职三件事
1）组织身份先收口
移出成员、撤销未用邀请链接、确认 SSO 自动加入范围是否仍合理；占用席位与计费是否同步下降。只关 Git 不关掉 AI 组织成员，是常见漏项。
2）密钥与连接器
轮换或作废：个人签发的 MCP 凭据、云厂商 key、数据库只读账号、CI/CD 里绑的个人 Token。追问一句：TA 的 IDE / 智能体里曾「一键授权」过哪些外部系统？ 没有登记表，就只能赌运气。
3）上下文与自动化遗产
全局 Skill、只在本机的规则片段、传到群里的「万能 prompt」、远程 / WSL / SSH 开发机上的代理——不要求 HR 懂技术，但 Tech Lead 要问：有没有文档 owner、长跑任务验收人要换人。为后续「多环境上下文对齐」专篇埋一句即可。
反模式： 人走了才听说「某个 MCP 还能打公司内网」；或离职清单只勾 Git/GitLab，从不勾 AI 工具组织与 API Key——这是把供应链风险留给下一任。
四、（轻量）复杂交付给新人的「肌肉记忆」
在多模块、低代码或强规范实践里，有一种与工具无关的教法是：先分层、再分批；先跑通环境，再让 AI 大规模读代码。大任务拆成「骨架 → 增量 → 规范扫尾」——例如业务主体先落地，规范类、异常类检查放在后面当验收，避免一上来就用「全套规则」把模型拖进上下文泥潭。新人若懂这套顺序，和 AI 结对时会少做大量无效重试（环境没稳就扫全仓库，人和模型都崩溃——这点和「等传统项目先装好依赖再跑分析」是同一逻辑）。
顺手对齐团队内部一句分工即可：规则偏「常驻共识」，技能包偏「按需加载的场景 SOP」，MCP 是「外接工具」——三者别混成一大坨私货。新人问清「哪些必须写进仓库规则、哪些用共享 Skill」，比每人复制一份万行 prompt 要强。
本节不对任何单一框架展开，只借复杂交付里 顺序与分层 这一点，给入职培训一个技术以外的抓手。
五、入职 / 离职半页 Checklist
| 事项 | 责任人 | 完成标准 | 对应第 1 篇 |
|---|---|---|---|
| 组织成员 / 角色 / 邀请或 SSO 范围 | Tech Lead + IT/行政 | 无游离占席；管理员明确 | 产出 / 行为 |
| 仓库规则与文档入口已拉取 | 本人 + Mentor | 能指出禁区与事实源优先级 | 上下文 |
| 自动执行默认策略已确认（终端 / MCP） | Tech Lead | 书面或截图进 wiki；新人签字知悉风险 | 行为 |
| MCP 白名单与审批记录在案 | 安全或 Tech Lead | 无群聊密钥；有独号或工单 | 行为 |
| 用量与席位预期沟通过 | Tech Lead | 新人知道「找谁加席、何时算异常」 | 产出 |
| （离职） 移出 AI 组织 / 撤销链接 | 管理员 | 与 Git 权限回收同日或更早 | 行为 |
| （离职） MCP / 云 / CI 个人 Token 轮换 | Tech Lead + 本人 | 检查清单打勾；可疑项有记录 | 行为 |
| （离职） 文档与长跑任务 owner 更新 | 直属 lead | 无悬挂验收人 | 产出 |
六、三条可执行结论
- 入职先收紧「身份 + 默认行为」，再放开模型能力——否则快在个人，乱在组织。
- 离职按「组织 → 密钥 → 上下文」镜像拆，漏一步就是隐性供应链。
- 规则 / 技能 / MCP 分层教一遍，新人少踩「全量私货 + 自动执行全开」。
下周最小一步： 把上表印成半页，下一个新人到岗日用一次、下一个老人离场日用一次——走完两轮，你们就会有真实增删项，而不是我替你们写的标准答案。
七、结语
这一篇把「什么时候写进人、什么时候从系统拆走」说清了。AI Coding 实战里，人的生命周期和 Token 生命周期绑在同一张表上，团队才谈得上可审计、可接力。
如果你希望我按你们行业（金融 / SaaS / 政企等）把 MCP 白名单字段或离职排查话术 再压成一页，欢迎私信我，我按常见模版回一版可粘贴的——时间有限，优先回信息写清角色的 Tech Lead / 负责人。
我们不赌「人走了会不会良心发现删 Key」，只赌清单有没有进迭代纪律。
