很多人手里都有一份或者好几份技能清单。有的贴在简历上，挂在求职平台的个人主页里，印在名片背面；有的只存在于自我介绍时脱口而出的几句话里。但真被人追问“你到底会什么、熟练到什么程度、拿什么证明”，大部分人立刻卡壳，我也不例外。越说不清楚自己的 skills，我在选方向、投简历、带项目的时候就越被动。
去年开始，我把“skills”当成一个正式项目来做，不是“报个班学点新东西”那种心态，而是像做产品一样去定义、拆分、迭代、存储自己的每一项能力。这套东西的目录名就叫skills。这篇文章会把它的完整思路、仓库结构、字段设计、评估方法和踩坑记录都摊开来讲。适合想系统梳理自己能力的个人，也适合需要帮团队搭建技能地图的管理者。
1. 先搞清楚 skills 到底在管理什么，否则技能清单永远是废纸一张
动手之前，我做过一次自我观察：翻出三年前写的简历，把“专业技能”那几行逐条看了一遍，发现我能很有把握地证明的不到一半。某条写“熟悉项目管理”，但真要我说清楚熟悉哪种场景下的项目管理、换一个行业还能不能上手，答案非常模糊。这不是个例。大多数技能清单的共同问题是：列出来的不是技能，是名词。名词没有验证标准、没有上下文、也没有产出物，本质上是一张自我安慰的贴纸。
1.1 “做了五年”为什么不等于“拥有一项技能”
我和不少同行聊过，他们给自己技能打分的常用依据是年限，“这个我做了 X 年”。后来我把这句话拆开看，发现年限最多算背景变量。同一个动作重复八年，和用不同方案解决八轮问题，完全是两码事。前者只积累手感，后者才积累可迁移的方法。
真实技能一般由三块组成：
- 知识部分：知道概念、原理、适用边界。
- 方法部分：知道怎么做、为什么这么做、异常情况怎么处理。
- 证据部分：有实际产出物和可验证的结果。
三块都齐全，技能才能真正成立。拿“会用 SQL 取数”来说，知识是理解表结构和查询逻辑；方法是会根据业务问题选择合适的聚合、过滤和连接方式；证据是一次实际取数中面对的脏表、拆解过程、最终输出结果。缺了证据，前面两块最多叫“学过”，不能叫“会”。
这就带来一个硬性要求：任何写进 skills 的技能，都必须能在 30 秒内指出一条对应证据。没有证据的技能，我一律标成“待验证”，而不是直接承认它会。
1.2 技能、职位、能力：三层概念别混着用
有一个问题困扰我挺久：为什么有些人技能清单写得挺全，跳槽还是找不到方向？后来发现是把技能、职位、能力三层混在一起用。
职位是组织里设置的生产位置，是一组技能的容器；能力是一个人整体能成事的水平，技能、认知、沟通习惯、抗压方式都算进去；技能是三者里最小、最可拆解、最可转移的单位。把这三层分开，很多职业规划问题都会变简单。
举个例子，有人想从运营岗转到数据分析岗，岗位概念差别很大，但如果把现有技能拆出来：“能从用户反馈里提取需求”“能把业务问题转化成数据指标”“能用表格做出清晰的汇报图”，这些技能在新岗位上同样生效，只需要补齐“会用 SQL 取数”“理解统计基础”两块就行。岗位在变，技能这个单位没有变。
所以我把当前所有能力当作一个知识库，按领域分组，按可迁移性评估，再用证据不断校验。项目标题就一个字：skills。意思很明确：不聊职位、不聊头衔，只聊技能本身。
1.3 我把“skills”当项目管理之后的三个显性变化
用项目的方式管理技能，我给项目立了三条纪律：可见、可追溯、可更新。可见，是指技能不能只存在脑子里，要有专门的文件存放；可追溯，是指每项技能都有变更记录和评审日期；可更新，是定期对技能做加减法。
坚持一段时间后有三个变化特别明显。第一，自我介绍变简单了，不再空泛地说“我综合能力不错”，而是直接给出几个已验证的技能包。第二，学习方向变准了，每次看课程、读资料、做练习都会先问一句“它要补充哪个技能包的哪个部分”。第三，对“自己不行”的判断也更准确。以前觉得自己啥都不会，其实是技能没有拆开，焦虑来自看不清全貌；拆成技能包之后，问题变成“某项技能还没到 R2，需要补证据”，可操作的路径一下就清晰了。
2. 用技能包这种数据结构代替一行行的名词堆砌
技能清单如果只有一行行名词，它的上限就是简历上的两三行。要让它变成可以长期管理的对象，就得转换成一种数据结构。我把它叫技能包（skill package）。技能包不只是一条记录，它是一套自包含的信息单元，包含元信息、评估标准、证据文件和评审记录。
2.1 技能包字段：从名称到证据
技能包里最基础的字段，我用了下面这组：
| 字段 | 必填 | 说明 | 示例 |
|---|---|---|---|
| ID | 是 | 全局唯一编号，方便引用 | SK-007 |
| 名称 | 是 | 动词加宾语，明确可检验 | 用 SQL 从业务数据库取数 |
| 领域 | 是 | 所属能力域 | 数据处理 |
| 熟练度 | 是 | R0-R3 行为等级 | R2 |
| 前置技能 | 否 | 依赖哪些技能 | SK-002 SQL 基础 |
| 证据 | 是 | 能打开的产出物或证明链接 | evidence/取数示例.sql |
| 最后评审 | 是 | 最近一次复核时间 | 2025-06-01 |
| 状态 | 是 | active / 待验证 / 已归档 | active |
表里最容易被忽略的是“名称”。我踩过的坑是第一次命名时写的是“数据分析”“做事细心”这类词，后来发现它们完全没法评估。改成“能从原始数据里清洗出可用于分析的表格”之后，验证路径立刻清晰了。每次调整名称，本质上是把模糊的自我评价改写成可操作的工作任务。
2.2 用行为等级 R0-R3 衡量熟练度，而不是“80%熟练”
百分比看起来精细，但“SQL 熟练度 80%”在两个人眼里含义可能完全不一样。我给技能包设计了四个行为等级：
| 等级 | 定义 | 典型行为 |
|---|---|---|
| R0 | 听说过名称 | 能说出它是什么，但没实际操作过 |
| R1 | 能照着做 | 照着教程或模板能完成，脱离教程容易失败 |
| R2 | 能在约束下独立完成 | 给定场景、目标、约束条件，能独立完成常规任务，边角问题需要确认 |
| R3 | 能教别人做 | 能拆任务、定标准、带新人，能处理非常规情况 |
判断熟练度时最关键的分界线是 R2 和 R3。R2 说明你会做，R3 说明你能把这种“会”结构化地传递出去。我的体会是达到 R3 比想象中难，因为它要求你见过足够多的异常情况，并且能把解决办法讲成规则。很多人自评 R3，但真让他带一个零基础的人，很快就露馅。
2.3 前置技能与技能树：让清单从果盘变成有逻辑的结构
技能不是一组平铺的水果，很多技能之间存在硬依赖。我在技能包里加了prerequisites字段，把依赖关系明确写出来。比如技能“做数据看板”依赖“会用 SQL 取数”“会选图表”“能拆业务指标”。
这样做的好处很直接：评估一项技能时，如果它的前置技能评级低于它，就说明当前评级大概率虚高。排列方式上，我用领域分组加层级展示，同一个领域下的技能从上到下共享前置关系。这个结构对做学习规划特别有用，每次只动一个技能树分支，而不是随机地东学一点西学一点。
3. 搭建个人 skills 仓库：目录、文档、版本控制
数据结构设计好之后，要落地成文件系统。我选了纯文本方案：每个技能包一个文件夹，里面用 Markdown 和 YAML 存结构化信息。选纯文本的原因是它随处可编辑、可做差异对比、可进版本控制，以后想写脚本统计也容易。
3.1 目录设计：让每项技能自带“说明书”和“证据盒”
仓库目录一开始长这样：
skills/ ├── README.md # 入口文件，快速索引与状态总览 ├── config.yaml # 项目元信息 ├── domains/ │ ├── documentation.md # 文档能力域总览 │ ├──>ID: SK-009 name: 用 Markdown 编写新手可读的技术文档 domain: documentation prerequisites: - SK-001 Markdown 语法基础 - SK-003 结构化写作基础 level: R2 state: active last_reviewed: 2025-09-14 evidence: - evidence/demo.md然后写criteria.md，内容不是形容词，而是可检查的操作，比如：
- 能在给定主题下完成一篇 5000 字以内的操作文档。
- 读者按文档操作时，不需要额外求助就能完成任务。
- 全文中的专业术语都有第一次出现的定义。
- 新手读完可以复述出至少三个关键步骤。
这些标准每一项都能当场验证。我还在review.md里记录了历次评审结论，格式很朴素：评审日期、自评等级、证据更新点、下一阶段要补什么。配合git log，整个技能的成长历史就完整了。
3.3 用 git 提交记录技能变更，技能履历自动生成
把仓库放进版本控制系统之后，每次技能变化都对应一条提交记录。比如某次提交是“SK-009: R2→R3，补充了面向零基础读者的案例集”。几个月后看git log，得到的就是一份比简历可信得多的能力履历。
它和普通简历的区别在于：有日期、有变更、有证据文件，不是面试前临时美化出来的样子。这个习惯也解决了“我是不是太久没更新技能”的焦虑，翻一下 log 就知道上次碰这个技能是什么时候，有没有过期嫌疑。
4. 自我评估、作品证据、同行复核：技能评估的三种手段
仓库结构固定下来之后，最容易骗到自己的环节是评估。会写一个skill.yaml不代表技能水平真实。我给每个技能包设计了三种验证手段，从不同角度交叉确认。
4.1 自测题要能“当场做出来”，不能只问“会不会”
criteria.md里我要求每项技能至少有三个自测题。设计原则是：题目必须能在限定时间内现场完成并产出物。比如技能“数据清洗”的自测题是：
- 给一张包含重复行、缺失值、乱码的 3000 行表格，限定半小时，能否交付一张内容一致、结构规整的数据集？
- 每一步清洗动作是否都有决策依据，能说清“为什么删、为什么留、为什么替换”？
- 如果数据量扩大一百倍，方案是否需要更换？
而“你会不会用 VLOOKUP”这种题不算自测，它只能验证记忆，不能验证调用能力。写题的时候，时间、产出、质量标准三个要素缺一不可。没有时间就没有紧迫感，没有质量标准就什么都能算“完成”。
4.2 每项技能挂一个最小演示作品
技能等级的描述说到底还是语言，语言可以被修饰，证据文件是反修饰的。我给每个技能包准备了一个evidence/目录，里面放一个很小的作品。规模不用大，关键是能证明这项技能的最后一步。
比如技能是“会用 Markdown 写技术文档”，证据就是一份你重构过的文档开头；技能是“SQL 性能优化”，证据就是一句改写前后的 SQL 加执行计划对比。如果是敏感工作产出不能外发，可以用虚构数据做一个同类型小样，把方法和思路还原出来。
给技能配证据还有一个边际好处：更容易把隐形的能力带到面试桌上。我见过不少候选人口头表达很顺畅，但缺少证据时验证成本太高；有了证据，双方判断都快很多。
4.3 请同事做交叉验证，把评估里的水分挤出去
自我评估很容易受信心干扰，高估和低估都可能。我每隔半年会把部分技能包发给几个有工作交集的人，请他们回答三个问题：你看过我相关的实际表现，和自评等级一致吗？高出还是不足？能举一个例子吗？
回复里常见的情形是：“你说这个技能是 R3，我觉得差不多，但那次处理异常情况时你其实还是问了别人。”这类细节靠自我评估很难意识到。交叉验证不需要很多人参与，三四个就够，重点是有真实合作场景，而不是关系远近。反馈之后，我会把结果记进review.md，再修订相应等级。
5. 可迁移性与技能组合：哪个技能会复利，哪个技能会过期
管理技能不只是为了应付眼前的工作，是为了做长线决策。我会定期给仓库里的技能做“迁移性”体检，判断哪些值得继续投入，哪些应该慢慢放手。
5.1 识别可迁移技能的三个属性
我给技能的可迁移性打分，主要看三个属性。第一，换一个行业是否仍然成立；第二，换一套工具是否仍然成立；第三，它是否嵌在需要判断和沟通的流程里，而不是单纯的按钮操作。
“逻辑推理与问题拆解”属于换行业、换工具都成立，且很难被自动化替代的技能；而“会用某款特定报表工具的拖动界面”，换一款工具就基本归零。规划投入时，我会把更多时间放在可迁移技能上，把工具类技能压到最小必要级别，够用就行。
5.2 过期技能的处理：降级、归档、删除
技能会过期不是心态问题，是必然结果。我判断过期有三个标准：
- 最近一年没有使用场景，且未来半年预计也没有。
- 相关工具或方法论已经被新一代明显替代。
- 与当前主线方向不再兼容。
符合两条就进入归档流程，移到archive/目录，并在 README 里标注 archived。归档不是删除，评估记录和历史证据都还在，万一哪一天需要回溯，仍然有据可查。主目录因此一直保持干净，不会被沉没成本占满。
5.3 组合技比单点技能值钱得多
单点技能在市场里很快会被标价。会 Python 的人很多，会写作的人很多，会项目管理的人也很多。但把“用 Python 做自动化报表”和“能把报表讲给业务方听”组合起来，就成了一个稀缺组合。
在 skills 仓库里，我会在roadmap.md写清楚下一步想构建什么组合，然后倒推缺哪些组件。比如想具备“用数据图表向非技术人员汇报运营状况”这个组合能力，就得拆出取数、图表设计、口头表达、术语简化四块，看自己缺哪块就补哪块。这样学习不再跟风，而是像搭积木一样，永远心里有数。
6. 把 skills 仓库用在求职、复盘和团队管理中
仓库建好之后，真正让人感受到价值的是它被不断使用。我可以把它的几个出口列出来，给同样在维护这类项目的人一点参考。
6.1 需要简历时，从仓库里导出而不是现场编
维护一段时间后，写简历这件事从“回忆加美化”变成了“导出加筛选”。先在 README 里挑出和目标职位相关的技能包，再看对应的 criteria 和 evidence，最后写进简历。面试时如果被追问细节，我可以直接打开某个技能包的 evidence，把作品或评审记录展示出来。
多数面试官没意料到会看到一套结构这么完整的能力证据。当对方发现你每一句都能落到具体产出上，沟通效率会高很多，也不用在“到底会不会”的问题上反复拉扯。
6.2 项目复盘后顺手补充证据，成本最低
补充技能证据的最佳时间，是项目复盘后的半小时。当时任务目标、困难点、解决路径和最终效果都还热乎。我会趁这段时间把项目里真正用到、且有所提升的技能包更新一遍：等级是否要变，证据文件是否要补，criteria 里有没有要新增的边界条件。
这件事单独安排在季度做会很沉重，但跟在复盘后面就是顺手的事。成本低了，坚持的概率才会高。
6.3 三个常见误区与应对
最后说三个我在维护 skills 项目时踩过的误区。
第一个是“只存不评”。工具意识大于判断意识时，每学一个东西马上写进仓库，但还没到 R1 就敢标 R2。应对办法是把“熟练度”和“证据”绑定：评级修改必须同时有证据更新，没有就降格处理。
第二个是“只收不归档”。仓库当收藏夹用，技能越堆越多，可读性崩塌。应对办法是每次季度评审只保留真正在用的技能包，其他进 archive，宁可少而精，不要多而乱。
第三个是“只列不证”。证据文件存在，但写得像日记，打不打得开、别人看不看得懂，完全没验证。我的应对办法是假设自己三个月后失忆，拿到的证据能不能直接让我恢复记忆。如果一个文件需要你站在旁边解释一大段才能让人看懂，那它就不合格，重新整理比留着更省事。
维护一个叫 skills 的项目后，我收获最大的其实不是那张能力清单，而是一套不断校准自我判断的工作方式。它让我在学习前多一点分类的耐心，在评估时少一些感觉主义的自信，在谈机会时手里有可打开的证据。按这套方法把技能一件一件建好，是一个能长期使用的基本功。如果你想试，没必要一开始就搭出完整结构，从最低成本的动作开始就行：先给一项你最有把握的技能写个 skill.yaml，放一个能证明它的证据文件，然后每季度回去更新一次。一年之后你可能会惊讶，原来自己并不是“什么都不会”，只是从没把已有的东西想清楚、放整齐。
