可能很多人第一次看到“skills”这个项目名都会觉得含义太宽泛但对我来说它恰好代表了我这几年在做的一件很朴素的事把“我会什么”“我多会”“我凭什么说我会”这三件事用一套系统管理起来。这个项目最初只是一个命令行小工具用来记录我的技术技能清单后来慢慢长成了一个带等级、带证据、带时间戳、能生成个人技能画像的轻量系统。它解决的核心问题很简单面试、写简历、年中述职的时候我常常说不清楚自己到底在哪个水平线上全靠记忆和感觉结果就是自我评价忽高忽低和别人的认知对不上。这篇文章我把它作为一次完整的实操复盘写出来适合想建立个人技能档案、带小团队做能力盘点、或者打算做技能管理工具的人参考。1. 项目背景为什么我会做一个叫 skills 的项目1.1 最开始的痛点我属于平时喜欢往开阔地带走的人今天学一点 Python明天碰一下容器化后天又看两眼前端框架。学习本身是快乐的但副作用也很明显知识面看着很广每一条都浅尝辄止。直到有一次准备季度述职领导让我把“核心能力”列一列我打开旧的简历文档发现上面写的还是三年前的描述实际掌握的内容早就变了但又说不出自己究竟进展了多少。那一周我做了一个很蠢的尝试把电脑里所有项目目录过了一遍试图从工程实践中反推技能水平。结果更糟糕项目目录多到几十个有的一次性的脚本有的是给别人搭的临时工具有的只开了个头。靠翻文件的方式评估自己等于用记忆去还原一张本来就没存的图完全做不到。也是那段时间我帮团队整理培训需求发现大家对自己能力的描述五花八门有的人把“用过”说成“熟练”有的人明明掌握了工具链却说自己只会皮毛。这种主观性不只是沟通问题它会直接影响任务分派和成长规划。我当时就在想如果有一份结构化的、带证据链的技能清单这些问题是不是能直接解决一半。1.2 这个项目到底解决什么问题skills 要解决的不是“给技能打分”这么简单。它要解决的是一连串问题怎么用同一套标准描述不同领域的能力而不是这个工具一个标准、那个框架另一个标准怎么让自我评价不再凭感觉而是有据可查、经得起别人问怎么让技能清单不是一潭死水而是能持续更新、能回溯历史怎么让技能盘点不仅服务于个人还能用于团队任务指派、培训规划因此我做了三个核心设计决策。第一数据全部落成本地文件用版本管理工具维护每次改动都有记录。第二每一项技能必须绑定至少一条“证据”证据是客观存在的工程产物、事件或反馈。第三等级描述采用业界成熟的五级模型并且为每个等级写清楚行为特征不搞抽象数字。这三个决策贯穿了后续所有代码和数据结构。你可以把 skills 理解成一个“能力界的账本”每次新增一条技能都像记一笔账必须有凭证、有时间、有来源。1.3 适合谁用从我实际体验来看有三类人最值得在这个思路上下功夫技术从业者每年做个人复盘、换工作写简历、和 leader 对齐成长预期。团队负责人想了解组内成员的真实能力分布辅助分派任务、制定培训方向。自由职业者需要不断向客户解释“我能做什么、我哪方面最强”证据化技能清单要比口头说服更有力。如果你只是想找一个现成的指标系统打分这个项目可能不太合适如果你想建立一套属于自己的、能持续运转的能力记录方式这篇文章的代码和思路你基本可以照着搬。2. 整体设计与核心取舍2.1 数据模型技能、等级、证据、时间戳最开始我画了一张简单的 ER 图后来发现需要管理的实体并不复杂核心就是四个字段组合在一起。一个技能记录长这样- name: Python category: 编程语言 level: competent evidence: - 2024-11 为某数据清洗工具新增并发处理模块线上稳定运行两个月 - 2025-01 独立完成某内部脚本框架的重构测试覆盖率达到 85% updated: 2025-01-08字段拆解一下name技能名称尽量用公认的叫法比如 Python、SQL、项目管理不要自创“高效沟通与协调”这种模糊词。category所属分类我用“编程语言”“前端技术”“数据技术”“开发工具”“软技能”“领域知识”六类后续可以自己改。level五级等级中的一个具体标准见 2.3。evidence证据列表这是整个模型的灵魂。每条证据应该包含大致的发生时间、项目/场景、具体做了什么、可观察的结果。没有证据的技能会让人缺乏信任感。updated最近一次更新的日期用于判断这条技能是不是已经“过期”也方便生成周报、月报的变化统计。这套模型是可以直接迁移到关系型数据库的但第一阶段用本地文件就足够了。本质上任何能支持“列表键值对”的数据格式都可以我只是选了 YAML。2.2 为什么用 YAML 而不是数据库很多人一听到“做系统”第一反应就是上数据库。我在这个项目里反其道而行刻意选了 YAML 文本文件。理由很简单个人系统数据量极小几千条技能撑死了也到不了数据库的规模。文本文件可以直接放进版本管理工具技能的每一次变更历史都可以被追踪这是上难度很高才能实现的效果。可以在命令行里直接用文本编辑器改不需要写任何管理后台。对新手友好打开文件就能看懂结构不会把问题复杂化。当然 YAML 也有缺点比如缩进错了就解析失败、转义字符处理麻烦。所以我在代码里加入了“读取前校验”和“错误提示定位”并在 CLI 命令里尽量用结构化的增删改绕开手改文件的麻烦。如果你一定要用数据库我觉得也可以SQLite 是比 MySQL 更好的选择因为零部署、单文件、可移动。但对我来说YAML 这套方案已经够用了能持续维护才是最重要的。2.3 等级体系借了成熟模型的五级框架我在 1.2 提到的五级模型就是工程领域常说的技能发展模型。等级名称和典型特征我给它们做成了下表等级我的判断依据新手novice需要步骤指引无法独立完成遇到问题容易卡住高级新手advanced能完成常见任务但遇到边界情况依赖搜索或求助解决方案缺乏全局性胜任competent能独立完成任务能处理教科书之外的场景会考虑多个方案并权衡精通proficient能整体把控一个领域能总结出方法论能指导他人并能预防潜在问题专家expert能创造新方法、新思路是团队或社区公认的“破局者”对非常规问题有直觉级判断需要强调的是我用的不是简单的“熟悉/掌握/精通”因为那个口径每个人理解都不一样。等级判断的唯一推荐方式是结合证据。比如你自己觉得“Python 是精通”但没有产出过有影响力的项目也没解决过疑难问题那大概率是胜任而不是精通。2.4 目录结构与命令设计实际项目目录长这样skills/ ├── cli.py ├── core.py ├── models.py ├── config.py ├── templates/ │ ├── profile.md │ └── weekly.md └── data/ └── skills.yaml关于命令我做的是尽量小、尽量分而治之的 CLIskills init skills add 编程语言/Python --level competent --evidence 2025-01 独立完成某数据采集工具 skills update 编程语言/Python --level proficient skills rm 编程语言/废弃技能 skills ls --category 编程语言 skills snapshot skills report --format markdown skills suggest一条命令对应一个动作没有任何隐式状态。如果你也打算照着写建议保持这个原则宁可命令多一点也不要搞出一个“魔法命令”让你看不懂自己在干什么。3. 核心实现让 skills 工具真正跑起来3.1 命令行入口与数据读写流程我用的是 Python 标准库 argparse没有引全功能框架这样部署成本最低。整个程序的读写流程可以理解为三步读取 YAML 文件转换成 Python 字典。执行增删改查操作更新字典。重新序列化写回原文件。这个流程简单有效但有一个细节必须处理写回文件的时候不能破坏原有的注释和格式。YAML 库在 dump 的时候默认会丢弃注释我用的是自定义的“节点级”操作方法尽量避免整文件重写。如果你也想做类似工具我的建议是尽早确定好“最小改动”策略否则每执行一次命令文件就乱一次最后你都懒得开了。核心代码的骨架大概长这样def load_data(path): with open(path, encodingutf-8) as f: return yaml.safe_load(f) def save_data(path, data): with open(path, w, encodingutf-8) as f: yaml.safe_dump(data, f, allow_unicodeTrue, sort_keysFalse)注意sort_keysFalse这个参数默认情况下 yaml 会把字典按字母排那样会把你的分类顺序打乱体验很糟糕。3.2 让“证据”成为强制字段这是整个系统里最“反人性”但最有效的一步。在 add 命令里我把--evidence设为必填参数如果你不填命令直接拒绝执行。$ skills add 编程语言/Go --level competent 错误至少需要一条证据evidence 不能为空。一开始我也觉得强制证据太麻烦但用了一段时间后我发现它倒逼我在“记一次技能”的时候同步想起“我到底在什么场景用过”。如果没有这条证据以后回看清单我根本分辨不出来这是个踩过水的小坑还是真的学会了。证据本身最好遵循“时间 场景 结果”的格式。比如“2024-12 在订单服务重构中负责缓存层改造接口响应时间降低 40%。”这种描述既具体又便于别人核实。尽量避免写“熟悉 Python”那不是证据是立场。3.3 报告生成技能矩阵与个人画像数据是有了但人看起来还是不够直观。我加了一个 report 命令目前能生成两类东西一类是按分类聚合的技能矩阵一类是个人画像 Markdown。技能矩阵用表格展示| 分类 | 技能 | 等级 | 最近更新 | 证据数 | | --- | --- | --- | --- | --- | | 编程语言 | Python | 胜任 | 2025-01-08 | 2 | | 编程语言 | JavaScript | 高级新手 | 2024-11-20 | 1 |个人画像则是把所有“精通/专家”级别的技能汇总成一段总结性文字同时会附带更新时间避免画像过期。这两个功能放在一起基本上可以替代我原来手写“个人亮点”的过程。我实现上用了模板引擎模板放在 templates 目录下改样式和生成格式都方便。如果你想输出 HTML 甚至 PDF思路也是完全一样的就是把模板换掉。3.4 快照与历史回溯自我复盘的精神基础技能系统最怕“只增不改”或者“只改不留”那样到了年底你根本看不出自己这一年的变化。我给 skills 加了一个 snapshot 命令它做的唯一一件事是把当前 YAML 复制一份到snapshots/2025-01-12.yml这样的路径下。这条命令本身没什么技术含量但它带来的行为改变非常大每周五下班前我会主动执行一次skills snapshot月末再跑一次 diff 看一下这个月在哪些技能上投入了时间、哪些技能已经被标记成过期。配合版本管理工具的 diff 功能我可以精确看到自己技能树的全貌演化过程这让我在季度总结的时候写出来的东西跟以前完全不是一个颗粒度。4. 实操记录从零上手的一个完整示例4.1 初始化与第一份清单我第一次跑这套流程大约花了 40 分钟。先执行skills init生成默认配置和空数据文件然后开始录入。这里我有一个很实用的建议不要一上来就追求大而全先只录入“最近 3 个月你实际用过”的技能其他的一律不写。这样做有两个好处一是数据质量高二是以后更新起来不会有心理负担。我当时录入的第一批技能是Python、Bash、SQL、Docker、Markdown 写作、需求梳理。我把每一项都按照“五级模型 证据”格式填好最后生成的清单让我第一次对自己的能力底盘有了比较清晰的认识。4.2 日常维护节奏日常维护我把它变成了一种轻量习惯每周五新增技能或更新证据跑一次 snapshot。每月底跑一次 report看一下当月技能变化 diff。每季度针对“精通及以上”的技能做一次复核确认证据是否还立得住。这里的关键是“小步快跑”不要想着一个月只做一次大更新那样很容易因为积压太多而彻底放弃。技能归档还有一个诀窍凡是超过一年没更新、也没证据投入的技能我会把它移入“休眠清单”而不是直接删除避免误删和将来重新想起时有记录可查。4.3 一次完整的季度复盘流程假设现在是 4 月份我要做 Q1 复盘。我的操作路径是这样的# 先看当前清单 skills ls --all # 对比快照 diff snapshots/2025-03-31.yml data/skills.yaml # 生成季度技能画像 skills report --format markdown --out Q1-profile.md然后我会打开 Q1-profile.md对照 Q1 的目标清单逐一核验。这个过程看起来只是生成了一份文件但实际上它逼着我把抽象的“成长”变成了可量化的清单变化。第一季度我在实践中做了一次 DBA 相关工作于是把 SQL 从“高级新手”更新成了“胜任”并补了一条小项目证据这种感觉比自己在心里默默以为自己进步了要踏实得多。5. 踩坑实录与问题排查5.1 分类体系漂移旧数据该怎么迁移我用了大概三个月后就遇到一个问题最初把分类设得太粗只有“技术”和“非技术”两类结果“技术”分类里混进来沟通、项目管理、Python乱七八糟。后来我决定把分类细拆成六类于是所有历史数据都需要迁移。我踩的坑是直接在 YAML 里手动批量替换结果因为缩进问题导致整个文件解析失败。这个教训告诉我迁移一定要写脚本不能用人工。用 Python 把旧数据读进来然后根据关键词映射表移动分类最后再写回去十分钟搞定。这类问题以后也还会出现我建议你在项目里预留好“数据迁移脚本”目录每次分类规则变更都留一个版本化的迁移脚本而不是就地改数据。5.2 自评分数失真怎么面对“高估”和“低估”我在内部试用的时候让团队成员也按这套体系给自己打分。结果非常有意思有的人明明只写了几个脚本却给自己标了“精通”有的人做过很复杂的系统改造却只敢标“高级新手”。这说明自评这件事天生就受性格和参照系影响。后面我采用了一个温和的校正机制自评只作为起点一个月或一个季度后和实际协作的同伴做一次对照复盘。如果证据里找不到能支撑当前等级的内容我会暂时把等级降一级。这个方法不能做到完全客观但起码能压制住“自我感觉良好”的系统偏差。5.3 常见问题速查表问题原因解决办法YAML 解析报错手改文件导致缩进或转义错误用 CLI 命令变更数据不要直接用编辑器改技能分类混乱分类粒度太大或太小提前定义好 6 类左右的一级分类尽量别超过两级等级普遍偏高缺少证据约束强制证据字段定期做同伴交叉评价维护频率下降数据过期没有养成更新习惯固定每周快照用好 reminder 或日历提醒报告输出和预期不符模板没更新模板单独版本化修改后立刻跑一次渲染确认这五类问题几乎是我所有使用者的共性踩坑点提前知道它们能让你的使用过程顺畅非常多。6. 向团队场景和 AI 辅助扩展6.1 从个人工具到团队技能地图后来我把这个工具的思路带进了团队做了一次轻量化改造每位成员维护一份自己的 YAML 文件定期提交再由一个汇总脚本生成团队技能地图。汇总结果不用于绩效只用于任务分派和培训规划。这个扩展比我预想的顺利原因是有三大好处第一负责人能一眼看出某个技术点谁最资深第二新人可以看团队地图里有哪些“高等级”的人去请教第三培训需求不用再靠猜测地图上“高级新手”扎堆的技能就是重点方向。当然我也要提醒一句团队版推广时一定要强调“这是成长工具不是绩效考核”。只要一牵扯考核大家就会开始美化自己的清单最后数据全废。6.2 接入 AI 辅助的初步尝试在最近几个月我开始把 skills 和语言模型能力结合做自动化。具体做了两件事技能盘点草稿输入一段“最近做了啥”的自然语言记录AI 帮忙抽取技能名称、等级和证据片段然后我再人工确认。成长建议根据当前技能分布和最近快照差异生成下一阶段的学习方向和推荐项目减少我从零做规划的成本。这块落地起来不复杂核心还是把数据喂给合适的模型再对输出做结构化校验确保生成结果能直接 merge 进原有 YAML。这个方向我没做得很重但它让我意识到技能管理未来应该是“人负责判断工具负责记录AI 负责提炼”。6.3 我个人坚持下来的体会最后说一点我的真实感受。很多人觉得记录技能很麻烦坚持不下来我也曾经断更过。但后来我降低了对自己的要求不追求每天记只追求每周留下一个快照不追求每条技能都有完美证据只要求以后能讲清楚“我为什么会这么评价自己”。这套系统没有给我带来直接的工资涨幅也没有让我的简历一键金光闪闪。但它让我的能力不再是一团模糊的感觉而是我能随时打开、随时查阅、随时向别人展示的真实资产。如果你也在为“我说不清自己会什么”而烦恼我建议你从今天起放下打分评测的心思认真记录三件事你做过什么、拿到过什么结果、你在这件事里的位置是什么。这三件事记录得多了你的能力画像自然就清晰了。skills 这个项目到现在仍然在迭代但它核心的价值不是代码本身而是让我养成了用证据说话的工作习惯。希望这篇复盘能给你的技能管理、团队盘点或者工具设计带来一些启发。
深度指南：让Mermaid图表自适应容器宽度与字体加载的5个技巧)
