1. 项目定位与整体设计思路

1.1 先聊聊"skills"到底想说清楚什么

"skills"这个标题，乍一看特别大，但其实落到实际工作里，指向非常明确：怎么把一个抽象的、模糊的"能力"，变成一张张看得见、能比较、可追踪的清单。

我做这个项目之前，也说不清自己到底会什么。打开简历能写不少词，但你要真问我"前端开发"这项技能现在是7分还是4分，哪里强哪里弱，我答不上来。面试别人、写复盘、做年度计划的时候，全凭一种"感觉"。这种感觉最大的问题在于：它没法帮你在关键时刻做决策。该往哪个方向补？补到什么程度才算好？三个月后的你到底比现在强在哪里？没有结构化的记录，这些问题永远只能靠猜。

所以这个项目解决的不是"学会某项技能"的问题，而是"管理自己技能资产"的问题。它把散落在简历、项目经历、笔记里的能力点收拢到一个统一框架里，通过分类、打分、可视化、计划、复盘这条链路，让"技能成长"这件事从玄学变成工程。

适合谁来看？两类人。一类是技术栈比较杂、什么都沾一点但不够精的人，这套系统能帮你找到真正的短板和优先级；另一类是带团队、需要给别人做技能盘点或制定培养方案的人，这套方法可以直接复制成一套轻量工具，不用上重型的人力系统。

1.2 三条设计原则：为什么我不是做一个网页应用

最早我设想过做一个漂亮的可视化平台，带登录、数据库、图表。后来在整理第一版数据时就发现，项目本身的价值不在展示，而在"框架"和"数据"。

我给自己定下三条原则。

第一条，可量化优先于可展示。每项技能必须能落到具体分数和行为描述上，否则雷达图再好看也是自欺欺人。第二条，必须有闭环。记录只是起点，评估、学习、复盘三步必须跟上，否则它就是一张永远不更新的死清单。第三条，工具要轻。整个项目用 Markdown 存数据、用脚本算分数、用 Python 画图，单人维护毫无压力。如果一开始就用大平台，我大概率连数据都没填满就放弃了。

事实证明这个决策是对的。最重的部分永远是"往表格里填真实数据"，而不是"造一个系统"。工具越轻，坚持填充的成本越低。

1.3 整体架构与数据流转

整个系统分成四层，数据从底层往上逐层流动：

每一层都只依赖前一层产出的数据，不搞额外耦合。比如你要更新技能清单，只需要改 skills.md 里的一行；你要重新算优先级，跑一遍评估脚本即可；要画新的雷达图，直接读取 scores.csv 输出图片。

这样设计的好处是：任何一步卡住了，其余部分还照样可用。哪怕你不写代码，只用表格和文档，同样能完成这套流程的八成价值。

2. 技能盘点：怎么把"感觉"变成"清单"

2.1 先分区块：核心区、辅助区、兴趣区

盘点技能最怕两件事：一是漏，二是多。漏，是因为很多能力自己不觉得是技能，比如"快速定位线上问题""写简洁的文档"，这些不会被写进简历，但在实际工作里极其值钱。多，是人很容易把自己见过的、摸过一下的都列进去，结果清单铺满一屏，各个都像技能，各个都不精。

我在 skills.md 里把技能分成三个区块，目的就是为了应对这两个问题。

核心区，指当前直接决定产出质量的技能。比如我做前端相关工作，那"组件设计与拆分""状态管理""构建工具配置"就是核心。辅助区，指不直接产出、但大幅提高效率的技能，比如"Shell脚本""设计感/基础视觉审美""英文技术文档阅读"。兴趣区，指现在用不上、但作为长期储备的能力，比如"写作""演讲"。

这样分完以后，清单的人数从打算列出来的60多项，压缩到了18项。空间感一下子就出来了：不是所有会的东西都值得占一格，技能管理的本质是管理注意力，而不是炫耀收藏。

2.2 拆粒度：一项技能至少要能落到"动作"上

"前端开发"这个词是没法管理的。把它列入清单，你打几分都说得通，它也没法转化成具体的学习动作。所以我给每项技能加了"行为描述"一栏，描述必须具体到能看出下一步干什么。

举个例子。

你看，"构建配置"这一项，加上了"开发/生产环境""代码分割""缓存"这几个动作词，它就不再是泛泛而谈。盘点的意义就在这儿：把一个模糊的大词，拆成若干个可校验、可打分的小动作。

2.3 skills.md 清单模板

我用的就是最普通的 Markdown，没有引入任何系统。大致结构如下，你可以直接抄走用。

# skills ## 核心区 - 组件设计（行为描述：UI还原成可复用组件，设计props接口；当前信任分：3） - 状态管理（行为描述：跨页面状态方案设计；当前信任分：2） ## 辅助区 - 构建配置（行为描述：独立配置多环境构建；当前信任分：2） - 终端效率（行为描述：常用shell命令与管道组合；当前信任分：3） ## 兴趣区 - 技术写作（行为描述：输出复盘与技术说明；当前信任分：1）

每个条目后面带一个"当前信任分"，这个分数是主观的，不需要很精确，它只是盘点时的起点，后面会用更客观的打分模型替换掉它。先有大致判断，再补细节，是这步的核心节奏。

3. 技能评估模型：用一套公式代替"我感觉"

3.1 五级熟练度标尺

评分这件事，最容易出现的问题就是"拍脑袋"。今天心情好多打一分，明天遇到一次挫败就扣回两分。我用的是一个改良版的技能分级标尺，把0到4分每一档都绑定了行为特征，而不是抽象感觉。

这个标尺最大的价值，是逼你不是凭"感觉"，而是拿"我最近一次独立完成它是什么时候"来对号入座。比如"状态管理"不打2分，而是问：我有没有不查文档、独立设计过跨页面状态的方案？如果有，就是3；如果没有，就老实停在2。

你也可以把这个标尺做成贴纸上墙，每次打分前先过一遍行为描述再落笔，能省掉很多后续返工。

3.2 优先级怎么算：不只是练短板

有了熟练度，自然就会冒出下一个问题：是不是分数越低越该先补？不一定。有的技能你练了也用不上，优先级就会被浪费。

我引入了一个三维度评估方式：熟练度（S）、使用频率（F）、成长价值（V）。S 用上面那个0到4分；F 是指这个技能在当前工作或目标岗位里每周会不会用到，1到5分，5表示天天用；V 是这个技能对你三到五年后的发展帮助大小，1到5分。然后按下面这个公式算综合优先级得分：

P = (5 - S) × 0.5 + F × 0.3 + V × 0.2

解读一下：前半部分 (5 - S) 是"差距"，差距越大越该补；F 和 V 则代表"值不值得补"。一项技能即便很弱，但如果既用不上、又没成长空间，它的 P 值会被拉得很低，排到后面的位置。你可别小看这个顺序，很多人无效学习，就是因为在"弱但没用"的技能上花了太多时间，结果核心的技能反而不停往后拖。

我拿自己当时的一张评分表做个示例：

状态管理之所以排第一，不是因为它最差，而是它F和V都高，补它性价比最高。构建配置虽然熟练度和状态管理一样都是2分，但使用频率只有3，成长价值也只有3，所以被推后。这个结果和我的直觉预期完全一致，但又比直觉多了一组可解释的依据。

3.3 把评分画成雷达图

数据一旦变成表格，人脑判断起来还是会有点费劲。雷达图是技能管理里最直观的呈现形式。我自己用 Python 的 matplotlib 画的，整个脚本不到四十行。

import matplotlib.pyplot as plt import numpy as np skills = ['状态管理', '组件设计', '构建配置', '技术写作', '终端效率'] scores = [3, 4, 2, 2, 3] angles = np.linspace(0, 2 * np.pi, len(skills), endpoint=False).tolist() scores += scores[:1] angles += angles[:1] fig, ax = plt.subplots(figsize=(6, 6), subplot_kw=dict(polar=True)) ax.plot(angles, scores, linewidth=2) ax.fill(angles, scores, alpha=0.25) ax.set_xticks(angles[:-1]) ax.set_xticklabels(skills) ax.set_ylim(0, 4) plt.show()

这个图的重点不是美观，而是让你一眼就能看出"哪几个维度明显凹陷"。雷达图是给每季度复盘用的，数据从评估脚本直接读出来，不额外维护任何东西。你完全可以用在线图表工具，或者哪怕在纸上手绘，只要形状足够直观，效果是一样的。

4. 从评估到行动：把分数转化成学习路径

4.1 目标不是"学会"，而是分数前进一档

技能规划常见的一个误区，是给自己定"我要学会状态管理"这种目标。这种话说出来轻飘飘的，没有行动约束力。我把规划规则改成：每个季度，针对优先级前二的技能，让熟练度分数前进一档。

比如我当时的"构建配置"是2分，行为特征对应"能按文档完成标准场景"。我要把它推到3分，就得满足3分的行为特征：独立完成非标准场景。基于这个，学习路径就很具体了：

1. 找两个真实场景：给现有项目设置多环境变量，拆分公共代码做按需加载。
2. 不看现成模板，从空配置开始写。
3. 遇到卡点先排查，排查不了再查文档，全程记录问题清单。
4. 完成后写一篇配置复盘，包含做了什么、遇到哪两个坑、为什么这么配。

你看，因为"3分"对应了明确的行为特征，学习任务就全部围绕"创造非标准场景"展开，不再是漫无目的地刷教程。

4.2 季度计划模板：时间、行动、验证

我每个季度初在 plan.md 里写一张清单，结构固定，填写不超过十分钟。

## 2024-Q3 计划 ### 重点1：构建配置（当前: 2 -> 目标: 3） - 场景：为项目创建多环境构建方案 - 行动：改造现有配置，记录决策原因 - 验证：能独立从零搭建一套配置 ### 重点2：技术写作（当前: 1 -> 目标: 2） - 场景：写3篇问题复盘文章 - 行动：每周固定时间输出400字 - 验证：文章能被别人读懂并给出反馈

留意"每周固定时间输出400字"这种写法的好处：它小到不可能失败，又能积累出最终产出。我以前喜欢写"每周写一篇文章"，结果连续三周挂在"找选题"上。改成"先写400字"之后，反而很快进入了状态，选题也会在写的过程中自己浮现。

4.3 复盘机制：分数要跟得上行动，计划要跟得上现实

计划做得再好，如果三个月后才来检查，基本等于没做。我给自己设计了一个双频次的复盘节奏。

每周做一次"轻复盘"，十分钟搞定，记录三件事：这周做了哪个行动计划，卡在哪里，下周的微调是什么。这个复盘不用打分，只记录执行与障碍。

每月做一次"重评估"，把跟计划相关的技能重新打一次分。这里要注意，重打分必须重新对照行为标尺，不能凭"我感觉这几天有进步"顺手改分。如果行为特征没有变化，分数就保持不变。这样看起来很残酷，但它避免了虚假进步感——也正是这个制度，逼着我每月写一次"行为证据"清单，把做过的事情落到文档上。

一个季度结束时，把月度对比拉到一起，就只问一个问题：这季度的行为特征变了没有？变了，分数自然上升；没变，也别急于加码，先回来排查执行卡点。

5. 常见问题与排查技巧实录

5.1 清单越列越多，到底怎么收

我做第一版清单时，从"会做饭"到"会用视频剪辑软件"列了差不多70项，铺开一屏，看起来很有面子，实际上完全没法规划。后来我干了一件事：把所有"近三个月没用过且未来半年也预计不会用"的技能全部移入一个叫"存档区"的地方。

这招特别有效。存档区不是删除，它保留了你曾经投入过的事实，但把注意力的权重清零。技能管理不是做加法，而是学会做减法。核心区的数量，我建议控制在6到12项之间，否则优先级永远排不出来。

5.2 打分总在变化，评估结果不可信怎么办

如果你某一天打3分，过两天的同一技能又觉得"好像还是个2"，那不是你评估方法不对，而是你的参照系漂移了。解决这个问题只有一个办法：给每一分值的行为特征配一个"证据锚点"。

什么是证据锚点？就是一个作品、一次操作记录、或一段具体的经历描述。比如我给"构建配置"的3分锚点，是"某项目的多环境配置由我独立完成，并在评审中解释过缓存策略”。打分前先翻这些证据，就不会凭情绪乱给分。如果找不到证据，说明这个技能并不像你以为的那么熟练，老老实实降分。后来我就慢慢习惯了给每个锚点贴上产生日期和服务项目编号，复盘时按时间排序，几句话就把自己的成长线勾勒清楚，比任何量表都有说服力。

5.3 计划做了，执行三周就断线，怎么救

这是最普遍的坑，我也反复掉进去过。后来救回来靠三个小办法。

第一个，把执行单位缩到最小。不是"周末花两小时学习"，而是"每天午休后先打开项目配置弄20分钟"。启动阻力小了，执行率立刻上了一个台阶。第二个，搭一条公开的进度线。我在 README 里贴了一张"本周进展"记录表，它会迫使你每周至少更新一次，同侪压力比任何自律工具都管用。第三个，允许"降档执行"，不允许"零执行"。状态很差的时候，打开文档哪怕只写一行记录也算完成。这一行记录的意义在于维持链条不断，回头想恢复时，成本比从零开始要低太多。

为了方便你排查，我把三个高频问题整理成了速查表：

这些坑几乎每个人都踩过，区别只在于有人踩完还能爬起来，有人爬起来就忘了。这套系统的核心功能之一，就是把这些"坑"显性化，让你能一次次带着证据复盘，而不是一遍遍从头开始。

我个人实操下来最大的感受是：技能管理这件事，技术方案真的不是瓶颈，数据收集和持续迭代才是。一个技能雷达图，用 Python 一小时就能画完；但要让分数后面每一档都站着真实的证据，却需要几个月的时间来打磨。所以如果你也要搭自己的 skills 系统，我的建议是：不要先去找漂亮的工具，也不要急着画图，先把清单老老实实写出来，再给每一项想清楚"我凭什么这么打分"。这一步最便宜，也最值钱。