“skills”是我最近一年里维护频率最高的个人项目。单看这个名字确实不起眼但它几乎解决了我最头疼的一类问题技能越堆越多、越学越焦虑最后却说不清楚自己到底会什么、不会什么、下一步该练什么。我不是把它做成一个花哨的App也没有引入复杂的任务管理平台核心就是一套以纯文本为主、配少量脚本的“技能档案系统”。它帮我完成三件事把模糊的“我想学很多东西”拆成可执行的技能项给每一类技能记录可验证的证据和熟练度用轻量脚本做周期性巡检逼着我去更新而不是遗忘。如果你跟我一样觉得自己学了跟没学一样或者想从一个只会“收藏资料”的状态切换到“真正积累能力”的状态这篇记录应该能给到一些可复用的思路。我尽量把设计逻辑、文件结构、代码示例和踩坑细节都写清楚方便你直接照着自己的情况复制一版。1. 项目起因为什么我非要建一个“skills”库1.1 最开始的场景技能焦虑大概是从两年前开始我对“好像什么都会一点又什么都拿不出手”这种感觉越来越强烈。今天刷到别人说某个框架好用我就想学框架明天看到一份岗位要求里写着“熟悉持续集成”我又觉得这是自己欠缺的部分。于是我的浏览器收藏夹里堆了上百个教程链接网盘里也存了好几个G的学习资料但真到了写简历或者接项目的时候能拿出来讲的东西依然很少。问题不在资料不够而在没有一个结构化的东西去承接这些输入。今天看一段教程明天做一个Demo后天又换了一个方向这些东西之间的关联、熟练程度、是否需要复习全部靠脑子来记。而人脑最不擅长做这种长期跟踪和对比的事情最后自然就变成了“学完就忘”。后来我开始尝试用备忘录和Excel去记录学习进度但都没坚持下来。备忘录太零散写进去就很难再回头整理Excel虽然可以做排序和筛选但每次打开要维护表头、行列、状态总觉得在做表格而不是在积累技能。核心矛盾是我需要一个既轻量、又可以长期维护、还能让我随时看清楚全局的机制。1.2 从待办清单到技能档案一开始我把它当成To-Do新建一个清单写上“学完某某课程”“读完某某书”完成一项就划掉一项。这样确实带来了一点掌控感但很快暴露了问题技能不是一次性的任务它是需要持续迭代的。比如我把“熟练掌握Docker”写成了待办等我能启动一个容器后我就把它勾掉了。但过了三个月当我需要在项目里写Compose编排、多阶段构建时我发现自己的理解远够不上“熟练”。问题就在于我从来没有定义一个“熟练”的标准也没有记录我在什么场景下真正用到过这个技能。所以我把思路做了一个转换不再把技能当作一个要“完成”的事件而是当作一份“档案”。每份档案是一个持续更新的页面记录技能本身、我的水平等级、最近一次练习时间、做过的实际案例以及下一步要补的短板。这样技能的积累变成了一条有迹可循的曲线而不是一堆互不关联的勾选记录。1.3 设计目标与选型原则在建“skills”之前我给自己定了几个很明确的原则避免又掉进“工具选型”的坑里。第一数据必须是我的不能只存在某个平台的服务器上第二格式必须足够通用最好能用文本编辑器打开和修改第三维护成本要低不能每次记录都要启动一个很重的应用第四要方便统计和巡检能让我一眼看出哪些技能长期没更新。按这个思路我最后选了Markdown加上JSON再用Git做版本管理。Markdown负责写技能详情因为它的可读性最好JSON负责存结构化的元数据比如技能分类、熟练度、状态、上次更新时间方便脚本去扫描和统计Git负责记录整个技能的演变历史。有人可能会问为什么不直接用飞书文档、Notion这类工具它们确实好用但对个人技能管理来说有几个隐性成本一是数据结构不透明导出麻烦二是它会分散你的注意力写着写着技能档案就变成了整理文档三是很难做自动化比如“自动找出30天没更新的技能”这个需求在文档工具里实现起来很别扭。我想要的是一套能在我本地随时跑的轻量系统这也是后面为什么加了一个几十行统计脚本的原因。2. 核心模块拆解skills 到底在管什么2.1 技能的结构化定义既然叫技能档案第一个问题就是一份“技能档案”里应该包含哪些字段我一开始写得很随意一个标题加一段感想结果发现回到主页时根本看不出来自己处于什么阶段。后来我反复迭代最终稳定到下面这一组字段。技能名称具体到动词加对象例如“编写Docker Compose编排文件”而不是“Docker”。分类基础能力、专业方向、工具链、软技能用来做横向对比。熟练度等级L1了解、L2上手、L3熟练、L4精通。当前状态学习中、可用、搁置、待复习。最近一次练习时间用于巡检脚本判断是否过期。证据链接写过的项目地址、笔记链接、面试中讲过的案例用来说明“我确实做过”。下一步动作一句话说清楚下一次尝试要提升什么。核心逻辑其实很简单技能没有客观分数你给自己定义清楚“下一步动作”之后能力提升才有抓手。举个例子我写“Python脚本自动化”熟练度标成L3“熟练”但如果没有证据这个L3就是编的。后来我给自己加了一条规则没有证据链接的熟练度最多只能标到L2想上L3必须有一个能拿出来展示的东西。2.2 技能分类与技能树技能多了以后分类就成了刚需。我给自己的所有技能分了四个大类每个大类下再拆出更细的小类形成一棵技能树。基础能力数据结构、算法、操作系统、网络基础、英语阅读。专业方向前端开发、后端开发、数据库设计、系统设计、数据分析。工具链Git、Docker、CI/CD、自动化测试、编辑器效率。软技能文档写作、沟通协作、复盘方法、项目推进。这里要特别说明一点分类不是一成不变的它会随着你对技能理解的加深而调整。我最初把“文档写作”归到了工具链里但后来发现它其实应该属于软技能因为它的学习方式和使用场景跟工具链差别很大。定期把技能树拿出来重构一次本身就是一次很好的能力盘点。针对每一种分类我还会做一个“技能水平矩阵”用二维表格把各个技能和熟练度等级对应起来。这样看全局的时候特别直观哪个大类长期空白、哪个技能很久没更新、哪块能力最需要补一目了然。2.3 学习闭环输入、实践、复盘建了分类和字段之后我发现记录系统本身还不够因为如果没有一套学习节奏档案最终会变成一个“摆设”。于是我把技能的积累过程拆成了三个环节输入、实践、复盘。输入指的是看文档、读源码、上课、拆项目它的产出是理解和笔记。实践是指把输入用起来写一个小项目、修一个Bug、做一次分享都是实践。复盘是指回到技能档案里更新熟练度、补充证据、写下失败点和下一步动作。我给自己定的节奏是输入之后必须有一到两次完整的实践否则下次复盘时不会更新这个技能的熟练度每个技能在最开始就写清楚“什么样的实践算完成”比如“用Docker部署一个带数据库的服务”这就比“多练习”要具体得多。这样整个系统才能形成一个闭环而不是只有记录和遗忘。3. 实操记录从零搭一个可用的 skills 系统3.1 目录结构与初始化如果要从头复制我的方案你只需要一个支持Markdown的文本编辑器、Git、以及随意一个能跑Python或者Shell脚本的环境。整个仓库的结构如下。skills/ ├── README.md ├── skills.json ├── templates/ │ └── skill-template.md ├── entries/ │ ├── docker-compose.md │ ├── python-automation.md │ ├── sql-query-optimization.md │ └── ... ├── scripts/ │ ├── update-metadata.py │ └── review-reminder.py └── archived/ └── old-idea-that-i-dropped.mdREADME.md是整棵技能树的展示页我会在右上角放一段自动生成的统计信息比如技能总数、各等级分布、30天未更新数量。skills.json存每个技能的元数据entries里是每份技能档案的完整Markdown内容。scripts里放两个脚本一个负责解析Markdown内容并更新JSON另一个负责生成复习提醒。archived用来归档那些我明确放弃的技能避免删除后丢失经验。初始化的时候我先创建了模板然后把当时能够想到的核心技能分成四个大类一篇一篇地补进去。这个过程别贪多我一开始写了二十多个结果很多细节根本填不上最后主动砍到了十来个。技能档案的质量远比数量重要。3.2 技能模板怎么写我建议每个技能档案的开头都放一个YAML或者JSON格式的元信息块这样脚本解析起来非常方便。下面是我在用的模板。--- name: 编写Docker Compose编排文件 category: 工具链 level: L3 status: 可用 last_practice: 2025-02-18 evidence: - https://github.com/yourname/deploy-example next_action: 用Compose完成一个带持久化卷的多服务部署 --- ## 当前掌握 能编写多容器编排配置理解网络、卷、环境变量等基本概念。 ## 实践记录 - 2025-02-18完成项目A的部署配置包含nginx、api、postgres三个服务。 - 2024-12-30复习Compose中depends_on的启动顺序问题。 ## 待提升 - 多阶段构建与Compose配合时的镜像大小控制。 - 如何优雅地处理配置更新而不中断服务。 ## 教训 不要把Compose文件只当作“启动命令”它本质上是基础设施配置的一部分要纳入版本管理不然环境漂移会带来很多问题。这个模板最有用的部分是“待提升”和“教训”。如果只有“掌握了什么”很容易写完就再也不看“待提升”是给自己留的钩子下一次实践可以直接从这里找方向“教训”则是把踩过的坑沉淀下来避免同样的问题反复出现。3.3 用脚本做状态统计光有Markdown还不够我需要一个方式快速知道整个技能库的健康状态。于是写了一个非常简单的Python脚本核心逻辑是用正则去解析Markdown开头的元信息然后汇总成统计结果。import json import re from pathlib import Path from datetime import datetime, date SKILLS_JSON Path(skills.json) ENTRIES_DIR Path(entries) skills [] for md in ENTRIES_DIR.glob(*.md): text md.read_text(encodingutf-8) meta_match re.search(r^---\n(.*?)\n---, text, re.S | re.M) if not meta_match: continue meta dict( re.findall(r^(\w):\s*(.*)$, meta_match.group(1), re.M) ) skills.append({ name: meta.get(name, md.stem), category: meta.get(category, 未分类), level: meta.get(level, L1), status: meta.get(status, 未知), last_practice: meta.get(last_practice, 1970-01-01), }) skills.sort(keylambda x: x[last_practice], reverseTrue) with SKILLS_JSON.open(w, encodingutf-8) as f: json.dump(skills, f, ensure_asciiFalse, indent2) today date.today() stale [] for s in skills: last_date datetime.strptime(s[last_practice], %Y-%m-%d).date() if (today - last_date).days 30: stale.append(s) print(f技能总数: {len(skills)}) print(f30天未更新: {len(stale)}) for s in stale: print(f - {s[name]} (上次: {s[last_practice]}))这个脚本解决了我最大的痛点让我不用打开每个文件就能知道哪些技能正在“腐烂”。很多人以为技能是学过了就一直有效但实践后才发现长期不用的熟练度会退得很快。定期看到“30天未更新”的列表比任何打卡系统都管用。3.4 复习提醒与巡检光统计还不够我后来加了第二个脚本专门用来生成复习列表。它的逻辑很简单按“间隔重复”的思想如果一个技能最近一次实践时间是7天内它就不需要打扰我7到30天之间的属于“该看一眼”超过30天的属于“重点复习”。我是用Shell配合cron跑这个脚本的每周五下午会收到一条提醒。平时不主动看客户端只在固定时间做巡检这样做的好处是既能保持系统在运转又不会让“维护技能库”本身变成一种逃避学习的仪式感。#!/bin/bash cd ~/skills python3 scripts/update-metadata.py python3 scripts/review-reminder.py复习提醒的输出会根据状态给出不同建议比如“该技能超过30天没有实践建议本周安排一个30分钟的练习场景”。这里的关键不是让你去“看资料”而是安排一个具体的练习场景。因为没有场景的复习本质上只是在骗自己“我看过了”。3.5 与现有工具打通让这套系统真正融入日常工作还需要和本来就高频使用的工具打通。我把skills仓库作为本地Git仓库同时定期推到私有仓库做备份。每次提交的时候Commit message直接写当天做了哪个技能的实践比如“perf: 练习Docker Compose卷挂载细节”。这样Git历史本身就变成了一份时间线回头复盘的时候能非常清楚地看到自己把时间花在了哪里。代码编辑器方面我用VS Code编辑Markdown通过Todo Tree插件把“待提升”里的条目高亮出来。平时写代码时如果想到某个技能点会随手打开对应的档案追加一行备注。我不追求任何时候都立刻更新但会保证当天做过的实践最晚在当天结束前同步进去。如果你习惯用Obsidian也可以直接把这个仓库放到Obsidian的Vault里配合双链功能把技能档案和笔记系统打通。我试过这种方式它的好处是可以在技能档案里引用具体的学习笔记坏处是Obsidian的数据库文件有时候会带来额外的同步负担。个人体感是纯Markdown加Git仓库再加一个简单的文件浏览已经足够干净和高效。4. 常见问题与避坑指南4.1 技能太多不知道怎么分类我在刚开始整理时最常犯的错是分类过细比如前端里再分“框架”“状态管理”“样式方案”“构建工具”最后每个小类下面只有一两条记录维护成本反而变大。后来我调整策略大类保持四到六个小类只在必要时出现同一个技能如果横跨多个类就选它当前最需要提升的那个类而不是试图定义得面面俱到。如果遇到一个技能你明显想分成好几个方向那大概率说明它已经不止是一个“技能”而是一个“技能族”。比如“数据分析”这个词太大了它下面可能包含SQL、Python、可视化、统计学基础应该拆成多个独立档案。拆分的标准是每个档案都必须有独一无二的“证据链接”和“下一步动作”如果两个技能共享同一份证据那它们就应该合并。4.2 记了模板但坚持不下去很多人在尝试这种系统时会遇到同一个情况头三天记录很勤快后面就荒废了。我的体会是坚持不下去不是因为懒而是因为系统里塞了太多“伪技能”。所谓伪技能就是你其实根本没有明确的练习场景和学习计划只觉得自己“应该学”。解决办法是缩减库存。我把所有技能档案翻出来强制自己给每一项写“最近一次实践”和“证据链接”写不出来的全部归档。经过这轮清理真正有资格待在主列表里的技能少了一大半但每一项都是我近期实际在用的东西。宁可维护五份有证据的技术档案也不要维护五十份只写了一行标题的空壳。另外我给自己立了一个规矩每次新增技能前必须先写清楚为什么现在需要它以及准备拿它做什么。答不出来就不允许开新档案。这一条帮我把很多冲动学习挡在门外特别有效。4.3 实战验证比记录更重要这个系统能记录“我知道什么”但真正决定能力的是“我做过什么”。我见过很多人把技能档案整理得非常漂亮熟练度也标得很高但遇到真问题依然出不了手。所以我给自己设了一个很硬性的规则熟练度从L2升到L3必须有一个实际项目或者一份有效证据而不是自己觉得“差不多会了”。实践场景怎么找不一定非要重新造一个大项目。我可以从日常工作中找比如给团队写一个脚本、修复一个长期存在的Bug、把手工操作流程变成自动化脚本这些都可以当成证据。我还可以从已有代码里去挖把一个自己写过的小模块重构一遍然后记录重构前后的差异这样证据就有了。关键是不要想着“等我准备好了再实践”而是把当前手头一个最小的问题当成练习场。4.4 常见问题速查表问题原因我的解决方案技能档案写了一堆但不想回看缺少定期巡检机制每周固定时间跑复习提醒脚本强制浏览熟练度越标越高心里发虚没有硬性证据门槛没有证据不升L3升级前必须补实践记录分类太细维护成本高把技能族和技能混为一谈按“是否有独立证据”拆分或合并学了一段时间感觉没进步只有输入没有实践每项技能必须定义清楚的实践场景想新增技能怕三分钟热度缺少加入门槛必须写“为什么现在需要”和“下一步动作”我在实际维护过程中发现这张表和档案系统一样也需要定期更新。因为随着你的能力边界不断变化旧规则会变得不再合适。比如一开始“能否写出完整Compose文件”可能就算合格但后面你一定会遇到更复杂的部署场景这时候就要把标准往上提。写在最后如果你也准备建一个自己的“skills”仓库我比较推荐从最小版本开始一个README、一个template、三个真实技能的档案一个能统计更新状态的脚本。不要一上来就设计几十个字段也不要想着把分类一次做完美。先跑一个月感受一下自己在什么时候愿意更新、什么时候不想碰它再根据真实反馈去调整。我个人最受益的一个习惯是每周五下午花十分钟跑一遍巡检脚本看到那些超过30天没更新的技能后挑一个最容易的给它安排一个半小时的实践。哪怕只是把一条旧命令重新跑一遍也比打一堆“今天学习了”的卡有价值。这个系统真正改变我的不是记录的方式而是让我开始把“知道一个概念”和“拥有一个技能”分得清清楚楚。
用Markdown+JSON+Git搭建个人技能档案系统，告别学习焦虑
“skills”是我最近一年里维护频率最高的个人项目。单看这个名字确实不起眼但它几乎解决了我最头疼的一类问题技能越堆越多、越学越焦虑最后却说不清楚自己到底会什么、不会什么、下一步该练什么。我不是把它做成一个花哨的App也没有引入复杂的任务管理平台核心就是一套以纯文本为主、配少量脚本的“技能档案系统”。它帮我完成三件事把模糊的“我想学很多东西”拆成可执行的技能项给每一类技能记录可验证的证据和熟练度用轻量脚本做周期性巡检逼着我去更新而不是遗忘。如果你跟我一样觉得自己学了跟没学一样或者想从一个只会“收藏资料”的状态切换到“真正积累能力”的状态这篇记录应该能给到一些可复用的思路。我尽量把设计逻辑、文件结构、代码示例和踩坑细节都写清楚方便你直接照着自己的情况复制一版。1. 项目起因为什么我非要建一个“skills”库1.1 最开始的场景技能焦虑大概是从两年前开始我对“好像什么都会一点又什么都拿不出手”这种感觉越来越强烈。今天刷到别人说某个框架好用我就想学框架明天看到一份岗位要求里写着“熟悉持续集成”我又觉得这是自己欠缺的部分。于是我的浏览器收藏夹里堆了上百个教程链接网盘里也存了好几个G的学习资料但真到了写简历或者接项目的时候能拿出来讲的东西依然很少。问题不在资料不够而在没有一个结构化的东西去承接这些输入。今天看一段教程明天做一个Demo后天又换了一个方向这些东西之间的关联、熟练程度、是否需要复习全部靠脑子来记。而人脑最不擅长做这种长期跟踪和对比的事情最后自然就变成了“学完就忘”。后来我开始尝试用备忘录和Excel去记录学习进度但都没坚持下来。备忘录太零散写进去就很难再回头整理Excel虽然可以做排序和筛选但每次打开要维护表头、行列、状态总觉得在做表格而不是在积累技能。核心矛盾是我需要一个既轻量、又可以长期维护、还能让我随时看清楚全局的机制。1.2 从待办清单到技能档案一开始我把它当成To-Do新建一个清单写上“学完某某课程”“读完某某书”完成一项就划掉一项。这样确实带来了一点掌控感但很快暴露了问题技能不是一次性的任务它是需要持续迭代的。比如我把“熟练掌握Docker”写成了待办等我能启动一个容器后我就把它勾掉了。但过了三个月当我需要在项目里写Compose编排、多阶段构建时我发现自己的理解远够不上“熟练”。问题就在于我从来没有定义一个“熟练”的标准也没有记录我在什么场景下真正用到过这个技能。所以我把思路做了一个转换不再把技能当作一个要“完成”的事件而是当作一份“档案”。每份档案是一个持续更新的页面记录技能本身、我的水平等级、最近一次练习时间、做过的实际案例以及下一步要补的短板。这样技能的积累变成了一条有迹可循的曲线而不是一堆互不关联的勾选记录。1.3 设计目标与选型原则在建“skills”之前我给自己定了几个很明确的原则避免又掉进“工具选型”的坑里。第一数据必须是我的不能只存在某个平台的服务器上第二格式必须足够通用最好能用文本编辑器打开和修改第三维护成本要低不能每次记录都要启动一个很重的应用第四要方便统计和巡检能让我一眼看出哪些技能长期没更新。按这个思路我最后选了Markdown加上JSON再用Git做版本管理。Markdown负责写技能详情因为它的可读性最好JSON负责存结构化的元数据比如技能分类、熟练度、状态、上次更新时间方便脚本去扫描和统计Git负责记录整个技能的演变历史。有人可能会问为什么不直接用飞书文档、Notion这类工具它们确实好用但对个人技能管理来说有几个隐性成本一是数据结构不透明导出麻烦二是它会分散你的注意力写着写着技能档案就变成了整理文档三是很难做自动化比如“自动找出30天没更新的技能”这个需求在文档工具里实现起来很别扭。我想要的是一套能在我本地随时跑的轻量系统这也是后面为什么加了一个几十行统计脚本的原因。2. 核心模块拆解skills 到底在管什么2.1 技能的结构化定义既然叫技能档案第一个问题就是一份“技能档案”里应该包含哪些字段我一开始写得很随意一个标题加一段感想结果发现回到主页时根本看不出来自己处于什么阶段。后来我反复迭代最终稳定到下面这一组字段。技能名称具体到动词加对象例如“编写Docker Compose编排文件”而不是“Docker”。分类基础能力、专业方向、工具链、软技能用来做横向对比。熟练度等级L1了解、L2上手、L3熟练、L4精通。当前状态学习中、可用、搁置、待复习。最近一次练习时间用于巡检脚本判断是否过期。证据链接写过的项目地址、笔记链接、面试中讲过的案例用来说明“我确实做过”。下一步动作一句话说清楚下一次尝试要提升什么。核心逻辑其实很简单技能没有客观分数你给自己定义清楚“下一步动作”之后能力提升才有抓手。举个例子我写“Python脚本自动化”熟练度标成L3“熟练”但如果没有证据这个L3就是编的。后来我给自己加了一条规则没有证据链接的熟练度最多只能标到L2想上L3必须有一个能拿出来展示的东西。2.2 技能分类与技能树技能多了以后分类就成了刚需。我给自己的所有技能分了四个大类每个大类下再拆出更细的小类形成一棵技能树。基础能力数据结构、算法、操作系统、网络基础、英语阅读。专业方向前端开发、后端开发、数据库设计、系统设计、数据分析。工具链Git、Docker、CI/CD、自动化测试、编辑器效率。软技能文档写作、沟通协作、复盘方法、项目推进。这里要特别说明一点分类不是一成不变的它会随着你对技能理解的加深而调整。我最初把“文档写作”归到了工具链里但后来发现它其实应该属于软技能因为它的学习方式和使用场景跟工具链差别很大。定期把技能树拿出来重构一次本身就是一次很好的能力盘点。针对每一种分类我还会做一个“技能水平矩阵”用二维表格把各个技能和熟练度等级对应起来。这样看全局的时候特别直观哪个大类长期空白、哪个技能很久没更新、哪块能力最需要补一目了然。2.3 学习闭环输入、实践、复盘建了分类和字段之后我发现记录系统本身还不够因为如果没有一套学习节奏档案最终会变成一个“摆设”。于是我把技能的积累过程拆成了三个环节输入、实践、复盘。输入指的是看文档、读源码、上课、拆项目它的产出是理解和笔记。实践是指把输入用起来写一个小项目、修一个Bug、做一次分享都是实践。复盘是指回到技能档案里更新熟练度、补充证据、写下失败点和下一步动作。我给自己定的节奏是输入之后必须有一到两次完整的实践否则下次复盘时不会更新这个技能的熟练度每个技能在最开始就写清楚“什么样的实践算完成”比如“用Docker部署一个带数据库的服务”这就比“多练习”要具体得多。这样整个系统才能形成一个闭环而不是只有记录和遗忘。3. 实操记录从零搭一个可用的 skills 系统3.1 目录结构与初始化如果要从头复制我的方案你只需要一个支持Markdown的文本编辑器、Git、以及随意一个能跑Python或者Shell脚本的环境。整个仓库的结构如下。skills/ ├── README.md ├── skills.json ├── templates/ │ └── skill-template.md ├── entries/ │ ├── docker-compose.md │ ├── python-automation.md │ ├── sql-query-optimization.md │ └── ... ├── scripts/ │ ├── update-metadata.py │ └── review-reminder.py └── archived/ └── old-idea-that-i-dropped.mdREADME.md是整棵技能树的展示页我会在右上角放一段自动生成的统计信息比如技能总数、各等级分布、30天未更新数量。skills.json存每个技能的元数据entries里是每份技能档案的完整Markdown内容。scripts里放两个脚本一个负责解析Markdown内容并更新JSON另一个负责生成复习提醒。archived用来归档那些我明确放弃的技能避免删除后丢失经验。初始化的时候我先创建了模板然后把当时能够想到的核心技能分成四个大类一篇一篇地补进去。这个过程别贪多我一开始写了二十多个结果很多细节根本填不上最后主动砍到了十来个。技能档案的质量远比数量重要。3.2 技能模板怎么写我建议每个技能档案的开头都放一个YAML或者JSON格式的元信息块这样脚本解析起来非常方便。下面是我在用的模板。--- name: 编写Docker Compose编排文件 category: 工具链 level: L3 status: 可用 last_practice: 2025-02-18 evidence: - https://github.com/yourname/deploy-example next_action: 用Compose完成一个带持久化卷的多服务部署 --- ## 当前掌握 能编写多容器编排配置理解网络、卷、环境变量等基本概念。 ## 实践记录 - 2025-02-18完成项目A的部署配置包含nginx、api、postgres三个服务。 - 2024-12-30复习Compose中depends_on的启动顺序问题。 ## 待提升 - 多阶段构建与Compose配合时的镜像大小控制。 - 如何优雅地处理配置更新而不中断服务。 ## 教训 不要把Compose文件只当作“启动命令”它本质上是基础设施配置的一部分要纳入版本管理不然环境漂移会带来很多问题。这个模板最有用的部分是“待提升”和“教训”。如果只有“掌握了什么”很容易写完就再也不看“待提升”是给自己留的钩子下一次实践可以直接从这里找方向“教训”则是把踩过的坑沉淀下来避免同样的问题反复出现。3.3 用脚本做状态统计光有Markdown还不够我需要一个方式快速知道整个技能库的健康状态。于是写了一个非常简单的Python脚本核心逻辑是用正则去解析Markdown开头的元信息然后汇总成统计结果。import json import re from pathlib import Path from datetime import datetime, date SKILLS_JSON Path(skills.json) ENTRIES_DIR Path(entries) skills [] for md in ENTRIES_DIR.glob(*.md): text md.read_text(encodingutf-8) meta_match re.search(r^---\n(.*?)\n---, text, re.S | re.M) if not meta_match: continue meta dict( re.findall(r^(\w):\s*(.*)$, meta_match.group(1), re.M) ) skills.append({ name: meta.get(name, md.stem), category: meta.get(category, 未分类), level: meta.get(level, L1), status: meta.get(status, 未知), last_practice: meta.get(last_practice, 1970-01-01), }) skills.sort(keylambda x: x[last_practice], reverseTrue) with SKILLS_JSON.open(w, encodingutf-8) as f: json.dump(skills, f, ensure_asciiFalse, indent2) today date.today() stale [] for s in skills: last_date datetime.strptime(s[last_practice], %Y-%m-%d).date() if (today - last_date).days 30: stale.append(s) print(f技能总数: {len(skills)}) print(f30天未更新: {len(stale)}) for s in stale: print(f - {s[name]} (上次: {s[last_practice]}))这个脚本解决了我最大的痛点让我不用打开每个文件就能知道哪些技能正在“腐烂”。很多人以为技能是学过了就一直有效但实践后才发现长期不用的熟练度会退得很快。定期看到“30天未更新”的列表比任何打卡系统都管用。3.4 复习提醒与巡检光统计还不够我后来加了第二个脚本专门用来生成复习列表。它的逻辑很简单按“间隔重复”的思想如果一个技能最近一次实践时间是7天内它就不需要打扰我7到30天之间的属于“该看一眼”超过30天的属于“重点复习”。我是用Shell配合cron跑这个脚本的每周五下午会收到一条提醒。平时不主动看客户端只在固定时间做巡检这样做的好处是既能保持系统在运转又不会让“维护技能库”本身变成一种逃避学习的仪式感。#!/bin/bash cd ~/skills python3 scripts/update-metadata.py python3 scripts/review-reminder.py复习提醒的输出会根据状态给出不同建议比如“该技能超过30天没有实践建议本周安排一个30分钟的练习场景”。这里的关键不是让你去“看资料”而是安排一个具体的练习场景。因为没有场景的复习本质上只是在骗自己“我看过了”。3.5 与现有工具打通让这套系统真正融入日常工作还需要和本来就高频使用的工具打通。我把skills仓库作为本地Git仓库同时定期推到私有仓库做备份。每次提交的时候Commit message直接写当天做了哪个技能的实践比如“perf: 练习Docker Compose卷挂载细节”。这样Git历史本身就变成了一份时间线回头复盘的时候能非常清楚地看到自己把时间花在了哪里。代码编辑器方面我用VS Code编辑Markdown通过Todo Tree插件把“待提升”里的条目高亮出来。平时写代码时如果想到某个技能点会随手打开对应的档案追加一行备注。我不追求任何时候都立刻更新但会保证当天做过的实践最晚在当天结束前同步进去。如果你习惯用Obsidian也可以直接把这个仓库放到Obsidian的Vault里配合双链功能把技能档案和笔记系统打通。我试过这种方式它的好处是可以在技能档案里引用具体的学习笔记坏处是Obsidian的数据库文件有时候会带来额外的同步负担。个人体感是纯Markdown加Git仓库再加一个简单的文件浏览已经足够干净和高效。4. 常见问题与避坑指南4.1 技能太多不知道怎么分类我在刚开始整理时最常犯的错是分类过细比如前端里再分“框架”“状态管理”“样式方案”“构建工具”最后每个小类下面只有一两条记录维护成本反而变大。后来我调整策略大类保持四到六个小类只在必要时出现同一个技能如果横跨多个类就选它当前最需要提升的那个类而不是试图定义得面面俱到。如果遇到一个技能你明显想分成好几个方向那大概率说明它已经不止是一个“技能”而是一个“技能族”。比如“数据分析”这个词太大了它下面可能包含SQL、Python、可视化、统计学基础应该拆成多个独立档案。拆分的标准是每个档案都必须有独一无二的“证据链接”和“下一步动作”如果两个技能共享同一份证据那它们就应该合并。4.2 记了模板但坚持不下去很多人在尝试这种系统时会遇到同一个情况头三天记录很勤快后面就荒废了。我的体会是坚持不下去不是因为懒而是因为系统里塞了太多“伪技能”。所谓伪技能就是你其实根本没有明确的练习场景和学习计划只觉得自己“应该学”。解决办法是缩减库存。我把所有技能档案翻出来强制自己给每一项写“最近一次实践”和“证据链接”写不出来的全部归档。经过这轮清理真正有资格待在主列表里的技能少了一大半但每一项都是我近期实际在用的东西。宁可维护五份有证据的技术档案也不要维护五十份只写了一行标题的空壳。另外我给自己立了一个规矩每次新增技能前必须先写清楚为什么现在需要它以及准备拿它做什么。答不出来就不允许开新档案。这一条帮我把很多冲动学习挡在门外特别有效。4.3 实战验证比记录更重要这个系统能记录“我知道什么”但真正决定能力的是“我做过什么”。我见过很多人把技能档案整理得非常漂亮熟练度也标得很高但遇到真问题依然出不了手。所以我给自己设了一个很硬性的规则熟练度从L2升到L3必须有一个实际项目或者一份有效证据而不是自己觉得“差不多会了”。实践场景怎么找不一定非要重新造一个大项目。我可以从日常工作中找比如给团队写一个脚本、修复一个长期存在的Bug、把手工操作流程变成自动化脚本这些都可以当成证据。我还可以从已有代码里去挖把一个自己写过的小模块重构一遍然后记录重构前后的差异这样证据就有了。关键是不要想着“等我准备好了再实践”而是把当前手头一个最小的问题当成练习场。4.4 常见问题速查表问题原因我的解决方案技能档案写了一堆但不想回看缺少定期巡检机制每周固定时间跑复习提醒脚本强制浏览熟练度越标越高心里发虚没有硬性证据门槛没有证据不升L3升级前必须补实践记录分类太细维护成本高把技能族和技能混为一谈按“是否有独立证据”拆分或合并学了一段时间感觉没进步只有输入没有实践每项技能必须定义清楚的实践场景想新增技能怕三分钟热度缺少加入门槛必须写“为什么现在需要”和“下一步动作”我在实际维护过程中发现这张表和档案系统一样也需要定期更新。因为随着你的能力边界不断变化旧规则会变得不再合适。比如一开始“能否写出完整Compose文件”可能就算合格但后面你一定会遇到更复杂的部署场景这时候就要把标准往上提。写在最后如果你也准备建一个自己的“skills”仓库我比较推荐从最小版本开始一个README、一个template、三个真实技能的档案一个能统计更新状态的脚本。不要一上来就设计几十个字段也不要想着把分类一次做完美。先跑一个月感受一下自己在什么时候愿意更新、什么时候不想碰它再根据真实反馈去调整。我个人最受益的一个习惯是每周五下午花十分钟跑一遍巡检脚本看到那些超过30天没更新的技能后挑一个最容易的给它安排一个半小时的实践。哪怕只是把一条旧命令重新跑一遍也比打一堆“今天学习了”的卡有价值。这个系统真正改变我的不是记录的方式而是让我开始把“知道一个概念”和“拥有一个技能”分得清清楚楚。
