：從自評到雷達圖)
“skills”這個詞在程序員工具箱里通常是個命令、一個文件名或者某個配置文件里不起眼的字段。但過去兩個月它是我個人一直在迭代的一個項目一套基于純文本文件和個人腳本搭建的技能管理系統(tǒng)。它不是什么大平臺不依賴Notion模板也不用聯(lián)網(wǎng)建表就靠一個 YAML 文件加一個 Python 腳本把技能清單、自評等級、復(fù)盤記錄全部管起來。這套東西解決的是我自己的一個實際問題技能太多太雜腦子里一團漿糊學(xué)了后面忘前面簡歷上寫起來也沒底氣。如果你也處于這種狀態(tài)或者正打算給團隊建一張可落地的能力矩陣那這篇帖子就是給你準(zhǔn)備的。1. 項目定位與設(shè)計思路1.1 為什么用文件存儲而不是直接套用在線表格剛開始我想過用在線表格或者用飛書多維表格搭一個整齊好看還能多人協(xié)作。但后來我放棄了原因有三個。第一數(shù)據(jù)所有權(quán)問題技能數(shù)據(jù)是個人長期資產(chǎn)放在別人的服務(wù)器上哪天服務(wù)調(diào)整了、賬號出問題數(shù)據(jù)說沒就沒。第二離線使用問題在線表格一旦沒網(wǎng)基本上就是一塊白板而我在地鐵上、在飛機上經(jīng)常會有想記點技能的沖動。第三可復(fù)用和可遷移性一塊純 Markdown 或 YAML 文件可以被腳本讀取可以被 Git 記錄版本哪天想遷移到新工具改一改格式就能走。用文件存儲的本質(zhì)是“數(shù)據(jù)與工具解耦”。你可以用 VS Code 打開也可以用記事本打開甚至可以用cat命令在終端里看。這個思路和我平時管理配置文件是一樣的把配置和程序分開數(shù)據(jù)就在那里任誰都能讀。用生活里的事來類比這就好比整理衣櫥。你不需要先買一個昂貴的智能衣柜才能開始整理你需要做的只是把所有衣服拿出來分個類記錄哪些常穿、哪些壓箱底然后定期斷舍離。技能管理也是這個邏輯核心不在工具多高級而在你愿不愿意坐下來清點自己。1.2 從崗位需求倒推技能分類項目最開始我犯了一個典型錯誤看見什么技術(shù)就想往里面塞。今天看到 Docker 很火加一個明天看到大模型很火再加一個。結(jié)果技能清單變成了一大鍋亂燉根本沒有結(jié)構(gòu)感。后來我把思路完全倒過來不按“技術(shù)熱度”來而是按“目標(biāo)崗位需求”來。我先問自己一個問題我未來一年最有價值的角色是什么比如是“后端開發(fā)工程師”那我就圍繞這個角色拆解能力。程序設(shè)計能力數(shù)據(jù)結(jié)構(gòu)、算法、設(shè)計模式、系統(tǒng)設(shè)計語言與運行環(huán)境Java、Python、JVM、Linux框架與中間件Spring Boot、Redis、Kafka、MySQL工程化與交付CI/CD、Docker、Kubernetes、監(jiān)控告警軟技能需求溝通、技術(shù)文檔、指導(dǎo)新人這樣分類的好處是每一項都能對應(yīng)到實際工作場景也方便和招聘 JD 做比對。給團隊做能力矩陣時這個思路同樣適用先確定團隊要交付的目標(biāo)再倒推每個角色需要具備哪些技能而不是把每個成員會的一堆零碎工具羅列上去。1.3 技能粒度的控制不能粗到?jīng)]用也不能細(xì)到?jīng)]法評技能粒度是早期最讓我頭疼的問題。寫一個“Java”太粗了因為 Java 三個字根本看不出你到底是能寫 CRUD還是能搞并發(fā)調(diào)優(yōu)。寫一個“Java Stream 的 groupBy 用法”又太細(xì)了這類細(xì)節(jié)屬于知識點不該作為技能樹的葉子節(jié)點。我推薦的粒度是能獨立評估水平的一個能力域。例如“Java 并發(fā)編程”是一個技能可評估“Spring Boot 應(yīng)用開發(fā)”是一個技能可評估“MySQL 性能優(yōu)化”是一個技能可評估“Redis 的分布式鎖實現(xiàn)”更像一個知識點可以作為“緩存設(shè)計與實踐”這個技能下的一個備注而不是獨立技能判斷粒度是否合適的標(biāo)準(zhǔn)很簡單拿到這個技能名稱你能不能立刻判斷自己掌握到什么程度如果猶豫超過五秒那就說明要么它太寬要么它太窄。2. 核心功能拆解記錄、量化與復(fù)盤2.1 自評等級“0-5級”背后的能力階段模型量化技能我用的是 0-5 六個檔位。這個體系參考的是 Dreyfus 技能獲取模型簡化成六檔之后自評起來大腦負(fù)擔(dān)很低也方便在團隊里統(tǒng)一口徑。0 級沒接觸過1 級了解概念能說出它是干什么的2 級在指導(dǎo)下做過簡單任務(wù)3 級能獨立完成常規(guī)任務(wù)遇到問題能自己查資料解決4 級不僅能獨立交付還能根據(jù)項目場景做選型和優(yōu)化5 級能教學(xué)、能輸出方法論能指導(dǎo)別人避坑為什么不用百分制因為百分制容易制造“假精度”。你說你 Java 會 80 分那 80 分和 85 分有什么區(qū)別沒人能說得清。0-5 分級雖然粗糙但每一檔都有明確的行為描述自評時我只需要對照自己最近一次實操表現(xiàn)就能打出一個相對穩(wěn)定的分?jǐn)?shù)。我給技能記錄表格設(shè)計的字段很簡單技能名稱、所屬大類、自評等級、最近使用時間、關(guān)鍵證據(jù)。關(guān)鍵證據(jù)很重要它可以是一句話比如 “三月份完成訂單系統(tǒng)的接口冪等改造”也可以直接指向一個項目筆記的鏈接。有了證據(jù)你自評的 4 級才不會自嗨。2.2 技能雷達圖讓“短板”一眼現(xiàn)形技能清單一旦長到幾十項直接看表格其實是看不出整體結(jié)構(gòu)的。這時候需要用可視化方式輔助判斷我選的是雷達圖。雷達圖的每個軸對應(yīng)一個技能大類數(shù)值是該大類下所有技能等級的平均值。因為單個技能看多了容易鉆牛角尖而大類平均分能反映你的能力分布是否均衡。比如我自己的數(shù)據(jù)里“程序設(shè)計能力”平均分只有 1.8而“框架與中間件”平均分是 3.2。雷達圖上那一塊凹陷非常扎眼逼著我直面一個問題我花大量時間學(xué)框架但底層的數(shù)據(jù)結(jié)構(gòu)和算法基礎(chǔ)一直沒補上。這個發(fā)現(xiàn)比我列一百個技能都有用因為我終于知道下一步該往哪里發(fā)力了。生成雷達圖我用的工具很簡單就是 Python 的 matplotlib。腳本讀 YAML把技能按大類聚合并計算平均分然后生成一張 PNG 圖片。整個腳本不到 70 行后續(xù)你會在實操部分看到完整代碼。我更建議你在本地跑一遍這個腳本體會一下“從數(shù)據(jù)文件到圖”的整個鏈路跑通后的成就感。2.3 從靜態(tài)清單到動態(tài)復(fù)盤流程技能清單最大的敵人是“塵封感”。三個月不更新它就變成了一張過期的歷史博物館展品清單。我的做法是把這套系統(tǒng)嵌進月度復(fù)盤中每個月底花二十分鐘做四件事新增這一個月接觸了哪些新技能沒接觸到的就先不寫不必為了好看硬湊。重評把過往技能重新看一遍水平是否有提升有沒有因為久不用而退化。關(guān)聯(lián)給重要技能補充一條最近使用的證據(jù)比如項目名、PR 鏈接、一頁筆記。清理刪掉那些早就脫離主線、未來也不可能再用的技能標(biāo)簽給清單減負(fù)。這樣做的核心原因是技能水平不是一勞永逸的屬性而是會隨著使用頻率升降的變量。用“最近使用時間”這個字段做輔助你才能在雷達圖之外看到“哪些技能是存量哪些技能是活躍資產(chǎn)”。3. 實操用 skills 工具從零搭建技能檔案3.1 初始化項目目錄與數(shù)據(jù)文件這個項目我保持了極簡風(fēng)格目錄結(jié)構(gòu)只有三塊skills/ ├── data/ │ └── skills.yaml ├── scripts/ │ ├── read_skills.py │ └── radar_chart.py └── output/ └── radar.pngdata/skills.yaml存放技能樹scripts/放讀取和可視化腳本output/放生成的圖表。整體并沒有引入數(shù)據(jù)庫也沒有依賴 Docker因為它只需要在一個 python 環(huán)境里跑幾個腳本就夠。這里我刻意保持了極簡原因就是開頭說的數(shù)據(jù)歸數(shù)據(jù)腳本歸腳本不要一開始就搭建復(fù)雜設(shè)施。YAML 數(shù)據(jù)結(jié)構(gòu)設(shè)計如下version: 1.0 owner: your-name updated: 2025-01-15 categories: - name: 程序設(shè)計能力 skills: - name: 數(shù)據(jù)結(jié)構(gòu)與算法 level: 2 last_used: 2025-01-10 evidence: 完成一次二叉樹遍歷專題練習(xí) - name: 設(shè)計模式 level: 3 last_used: 2024-12-20 evidence: 在支付模塊中使用策略模式重構(gòu)代碼 - name: 語言與運行環(huán)境 skills: - name: Java 并發(fā)編程 level: 3 last_used: 2025-01-05 evidence: 排查過線上線程池阻塞問題 - name: Python 腳本開發(fā) level: 3 last_used: 2025-01-14 evidence: 實現(xiàn)自動化報表生成腳本選擇 YAML 而不是 JSON最重要的原因是可以寫注釋。技能這種數(shù)據(jù)幾乎每個字段都需要上下文比如“為什么給這個技能打 3 級”不寫下來下次自己都會忘。JSON 雖然也能寫注釋但支持度有限體驗不如 YAML 順手。另外YAML 用縮進表達層級結(jié)構(gòu)肉眼比 JSON 更清晰。3.2 自動校驗技能數(shù)據(jù)并輸出成長進度數(shù)據(jù)文件有了接著需要一個能讀取數(shù)據(jù)、生成統(tǒng)計信息的腳本。我寫了一個很短的read_skills.py它只做三件事讀取 YAML統(tǒng)計每個大類的技能數(shù)量和平均等級輸出一個表格方便我快速在終端里看。import yaml from collections import defaultdict def load_skills(pathdata/skills.yaml): with open(path, r, encodingutf-8) as f: return yaml.safe_load(f) def calculate_progress(data): stats [] for cat in data[categories]: names cat.get(skills, []) if not names: continue avg_level sum(s[level] for s in names) / len(names) stats.append({ category: cat[name], count: len(names), avg_level: round(avg_level, 2) }) return stats if __name__ __main__: data load_skills() print(f技能檔案管理員: {data[owner]}) print(f最后更新: {data[updated]}\n) for item in calculate_progress(data): print(f{item[category]:12} 技能數(shù) {item[count]:4} 平均等級 {item[avg_level]})跑這個腳本的方法很簡單cd skills pip install pyyaml python scripts/read_skills.py你不需要改造任何配置文件只要 YAML 里的數(shù)據(jù)是正確的腳本會自動把它打印成一個統(tǒng)計表。這個腳本的價值不在于功能強大而在于它把“數(shù)據(jù)”和“觀察”連接起來了。沒有這個腳本你打開 YAML 要頭腦里做聚合有了這個腳本一眼就能看到整體情況。3.3 生成可視化雷達圖讓成績單變成決策工具第二步我用 matplotlib 做了雷達圖腳本。代碼邏輯也不復(fù)雜讀取分類平均等級映射到雷達圖上。如果你的技能分類不是五類也沒關(guān)系腳本會自適應(yīng)分類數(shù)量。import yaml import matplotlib.pyplot as plt import numpy as np from math import pi def load_skills(pathdata/skills.yaml): with open(path, r, encodingutf-8) as f: return yaml.safe_load(f) def get_category_averages(data): labels [] values [] for cat in data[categories]: skills cat.get(skills, []) if skills: labels.append(cat[name]) values.append(round(sum(s[level] for s in skills) / len(skills), 2)) return labels, values def create_radar_chart(labels, values, save_pathoutput/radar.png): angles [i / float(len(labels)) * 2 * pi for i in range(len(labels))] values values[:1] angles angles[:1] fig, ax plt.subplots(figsize(8, 8), subplot_kwdict(polarTrue)) ax.plot(angles, values, linewidth1.5, linestylesolid) ax.fill(angles, values, alpha0.25) ax.set_xticks(angles[:-1]) ax.set_xticklabels(labels, fontsize12) ax.set_ylim(0, 5) ax.set_yticks([1, 2, 3, 4, 5]) plt.savefig(save_path, dpi300, bbox_inchestight) print(f雷達圖已保存到: {save_path}) if __name__ __main__: data load_skills() labels, values get_category_averages(data) create_radar_chart(labels, values)運行之后會在output/目錄里得到一張雷達圖。這張圖里每一瓣代表一個大類分值范圍是 0-5。最初跑通這個腳本時我盯著它看了好久因為那是第一次有了一張“可視化能力畫像”。對于團隊場景你還可以把每個成員的雷達圖打印出來貼在用研數(shù)據(jù)對面誰強誰弱、哪里有缺口會議室里一眼就能看明白。3.4 體驗一次完整的技能評估流程理論講完了腳本也有了我把一次完整的技能評估流程放在前面你拿到項目后可以直接照著做。選擇目標(biāo)角色。假設(shè)你是一名 Web 全棧方向的學(xué)生未來想找后端開發(fā)崗位。建立分類。在skills.yaml里先寫好三個大類基礎(chǔ)理論、后端技術(shù)、工程能力。錄入技能。每個類別下按粒度要求列 5-10 個技能給每個技能打等級、填最近使用時間和證據(jù)。運行統(tǒng)計腳本。用read_skills.py查看當(dāng)前掌握情況的匯總。生成雷達圖。用radar_chart.py生成圖對比各大類平均分。定一個動作。雷達圖上哪個大類最低下個月就圍繞這個大類的關(guān)鍵技能做一次刻意練習(xí)并在月底更新等級。不要小看最后一步很多人做完雷達圖就結(jié)束了根本沒有落到行動上。技能管理的價值不在“知道自己有多弱”而在“知道自己該補哪一塊”。4. 常見問題與避坑指南4.1 自評時手軟手嚴(yán)怎么校準(zhǔn)經(jīng)常有人問我“你怎么保證自評分?jǐn)?shù)的準(zhǔn)確性”誠實說自評永遠(yuǎn)有偏差但我們可以用方法減小偏差。我的習(xí)慣是三個校驗輪第一對照目標(biāo)崗位的招聘要求如果 JD 里明確寫了“熟練掌握 Java 并發(fā)編程”而你只能說出線程池的幾個參數(shù)那評級就不應(yīng)該超過 2第二找一個同事或朋友幫你評你會發(fā)現(xiàn)別人對你的判斷往往比你自己更保守第三用交付物說話你最近半年有沒有拿得出手的項目、文章或代碼如果一樣都沒有那這項技能即使打 3 級也很難讓人信服。自評偏差最集中的地方是“會用”和“能交”的混淆。你會用 Redis 的 GET/SET 命令能在本地跑起來這不代表你懂緩存穿透和緩存一致性。把技能重評時多問自己一個問題“如果這周有個人讓我基于這項技能解決一個線上問題我能不查文檔就說出排查思路嗎”答不上來就降一級。4.2 技能跨類和重疊怎么去重技能分類最容易遇到的坑是一項技能同時屬于兩個大類。比如 Docker既算“容器技術(shù)”又算“DevOps 工具鏈”再比如 Redis既算“分布式存儲”又算“緩存設(shè)計”。如果不處理重復(fù)雷達圖里同一項能力會被算兩次大類均值會虛高。我的處理原則有一個每個技能只在最貼近業(yè)務(wù)目標(biāo)的大類里掛載一次其他大類里絕對不重復(fù)出現(xiàn)。比如 Docker如果你的目標(biāo)是做后端服務(wù)部署那它掛在“工程化與交付”下如果你的目標(biāo)是做云原生基礎(chǔ)設(shè)施那它掛在“云原生基礎(chǔ)設(shè)施”下。重復(fù)技能本質(zhì)上不是數(shù)據(jù)問題而是分類目標(biāo)不清晰的映射方式。分類不準(zhǔn)造成的連鎖反應(yīng)很明顯雷達圖會“虛胖”讓你誤以為某些維度能力不錯實際上那只是同一個技能被算了兩遍。所以每次新增技能時先看它是不是已經(jīng)在其他類別里存在過。如果存在那就在原類別里補充描述而不是在多個類別里重復(fù)列一遍。4.3 項目做一半數(shù)據(jù)亂了怎么恢復(fù)文件式存儲最大的好處是可以用 Git 管理所以從項目第一天起我就把data/目錄納入版本控制。每周末對自己的技能檔案做一次 commit寫個簡單的信息比如 “月度復(fù)盤更新 Redis 等級為 3新增容器網(wǎng)絡(luò)學(xué)習(xí)筆記”。這樣的習(xí)慣建立了三層安全網(wǎng)本地有備份文件遠(yuǎn)端 Git 倉庫有歷史版本每個技能都有明確的變更時間線如果哪天真改亂了一條git revert或者git checkout -- data/skills.yaml就能恢復(fù)絕不至于哭天喊地。數(shù)據(jù)這種長期資產(chǎn)不做備份和版本管理就是在給自己埋雷。更重要的當(dāng)你一個月后再回來看那份 YAML 時Git 歷史能告訴你這個月你的技術(shù)方向發(fā)生了哪些變化等于給職業(yè)成長寫了個日記。4.4 常見問題速查表問題現(xiàn)象主要原因解決建議技能數(shù)量越來越多逐漸變成大雜燴沒有按目標(biāo)角色倒推分類先定義角色再列出角色需要的能力自評等級普遍偏高混淆了“知道”和“能交付”用關(guān)鍵證據(jù)和交付物校準(zhǔn)雷達圖某幾個維度虛高同一技能掛載到了多個大類按“一次掛載”原則去重技能檔案幾個月不更新沒有內(nèi)嵌到月度復(fù)盤中把更新技能列為每月固定動作新學(xué)技能總是加到舊分類里分類本身落后于業(yè)務(wù)目標(biāo)定期審視角色定位重構(gòu) YAML 分類樹5. 后續(xù)擴展方向skills 項目目前只服務(wù)我一個人但它天然可以擴展到團隊場景。給團隊做能力矩陣時不需要改變?nèi)魏魏诵脑O(shè)計只需要讓每個成員維護自己的skills.yaml然后由一個匯總腳本把所有成員的數(shù)據(jù)合并起來就可以生成團隊級的熱力圖哪條鏈路上缺人、哪類技能存在結(jié)構(gòu)性短板很快就暴露出來。另一個擴展方向是把它和招聘面試結(jié)合。把候選人簡歷里的關(guān)鍵詞按照這套技能分類整理一遍自動生成一張技能雷達圖面試官在開始聊技術(shù)之前就能直觀看到候選人的能力結(jié)構(gòu)省去先讀半天簡歷再做判斷的時間。這些后續(xù)能力我目前還在探索中但核心數(shù)據(jù)結(jié)構(gòu)已經(jīng)足夠支撐。我自己的體會是這套系統(tǒng)最大的價值不是那張好看的雷達圖也不是那一堆分級數(shù)字而是它逼著我每個月坐下來認(rèn)真想一遍我現(xiàn)在的技能結(jié)構(gòu)離我想要的職業(yè)方向還差在哪一塊。思考的過程本身比工具和腳本值錢得多。所以如果你也想搭一套別急著先寫代碼先拿一張紙列出來為你未來的角色拆十個技能出來再打上等級。這第一步比任何工具都重要。 用YAML和Python打造個人技能管理系統(tǒng)：從自評到雷達圖
“skills”這個詞在程序員工具箱里通常是個命令、一個文件名或者某個配置文件里不起眼的字段。但過去兩個月它是我個人一直在迭代的一個項目一套基于純文本文件和個人腳本搭建的技能管理系統(tǒng)。它不是什么大平臺不依賴Notion模板也不用聯(lián)網(wǎng)建表就靠一個 YAML 文件加一個 Python 腳本把技能清單、自評等級、復(fù)盤記錄全部管起來。這套東西解決的是我自己的一個實際問題技能太多太雜腦子里一團漿糊學(xué)了后面忘前面簡歷上寫起來也沒底氣。如果你也處于這種狀態(tài)或者正打算給團隊建一張可落地的能力矩陣那這篇帖子就是給你準(zhǔn)備的。1. 項目定位與設(shè)計思路1.1 為什么用文件存儲而不是直接套用在線表格剛開始我想過用在線表格或者用飛書多維表格搭一個整齊好看還能多人協(xié)作。但后來我放棄了原因有三個。第一數(shù)據(jù)所有權(quán)問題技能數(shù)據(jù)是個人長期資產(chǎn)放在別人的服務(wù)器上哪天服務(wù)調(diào)整了、賬號出問題數(shù)據(jù)說沒就沒。第二離線使用問題在線表格一旦沒網(wǎng)基本上就是一塊白板而我在地鐵上、在飛機上經(jīng)常會有想記點技能的沖動。第三可復(fù)用和可遷移性一塊純 Markdown 或 YAML 文件可以被腳本讀取可以被 Git 記錄版本哪天想遷移到新工具改一改格式就能走。用文件存儲的本質(zhì)是“數(shù)據(jù)與工具解耦”。你可以用 VS Code 打開也可以用記事本打開甚至可以用cat命令在終端里看。這個思路和我平時管理配置文件是一樣的把配置和程序分開數(shù)據(jù)就在那里任誰都能讀。用生活里的事來類比這就好比整理衣櫥。你不需要先買一個昂貴的智能衣柜才能開始整理你需要做的只是把所有衣服拿出來分個類記錄哪些常穿、哪些壓箱底然后定期斷舍離。技能管理也是這個邏輯核心不在工具多高級而在你愿不愿意坐下來清點自己。1.2 從崗位需求倒推技能分類項目最開始我犯了一個典型錯誤看見什么技術(shù)就想往里面塞。今天看到 Docker 很火加一個明天看到大模型很火再加一個。結(jié)果技能清單變成了一大鍋亂燉根本沒有結(jié)構(gòu)感。后來我把思路完全倒過來不按“技術(shù)熱度”來而是按“目標(biāo)崗位需求”來。我先問自己一個問題我未來一年最有價值的角色是什么比如是“后端開發(fā)工程師”那我就圍繞這個角色拆解能力。程序設(shè)計能力數(shù)據(jù)結(jié)構(gòu)、算法、設(shè)計模式、系統(tǒng)設(shè)計語言與運行環(huán)境Java、Python、JVM、Linux框架與中間件Spring Boot、Redis、Kafka、MySQL工程化與交付CI/CD、Docker、Kubernetes、監(jiān)控告警軟技能需求溝通、技術(shù)文檔、指導(dǎo)新人這樣分類的好處是每一項都能對應(yīng)到實際工作場景也方便和招聘 JD 做比對。給團隊做能力矩陣時這個思路同樣適用先確定團隊要交付的目標(biāo)再倒推每個角色需要具備哪些技能而不是把每個成員會的一堆零碎工具羅列上去。1.3 技能粒度的控制不能粗到?jīng)]用也不能細(xì)到?jīng)]法評技能粒度是早期最讓我頭疼的問題。寫一個“Java”太粗了因為 Java 三個字根本看不出你到底是能寫 CRUD還是能搞并發(fā)調(diào)優(yōu)。寫一個“Java Stream 的 groupBy 用法”又太細(xì)了這類細(xì)節(jié)屬于知識點不該作為技能樹的葉子節(jié)點。我推薦的粒度是能獨立評估水平的一個能力域。例如“Java 并發(fā)編程”是一個技能可評估“Spring Boot 應(yīng)用開發(fā)”是一個技能可評估“MySQL 性能優(yōu)化”是一個技能可評估“Redis 的分布式鎖實現(xiàn)”更像一個知識點可以作為“緩存設(shè)計與實踐”這個技能下的一個備注而不是獨立技能判斷粒度是否合適的標(biāo)準(zhǔn)很簡單拿到這個技能名稱你能不能立刻判斷自己掌握到什么程度如果猶豫超過五秒那就說明要么它太寬要么它太窄。2. 核心功能拆解記錄、量化與復(fù)盤2.1 自評等級“0-5級”背后的能力階段模型量化技能我用的是 0-5 六個檔位。這個體系參考的是 Dreyfus 技能獲取模型簡化成六檔之后自評起來大腦負(fù)擔(dān)很低也方便在團隊里統(tǒng)一口徑。0 級沒接觸過1 級了解概念能說出它是干什么的2 級在指導(dǎo)下做過簡單任務(wù)3 級能獨立完成常規(guī)任務(wù)遇到問題能自己查資料解決4 級不僅能獨立交付還能根據(jù)項目場景做選型和優(yōu)化5 級能教學(xué)、能輸出方法論能指導(dǎo)別人避坑為什么不用百分制因為百分制容易制造“假精度”。你說你 Java 會 80 分那 80 分和 85 分有什么區(qū)別沒人能說得清。0-5 分級雖然粗糙但每一檔都有明確的行為描述自評時我只需要對照自己最近一次實操表現(xiàn)就能打出一個相對穩(wěn)定的分?jǐn)?shù)。我給技能記錄表格設(shè)計的字段很簡單技能名稱、所屬大類、自評等級、最近使用時間、關(guān)鍵證據(jù)。關(guān)鍵證據(jù)很重要它可以是一句話比如 “三月份完成訂單系統(tǒng)的接口冪等改造”也可以直接指向一個項目筆記的鏈接。有了證據(jù)你自評的 4 級才不會自嗨。2.2 技能雷達圖讓“短板”一眼現(xiàn)形技能清單一旦長到幾十項直接看表格其實是看不出整體結(jié)構(gòu)的。這時候需要用可視化方式輔助判斷我選的是雷達圖。雷達圖的每個軸對應(yīng)一個技能大類數(shù)值是該大類下所有技能等級的平均值。因為單個技能看多了容易鉆牛角尖而大類平均分能反映你的能力分布是否均衡。比如我自己的數(shù)據(jù)里“程序設(shè)計能力”平均分只有 1.8而“框架與中間件”平均分是 3.2。雷達圖上那一塊凹陷非常扎眼逼著我直面一個問題我花大量時間學(xué)框架但底層的數(shù)據(jù)結(jié)構(gòu)和算法基礎(chǔ)一直沒補上。這個發(fā)現(xiàn)比我列一百個技能都有用因為我終于知道下一步該往哪里發(fā)力了。生成雷達圖我用的工具很簡單就是 Python 的 matplotlib。腳本讀 YAML把技能按大類聚合并計算平均分然后生成一張 PNG 圖片。整個腳本不到 70 行后續(xù)你會在實操部分看到完整代碼。我更建議你在本地跑一遍這個腳本體會一下“從數(shù)據(jù)文件到圖”的整個鏈路跑通后的成就感。2.3 從靜態(tài)清單到動態(tài)復(fù)盤流程技能清單最大的敵人是“塵封感”。三個月不更新它就變成了一張過期的歷史博物館展品清單。我的做法是把這套系統(tǒng)嵌進月度復(fù)盤中每個月底花二十分鐘做四件事新增這一個月接觸了哪些新技能沒接觸到的就先不寫不必為了好看硬湊。重評把過往技能重新看一遍水平是否有提升有沒有因為久不用而退化。關(guān)聯(lián)給重要技能補充一條最近使用的證據(jù)比如項目名、PR 鏈接、一頁筆記。清理刪掉那些早就脫離主線、未來也不可能再用的技能標(biāo)簽給清單減負(fù)。這樣做的核心原因是技能水平不是一勞永逸的屬性而是會隨著使用頻率升降的變量。用“最近使用時間”這個字段做輔助你才能在雷達圖之外看到“哪些技能是存量哪些技能是活躍資產(chǎn)”。3. 實操用 skills 工具從零搭建技能檔案3.1 初始化項目目錄與數(shù)據(jù)文件這個項目我保持了極簡風(fēng)格目錄結(jié)構(gòu)只有三塊skills/ ├── data/ │ └── skills.yaml ├── scripts/ │ ├── read_skills.py │ └── radar_chart.py └── output/ └── radar.pngdata/skills.yaml存放技能樹scripts/放讀取和可視化腳本output/放生成的圖表。整體并沒有引入數(shù)據(jù)庫也沒有依賴 Docker因為它只需要在一個 python 環(huán)境里跑幾個腳本就夠。這里我刻意保持了極簡原因就是開頭說的數(shù)據(jù)歸數(shù)據(jù)腳本歸腳本不要一開始就搭建復(fù)雜設(shè)施。YAML 數(shù)據(jù)結(jié)構(gòu)設(shè)計如下version: 1.0 owner: your-name updated: 2025-01-15 categories: - name: 程序設(shè)計能力 skills: - name: 數(shù)據(jù)結(jié)構(gòu)與算法 level: 2 last_used: 2025-01-10 evidence: 完成一次二叉樹遍歷專題練習(xí) - name: 設(shè)計模式 level: 3 last_used: 2024-12-20 evidence: 在支付模塊中使用策略模式重構(gòu)代碼 - name: 語言與運行環(huán)境 skills: - name: Java 并發(fā)編程 level: 3 last_used: 2025-01-05 evidence: 排查過線上線程池阻塞問題 - name: Python 腳本開發(fā) level: 3 last_used: 2025-01-14 evidence: 實現(xiàn)自動化報表生成腳本選擇 YAML 而不是 JSON最重要的原因是可以寫注釋。技能這種數(shù)據(jù)幾乎每個字段都需要上下文比如“為什么給這個技能打 3 級”不寫下來下次自己都會忘。JSON 雖然也能寫注釋但支持度有限體驗不如 YAML 順手。另外YAML 用縮進表達層級結(jié)構(gòu)肉眼比 JSON 更清晰。3.2 自動校驗技能數(shù)據(jù)并輸出成長進度數(shù)據(jù)文件有了接著需要一個能讀取數(shù)據(jù)、生成統(tǒng)計信息的腳本。我寫了一個很短的read_skills.py它只做三件事讀取 YAML統(tǒng)計每個大類的技能數(shù)量和平均等級輸出一個表格方便我快速在終端里看。import yaml from collections import defaultdict def load_skills(pathdata/skills.yaml): with open(path, r, encodingutf-8) as f: return yaml.safe_load(f) def calculate_progress(data): stats [] for cat in data[categories]: names cat.get(skills, []) if not names: continue avg_level sum(s[level] for s in names) / len(names) stats.append({ category: cat[name], count: len(names), avg_level: round(avg_level, 2) }) return stats if __name__ __main__: data load_skills() print(f技能檔案管理員: {data[owner]}) print(f最后更新: {data[updated]}\n) for item in calculate_progress(data): print(f{item[category]:12} 技能數(shù) {item[count]:4} 平均等級 {item[avg_level]})跑這個腳本的方法很簡單cd skills pip install pyyaml python scripts/read_skills.py你不需要改造任何配置文件只要 YAML 里的數(shù)據(jù)是正確的腳本會自動把它打印成一個統(tǒng)計表。這個腳本的價值不在于功能強大而在于它把“數(shù)據(jù)”和“觀察”連接起來了。沒有這個腳本你打開 YAML 要頭腦里做聚合有了這個腳本一眼就能看到整體情況。3.3 生成可視化雷達圖讓成績單變成決策工具第二步我用 matplotlib 做了雷達圖腳本。代碼邏輯也不復(fù)雜讀取分類平均等級映射到雷達圖上。如果你的技能分類不是五類也沒關(guān)系腳本會自適應(yīng)分類數(shù)量。import yaml import matplotlib.pyplot as plt import numpy as np from math import pi def load_skills(pathdata/skills.yaml): with open(path, r, encodingutf-8) as f: return yaml.safe_load(f) def get_category_averages(data): labels [] values [] for cat in data[categories]: skills cat.get(skills, []) if skills: labels.append(cat[name]) values.append(round(sum(s[level] for s in skills) / len(skills), 2)) return labels, values def create_radar_chart(labels, values, save_pathoutput/radar.png): angles [i / float(len(labels)) * 2 * pi for i in range(len(labels))] values values[:1] angles angles[:1] fig, ax plt.subplots(figsize(8, 8), subplot_kwdict(polarTrue)) ax.plot(angles, values, linewidth1.5, linestylesolid) ax.fill(angles, values, alpha0.25) ax.set_xticks(angles[:-1]) ax.set_xticklabels(labels, fontsize12) ax.set_ylim(0, 5) ax.set_yticks([1, 2, 3, 4, 5]) plt.savefig(save_path, dpi300, bbox_inchestight) print(f雷達圖已保存到: {save_path}) if __name__ __main__: data load_skills() labels, values get_category_averages(data) create_radar_chart(labels, values)運行之后會在output/目錄里得到一張雷達圖。這張圖里每一瓣代表一個大類分值范圍是 0-5。最初跑通這個腳本時我盯著它看了好久因為那是第一次有了一張“可視化能力畫像”。對于團隊場景你還可以把每個成員的雷達圖打印出來貼在用研數(shù)據(jù)對面誰強誰弱、哪里有缺口會議室里一眼就能看明白。3.4 體驗一次完整的技能評估流程理論講完了腳本也有了我把一次完整的技能評估流程放在前面你拿到項目后可以直接照著做。選擇目標(biāo)角色。假設(shè)你是一名 Web 全棧方向的學(xué)生未來想找后端開發(fā)崗位。建立分類。在skills.yaml里先寫好三個大類基礎(chǔ)理論、后端技術(shù)、工程能力。錄入技能。每個類別下按粒度要求列 5-10 個技能給每個技能打等級、填最近使用時間和證據(jù)。運行統(tǒng)計腳本。用read_skills.py查看當(dāng)前掌握情況的匯總。生成雷達圖。用radar_chart.py生成圖對比各大類平均分。定一個動作。雷達圖上哪個大類最低下個月就圍繞這個大類的關(guān)鍵技能做一次刻意練習(xí)并在月底更新等級。不要小看最后一步很多人做完雷達圖就結(jié)束了根本沒有落到行動上。技能管理的價值不在“知道自己有多弱”而在“知道自己該補哪一塊”。4. 常見問題與避坑指南4.1 自評時手軟手嚴(yán)怎么校準(zhǔn)經(jīng)常有人問我“你怎么保證自評分?jǐn)?shù)的準(zhǔn)確性”誠實說自評永遠(yuǎn)有偏差但我們可以用方法減小偏差。我的習(xí)慣是三個校驗輪第一對照目標(biāo)崗位的招聘要求如果 JD 里明確寫了“熟練掌握 Java 并發(fā)編程”而你只能說出線程池的幾個參數(shù)那評級就不應(yīng)該超過 2第二找一個同事或朋友幫你評你會發(fā)現(xiàn)別人對你的判斷往往比你自己更保守第三用交付物說話你最近半年有沒有拿得出手的項目、文章或代碼如果一樣都沒有那這項技能即使打 3 級也很難讓人信服。自評偏差最集中的地方是“會用”和“能交”的混淆。你會用 Redis 的 GET/SET 命令能在本地跑起來這不代表你懂緩存穿透和緩存一致性。把技能重評時多問自己一個問題“如果這周有個人讓我基于這項技能解決一個線上問題我能不查文檔就說出排查思路嗎”答不上來就降一級。4.2 技能跨類和重疊怎么去重技能分類最容易遇到的坑是一項技能同時屬于兩個大類。比如 Docker既算“容器技術(shù)”又算“DevOps 工具鏈”再比如 Redis既算“分布式存儲”又算“緩存設(shè)計”。如果不處理重復(fù)雷達圖里同一項能力會被算兩次大類均值會虛高。我的處理原則有一個每個技能只在最貼近業(yè)務(wù)目標(biāo)的大類里掛載一次其他大類里絕對不重復(fù)出現(xiàn)。比如 Docker如果你的目標(biāo)是做后端服務(wù)部署那它掛在“工程化與交付”下如果你的目標(biāo)是做云原生基礎(chǔ)設(shè)施那它掛在“云原生基礎(chǔ)設(shè)施”下。重復(fù)技能本質(zhì)上不是數(shù)據(jù)問題而是分類目標(biāo)不清晰的映射方式。分類不準(zhǔn)造成的連鎖反應(yīng)很明顯雷達圖會“虛胖”讓你誤以為某些維度能力不錯實際上那只是同一個技能被算了兩遍。所以每次新增技能時先看它是不是已經(jīng)在其他類別里存在過。如果存在那就在原類別里補充描述而不是在多個類別里重復(fù)列一遍。4.3 項目做一半數(shù)據(jù)亂了怎么恢復(fù)文件式存儲最大的好處是可以用 Git 管理所以從項目第一天起我就把data/目錄納入版本控制。每周末對自己的技能檔案做一次 commit寫個簡單的信息比如 “月度復(fù)盤更新 Redis 等級為 3新增容器網(wǎng)絡(luò)學(xué)習(xí)筆記”。這樣的習(xí)慣建立了三層安全網(wǎng)本地有備份文件遠(yuǎn)端 Git 倉庫有歷史版本每個技能都有明確的變更時間線如果哪天真改亂了一條git revert或者git checkout -- data/skills.yaml就能恢復(fù)絕不至于哭天喊地。數(shù)據(jù)這種長期資產(chǎn)不做備份和版本管理就是在給自己埋雷。更重要的當(dāng)你一個月后再回來看那份 YAML 時Git 歷史能告訴你這個月你的技術(shù)方向發(fā)生了哪些變化等于給職業(yè)成長寫了個日記。4.4 常見問題速查表問題現(xiàn)象主要原因解決建議技能數(shù)量越來越多逐漸變成大雜燴沒有按目標(biāo)角色倒推分類先定義角色再列出角色需要的能力自評等級普遍偏高混淆了“知道”和“能交付”用關(guān)鍵證據(jù)和交付物校準(zhǔn)雷達圖某幾個維度虛高同一技能掛載到了多個大類按“一次掛載”原則去重技能檔案幾個月不更新沒有內(nèi)嵌到月度復(fù)盤中把更新技能列為每月固定動作新學(xué)技能總是加到舊分類里分類本身落后于業(yè)務(wù)目標(biāo)定期審視角色定位重構(gòu) YAML 分類樹5. 后續(xù)擴展方向skills 項目目前只服務(wù)我一個人但它天然可以擴展到團隊場景。給團隊做能力矩陣時不需要改變?nèi)魏魏诵脑O(shè)計只需要讓每個成員維護自己的skills.yaml然后由一個匯總腳本把所有成員的數(shù)據(jù)合并起來就可以生成團隊級的熱力圖哪條鏈路上缺人、哪類技能存在結(jié)構(gòu)性短板很快就暴露出來。另一個擴展方向是把它和招聘面試結(jié)合。把候選人簡歷里的關(guān)鍵詞按照這套技能分類整理一遍自動生成一張技能雷達圖面試官在開始聊技術(shù)之前就能直觀看到候選人的能力結(jié)構(gòu)省去先讀半天簡歷再做判斷的時間。這些后續(xù)能力我目前還在探索中但核心數(shù)據(jù)結(jié)構(gòu)已經(jīng)足夠支撐。我自己的體會是這套系統(tǒng)最大的價值不是那張好看的雷達圖也不是那一堆分級數(shù)字而是它逼著我每個月坐下來認(rèn)真想一遍我現(xiàn)在的技能結(jié)構(gòu)離我想要的職業(yè)方向還差在哪一塊。思考的過程本身比工具和腳本值錢得多。所以如果你也想搭一套別急著先寫代碼先拿一張紙列出來為你未來的角色拆十個技能出來再打上等級。這第一步比任何工具都重要。