去年年初我建了一个名为 skills 的仓库本来只是想把会的东西列个清单结果它慢慢变成我复盘工作、规划学习的重要工具。很多开发者都有类似的经历简历上写着“熟练掌握”某项技能真要解释底层原理却支支吾吾想学新东西却不知道优先级年终复盘时只能靠记忆回想“这一年到底干了啥”。我解决这些问题的方式就是把技能状态固化到文本文件里再用简单脚本定期生成统计。这篇文章我会把项目的设计思路、字段定义、实操步骤和踩过的坑完整讲一遍。如果你也在被技能焦虑困扰或者想建立一套个人知识管理体系可以参考这套方法从零搭一个自己的 skills 系统。1. 为什么我要建一个 skills 项目1.1 技能焦虑背后的真实需求先说一个很现实的问题技能清单到底解决什么我最早用的其实是思维导图每次想到新技术就往上挂一个节点看起来特别完整。但用了一段时间发现思维导图只能记录“我接触过什么”完全记录不了“我现在处于什么水平”“这个技能多久没用了”。它本质上是静态的知识目录而不是动态的技能管理系统。真正让我下决心重做的是一次内部项目复盘。当时要评估团队里谁适合接一个新的数据处理任务大家都说自己会 Python会 SQL结果一聊细节有人只会用 Pandas 读 Excel有人连窗口函数都没写过。表面上是“会”实际上差距非常大。这件事给我的启发是技能不是一张“会/不会”的判断题而是一条有等级、有熟练度、有使用频率的连续状态。我们需要的不是贴在墙上的清单而是一个能持续追踪、随时回答“我当前在哪、接下来该补什么”的系统。skills 项目本质上就是一个“技能状态数据库”。每条技能记录都包含等级、熟练度、最近使用时间、关联项目等字段。通过定期更新这些字段我可以看到技能随时间的变化曲线哪项技能因为项目需要从生疏变成了熟练哪项技能三个月没碰正在退化。这种时间维度是普通笔记软件给不了的。1.2 工具选型为什么用纯文本加脚本有人会问市面上现成的技能管理 App 也很多为什么非要自己搭我试过几款最终放弃的原因有三个。第一数据所有权。App 的数据存在别人的服务器上一旦服务停止或者产品改版记录可能就没了。纯文本文件存在自己手里将来想迁移到任何工具都容易。第二定制成本。现成 App 的字段是定死的我想加一个“关联项目”字段或者定义一套自己的等级标准很多工具做不到。而用文本文件改格式只需要改一个模板。第三维护成本低。记录工具越花哨维护成本越高。一个 YAML 文件加一个 Python 脚本轻量到几乎感觉不到负担反而更容易坚持。我选的格式是 YAML原因是可读性好、支持注释、用 Python 解析非常简单。目录结构上数据文件和脚本分离数据文件里又分成技能主表和每周快照两个部分。主表保存当前最新的状态快照目录记录每次变更的历史。这样设计之后skills 项目就变成了一个“过去现在都能看”的系统只看主表知道当前水平对比快照知道变化趋势。2. 数据模型与字段设计2.1 技能条目的核心字段一个技能条目到底要记哪些信息我踩过不少坑之后最终沉淀下来的核心字段就八个id、name、category、level、proficiency、frequency、last_used、projects。字段含义示例id技能唯一标识建议用英文短横线pythonname展示名称Pythoncategory所属分类programminglevel1-5 的等级评分4proficiency0-100 的熟练度百分比75frequency使用频率dailylast_used最近一次使用日期2025-03-10projects关联的真实项目列表[data-pipeline]id 存在的意义是防止名称漂移。比如今天叫“Python”明天叫“Python 编程”同一个技能就分裂成了两条记录。用固定 id 做唯一标识脚本统计时就不会出错。name 可以随便改但 id 一旦确定就不要变。category 不是简单的标签而是用于分组统计的一级分类。我目前用的分类有编程语言、框架工具、领域知识、软技能、硬件设备。分类数量一定要克制超过八个就会让统计报表碎片化反而看不清楚结构。proficiency 和 last_used 这两个字段最容易造假也最关键。proficiency 填写时要对照事实不要凭感觉。我的校验方法是如果最近三个月的实际项目里没有用过这个技能熟练度最高只能填 50不管以前写过多少代码。last_used 则用来计算闲置天数是判断技能是否退化的核心依据。2.2 等级体系和熟练度怎么定义等级体系我用的是 1 到 5 分每个等级都有明确的场景化描述而不是“入门、中级、高级”这种模糊词。下面这版描述是我经过多次调整后定下来的等级描述1听过概念知道它能解决什么问题但没动手实践过2能照着教程或文档完成一个固定步骤的小任务3能在真实项目中独立使用不需要查资料就能完成常规操作4能根据实际场景做技术选型并解决非常规问题5能输出方法论、带新人并能针对瓶颈做深度优化等级和熟练度是互相校验的关系。比如 level 只有 2熟练度却填了 90这明显不合理说明评分标准没吃透。我的经验是熟练度可以理解为“在某个等级内我能稳定发挥的程度”而不是“绝对的水平”。一个 level 3 的人熟练度 90代表他在独立使用层面已经接近满格下一步才是冲击 level 4。还有一个容易被忽略的字段是 frequency。我把它分成 daily、weekly、monthly、rarely 四档。它的作用比想象中大即便两个技能 level 和 proficiency 都相同一个每天用、一个半年用一次实际竞争力完全不同。frequency 还可以辅助判断学习优先级——高等级但低频的技能往往比中等级但高频的技能更容易被高估。2.3 标签、分类与上下文分类解决的是“这个技能属于哪个领域”标签解决的是“哪些技能在业务上被捆绑使用”。我有很多技能其实是跨分类协作的比如数据分析场景需要 Python、SQL、统计学、数据可视化四个技能同时在场。这时候光靠 category 看不出关联我就给它们打上同一个标签>skills/ ├── data/ │ ├── skills.yaml │ ├── categories.yaml │ └── history/ │ ├── 2025-W01.yaml │ ├── 2025-W02.yaml │ └── ... ├── scripts/ │ ├── stats.py │ └── check.py └── README.mddata 目录放数据scripts 目录放脚本README 写使用说明。history 目录里保存的是每周快照文件名用 ISO 周数格式比如2025-W10.yaml表示 2025 年第 10 周。这样做的好处是文件按时间自然排序脚本扫描目录时非常方便。为什么把快照和主表分离因为主表总是最新的但我要回答“三个月前我的技能分布是什么样”这个问题时必须有历史快照。快照文件不需要写全量字段只记录 id、level、proficiency、last_used 这四列就够主要供 diff 对比使用。categories.yaml 单独放的意思是我希望先定义分类再在技能主表里引用分类。避免每个人随手写一个分类导致统计口径混乱categories: - id: programming name: 编程语言 - id: framework name: 框架工具 - id: domain name: 领域知识 - id: soft_skill name: 软技能 - id: hardware name: 硬件设备3.2 从零录入第一批技能第一步不是追求全而是追求真实。我建议先列出最近三个月实际用过的技能哪怕只有十项也不要凭记忆把三年前用过一次的东西写进去。因为 skills 系统的价值建立在数据可信的基础上数据污染比数据稀疏更致命。录入时每一条都按模板走- id: python name: Python category: programming level: 4 proficiency: 75 frequency: daily last_used: 2025-03-10 status: active projects: - id:>import yaml from collections import defaultdict with open(data/skills.yaml, r, encodingutf-8) as f: skills yaml.safe_load(f) stats defaultdict(lambda: {count: 0, level_sum: 0, proficiency_sum: 0, items: []}) for skill in skills: cat skill[category] stats[cat][count] 1 stats[cat][level_sum] skill[level] stats[cat][proficiency_sum] skill[proficiency] stats[cat][items].append(skill[id]) rows [| 分类 | 技能数 | 平均等级 | 平均熟练度 |] rows.append(| --- | --- | --- | --- |) for cat, data in sorted(stats.items()): avg_level data[level_sum] / data[count] avg_prof data[proficiency_sum] / data[count] rows.append(f| {cat} | {data[count]} | {avg_level:.1f} | {avg_prof:.1f} |) print(\n.join(rows))脚本运行方式就是在项目根目录执行python scripts/stats.py --data data/skills.yaml输出结果可以作为每周复盘的素材。我还会让脚本顺便输出一份“闲置技能 Top 10”的列表按 last_used 从早到晚排序标注每项技能已经多少天没碰。这个列表比平均分更能刺激我做出行动看着一项技能从 10 天没用于是变成 30 天、90 天心里那种“该捡起来了”的紧迫感非常真实。4. 复盘节奏与更新策略4.1 每周检视看频率和闲置度skills 项目最怕的不是不会设计而是更新停滞。我把复盘节奏固定成两个梯度每周小检视每季度大盘点。每周小检视我安排在周五下午前后不超过十五分钟。做的事情只有两件更新最近一周用过的技能的 last_used 和 frequency然后跑一次 stats.py 扫一遍“闲置技能 Top 10”。如果某项技能本周没用我并不强制修改它但至少要在心里确认一下是暂时不需要还是已经决定了放弃。这个节奏不能太快。曾经有一段时间我想每天更新结果坚持了三天就烦了因为大部分技能不会在一天内发生任何变化每天更新只是在制造噪音。每周一次的频率刚好能捕捉到变化又不会成为负担。我甚至允许“空更新”如果本周数据没有变化那就在 history 目录里复制上一周的快照并改个文件名至少保证时间线是连续的。4.2 季度盘点识别沉没技能和新增长点季度盘点是我最喜欢的环节因为它能回答一个长期问题我这三个月到底有没有变强盘点动作分四步。第一步对比最近三个月的快照找出 level 或 proficiency 上升超过 10% 的技能这些是实际增长的技能。第二步找出下降了 10% 以上的技能这些是正在退化的技能。第三步把 status 为 active 但是 60 天内没有出现过的技能标记为 dormant进入观察状态。第四步结合下一阶段的目标定出最多三个要重点提升的技能写入 README 的“季度目标”区块。一个很重要的经验是季度目标不要超过三个。我有一年野心很大列了七八个目标结果每项技能都被分成了一小块时间哪块都没做出成果。后来改成强制三项排在后面的即使再想学也要等前面的完成。这个约束看起来是限制实际上帮我把有限的精力集中在最关键的技能上进步反而更快。4.3 技能过期的处理策略技能不会一直有用。有的技术过时了有的领域我彻底不做了。刚开始我遇到这种情况会直接把技能删掉后来发现删除是最差的做法。因为一旦删除历史数据就断了将来想回顾“我为什么从某一个方向转出来”时没有任何记录可以支撑。我现在的做法是给每条技能加一个 status 字段取值有 active、dormant、archived 三种。active 是当前在用的dormant 是曾经使用但暂时搁置的archived 是基本退出主线的。归档不等于删除它只是把数据从核心统计中屏蔽掉。脚本里默认只统计 active 和 dormantarchived 不进入平均值计算避免拉低整体数据。比如我学过单片机开发但现在已经两年没碰了。如果它还在列表里意味着编程语言分类下有一个熟练度不低的技能统计出来会误导自己。把它归档后主表清爽了历史文件里还能查到当时的记录。这种做法更诚实也更利于长期维护。5. 常见问题与排查心得5.1 更新三分钟热度怎么办我估计八成读者最担心的问题都是这个搭好了系统然后一个月后懒得动了。这个问题我经历过不止一次。我的破解方法有三个。第一把记录动作的摩擦降到最低。模板一定不要复杂字段多了就会不想填。我曾经把它们扩展成二十多个字段结果每次更新都像做报表最后自然放弃了。后来又精简回八个核心字段才重新恢复每周更新。第二设定固定提醒。我在日历上设了每周五下午的重复事件到点就花十五分钟处理不需要临时决策。第三允许“低质量更新”。状态不好时我只更新日期和备注其他字段不动这就算完成。保持连贯性远比追求每次完美更重要。5.2 被“伪技能”带偏我在技能记录里犯过最多的错误是把“听说过、看过教程”当成“会”。最典型的一次我看完几个 Docker 的教学视频觉得自己已经会了给 Docker 打了个 level 3proficiency 70。结果真正做项目容器化时网络配置、数据卷挂载、镜像构建全都没踩明白整整卡了两天。回头看那两天其实是在为低效学习还债。从那以后我定了一条硬规则没有项目证据就不能把熟练度填到 60 以上。所谓项目证据可以是工作里的实际交付也可以是自己的开源项目、课程大作业甚至一次有效的技术分享。只要是“我动手做出来了一个有输入输出的事”就算证据。如果填 proficiency 时想不出证据那答案永远是“需要降级”。5.3 技能依赖关系的处理技能从来都不是孤立存在的。你可能发现某项技能一直学不会真正的原因是它的前置技能没打牢。我在 skills 项目里增加了一个 dependencies 字段专门用来记录前置技能- id: docker name: Docker category: framework level: 3 proficiency: 60 dependencies: - linux-basics - network-basics这个字段带来的实际好处是当我看到某项技能学习进度停滞我会去检查 dependencies 里的技能等级。如果 linux-basics 只有 2而 docker 想提升到 4那几乎是不可能的。于是学习计划就从“啃 Docker 文档”变成“先补 Linux 系统知识”。看起来绕了远路实际是最近的路径。还有一点不要把依赖关系变成链条过长。一级依赖就够了不需要 A 依赖 B、B 依赖 C、C 依赖 D 这样递归展开。否则维护成本飙升很快你就会放弃。我的做法是只记录直接依赖不写间接依赖数据简洁才能持续更新。最后分享一个小技巧我每次升级技能等级都会在 notes 里写下这次升级依据的项目。这样一年后回看看到的不是一串数字而是一条条可追溯的事实。个人经验是skills 项目最有价值的部分不是统计结果而是记录过程逼你诚实地面对自己。如果你也准备建一个从十个条目开始就够不需要一步到位。