一名資深工程師準備退休前，公司的第一個反應通常是要求他整理文件。
項目紀錄、標準程序、技術範本、供應商名單和過往問題，都可以存入公司系統。管理層希望把經驗留下來，讓年輕同事日後查閱。
但真正交接時，團隊很快發現最有價值的內容並不容易寫進文件。
為甚麼某類裂縫看起來不嚴重，卻需要立即升級？遇到顧問尚未回覆，甚麼情況可以先行施工？某家供應商報價較低，但為甚麼資深同事仍然不建議使用？面對幾個同時出現的問題，哪一個應該先處理？
這些並不是單純技術答案，而是多年累積的情境判斷。
人可以留下圖紙，卻很難留下自己如何看一張圖紙。
年輕工程師接收到很多知識，卻未必獲得足夠判斷機會
今天的年輕工程師可以更快取得標準、規範、技術資料和過往案例。數碼工具甚至可以協助搜尋、整理和初步分析。
但資訊增加，不代表專業成熟速度自然提高。
工程判斷需要在真實限制下形成。時間不夠、資料不完整、成本和安全互相拉扯、不同持份者有不同立場，工程師需要選擇一個可承擔的行動。
如果年輕同事長期只負責準備資料，而最終判斷永遠由資深工程師接手，他們便很難理解結論如何形成。
資深同事愈能幹，反而愈容易在最後一刻親自解決問題。項目順利度過危機，但團隊只看到答案，沒有參與判斷過程。
經驗不是「見過」，而是知道哪些差異值得在意
兩個看似相似的工程問題，實際風險可能完全不同。
同樣是進度落後，一個可能靠增加資源追回，另一個則由設計接口造成，加人沒有作用。同樣是測試數值異常，一個可能只是儀器問題，另一個卻是系統性變化的早期訊號。
資深工程師的價值，往往在於能夠辨認差異。
這種能力很難透過一般工作程序完整表達。程序會告訴人員需要檢查甚麼，經驗則幫助判斷哪一個結果不符合現場脈絡。
因此，知識傳承若只整理「正確做法」，便會失去大量真正有價值的內容：當標準做法遇到特殊條件時，資深人員如何取捨。
企業最容易留下成功案例，卻忽略那些差點出事的判斷
完工項目通常會留下報告、相片、數據和成果。
但最值得學習的，可能是那些最終沒有發展成事故、索賠或重大延誤的事件。
某位工程師在問題仍很小時決定停工檢查；某次採購在價格仍合理時被拒絕，因為交付能力令人懷疑；某個施工方案最終沒有採用，因為團隊預見了後續接口風險。
結果沒有發生，企業便很少記錄。
資深人員離開後，下一代只看到最後採用的方案，不知道當時排除了哪些選擇，也不知道甚麼訊號令團隊改變方向。
真正的經驗庫不應只有「我們做了甚麼」，還要記錄「我們曾經考慮甚麼，以及為甚麼沒有做」。
傳承不能等到退休前半年才開始
很多公司在資深人員即將離開時，才正式啟動交接。
但工程經驗依附於日常判斷，不可能在幾次分享會中完整轉移。
較有效的傳承，需要在項目運作中發生。重要會議後，資深工程師可以解釋自己為何關注某個問題；年輕同事先提出建議，再由資深人員補充盲點；項目出現偏差後，不只檢討結果，也討論當時有哪些訊號被忽略。
這種方式看似較慢，因為資深人員需要花時間解釋，而不是直接給答案。
但如果公司永遠以眼前效率為優先，資深工程師便會一直親自處理，直到離開當日，團隊仍然依賴他。
AI 可以保存資料，但未必自動保存專業判斷
AI 和企業知識平台可以整理過往文件、搜尋案例、總結會議和提示相似問題，對知識傳承具有很大潛力。
但若企業輸入的只有最終文件，系統學到的仍然只是結果。
要保存判斷，公司需要記錄更多過程：當時掌握哪些資料、有哪些不確定因素、考慮過哪些方案、誰反對、最後為甚麼選擇某一方向，以及結果是否符合預期。
AI 可以令這些內容更容易被搜尋和重用，卻不能代替企業建立反思習慣。
沒有被說出來的經驗，任何系統都無法保存。
真正的人才斷層，是公司失去作出可靠判斷的速度
資深工程師離開後，公司不一定立即失去技術能力。
圖紙仍有人畫，計算仍有人做，程序亦繼續運行。最先受影響的可能是判斷速度：問題需要更長時間升級，更多人參與討論，團隊在模糊情況下較難作出決定。
企業可能以為自己缺少一名員工，實際上失去的是一個多年形成的風險過濾器。
解決斷層不能只靠招聘另一位同樣資深的人，因為每個人的經驗建立在不同項目和組織環境上。
真正可持續的做法，是把專業判斷由個人英雄能力，逐步變成團隊可以觀察、討論、挑戰和累積的過程。
行業需要新一代工程師，企業更需要讓他們在資深人員仍然在場時，真正參與那些沒有標準答案的決定。