阿凱提離職前留下了一個共用雲端資料夾的連結，並附上一句「東西都在裡面，有問題再問我」。但三個星期後，當客戶需要一份新的對照表時，開發團隊發現有一半的規則沒人說得清為什麼。開發團隊成員問了兩個人，得到的答案卻是「好像是客戶嫌過」和「阿凱當時有說明，但現在沒人記得了」。這個事件涉及阿凱提、開發團隊和客戶，重要背景是團隊缺乏明確的規則和知識傳承，導致團隊成員無法理解規則的原因和目的。
菜鳥之友系列：《AI 工具實操與提示詞》・工具篇作者：業州愚公
阿凱提離職，最後一天下午，他把共用雲端資料夾的連結發到群裡，附一句「東西都在裡面，有問題再問我」。我當時還覺得挺周全。三個星期後，客戶要一份新的對照表，我打開那張專案卡，看到第三條規則寫著「輸出務必用條列，不要用段落」。為什麼？沒人知道。問了兩個人，一個說「好像是客戶嫌過」，另一個說「阿凱當時有講，我忘了」。那天我們花了四十分鐘爭論這條要不要留——而阿凱已經在新公司上班了。
上一篇講的是共用包的版本規矩，管住了「大家手上是不是同一版」。這一篇講另一種斷法：檔案還在，版本也對，但沒人知道它為什麼長這樣。
這種斷法比版本亂更難察覺。版本亂，你至少看得到三份檔案；理由斷了，你看到的是乾淨整齊的一份卡，直到某天有人問「這條能不能改」，全場沉默。而沉默的代價通常是兩個：要嘛沒人敢動，卡慢慢僵死；要嘛有人手一滑刪掉一條重要規則，兩週後才發現輸出全走樣。
我後來把這次的教訓整理成一套交接動作，用了三個人的小團隊試了一輪，也讓一位新人照著走過一遍。核心就一句話：交接要交的不是資料夾，是判斷力。
很多人以為交接就是「把資料夾權限開給下一個人」。資料夾只是第一樣，而且是最容易的那一樣。
| 要交的東西 | 具體是什麼 | 斷了會怎樣 |
|---|---|---|
| 檔案本體 | 專案卡、術語表、範例輸出、歷史版本子目錄 | 一眼就看得出，反而最少出事 |
| 規則的來由 | 每條規則當初為了解決什麼問題 | 沒人敢改，或亂改後全組走樣 |
| 常用問法 | 哪幾句話最出效果、哪些問法踩過雷 | 新人從零試錯，重複前人的坑 |
| 權限與鑰匙 | 共用資料夾權限、專案成員資格、API key 的歸屬 | 人走了門還開著，或該開的開不了 |
四樣裡面，只有第一樣是「複製貼上」能解決的。剩下三樣都得靠人坐下來講、寫下來，這也是為什麼多數交接只交成了四分之一。
最有效的補救辦法，簡單到有點不好意思：每條規則後面加一個括號，寫一句當初的理由。
原本是「輸出務必用條列，不要用段落」，改成「輸出務必用條列，不要用段落（客戶的窗口要在會議上直接轉貼進郵件，段落版他得自己拆）」。多了十四個字，這條規則就從「祖傳規矩」變成了「有出處的決定」。下一個人看到它，判斷力就接上了：客戶窗口換人了、或者現在改走簡報，這條就可以重新討論；客戶還是同一個、還是要轉貼，這條就別碰。
我們現在的寫法是三件套：規則一句、理由一句、加入日期。日期不是為了考勤，是為了讓後來的人知道輕重——跑了兩年的規則和上週才加的規則，可信度不一樣。
寫理由的時候有一個訣竅：寫「當時發生了什麼」，不要寫「為了提升品質」。 前者是事實，後者誰都能寫，寫了等於沒寫。
如果那位同事已經走了、問不到理由，怎麼辦？我的做法是標上一個記號，例如「（理由待確認）」，然後在下次真的需要改這條時，先小範圍試一次、對比輸出，用結果反推理由。不確定就標不確定，比編一個聽起來很合理的理由安全得多。
這一塊最容易被「人情」耽誤。同事好聚好散，開口要他交權限，好像顯得不信任人。但實務上，這不是信任問題，是衛生問題。
要做的一共三件：
第一，把個人名義的鑰匙換成角色名義。 如果團隊的 API key、雲端專案是用某個人的帳號開的，那個人一走，要嘛服務斷掉，要嘛帳單還掛在他名下。正確做法是用一個團隊共用的信箱或管理員角色去開，個人只是被授權使用。這樣人來人往，鑰匙不動。
第二，離職當天就撤權限，不要「等他交接完再說」。 聽起來冷，但這是保護雙方：他走了之後資料出了問題，沒有人會懷疑到他頭上。撤權限的同時，記得把「管理員」這個角色明確交給某一個具體的人，別讓它變成一個空位。
第三，留一份「誰有權限」的清單。 三個人的團隊也要有。我們第一次做的時候才發現，有一位早就離職的實習生還在共用資料夾的成員名單裡——沒出事，但這說明了一件事：沒有清單的權限，等於沒有權限管理。
各家工具在成員管理、金鑰設定的入口上差異不小，實際位置以官方最新版本為準；但「用角色持有、不用個人持有」這個原則，跟用哪家工具無關。
交接有兩個方向，離開的那一半常被討論，進來的那一半常被忽略。而新人上手的好壞，直接決定這張卡能不能繼續活下去。
我們試過兩種帶法。第一種是「先把卡讀一遍，有問題問我」——結果新人讀完點頭，實際動手還是照自己的習慣來，卡上的規則像貼在牆上的標語。第二種是「先做一遍，再讀卡」：給他一個真實的小任務，讓他按自己的方式做出來，然後兩個人一起對照卡上的規則，看哪些地方他走偏了、哪些地方卡根本沒寫清楚。
第二種麻煩，但效果差得遠。因為它同時驗了兩件事：新人有沒有讀懂，以及卡有沒有寫明白。我們第一次用這招，新人做出來的東西有三處跟卡不符，其中兩處是他的問題，第三處真的是卡的漏洞——那條規則寫得太抽象，只有老成員才懂它在說什麼。
口頭交接的問題是「講過就沒了」。我們現在固定填一張表，長度控制在一頁以內：
| 欄位 | 填什麼 | 為什麼要填 |
|---|---|---|
| 交接日期與雙方 | 誰交給誰，哪一天 | 出事時知道該問誰 |
| 卡上未解的問題 | 例如「第三條理由待確認」 | 把不確定攤在陽光下 |
| 待轉移的權限 | 逐項列出，勾一項劃一項 | 避免「以為交了」 |
| 新人首輪試做 | 做了什麼任務、對出幾處落差 | 驗卡，也驗人 |
| 下一次覆核日 | 通常訂在一個月後 | 讓交接有收尾，不是散場 |
這張表不需要任何工具，一份共用文件就夠。它的價值不在紀錄本身，在強迫雙方把「差不多都講了」變成「逐項確認過」。人對模糊的東西天生樂觀，表格是對抗這種樂觀最便宜的工具。
問：人都要走了，還讓他花半天寫這些，會不會太不近人情？
反過來想：真正不近人情的是三個星期後，一群人對著一張沒人看得懂的卡，在群裡連環追問一個已經離職的人。而且寫理由這件事，對要走的人也有好處——他把自己這兩年做的判斷留下一份紀錄，這比在群裡發一段告別的話實在。實務上我會把這件事排在最後一週，切成三次、每次半小時，不要壓在最後一天。
問：小團隊就三個人，也要搞這一套嗎？
不必全上。三個人的團隊，至少做兩件：規則後面寫理由、權限用角色持有。這兩件的成本加起來不到半小時，但擋掉的是最貴的兩種事故——規則失傳、鑰匙失控。表格和新人試做可以等真的有人來有人走時再補。
共用包這種東西，平時看不出價值，人一動就見真章。它考驗的其實不是工具用得多熟，而是有沒有人願意多寫那十四個字、多填那一頁表。
卡是死的，寫卡的人是活的。人會走，那就讓卡自己會說話。
工具推薦隨身機器人（新用戶免費試用 7 天）
交接清單、覆核日、權限到期提醒，這些靠記性最容易漏。我把這張交接表交給隨身機器人盯著：該撤的權限到點提醒、一個月後的覆核自動排進去，人走了流程不會跟著走。新用戶免費試用 7 天，試過再決定要不要留下。到 sylogs.com 首頁點「隨身機器人」即可開通。
下一篇預告： 交接補上了，新的問題又冒出來——這張卡跑了半年，規則越加越多，有些早就沒人用、有些互相打架，卻沒人敢刪。下一篇講「共用包的定期體檢」：三個月沒人碰的規則、過期的資料、沒人問的問題，怎麼一次清乾淨。
業州愚公 ｜ SY 視野（sylogs.com）原創內容，轉載請註明出處。
編輯評論 / Editor's Note
這則故事揭示了企業中常見的知識隱藏問題，當關鍵人物離職後，許多重要的知識和經驗可能會隨之流失。這種情況下，企業可能需要重新評估和整理現有的規則和流程，以避免類似的困境。同時，也反映出知識管理和傳承的重要性，企業應該積極建立完善的知識管理系統。