在許多的組織，溝通與協作都是生產力瓶頸之一，而在軟體開發的領域，溝通與協作的特殊挑戰在於「內隱知識」。

曾經有一回，我與一位工程師 A 一同 pair programming ，我們需要做的第一件事，是安裝一個 command line 程式在我的電腦裡。很不巧的，A 用的作業系統是 Linux ，所以他告訴我的 config 檔位置在我的電腦不起作用，因為我用的電腦是 macOS。

就在我正在困擾該上哪尋文件時，A 則不急不徐地指導我下 Dtrace 指令，透過 Dtrace 來監看 command line 程式，它啟動時所調用的 system call ，然後再 grep 一下，就找出 macOS 上對應的 config 檔。

像上頭的例子這樣不查閱文件，反而依賴對系統的透徹瞭解進而抄捷徑解決問題的知識，這就是典型的內隱知識。

內隱知識的轉移困難，可以說是軟體業長久以來的挑戰之一。此一挑戰不只發生在組織之內，可以說是整個產業都受到這個困難的影響。軟體業週期性地發生大規模的「重造輪子」現象，這往往是技術環境根本性變革（例如從地端部署轉向雲原生、或新的程式語言範式出現）所驅動的必要轉型。然而，這種轉型之所以成本高昂、風險難控，關鍵在於前人內隱知識的難以繼承。當一個新專案啟動時，它極少能獲得前一個世代系統的完整內隱知識，導致團隊必須在遇到重大困難或系統失敗時，才倉促回頭研究舊系統的足跡。內隱知識的斷層，使得本已複雜的技術遷移，變成了從零開始摸索的艱難挑戰。

應對之道

內隱知識的轉移困難，大致上有兩個方向來處理：

1. 設計組織流程與溝通方式，讓內隱知識會在組織日常的運作過程之中，逐步地顯式化。
2. 設計組織架構，讓不同的團隊專注不同的任務，因而減少內隱知識傳遞的需求。

流程

以軟體專案的工作交接為例，這就很需要流程來輔助。一套好的流程，可以有效地協助，接手工作的人，儘快地踩過所有的坑，確保內隱知識可以被移轉。

一套簡易的專案交接流程可以是：

1. 確保新手可以在本機端將專案設置起來。
2. 確保新手在本機端做基本的測試。
3. 確保新手知道如何布署專案。
4. 確保新手知道如何在生產環境中除錯。

若標準的流程要求上述的事必須一一執行並且記錄，交接過程就可以迴避許多舊的坑、或是提早發現新的坑，因為減少日後的風險。

在軟體，常常發生的事情是，軟體與和文件都沒有任何改變，但是建置會失敗、布署也會失敗，那是因為某些依賴的版本已經更新、又或是某些布署用的作業系統已經產品壽命結束。遇到這些坑時，原專案開發者的內隱知識就會立刻派上用場。

文件 (溝通方式)

除了流程之外，將內隱知識顯式化最直接的方式就是撰寫文件。然而，文件撰寫常常語焉不詳，其原因就在於沒有意識到，文件所要傳達的知識，是為了滿足不同情境的需求。

Diátaxis 是一種系統化的文件撰寫方法，它將文件的類型，根據讀者的需求，分成四種：

• 起步教學（Tutorials）：這類文件旨在引導讀者從零開始，逐步完成一個具體的、有意義的專案或任務。它回答的是「如何開始？」的問題。

• 操作手冊（How-to guides）：當讀者已經知道自己想達成什麼目標，但不知道具體的操作步驟時，這類文件就派上用場。它回答的是「我如何解決某個特定問題？」的問題。

• 技術參考（Technical reference）：這類文件就像是一本字典或百科全書，詳盡地記錄了所有函式、類別、介面、指令或配置選項。它回答的是「這是什麼？」的問題。

• 解釋（Explanation）：這類文件旨在提供宏觀的背景知識與理解，回答的是「為什麼？」的問題。

藉由區分這四種文件類型，我們可以確保每一份文件都能針對特定讀者、特定情境，提供最有效的資訊。如此一來，文件將不再是孤立的知識碎片，而是成為一個有系統、能協助團隊持續成長的知識庫。

RAG-based 知識庫

除了手動撰寫文件，現代 AI 工具的興起，為內隱知識的顯式化提供了強大的技術途徑。傳統上，非正式的文件很容易散落各處、容易過時，但 RAG (Retrieval-Augmented Generation) 知識庫工具改變了這一現狀。

這些工具（例如 Google NotebookLM）的價值在於，它允許開發團隊將所有非結構化的知識碎片——包括會議逐字稿、舊版程式碼、設計文件、甚至 Slack 聊天紀錄——全部匯入，建立一個專屬於專案的知識索引。

這讓內隱知識的轉移從「人類搜尋與歸納」轉為「AI 快速檢索與提煉」：

• 跨文件問答： 新手工程師不再需要大海撈針地尋找文件，可以直接問 AI：「專案中 UserAuth 模組的設計初衷是什麼？」AI 會從所有來源中精確引用程式碼註釋、設計文件或歷史討論，回答這個「為什麼」的問題。

• 程式碼與知識的驗證： RAG 工具不僅能整理非正式討論，它更能將這些非正式的知識（例如某個設計決策）與最新的程式碼狀態進行比對，指出語義上可能存在的矛盾或過時的描述，確保口頭上的理論與實際運作保持一致性。

藉由 RAG-based 知識庫，團隊能夠在不中斷日常開發的情況下，將原本散落在開發者心智中、未曾寫下的「理論」，有效地轉化為可查詢、可驗證的顯式知識，從而大大降低內隱知識的轉移成本和風險。

組織架構

考慮到「不確定性」的挑戰， Basecamp 提出了一種產品開發方法論 ShapeUp ：一組人負責「塑造未來的專案」；另一組人則負責在六週週期內「建構專案」。我們也可以看成，善長處理不確定性挑戰的團隊是塑造團隊；而以六週為週期內工作的則是循環團隊。

考慮到「複雜性」的挑戰，Team Topology 主張將團隊分成 Steam-aligned Team 和 Platform Team 。 Stream-aligned Team 專注於單一、有價值的業務流程或產品，他們是離客戶最近的團隊，負責從頭到尾提供價值。而 Platform Team 則負責提供內部平台服務（例如，基礎設施、部署工具、監控系統等），以 「即服務」（as-a-Service） 的方式，讓 Stream-aligned Team 能夠自助式地使用。這種分工的核心目的是減少 Stream-aligned Team 的認知負荷。透過將複雜的底層技術細節交由專業的 Platform Team 處理，Stream-aligned Team 得以更專注於業務邏輯和快速交付客戶價值，進而應對軟體系統日趨複雜的挑戰。

考慮到「修改傳播」的挑戰，許多團隊會有架構師的角色，他們負責在專案的早期做種種的規畫或是技術選型，讓日後即使發生了修改傳播的現象，還是容易修正或是緩解。

透過專業分工，可以有效地減少內隱知識傳遞的需求，進而抵達管理學所謂的「讓平凡人做不平凡的事」的境界。

相關理論

Peter Naur 在 1985 年發表的著名文章 Programming as Theory Building（程式設計即理論建構）。核心論點是：一個成功的軟體系統，其主要資產並不是程式碼或文件等實體產物，而是存在於開發團隊心中的一套理論（Theory）。

理論的本質：軟體開發的內隱知識

Naur 所說的「理論」並非科學定律，而是指開發團隊對以下兩方面的完整心智理解 (Mental Grasp)：

1. 程式碼運作的原理： 程式的各個部分是如何被設計、如何相互作用，以及它在執行時如何與機器互動。

2. 程式與其環境的關係： 程式碼如何反映現實世界的需求和約束，以及環境中的哪些變化可能要求程式碼進行調整。

這個「理論」就是 Naur 所指的軟體開發的內隱知識。它無法被完全寫進文件或程式碼註釋中，只能透過經驗、對話和親身實踐來獲得和維護。

也因此，Naur 的論點為本文中提到的「流程」和「文件」策略提供了哲學基礎：這些措施的真正目的，就是最大程度地將團隊的共享理論顯式化、結構化，並確保其能夠持續地在團隊成員之間重新建構、檢視和轉移。

小結

即便軟體工程師群體具備高於平均的語言與思考能力，溝通與協作上的難題卻始終揮之不去。這是因為軟體系統的真正核心資產，如 Peter Naur 所言，並非程式碼或文件本身，而是存在於開發者心智中的理論──也就是難以言喻的內隱知識。

內隱知識的傳遞，遠比表面上的文件交換複雜。正因其難以顯式化，它成了軟體開發中影響生產力的主要瓶頸與風險來源。因此，我們必須從多個維度著手：透過流程來標準化知識軌跡、藉由系統化文件或是 RAG 工具來共同結構化知識、並利用組織架構來減少認知負荷與內隱知識傳遞的需求，以有效管理這個無形的挑戰。

工商時間

恭喜你讀完了 30 day 的內容，覺得如何？對你有用嗎？

我有開「進階軟體開發」的一對一課程，教材就是本系列文。課程廣告連結