我手机里存过不少“技能清单”每次换工作或者写年终总结的时候都会临时凑一份Excel 表格、石墨文档、甚至朋友圈九宫格都有过。直到有一年盘点我发现同一个技能在不同版本的清单里居然写着三种熟练度彻底对“感觉”失去信任。于是我开始做一件事把“我会什么”变成一套能持续更新的系统项目名就叫 skills。它不是什么高深的技术产品就是一套用 Markdown 文件组织起来的个人能力资产库把每一项技能从一句简历描述拆成可验证、可复盘、可检索的台账。这篇文章就记录一下这套东西是怎么设计的、用的时候踩过哪些坑以及从个人延伸到团队后它还能玩出什么花。1. 为什么我会把“skills”做成一个项目1.1 技能管理的痛点简历之外没有底账大多数人对自己能力的认知是“大概会一点”。面试官问“你 Python 怎么样”你回答“还行”领导问“你能带项目吗”你回答“带过”等真要写进简历的时候只能翻聊天记录找以前的成果。这种状态最大的问题在于你所有的技能证据都散落在邮件、群聊、代码仓库、项目文档里没有一份统一台账。到了年底汇报又得重新去“考古”。我自己最崩溃的一次是准备晋升答辩需要列出过去一年的关键产出。我翻遍了电脑里的十几个文件夹最后靠邮箱搜索才拼出七七八八。那个时候我就意识到不是我没有能力而是我没有一个地方能快速回答“我到底积累了哪些可迁移的本事”。skills 这个项目就是为解决这个底账问题而生的。1.2 从“我会什么”到“我能证明什么”口头上的“会”只是态度不是资产。真正的技能资产管理核心是“证据链”。你说你会项目管理那你得能讲出你负责过什么规模的项目、用了什么方法、冒了什么风险、最后交付了什么结果。你说你会数据分析你得能拿出你处理过多少数据量、用什么工具链、产出了什么决策建议。我把这个逻辑固化在 skills 项目里每一项技能都绑定至少一个实际案例没有案例的技能要么是还没验证过的潜力要么就是被高估了。这样做的好处是当你在简历上写“精通 XX”的时候脑子里随时可以调出一个真实故事来支撑而不是被追问两句就开始含糊。1.3 这套方案适合谁说实话这套东西适合的人群比我想象中广。程序员、设计师、运营、产品经理可以用它做个人能力盘点团队负责人可以用它做团队能力地图刚毕业的新人可以用它建立自己的成长轨迹甚至自由职业者可以用它来梳理自己的服务套餐。只要你的工作能力需要用“技能”来描述skills 的思路就能复用。不过我得先泼一盆冷水这套方案不是拿来“收藏”的它需要你花时间去维护。如果你只是想要一个自我感觉良好的清单那不如不建。真正让 skills 起作用的是你在每次更新时逼自己回答“凭什么说我会这个”的那个过程。2. 整体设计给技能库立一套骨架2.1 目录结构技能、案例、复盘的“三件套”skills 项目的目录结构是我迭代过很多版才定下来的基本原则是把“技能定义”和“技能证据”分开把“阶段性思考”和“日常记录”分开。我实际用的目录结构大致如下skills/ ├── skills/ │ ├── communication.md │ ├── python.md │ ├── project-management.md │ └── ... ├── cases/ │ ├── 2024-03-15-data-pipeline.md │ ├── 2024-06-20-cross-team-coordination.md │ └── ... ├── reviews/ │ ├── 2024-Q2-review.md │ └── ... └── templates/ ├── skill-card.md └── case-log.md每个文件承担不同职责。skills目录下是技能卡片每项技能一个文件cases目录下是具体案例按日期和主题命名reviews目录下是阶段复盘每个季度或项目结束后写一份。templates目录放通用模板降低新建文件的成本。为什么要这么分因为技能是抽象的、会变化的而案例是具体的、一次性的。如果把案例直接写在技能卡片里技能卡片会越来越臃肿而且同一个案例可能同时支撑多个技能放在案例库里就可以通过标签或链接被多份技能卡片引用。复盘单独放一个目录是希望它带有时间维度的总结而不是散落在各处的心得。2.2 技能卡片用统一字段描述一项技能我写技能卡片时坚持用统一模板因为只有字段统一了才能做横向对比和检索。模板大概长这样--- 名称: 数据分析 分类: 硬技能 熟练度: L3 最近使用: 2024-05-12 状态: 活跃 --- ## 能力描述 基于业务问题完成数据提取、清洗、分析和可视化输出可执行的结论。 ## 证据链 - [2024-03-15 数据管道重构](../cases/2024-03-15-data-pipeline.md) - [2024-05-12 用户留存分析](../cases/2024-05-12-retention-analysis.md) ## 关联技能 - SQL - Python - 项目汇报 ## 使用历史 - 2024 Q1 用于月度业务复盘 - 2023 Q4 参与指标口径统一项目 ## 待提升 - 实验设计能力 - 因果推断方法这几个字段不是拍脑袋定的。熟练度用来快速分级最近使用用来识别技能是否在“保鲜期”证据链直接指向案例文件关联技能用来建立技能网络使用历史记录技能在哪些场景里被调用过待提升则给下一步学习画个方向。很多人做技能管理只写“我会什么”不写“我在哪里用过了什么”导致技能变成一个静态标签。我的经验是哪怕只是多记一个“最近使用”日期整个系统的价值都会翻倍因为日期会提醒你哪些技能正在生锈。2.3 文件命名与检索别小看这些细节文件命名看似小事实际影响长期使用。我统一用全小写字母加连字符比如project-management.md不会出现数据分析.md和> 
长河君 · 2026/10/31 23:38:49 · 阅读 1.2k 用Markdown构建个人技能资产库：从“我会什么”到“我能证明什么”
我手机里存过不少“技能清单”每次换工作或者写年终总结的时候都会临时凑一份Excel 表格、石墨文档、甚至朋友圈九宫格都有过。直到有一年盘点我发现同一个技能在不同版本的清单里居然写着三种熟练度彻底对“感觉”失去信任。于是我开始做一件事把“我会什么”变成一套能持续更新的系统项目名就叫 skills。它不是什么高深的技术产品就是一套用 Markdown 文件组织起来的个人能力资产库把每一项技能从一句简历描述拆成可验证、可复盘、可检索的台账。这篇文章就记录一下这套东西是怎么设计的、用的时候踩过哪些坑以及从个人延伸到团队后它还能玩出什么花。1. 为什么我会把“skills”做成一个项目1.1 技能管理的痛点简历之外没有底账大多数人对自己能力的认知是“大概会一点”。面试官问“你 Python 怎么样”你回答“还行”领导问“你能带项目吗”你回答“带过”等真要写进简历的时候只能翻聊天记录找以前的成果。这种状态最大的问题在于你所有的技能证据都散落在邮件、群聊、代码仓库、项目文档里没有一份统一台账。到了年底汇报又得重新去“考古”。我自己最崩溃的一次是准备晋升答辩需要列出过去一年的关键产出。我翻遍了电脑里的十几个文件夹最后靠邮箱搜索才拼出七七八八。那个时候我就意识到不是我没有能力而是我没有一个地方能快速回答“我到底积累了哪些可迁移的本事”。skills 这个项目就是为解决这个底账问题而生的。1.2 从“我会什么”到“我能证明什么”口头上的“会”只是态度不是资产。真正的技能资产管理核心是“证据链”。你说你会项目管理那你得能讲出你负责过什么规模的项目、用了什么方法、冒了什么风险、最后交付了什么结果。你说你会数据分析你得能拿出你处理过多少数据量、用什么工具链、产出了什么决策建议。我把这个逻辑固化在 skills 项目里每一项技能都绑定至少一个实际案例没有案例的技能要么是还没验证过的潜力要么就是被高估了。这样做的好处是当你在简历上写“精通 XX”的时候脑子里随时可以调出一个真实故事来支撑而不是被追问两句就开始含糊。1.3 这套方案适合谁说实话这套东西适合的人群比我想象中广。程序员、设计师、运营、产品经理可以用它做个人能力盘点团队负责人可以用它做团队能力地图刚毕业的新人可以用它建立自己的成长轨迹甚至自由职业者可以用它来梳理自己的服务套餐。只要你的工作能力需要用“技能”来描述skills 的思路就能复用。不过我得先泼一盆冷水这套方案不是拿来“收藏”的它需要你花时间去维护。如果你只是想要一个自我感觉良好的清单那不如不建。真正让 skills 起作用的是你在每次更新时逼自己回答“凭什么说我会这个”的那个过程。2. 整体设计给技能库立一套骨架2.1 目录结构技能、案例、复盘的“三件套”skills 项目的目录结构是我迭代过很多版才定下来的基本原则是把“技能定义”和“技能证据”分开把“阶段性思考”和“日常记录”分开。我实际用的目录结构大致如下skills/ ├── skills/ │ ├── communication.md │ ├── python.md │ ├── project-management.md │ └── ... ├── cases/ │ ├── 2024-03-15-data-pipeline.md │ ├── 2024-06-20-cross-team-coordination.md │ └── ... ├── reviews/ │ ├── 2024-Q2-review.md │ └── ... └── templates/ ├── skill-card.md └── case-log.md每个文件承担不同职责。skills目录下是技能卡片每项技能一个文件cases目录下是具体案例按日期和主题命名reviews目录下是阶段复盘每个季度或项目结束后写一份。templates目录放通用模板降低新建文件的成本。为什么要这么分因为技能是抽象的、会变化的而案例是具体的、一次性的。如果把案例直接写在技能卡片里技能卡片会越来越臃肿而且同一个案例可能同时支撑多个技能放在案例库里就可以通过标签或链接被多份技能卡片引用。复盘单独放一个目录是希望它带有时间维度的总结而不是散落在各处的心得。2.2 技能卡片用统一字段描述一项技能我写技能卡片时坚持用统一模板因为只有字段统一了才能做横向对比和检索。模板大概长这样--- 名称: 数据分析 分类: 硬技能 熟练度: L3 最近使用: 2024-05-12 状态: 活跃 --- ## 能力描述 基于业务问题完成数据提取、清洗、分析和可视化输出可执行的结论。 ## 证据链 - [2024-03-15 数据管道重构](../cases/2024-03-15-data-pipeline.md) - [2024-05-12 用户留存分析](../cases/2024-05-12-retention-analysis.md) ## 关联技能 - SQL - Python - 项目汇报 ## 使用历史 - 2024 Q1 用于月度业务复盘 - 2023 Q4 参与指标口径统一项目 ## 待提升 - 实验设计能力 - 因果推断方法这几个字段不是拍脑袋定的。熟练度用来快速分级最近使用用来识别技能是否在“保鲜期”证据链直接指向案例文件关联技能用来建立技能网络使用历史记录技能在哪些场景里被调用过待提升则给下一步学习画个方向。很多人做技能管理只写“我会什么”不写“我在哪里用过了什么”导致技能变成一个静态标签。我的经验是哪怕只是多记一个“最近使用”日期整个系统的价值都会翻倍因为日期会提醒你哪些技能正在生锈。2.3 文件命名与检索别小看这些细节文件命名看似小事实际影响长期使用。我统一用全小写字母加连字符比如project-management.md不会出现数据分析.md和>