一张多维表格换了人接手，几个月后才发现，一堆自动化的配置者还是那位已经离职的同事。哪几条还在跑、哪几条早就停了，从外面看不出来。
这张表串起好几个部门，上面挂着自动化提醒，旁边接着 AI 助手和知识库，上线那天一切都对。出问题的是另一层：这里面有多少东西，挂在某一个具体的人身上。 我们现在接手或交出这样一套系统，头一件事就是把这一层清点出来。
挂在人身上的，远不止配置者
- 自动化的执行身份。 飞书多维表格的自动化，以配置者或机器人的身份运行。配置者离职、权限被回收，挂在他名下的自动化可能跟着失效。
- 消息接收人。 接收人选某个具体的人，等于把当时的人名写进了流程；选记录上的人员字段，那一格存的也是当时选中的那个人。岗位换了、人走了，两种都不会跟着变。
- 第三方 Key。 在 Dify 里，一个人用自己的账号申请、填了一次，整个团队的应用都在用他那把。扣子自定义插件里写死的接口密钥，会跟着插件的复制件一起走，传到第几手，当初领 Key 的人自己也数不清。他的账号一回收，或者这把 Key 不得不换，用到它的地方会一起停。
- 知识库。 Dify 的知识库建在谁的账号下就归谁，默认权限只开给建库的人自己。他一转岗，引用这个库的应用出了问题就没人接得住，而这类东西不在任何一份项目文档里。
- 唯一的管理员。 自建的 Dify 装完，默认只有一个管理员，加人、配模型都要经过他。他休假或离职，谁也进不去后台，找回账号也要费一番周折。
失效的样子，和正常一模一样
这些东西出了问题，大多不报错；就算报，也报在平时没人看的地方。
接收人为空，这一步直接跳过。 不发，也不报错，日志照样记成功。最该被提醒的，恰恰是刚建好、还没指派负责人的单，它们一条都收不到，越没人管的单越安静。人员字段还挂着离职同事的，提醒照发，石沉大海，运行记录里未必看得出异常。
Key 的主人一走，用它的流程会在某一天一起停。 他的账号哪天被回收，Key 就在第三方那一侧跟着失效，用到它的流程同时不工作，谁也说不出为什么。平台这边只知道「授权配过」，状态看上去还是好好的。
修改人那一列还在变，只是不再代表人。 一条记录的状态被改错了，业务负责人想查是谁改的：「最后修改人」是那个机器人，隔壁几条也是它，整张表几百条记录，这一列只剩一个名字。自动化每碰一次记录，就把修改人和更新时间刷成自己。这一列不报错也不变空，名字还在变、时间还在动，靠它做的追溯、按它算的停滞天数，就这样悄无声息地废掉了。
自动化停过，只有动手的人知道。 为了批量导入，有人先把自动化停掉，做完再开，停用期间的变更不会补跑；他没跟业务方说一声，别人看到的就是「系统漏单」。每月的执行次数配额用完也会停，提示不在日常用表的人眼前，多数人注意不到。
日志上的「成功」只说明这条自动化跑完了，消息有没有送到人手里，它不管；授权上的「正常」只说明当初配过，现在还能不能用，它看不出来。平时一切正常，出事那天才发现整条路只有一把钥匙，而拿钥匙的人已经不在了。
我们现在的规矩
- 接收人不取记录上的历史人员字段。 做一张「岗位—当前负责人」的小表，记录关联到岗位，消息从小表里找人，换人只改一格。
- 「没人可发」本身要变成一条消息。 负责人为空的记录单独汇总，发给一个固定的兜底接收人。
- 共用的 Key 用公司账号申请，不用个人账号；用了哪几把、各自是谁申请的，写进部署文档。
- 自建平台装完当天加第二个管理员，用另一个人的邮箱；管理员账号用的是哪个邮箱，写进部署文档。
- 要追溯、要统计的痕迹，都落成自己控制的字段。 自动化每写一次，就把「什么时候、因为什么、改成了什么」追加进一列操作记录；停滞天数改用一列「本状态开始时间」来算，不再依赖「最后修改人」「最后更新时间」。
- 停用自动化前后，各在群里说一声。 执行次数还剩多少，每月看一次。
- 交接清单单列一栏「他名下的东西」： 他建的知识库、工具授权、API Key、以他为配置者的自动化。
- 关键知识库建在团队空间，权限给到全员。 交接完，把关键链路真跑一遍再签字。
加第二个管理员花一分钟，把 Key 的归属写进文档花五分钟。省下的，是「等某个人回来」这种技术解决不了的等待。
交接清单上最该写的，是几行人名：谁配的自动化，谁领的 Key，谁建的库，谁是管理员。