阿凯提离职前留下了一个共用云端数据夹的连结，并附上一句「东西都在里面，有问题再问我」。但三个星期后，当客户需要一份新的对照表时，开发团队发现有一半的规则没人说得清为什么。开发团队成员问了两个人，得到的答案却是「好像是客户嫌过」和「阿凯当时有说明，但现在没人记得了」。这个事件涉及阿凯提、开发团队和客户，重要背景是团队缺乏明确的规则和知识传承，导致团队成员无法理解规则的原因和目的。
菜鸟之友系列：《AI 工具实操与提示词》・工具篇作者：业州愚公
阿凯提离职，最后一天下午，他把共用云端数据夹的连结发到群里，附一句「东西都在里面，有问题再问我」。我当时还觉得挺周全。三个星期后，客户要一份新的对照表，我打开那张专案卡，看到第三条规则写着「输出务必用条列，不要用段落」。为什么？没人知道。问了两个人，一个说「好像是客户嫌过」，另一个说「阿凯当时有讲，我忘了」。那天我们花了四十分钟争论这条要不要留——而阿凯已经在新公司上班了。
上一篇讲的是共用包的版本规矩，管住了「大家手上是不是同一版」。这一篇讲另一种断法：文件还在，版本也对，但没人知道它为什么长这样。
这种断法比版本乱更难察觉。版本乱，你至少看得到三份文件；理由断了，你看到的是干净整齐的一份卡，直到某天有人问「这条能不能改」，全场沉默。而沉默的代价通常是两个：要嘛没人敢动，卡慢慢僵死；要嘛有人手一滑删掉一条重要规则，两周后才发现输出全走样。
我后来把这次的教训整理成一套交接动作，用了三个人的小团队试了一轮，也让一位新人照着走过一遍。核心就一句话：交接要交的不是数据夹，是判断力。
很多人以为交接就是「把数据夹权限开给下一个人」。数据夹只是第一样，而且是最容易的那一样。
| 要交的东西 | 具体是什么 | 断了会怎样 |
|---|---|---|
| 文件本体 | 专案卡、术语表、范例输出、历史版本子目录 | 一眼就看得出，反而最少出事 |
| 规则的来由 | 每条规则当初为了解决什么问题 | 没人敢改，或乱改后全组走样 |
| 常用问法 | 哪几句话最出效果、哪些问法踩过雷 | 新人从零试错，重复前人的坑 |
| 权限与钥匙 | 共用数据夹权限、专案成员资格、API key 的归属 | 人走了门还开着，或该开的开不了 |
四样里面，只有第一样是「复制贴上」能解决的。剩下三样都得靠人坐下来讲、写下来，这也是为什么多数交接只交成了四分之一。
最有效的补救办法，简单到有点不好意思：每条规则后面加一个括号，写一句当初的理由。
原本是「输出务必用条列，不要用段落」，改成「输出务必用条列，不要用段落（客户的窗口要在会议上直接转贴进邮件，段落版他得自己拆）」。多了十四个字，这条规则就从「祖传规矩」变成了「有出处的决定」。下一个人看到它，判断力就接上了：客户窗口换人了、或者现在改走简报，这条就可以重新讨论；客户还是同一个、还是要转贴，这条就别碰。
我们现在的写法是三件套：规则一句、理由一句、加入日期。日期不是为了考勤，是为了让后来的人知道轻重——跑了两年的规则和上周才加的规则，可信度不一样。
写理由的时候有一个诀窍：写「当时发生了什么」，不要写「为了提升品质」。 前者是事实，后者谁都能写，写了等于没写。
如果那位同事已经走了、问不到理由，怎么办？我的做法是标上一个记号，例如「（理由待确认）」，然后在下次真的需要改这条时，先小范围试一次、对比输出，用结果反推理由。不确定就标不确定，比编一个听起来很合理的理由安全得多。
这一块最容易被「人情」耽误。同事好聚好散，开口要他交权限，好像显得不信任人。但实务上，这不是信任问题，是卫生问题。
要做的一共三件：
第一，把个人名义的钥匙换成角色名义。 如果团队的 API key、云端专案是用某个人的账号开的，那个人一走，要嘛服务断掉，要嘛帐单还挂在他名下。正确做法是用一个团队共用的信箱或管理员角色去开，个人只是被授权使用。这样人来人往，钥匙不动。
第二，离职当天就撤权限，不要「等他交接完再说」。 听起来冷，但这是保护双方：他走了之后数据出了问题，没有人会怀疑到他头上。撤权限的同时，记得把「管理员」这个角色明确交给某一个具体的人，别让它变成一个空位。
第三，留一份「谁有权限」的清单。 三个人的团队也要有。我们第一次做的时候才发现，有一位早就离职的实习生还在共用数据夹的成员名单里——没出事，但这说明了一件事：没有清单的权限，等于没有权限管理。
各家工具在成员管理、金钥设置的入口上差异不小，实际位置以官方最新版本为准；但「用角色持有、不用个人持有」这个原则，跟用哪家工具无关。
交接有两个方向，离开的那一半常被讨论，进来的那一半常被忽略。而新人上手的好坏，直接决定这张卡能不能继续活下去。
我们试过两种带法。第一种是「先把卡读一遍，有问题问我」——结果新人读完点头，实际动手还是照自己的习惯来，卡上的规则像贴在墙上的标语。第二种是「先做一遍，再读卡」：给他一个真实的小任务，让他按自己的方式做出来，然后两个人一起对照卡上的规则，看哪些地方他走偏了、哪些地方卡根本没写清楚。
第二种麻烦，但效果差得远。因为它同时验了两件事：新人有没有读懂，以及卡有没有写明白。我们第一次用这招，新人做出来的东西有三处跟卡不符，其中两处是他的问题，第三处真的是卡的漏洞——那条规则写得太抽象，只有老成员才懂它在说什么。
口头交接的问题是「讲过就没了」。我们现在固定填一张表，长度控制在一页以内：
| 栏位 | 填什么 | 为什么要填 |
|---|---|---|
| 交接日期与双方 | 谁交给谁，哪一天 | 出事时知道该问谁 |
| 卡上未解的问题 | 例如「第三条理由待确认」 | 把不确定摊在阳光下 |
| 待转移的权限 | 逐项列出，勾一项划一项 | 避免「以为交了」 |
| 新人首轮试做 | 做了什么任务、对出几处落差 | 验卡，也验人 |
| 下一次覆核日 | 通常订在一个月后 | 让交接有收尾，不是散场 |
这张表不需要任何工具，一份共用文件就够。它的价值不在纪录本身，在强迫双方把「差不多都讲了」变成「逐项确认过」。人对模糊的东西天生乐观，表格是对抗这种乐观最便宜的工具。
问：人都要走了，还让他花半天写这些，会不会太不近人情？
反过来想：真正不近人情的是三个星期后，一群人对着一张没人看得懂的卡，在群里连环追问一个已经离职的人。而且写理由这件事，对要走的人也有好处——他把自己这两年做的判断留下一份纪录，这比在群里发一段告别的话实在。实务上我会把这件事排在最后一周，切成三次、每次半小时，不要压在最后一天。
问：小团队就三个人，也要搞这一套吗？
不必全上。三个人的团队，至少做两件：规则后面写理由、权限用角色持有。这两件的成本加起来不到半小时，但挡掉的是最贵的两种事故——规则失传、钥匙失控。表格和新人试做可以等真的有人来有人走时再补。
共用包这种东西，平时看不出价值，人一动就见真章。它考验的其实不是工具用得多熟，而是有没有人愿意多写那十四个字、多填那一页表。
卡是死的，写卡的人是活的。人会走，那就让卡自己会说话。
工具推荐随身机器人（新用户免费试用 7 天）
交接清单、覆核日、权限到期提醒，这些靠记性最容易漏。我把这张交接表交给随身机器人盯着：该撤的权限到点提醒、一个月后的覆核自动排进去，人走了流程不会跟着走。新用户免费试用 7 天，试过再决定要不要留下。到 sylogs.com 首页点「随身机器人」即可开通。
下一篇预告： 交接补上了，新的问题又冒出来——这张卡跑了半年，规则越加越多，有些早就没人用、有些互相打架，却没人敢删。下一篇讲「共用包的定期体检」：三个月没人碰的规则、过期的数据、没人问的问题，怎么一次清干净。
业州愚公 ｜ SY 视野（sylogs.com）原创内容，转载请注明出处。
编辑评论 / Editor's Note
这则故事揭示了企业中常见的知识隐藏问题，当关键人物离职后，许多重要的知识和经验可能会随之流失。这种情况下，企业可能需要重新评估和整理现有的规则和流程，以避免类似的困境。同时，也反映出知识管理和传承的重要性，企业应该积极建立完善的知识管理系统。