老周做了三十年工程，準備退休。
公司很重視知識傳承。
他的SOP、報告、Email、會議紀錄、異常案例、維修資料，全都整理進系統。
大家鬆了一口氣。
「老周的經驗留下來了。」
真的嗎？
文件當然留下來了。
但下一個工程師遇到異常時，真正需要的往往不是：
老周以前怎麼做？
而是：
他當時為什麼這樣做？
那個判斷依賴哪些條件？
哪些條件今天還存在？
哪一次他自己也曾經判錯？
又是哪一次現實逼他把原來的經驗改掉？
這些如果沒有留下，知識庫保存的可能只是答案的外殼。
查得到，不等於做得出。
公司裡有很多東西，本來就適合放在外面。
BOM。
規格。
料號。
現行SOP。
供應商資料。
最新測試結果。
這些會變，也應該隨時更新。
但另外一些東西，不只是資料。
例如：
什麼訊號值得追？
哪一種異常看似正常，其實要小心？
什麼時候不能太相信平均值？
什麼條件一變，原來的方法就該重看？
這些比較接近能力。
所以企業AI真正值得累積的，不只是「知道很多」。
而是逐漸形成自己的判斷方式。
可以濃縮成一句：
知識可以放在外面，能力可以長進裡面。
問題也從這裡開始。
假設老周常說：
「看到A，先查B。」
這句話很好用。
AI整理幾千筆案例後，也發現大部分時候確實如此。
於是系統很自然地把它蒸餾成：
A → B
久了以後，經驗就變成規則。如果系統沒有連同適用條件、例外紀錄與曾經失敗的情境一起保存，這條捷徑很容易被當成普遍有效。
再久一點，規則就變成「大家都知道」。
危險恰恰在這裡。
因為真正該留下的不只是：
看到A先查B。
還有：
為什麼？
在哪些產品成立？
哪個年代成立？
哪種材料不成立？
哪一次A出現，最後卻根本不是B？
那次錯誤之後，老周改了什麼？
如果這些沒有一起留下，成功經驗愈完整，反而愈容易變成祖訓。
《明思》的，在這裡不能只保存成功做法。
還要留下：
它成立的條件。
它失效的案例。
它被修正的過程。
這時才真正有用。
不是問：
這條經驗準不準？
而是問：
它在哪裡不準？
則再往前一步：
新的資料進來之後，這條經驗要不要降權？
要不要改寫？
甚至要不要讓它退休？
最後。
重新問一次：
當初為什麼形成這個做法？
今天，那個理由還存在嗎？
《莊子》裡有個輪扁斫輪的故事。
桓公讀古人的書。
輪扁卻說，真正做輪子的分寸，快不得，慢不得，那種手感「得之於手而應於心」，很難完整說給別人聽。
這個故事放到AI時代，不能簡單理解成：
「默會知識無法數位化。」
那太快了。
真正值得問的是：
過去那些只能靠長年手感留下的判斷，AI能不能從大量案例、反例與修正裡，逼近它背後的條件？
有些可以。
有些仍然不行。
但無論如何，把一句老工程師的經驗寫進知識庫，不等於已經把他的能力傳下來。
那只是把話留下。
能力還要經過現實重新長一次。
所以企業AI不應只蒐集「怎麼做」。
它還應該參與經驗的蒸餾。
哪些經驗反覆成立？
哪些只適用某一代產品？
哪些因材料、供應商、設備改變而失效？
哪些看似是直覺，其實背後有穩定條件？
哪些只是傳說，從來沒有真正被驗過？
這時，AI就不再只是公司的大型搜尋器。
它開始幫組織把經驗分成：
仍然有效的。
條件式有效的。
需要重新驗證的。
以及應該淘汰的。
這也意味著，公司AI真正要繼承的，不只是成功史。
還有：
成功被推翻的歷史。
哪一條SOP曾經是對的，後來為什麼不對？
哪個判斷曾經救過很多案子，後來在哪個新產品上失效？
哪位專家的直覺曾經被大家相信，最後又是什麼證據迫使大家改變？
這些歷史如果留下來，AI學到的就不只是：
「以前的人怎麼想。」
還有：
「以前的人什麼時候願意承認自己想錯了。」
這可能比保存答案更重要。
那些曾經救過公司的判斷，不必因此獲得永久通行證。新產品、新材料與新的使用條件一旦出現，原有規則就應重新接受檢查；必要時，它得降權，甚至退出。
如果AI有一天能把一家公司幾十年的經驗濃縮得比任何人都完整，我們要怎麼確保它繼承的不是昨天最成功的答案，而是昨天仍然願意被今天推翻的能力？