企業知識庫．系列講座 - 第02集 研發工程部 把設計決策與離職經驗留下來

企業知識庫．系列講座 - 第01集 認識智庫引擎 導入前提 公司痛點與基礎設定

企業知識庫．系列講座 - 第02集_研發工程部-把設計決策與離職經驗留下來

企業知識庫．系列講座 - 第03集_採購部-找回議價依據與供應商經驗

企業知識庫．系列講座 - 第04集_製造_品保與設備維修-縮短停線時間

企業知識庫．系列講座 - 第05集_客服_業務與人資-現場回答_客訴複用與新人訓練

企業知識庫．系列講座 - 第06集_跨部門失敗模式與系統能力邊界

企業知識庫．系列講座 - 第07集_未來整合_導入順序與第一個月里程碑

這裡是智庫引擎，專為企業設計的知識庫。上一集我們把骨架蓋好了，這一集進第一個部門，研發工程部。畫面上這六個字是本集的主軸：留下決策，帶走經驗。請注意這兩件事的差別。人走了，經驗當然跟著走，這個攔不住。但當年為什麼做那個決定，這件事應該留在公司裡。上面那行小標寫得很精準：這是針對多型號、高複雜度的研發環境所寫的落地指南。型號越多、改版越勤的公司，這一集對您越有用。右邊那張工程圖上，三個橘點各拉出一條線。等一下您會看到，研發部真正的資產，就藏在那種「為什麼標在這個位置」的線上。

我們從一個真實會發生的場景開始。左邊這張卡片是專案交接簡報。時間，二〇二六年四月八號。負責人，機構工程師李孟璇。任務是接手 E P S 五千的日本客戶客製案，客戶要求散熱片減薄一點五毫米。聽起來只是一個小小的尺寸調整。但請看左下角那個橘色的警示：當年做出 E P S 三千設計決策的資深工程師陳志偉，上個月離職了。於是右邊出現三個問號。第一，當年為什麼把厚度定在這個值？第二，以前有沒有人試過更薄的方案，結果如何？第三，如果現在改薄，會牽動哪些零件跟哪些圖面？這三題，每一題的答案都曾經存在。它們就在某一場會議裡、某一份簡報裡，或者只在某一個人的腦子裡。而現在，那個人已經不在了。 那接下來會發生什麼事？畫面左右兩邊，是兩條路。先看左邊，傳統作法。第一步，翻共用硬碟，花掉一點五天，結果只找到四個檔名很像的舊版本。第二步，去問五位同事，前後分散兩天，得到的是模糊的記憶。第三步，走投無路，決定重做一次熱測試。兩週，八到十二萬。右邊那條路只有一句話：完整的脈絡跟精準的數據，三分鐘。但真正要請您看的，是最底下那條橘色的警語。最貴的代價，不是那兩個星期。假設當年把厚度定在那個值，根本不是為了散熱，而是為了通過客戶的安規認證——那麼重做熱測試，永遠測不出這件事。測試會漂亮地通過，產品會順利出貨，然後在客戶端的認證階段被整批退回來。知識沒留下來，最可怕的不是慢，是您會很有效率地走向一個錯的答案。 為什麼會這樣？答案在這張天秤上。左邊這一盤，是規範本文，回答的是「規定是什麼」。右邊這一盤是設計審查的錄音，回答的是「為什麼」。您看得出來，天秤是往右邊沉的。中間那句話，請您記下來：系統只能回答規定是什麼，答不出為什麼。而為什麼，才是資深工程師帶走的真正資產。所以下面兩個框，就是這一集最重要的分岔。左邊，失敗的導入：只把規範本文丟進去。文件是齊了，但脈絡沒了。系統會告訴您厚度是多少，卻永遠說不出為什麼是這個數字。右邊，成功的導入：把會議紀錄跟決策過程一起匯進去。那才是把離職的經驗留下來。很多公司導入失敗，不是系統不行，是只餵了左邊那一盤。 那到底該放什麼進去？畫面左邊是該放的，右邊是絕對不能放的。先看左邊，第一項用橘框框起來，叫黃金素材：近三年的設計審查、審圖會議錄音。它是「為什麼」的唯一來源。如果這一集您只做一件事，就做這件——把會議錄音找出來。第二項，必備追蹤：現行版加前一版的規範、工程變更單連同它的影響範圍，還有異常分析報告。為什麼要留前一版？因為新舊一比，才知道改了什麼。第三項，特殊處理：關鍵尺寸的圖面，人工加註解、截圖放進去。右邊三項，一項都不能碰。第一，設計圖的原始檔。系統讀不懂它，放進去只是佔空間。第二，未定案的草稿。這一項最危險——它會污染決策的依據，比沒有更糟。第三，商務報價的附件。那是採購跟業務的地盤，混進來會直接引發權限災難。 素材選好了，接著是設定。這一頁有四個框，右邊那個橘色的最重要。左上，權限與分類。團隊設定成研發工程跟品保共享。理由是驗收的標準要一致——研發說合格，品保也要照同一份依據判。分類架構只用三個：設計規範、審查決議、異常與矯正。左下，提示詞。自訂一組專門用來解讀機構圖標註的規則，強制它把尺寸跟公差整整齊齊列出來，而且判讀不確定的地方要自己講出來。它可以不確定，但不可以裝作確定。右邊這個致命警告，請您一定要看。研發資料套的是嚴格遮罩，就是把不相關的內容蓋掉。但這裡一定要多寫一句話：不要蓋掉型號、尺寸、公差、電氣參數。漏了這一句，系統會把最關鍵的那幾個數字蓋掉。剩下的工程資料，會完全失去價值。 匯入的時候，三條線同時跑。最上面一條，規範跟工程變更單，走文件轉文字。中間一條，審圖會議的錄音錄影，走影音轉逐字稿。這條線最花時間，但它產出的就是剛剛說的黃金素材。最下面一條，圖面標註的截圖，走圖片解讀，套用剛剛設好的那組提示詞。三條線的終點是同一個地方，右邊那個工程知識盒。最底下那行叫最佳實踐，但講白一點是血淚教訓：匯入的當下，就要同步貼上團隊跟分類的標籤。不要想著「先全部倒進去，之後再慢慢補」。三千份文件事後一筆一筆補標籤，那個工作量會壓垮負責的人，而且一定補不完。 倒進去之後，還有一條品質防線，畫面上這條由左往右的流程。第一站，清洗。信心度太低的內容不會直接放行，會被丟進待審核。第二站，就是中間那個橘色的大方塊，人工閘門。上面寫著絕對紅線：第一批資料必須人工審閱。我知道這一步很煩。但它是防止垃圾進、垃圾出的唯一一道防線。第一批您放水，之後每一個錯的答案都會有出處、看起來都很可信，那時候要抓就來不及了。第三站，簡報上寫的是蒸餾與正規化。白話講，就是把內容再整理成一頁一個主題的知識卡，順手把標題的寫法統一，讓卡片跟卡片之間的連結不會斷掉。最後一站，整理成可以被查詢的樣子。右下角那句警語很直接：這一步沒做，之後不管問什麼，系統都只會回您「查無依據」。 做完之後，回到第二頁那三個問號。畫面最上面是李孟璇打進去的問題：E P S 三千的散熱片厚度是怎麼定的？試過更薄嗎？下面是系統的回答。第一句，厚度定為多少，數值直接給出來。第二句才是重點：曾經評估過減薄一點五毫米，但在二〇二三年十月的設計審查上，因為特定安規要求的散熱面積而被否決。您看，這正是我們一開始擔心的那件事。原因不是散熱不夠，是安規。重做熱測試永遠測不到它。第三句，如果要變更這個厚度，會牽動零件 A、零件 B，以及相關的工程變更影響範圍。最下面兩個小方塊是出處：來源一，會議逐字稿的第八分二十四秒；來源二，設計規範 Rev B 版。有出處，李孟璇才敢拿這個答案去跟客戶談。底下那行總結：兩週加十二萬的重測，換成三分鐘。 再來是老實話時間。畫面上三欄，是這套系統的邊界。第一欄，可以繞過去的。它讀不懂設計圖檔，也量不出圖面上的尺寸。對策是人工把關鍵尺寸做成標註截圖，改走圖片那條線。另外，工程變更的影響清單有時候不完整，系統可以順著關聯往外找一到三層，但找得完不完整，取決於當初那張變更單填得好不好。第二欄，還要開發的。目前分類多選的時候沒辦法取交集，還有文字區塊還不會自動帶上章節標題。這兩項已經排在開發順序裡了。第三欄最重要，本質上就不該做的。尺寸鏈計算、公差疊加分析——那是專業計算軟體的領域，不該交給語言模型。它算得出一個看起來很像的答案，而那正是危險的地方。自動審核新圖面合不合規，也一樣。那是未來的想像，現在沒有實作。一套系統肯講清楚自己不做什麼，您才敢把它放進研發流程。 最後，怎麼算驗收通過？畫面上三個數字。第一個，越權洩漏，零。這是唯一不能妥協的一條，不是「盡量」，是零。第二個，該找到的資料有沒有找到，要在八成以上。第三個，附上的出處對不對，要在七成以上，而且章節必須精準對應。下面這個測試最有意思。刻意出三到五題「公司裡根本沒有答案」的考題丟給它。通過的標準是：系統必須老實回一句「查無相關依據」。只要它硬掰一題，就是不通過。最後請留下二十題基準考題。以後每次系統改版，拿同一份考卷再考一次，就知道是變好還是變壞了。下一集，我們去採購部，看看那些埋在前任信箱裡的議價依據，該怎麼找回來。