知識集中很少是團隊一開始刻意設計的結果。趕進度、修問題與補需求時，最複雜、最急迫、最容易出錯的工作，常會交到最熟悉系統的人手上。
這樣安排在短期內相當合理，因為熟悉的人能快速判斷、直接處理，也能在問題發生時立即補上缺口。
幾次類似安排之後，系統背景、設計原因、例外規則、部署細節與客戶習慣，就會隨著處理經驗留在少數人手中。其他成員看得到最後結果，卻未必清楚過程中做過哪些判斷。
由單一成員負責關鍵領域，初期確實能提高處理效率。某個模組出問題時，大家知道該找誰。某段程式需要修改時，也知道誰最清楚影響範圍。主管安排工作也更直覺，因為責任邊界看起來很清楚。
這樣的分工會讓依賴固定下來。需求進來時，工作直接交給最熟悉的人。事故發生時，也由同一位成員排查。新成員想理解系統時，第一個建議多半也是去詢問他。最後，這個人便成為該領域唯一的入口。
單人負責會讓知識傳遞停留在被動狀態。其他成員多半要等到需要支援、接手或排查問題時，才會接觸這個領域。工作進行順利時，不會想到要將判斷準則整理出來，也不會將相關經驗轉成文件、測試或設計紀錄。
知識傳遞需要投入時間。要讓另一個人理解系統，需要一起閱讀需求、程式與測試，也要說清楚當初採用這項設計的原因。
這些活動需要在日常工作中保留時間，因此交付壓力長期偏高時，知識傳遞就會不斷地被延後。
某個領域只有一個人熟悉，大家心裡可能都知道，卻一直找不到時間改善。這次先讓他處理，下一次再安排交接。這次先請他救火，後續再補文件。這次先趕上線，之後再安排分享。類似決定重複幾次，知識傳遞便會成為一直排不進去的工作。
交付壓力也會影響效率判斷。結對編程（Pair Programming）、共同設計、文件更新與程式碼導讀，都需要投入眼前的工作時間。期限接近時，任務常會直接交給最熟悉的人完成。當次任務順利結束，其他成員的接手能力仍停留在原處。
知識要在需求討論、設計、開發與事故處理中被更多人看見，光靠個人主動分享並不穩定。把知識分享納入工作流程後，重要資訊才會在日常工作中被整理與接手。缺少這些機制時，知識集中便會成為默認的運作方式。
例如，重要設計沒有留下架構決策紀錄（Architecture Decision Records, ADR），後來接手的人只知道目前採用的做法，卻不清楚當時的考量與限制。程式碼審查（Code Review）若只檢查格式與錯誤，沒有討論設計意圖，審查也很難建立共同理解。文件沒有隨著需求與程式變更一起更新，相關知識便會繼續留在人腦裡。
知識分散需要刻意安排。關鍵模組可以輪流交由不同成員修改，重要事故也應讓其他成員共同參與排查。這些安排需要投入額外時間，能降低後續等待、工作接手與緊急救火的風險。
缺少知識分享機制時，每次遇到問題都會走回相同路徑：「找最熟悉的人、請他快速處理，再等他有空說明」。這條路走得越久，其他成員越難進入這個領域，關鍵人物也越難離開。知識孤島會在這個循環中被固定下來，英雄文化也會跟著形成。
知識孤島形成後，對特定成員的依賴會影響工作方式。原本只是某個人熟悉一部分系統，後來會變成重要問題都要經過他。需求修改前要先問他，事故發生時要先找他，上線前也要等他確認。這種依賴一開始來自信任，後來便會形成單點風險。
英雄文化也會在一次次救火中被強化。麻煩出現時，都由固定人選把問題處理掉，大家便會越來越相信這個人不可或缺。被依賴的人也會承受更高壓力，因為他知道自己沒有介入，事情很可能停在原地。
當某個人掌握關鍵知識，問題便會自然集中到他身上。這種做法一開始很省事，因為大家知道找誰最快。問題很快被接住，其他人也少了一次重新理解系統的機會。久而久之，其他成員會更少接觸那個領域。
每次問題都有固定的答案來源，大家不需要自行查找背景，也不需要完整理解設計原因。
新成員加入時，也可能直接被告知「這一塊問某某就好」。這句話看似只是提供方向，也在暗示這個領域的知識尚未進入團隊共同範圍。
長期由固定人選接住問題，會讓工作入口變得狹窄。即使團隊成員眾多，能做出判斷的人仍然很少。當關鍵人物正在開會、休假或處理其他緊急工作時，問題便會開始排隊。表面上人力充足，許多決策仍卡在同一個人身上。
救火帶來的回饋很直接。系統壞了，有人半夜修好。客戶卡住，有人立刻找出資料問題。上線失敗，有人知道該調整哪個設定。
這些場景會把焦點放在個人能力上，並將穩定交付寄託在少數人的反應速度。
被稱為英雄的人，多半沒有刻意讓旁人依賴自己。他可能責任感較強，也可能長期處理大量問題，因此比其他人更熟悉系統脈絡。每當他出手解決一次狀況，大家便更相信下一次也能交給他處理。一次次成功救火，也讓這項工作成為默認的角色責任。
英雄經常也是機制的受害者。當關鍵知識、事故判斷、部署經驗與客戶規則集中在個人身上，他很難真正下班，也無法放心休假。手機通知一響，其他人便期待他立即回應。系統發生問題時，他也會認為自己必須介入。長期承受這種壓力，可能造成高度倦怠（Burnout）。
這份壓力也可能讓英雄產生內在拉扯。他知道知識分享、交接、文件與接手機制都需要補上，也可能擔心所有人都能處理後，自己的價值會受到影響。「害怕失去不可替代性」未必會被說出口，仍可能讓人無意識地保留資訊、延後交接，或習慣將關鍵問題重新接回自己手上。
當救火受到獎勵，預防性工作便會被排到後面。補文件、改善監控、整理測試、分散權限與安排交接，都缺少救火當下的可見成果。若只稱讚誰化解了危機，沒有追查危機反覆發生的原因，系統問題便會被美化成個人表現，英雄也會繼續承受不健康的期待。
在 AI 時代，英雄角色也可能被重新包裝成「最會使用 AI 的人」。他能迅速問出解法、產生修正方案，看起來掌握了新的生產力。提示詞（Prompt）、判斷方式、驗證流程與系統背景若沒有被整理出來，英雄文化仍會延續，只是換了一套工具。
英雄文化最大的風險，是讓人誤以為系統仍在穩定運作。只要有人能及時解決問題，管理者就可能認為狀況仍在控制範圍內。
從交付能力來看，檢查重點會落在兩件事：問題為何只有少數人能處理，以及缺少這些成員時，日常運作能否繼續維持。
英雄文化進入日常工作後，許多脆弱點會暫時被掩蓋。文件過期時，團隊可以直接詢問熟悉的人。測試不足時，有人記得哪些地方需要手動驗證。部署流程不清楚時，也有人會補上未被記錄的特殊步驟。這些問題短期內未必立即造成事故，團隊對個人記憶與經驗的依賴卻會不斷加深。
這種文化也會限制團隊學習。其他成員缺少接觸關鍵問題的機會，很難從處理過程中建立判斷能力。
新人也會接收到一個錯誤訊號：遇到重要問題時，只要找到熟悉的人就能處理，不需要完整理解系統。久了之後，工作模式會變成少數人支撐主幹，其他成員只能負責周邊與低風險工作。
英雄文化讓團隊依賴少數可靠成員處理難題，也讓交付穩定性受到個人時間與狀態影響。
穩定交付需要可預期的流程、可接手的知識，以及多人都能參與判斷的工作方式。當關鍵問題集中在少數人身上，整條交付流程就會受到個人時間與工作狀態影響。
只要關鍵人物仍在，許多問題都能被暫時壓住，這種表面穩定會延後風險被看見的時間。等到關鍵人物休假、離職、轉調，或同時被多項工作卡住時，交付能力的缺口就會快速浮現。
英雄文化也會讓決策入口變窄。當某個功能、模組或客戶流程只有少數人熟悉，需求評估、技術設計與上線判斷都需要等待這些人確認。即使其他成員有時間，也很難直接往下推進，因為他們缺少足夠背景來承擔判斷責任。
這類等待不一定會直接出現在任務狀態回報上。狀態可能仍停在開發中、確認中或待測試，實際卡住的原因卻是「等待某人回覆」。
若同一個人負責多個關鍵領域，他的行程就會成為隱性排程。需求能否拆解、拉取請求（Pull Request, PR）能否合併、事故能否結案，都取決於他何時有空。
等待也會提高重新理解上下文的成本。問題擱置幾天後，原有的討論脈絡會開始散失。等關鍵人物終於有時間時，大家還需要重新說明背景、補充現況，並確認前面做過哪些嘗試。
這些時間看似只是溝通成本，最後會變成需求、開發與上線之間的空轉。
英雄文化會減少其他成員練習判斷的機會。每次遇到複雜問題，都由最熟悉系統的人處理，旁人只能看到最後結果。
久了之後，他們可能知道問題最後如何解決，卻不清楚過程中如何判斷、排除了哪些線索，以及評估過哪些風險。
學習需要直接接觸真實問題。新人若長期只負責低風險任務，很難理解系統中較深層的規則。中階成員若缺少參與設計取捨的機會，也很難建立獨立判斷的能力。團隊表面上人力充足，真正能處理高風險問題的卻只有少數幾個人。
當需求增加、系統擴大、問題變得複雜時，少數成員很難承接所有判斷工作。關鍵領域若沒有其他人可以協助，工作量增加後便會開始排隊。排隊又會促使大家依賴關鍵成員快速處理，學習空間也再次被壓縮。
英雄文化最直接的風險，會在關鍵人物離開工作現場時浮現。請假幾天、臨時生病、轉往其他專案，甚至同時被多場會議占滿，都可能讓原本順利進行的工作突然停住。
交付流程若依賴個人記憶，人員無法參與時，工作也會失去推進動力。
離職帶來的影響會直接出現在交接現場。交接期間才發現文件不完整、部署步驟不清楚、例外規則沒有人掌握，測試資料的建立方式也沒有留下紀錄，這類狀況並不少見。
接手的人只能從過往的拉取請求、零散訊息與程式碼中推測。這種接手方式會拉長理解時間，也會提高後續修改錯誤的風險。
請假與離職會讓管理者看見一項事實：團隊過去維持的穩定，有一部分來自個人記憶與責任感。
這種穩定缺少足夠支撐，相關知識尚未轉成文件、測試、流程、共同設計與多人能力。當關鍵人物不在時，原先被壓住的問題便會集中浮現。
巴士係數（Bus Factor）用來觀察團隊失去多少關鍵成員後，系統或專案便無法正常維持。這裡的「失去」不只代表離職，也包含請假、轉調、長期支援其他專案，或臨時無法參與工作。
若某個服務只有一個人能部署、某個模組只有一個人能修改，或某段事故處理流程只有一個人熟悉，這些區域的巴士係數就偏低。
可以先用簡單方式盤點關鍵領域。列出核心模組、部署流程、重要客戶規則、資料修復流程，以及金流、權限等高風險區域，再標記每個區域有幾個人能獨立判斷、幾個人能協助修改，以及幾個人只能依照指令操作。
某個區域若長期只有一個人能獨立處理，就代表知識集中程度過高，需要優先改善。
巴士係數的目標不需要設定成每個人都熟悉所有事情。每個關鍵區域至少應有兩到三個人理解主要流程、風險位置與接手方式。當某些區域的巴士係數偏低，團隊可以安排輪流維護、結對修改與共同事故演練，並要求重要變更留下架構決策紀錄（Architecture Decision Records, ADR）與操作文件。
平均恢復時間（Mean Time to Restore, MTTR）用來觀察事故發生後，需要多久才能恢復服務或完成修正。
除了檢視整體數字，還可以比較某位關鍵成員參與時，修復時間是否大幅縮短，以及他未能參與時，修復時間是否拉長。
這項差異可以反映對特定成員的依賴程度。假設同類型事故由某位資深開發者參與時，平均 30 分鐘就能定位問題。他未參與時，其他人需要 3 小時才能找到原因。這項結果除了顯示該開發者具備豐富經驗，也代表排查知識、監控判讀方式、系統脈絡與修復步驟尚未被共同掌握。
事故復盤時可以記錄幾項資訊，包括參與排查的人員、找到原因所需的時間、恢復服務所需的時間、排查過程使用的文件、只能透過口頭詢問取得的資訊，以及只有特定成員熟悉的步驟。累積多次紀錄後，修復能力是否集中在少數人身上就會比較清楚。
這項指標也能協助決定改善順序。當平均恢復時間高度依賴特定成員參與，可以優先補強事故處理手冊、監控指標說明、常見故障診斷流程與修復演練。
AI 可以協助整理事故紀錄、歸納處理步驟與產生排查清單，後續仍需透過演練確認其他成員能否依照這些內容完成判斷與修復，讓事故處理能力真正轉移到多人身上。
拉取請求（Pull Request, PR）的等待時間，也能反映知識是否集中。
若大量拉取請求都必須等待同一位審查者，代表部分領域的判斷入口過於集中。開發完成到合併之間會形成排隊，關鍵成員的行程也會直接影響交付節奏。
可以觀察幾項數據，包括特定審查者負責的拉取請求比例、拉取請求首次回應時間、同一審查者名下待審查拉取請求的平均停留時間，以及高風險模組是否長期由固定人員批准。
若超過 60% 的關鍵拉取請求都集中在一到兩位審查者身上，就需要進一步確認這項分工是否合理，或是知識尚未擴散而形成審查瓶頸。
排隊集中在特定審查者身上時，審查品質也可能受到影響。審查者同時面對大量變更時，只能先處理最急迫的項目，其餘變更便會繼續等待。
等待時間拉長後，開發者需要重新建立上下文，合併衝突與返工風險也會提高。審查者長期承受高負荷，也可能出現審查疲勞，降低對需求偏差、架構風險與隱藏副作用的敏感度。
共同審查規則可以讓更多成員承接低風險變更，高風險變更則採用雙人審查，並安排熟悉關鍵模組的人員帶領其他成員共同參與。
AI 預先審查也能先處理格式、測試、安全掃描與變更摘要，讓人類審查者把注意力放在業務規則、架構邊界與風險判斷上。
結對工作可以讓知識在做事的過程中被看見。兩個人一起看需求、拆解問題、修改程式、檢查測試，接手的人會看到完整判斷過程。
許多細節是在處理問題時才會浮現，例如哪些欄位不能改、哪些資料狀態很危險、哪些測試失敗代表真正風險。
共同設計也能降低關鍵知識集中。需求進入開發前，可以安排短時間設計討論，讓熟悉系統的人把背景講出來，也讓其他人一起確認影響範圍。這個過程不需要開很長的會，重點是把原本留在個人腦中的判斷搬到大家面前。
AI 也可以放進結對流程中。開發者一起看 AI 產生的方案，討論哪些地方符合系統現況，哪些地方需要調整。這樣 AI 產出就會變成共同討論素材，避免成為某個人私下完成工作的捷徑。討論過程也能讓提示詞怎麼寫、結果怎麼驗證、風險怎麼判斷被更多人看見。
當結對與共同設計變成日常安排，知識就不會只靠人情請教流動。關鍵成員仍然能發揮經驗，新人和其他成員也能在實際工作中慢慢接近關鍵區域。能處理高風險問題的人變多後，對單一人物的依賴也會降低。
口頭說明很方便，卻很快會消失。一次會議、一段聊天室對話、一個臨時提醒，都能解決眼前問題，後續接手的人卻不一定找得到。
知識共享要進入日常流程，文件就需要補上口頭傳承留下的缺口。
文件不需要寫成厚重手冊。適合長期維護的內容，多半是那些會反覆被問、反覆被改、反覆出錯的資訊。
例如系統邊界、重要流程、部署步驟、資料規則、常見事故處理方式，以及架構決策紀錄。這些內容只要能讓下一個人少問一次、少猜一次，就已經有價值。
AI 時代下，提示詞（Prompt）也應該成為共同知識的一部分。可以建立內部提示詞知識庫保存常用的需求拆解、測試生成、事故分析、程式審查、重構輔助等指令。每一份提示詞除了記錄指令內容，也要記錄適用情境、限制條件、需要搭配的文件，以及使用後要檢查哪些結果。
重要提示詞可以進入共同審查。若某個提示詞會用來生成高風險程式、測試案例、資料修復腳本或部署操作，可以像審查程式碼一樣檢查它。
審查重點包含輸入資料是否安全、限制條件是否清楚、是否引用正確文件、是否要求 AI 說明假設，以及輸出結果要經過哪些驗證。提示詞共同審查能避免少數人的 AI 使用方式變成新的知識孤島。
文件也要跟工作連在一起。需求改變時，更新規則說明。架構決策完成時，補一份簡短的架構決策紀錄。事故結束後，把排查線索與修正方式放回知識庫。AI 對話中出現重要判斷時，把結論整理到團隊看得到的地方。
知識共享能不能長期維持，最後會回到責任怎麼被看待。
若某個模組被視為特定成員的責任，其他人便容易停在旁邊等待。當系統被視為團隊共同交付的成果，成員會更願意參與理解、補充文件與進行程式碼審查（Code Review），事故發生後也會一起整理處理經驗。
共同當責的合理期待，是關鍵領域至少有多人能理解主要流程、風險位置和接手方式。
有人更熟悉特定領域很正常，重要判斷仍要避免集中在同一個人身上。這需要在工作分配、審查安排和學習節奏中刻意設計。
管理者也要建立當責文化的環境。若績效只看個人產出量、完成任務數或救火次數，英雄角色就很難改變。團隊成員會認為快速解掉問題才容易被看見，教會別人、補齊文件與降低依賴反而像額外工作。
考核標準需要把賦能他人（Enablement）與降低單點依賴納入開發者的表現判斷。像是帶新人接手關鍵模組、讓第二個人能獨立處理事故、建立可重用提示詞、補上架構決策紀錄、改善操作文件、擴大審查者範圍，這些都應該被視為工程貢獻。它們未必會立刻增加功能數量，卻會提高後續交付的穩定度。
對資深開發者來說，分享知識能打開新的發展空間，可替代性其實是代表他的能力已經從個人效率擴展成為團隊能力。當他的知識能被其他人接手，他才有空間處理更大的設計問題、培養新人、參與跨團隊改善，或轉去嘗試更有價值的新專案。
當知識能在工作中被多人看見、理解與維護，知識孤島就會慢慢被拆開，英雄文化也會失去生長空間。
iThome鐵人賽
看影片追技術