我反覆思考的一點：每個工程團隊都有其「公車因子」，不論他們是否承認。 當關鍵知識僅存於少數人腦中，而非記錄在任何地方時，整個系統就會變得越脆弱。而暴露這個問題的，從來不是重大災難，而是那些微小的細節：有人去度假、生病了，或連續開會，結果一個兩分鐘的問題突然變成阻礙兩天的瓶頸。 這個服務為何這樣建構？在修改這個 API 之前，究竟哪些部分依賴它？這個問題是否早在八個月前就由已離開團隊的人解決過？ 這些答案不該需要去追蹤「唯一知道的人」。但在大多數團隊中，這正是實際運作的方式。 這正是 @CNPYNetwork 和 https://t.co/ZZmN9Y6mOV 讓我感到特別的原因：有趣的機會不僅在於打造更聰明的程式撰寫助手，更在於讓團隊中的任何人隨時隨地都能取得這種組織知識，而不是讓它只存在於某個人的記憶中，隨其離去而消失。 最強大的團隊，並非擁有最出色個人記憶力的團隊，而是那些打造了能為他們記憶的系統的團隊。