裝了三十個技能，真正天天用的沒幾個：掘金這篇WorkBuddy清單，把話挑明了

9月18日，掘金作者殷紫川貼出一篇將近半小時閱讀量的長文，標題直接寫著「最值得落地的10個技能，效率直接翻倍」。文章本身是站在Java後端開發者的視角，把專案初始化、編碼、評審、測試、排障到部署的整條流程拆開，逐一推薦經過實戰驗證的Skill。但在技術社羣裡被轉發時，大家討論的往往已經不是清單裡的某一項，而是開頭那句坦白：試過近三十個技能，真正嵌進日常流程的，其實只有那幾個。

這句話之所以有共鳴，是因為它戳中了一個很普遍的狀態。

先把背景補上

WorkBuddy這類工具的技能生態，過去一段時間長得很快。功能目錄越拉越長，安裝成本看起來又低，於是出現了一種典型的囤積行為：看到別人推薦就裝，裝完試一次，然後再也沒打開過。原文作者自己承認踩過「功能花哨但沒用」「安裝後再沒打開過」的坑，這個描述幾乎可以直接對應到許多開發者本機裡那一排沉睡的技能圖示。

這種囤積並不陌生。它和許多人手機裡裝滿生產力App、書籤列塞滿「之後再看」的教程，是同一種心理：安裝這個動作本身，就已經提供了「我在進步」的滿足感。真正的篩選發生在使用階段，而使用階段才是最殘酷的。

清單裡的兩個樣本

以原文花最多筆墨的兩個技能為例，可以看出這份清單的篩選標準。

第一個是springboot-scaffold，定位是Java後端專案的快速啟動器。作者算過一筆帳：一個帶分頁查詢和條件篩選的增刪改查介面，從建Maven專案、加依賴、寫配置、分層建包，到統一返回體和全域異常處理，傳統做法少說一個半小時，還經常漏掉某個註解導致啟動失敗。交給這個技能，一句話描述清楚技術棧和實體關係，三十秒生成完整可運行的專案結構，連建表SQL都順帶產出。

第二個是code-review，把業界公認的評審標準固化成檢查清單，從程式碼品質、安全性、效能、可維護性幾個維度做結構化審查。作者觀察到很多團隊的評審流於形式，要嘛沒時間細看，要嘛各人標準不一吵不出結論。把標準寫死成清單，至少讓「看過」和「看懂」有了明確界線。

這兩個技能的共通點很清楚：它們都卡在工作流裡每天必經的位置上，而非解決偶發需求。這正是「天天用」和「裝過」的分水嶺。

為什麼「貼合工作流」比「功能強大」重要

原文反覆強調一個觀點：很多人裝技能喜歡求多求全，實際上真正提升效率的，永遠是貼合技術棧、匹配工作流的那幾個。這個判準聽起來樸素，卻和技能生態的推廣邏輯相反。生態傾向於展示「還能做什麼」，使用者需要的卻是「我明天上班會不會用到」。

作者給出的實作建議也很務實。生成骨架時務必指定JDK版本、Spring Boot版本和ORM框架，因為預設版本可能和專案技術棧對不上，事後改依賴反而更花時間。腳手架生成的程式碼被嫌死板，他的解法是基礎層交給工具，複雜業務邏輯自己寫，順便讓團隊的專案結構保持統一，新人接手不用重新熟悉不同的包結構。

這種「基礎交出去、核心留手上」的分工思路，和之前開發者社羣裡把每天領積分的雜事交回給WorkBuddy自己處理的分享，走的是同一條路：判斷哪些事情值得自動化，比把所有事情都自動化更重要。

一份清單，照出一種工作態度

把視野拉遠一點，這類「我試了三十個、留下十個」的長文，在開發者社羣一直有穩定的讀者羣。它們的價值不在於清單本身能不能照抄，畢竟每個人的技術棧和工作流都不同，而在於提供了一種篩選方法：用實際專案當過濾器，用使用頻率當計分板。

殷紫川在文中說，這十個技能每個都經過至少十個專案的實戰驗證。這個數字本身無法被旁人核實，但「經過十個專案才敢推薦」這個表述，已經說明了篩選的成本。願意付這個成本的人，寫出來的清單才有人讀；只想湊熱點列功能的清單，通常活不過一輪轉發。

對照來看，技能囤積者缺的往往不是工具，是那十個專案的耐心。清單會過時，工具會換代，但「裝了不等於會用、會用不等於天天用」這件事，大概每隔一段時間就會被一篇新的長文重新提醒一次。這次輪到WorkBuddy，下次大概是別的名字，而文章開頭那句坦白，多半還會原封不動地出現。