技能衰退比技能缺乏更危險

維護的成本被低估了

我在想一個問題：為什麼有些團隊的技術棧看起來很完整，但執行品質反而不穩定？後來發現，他們通常犯了同一個錯誤——把「擁有」和「維持」混為一談。

Vincent Chan 在 Threads 上提到的一個觀點戳中了我的想法：skills 維護的核心在於對抗漂移，而非增加數量。

這句話乍看簡單，但拆開來很扎手。它說的不是「你要學新東西」，而是「你已經會的東西，正在以你沒注意到的速度變鈍」。

漂移發生在哪裡

一個開發者六個月沒寫 Go，再回頭時會發現什麼？不是忘了基礎語法——那些會回來。問題出在更細微的地方：

• 對新版本的最佳實踐不熟悉
• 生態圈的工具鏈更新了，但你還在用舊的心智模型
• 團隊內部對某個模式的理解已經演進，但你還停在上次動手時的認知
• 性能瓶頸的位置移動了，但你的直覺沒跟著調整

這不是遺忘，這是上下文漂移。你的知識沒有消失，但它變成了孤島——和當前的系統、工具、團隊認知脫節了。

為什麼數量陷阱這麼誘人

「我們需要更多人懂 Kubernetes」、「我們要學 LLM」、「我們應該掌握 Rust」——這些聲音很容易贏得討論。它們給人一種在進步的感覺。

但現實是：如果你的團隊連已有的技能都在漂移，新增技能只會加速整體的熵增。你會變成一個什麼都會一點、什麼都靠不住的組織。

我後來決定用另一個指標來衡量技術健康度：不是「我們會多少種技術」，而是「我們有多少種技術在實際使用中保持活躍」。

維持的成本是什麼

對抗漂移的成本不是靠「每個人都要定期複習」。真正有效的做法：

• 讓技能保持在使用狀態——不是學過就算，而是定期在生產環境中動手
• 建立反饋迴圈——新版本、新工具出來時，有人要快速評估對你的影響
• 文件不是備忘錄，是活文件——每次使用時更新，記錄當前的最佳實踐，而不是歷史記錄
• 設定漂移檢測點——定期問：這個技能的上下文最後一次更新是什麼時候？

這些都不便宜。但比起「發現關鍵時刻某個技能已經不堪用」要便宜得多。

這不是效率問題

有人會說：「那我們就定期複習吧，效率很高。」但實際上，複習的效果很差。你不是在學新東西，所以大腦不會高度參與。你也不是在解決真實問題，所以複習的內容很快又會漂移。

這是一個選擇：你要麼接受「技能需要持續使用才能維持」這個事實，要麼接受「我們的技能棧會逐漸變成僵屍」。

我現在看技術決策時，除了問「這個技術能解決問題嗎」，還會問「我們有能力持續維持它嗎」。如果答案是「不太確定」，那就要重新考慮。

我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。

原始來源：https://www.threads.com/@vincent.chanw/post/DV5PpFhkVdv