企业官网建设流程全解析

一个叫skills的项目，听起来就像是捡到一张写满励志语录的便利贴，但真正往里挖的时候，会发现这事儿比想象的深得多。它不是一个 APP，也不是一门课程，而是一套个人技能管理系统。我用 Obsidian 做地基，把零散的“我会一点 xx”“我学过 yy”彻底结构化，变成能随时查询、能量化成长、能反哺简历和个人定位的资产库。这套系统不绑定任何云端服务，纯本地运行，数据完全自持，隐私和稳定性都有保障。适合谁用？如果你正处于技能多而杂、学了就忘、或者年底写总结时想不起来自己这一年到底干了什么的阶段，这篇内容能给你一套直接用得上的解法。

先说说为什么会有这个项目。我自己在梳理竞争力的时候，有一种普遍痛感：知识付费囤了一堆课，技能树却始终糊成一团。每次面试写简历，都是临时翻聊天记录、翻项目文件现编“精通/熟练/了解”；每次定学习目标，脑子里都是“学 Python”“学设计”，但一个月后还是原地踏步，因为根本不知道自己水平线在哪、下一步具体该练什么。后来我意识到，核心问题不是不努力，而是缺少一个可追踪、可回看、可迭代的技能账本。就像没有账本的生意，再忙也是糊涂账。

所以这个skills项目的核心逻辑很简单：把技能当成资产来管理。有库存（当前水平）、有流水（投入时间和练习记录）、有报表（技能树视图和成长趋势），缺什么补什么能一眼看清。下面我就把搭建思路、模型设计、具体实操到踩坑记录完整拆出来。

1. 项目整体设计与思路拆解

1.1 需求解析：这套系统到底在管理什么

很多人一上来就尝试把所有会的东西都列进去，这是常见错误。“会做饭”“会修水管”“会办公软件”这种颗粒度，管理起来没有任何指导意义，反而会让自己陷入“我好像什么都会一点”的错觉。真正的技能管理，需要颗粒度细到“一个技能对应一个可练习、可描述的动作”。

比如“Python”，如果只写“Python 熟练”，它只是个标签，不是一个可管理的技能。拆解下来应该是：Python 基础语法、面向对象编程、Pandas 数据处理、Requests 接口调用、FastAPI 后端开发、Pytest 单元测试。这六个才算技能，而且它们之间还有依赖关系，需要被记录。

这套系统的设计目标只有三个：

• 定位：随时知道某个技能在什么水平，不靠感觉靠数据。
• 规划：基于当前水平排序，找出下一个高性价比的提升点。
• 证据：每个技能关联项目、笔记、作品，输出简历时一键导出。

我放弃了用一个巨大的思维导图或 Excel 表格的方案。思维导图适合发散记录，但不适合持续追踪和查询；Excel 能做数据透视，但对“证据链”的记录很弱，也很难承载笔记和作品链接。最终选型是 Obsidian 加 Markdown 文件加 Dataview 插件，把每个技能做成一张“卡片”，用 YAML 头部作为结构化字段，用正文承载证据和笔记，靠 Dataview 自动汇总。

1.2 方案选型背后的取舍

选择 Obsidian，出于三个实际考虑：

• 纯本地：技能数据是很私人的，不想存在别人服务器上；Obsidian 用本地 Markdown，同步靠 Git 或官方 Sync，自由度最高。
• 反链和块引用：一个技能可以关联到某篇学习笔记、某个项目的某个段落，这种“证据链”能力是表格工具给不了的。
• 插件生态：Dataview、Templater、Kanban 这些组合起来，能接近 Notion 的体验，但更轻快，且不卡。

当然，纯本地方案也有代价。手机端编辑体验一般，实时协作基本为零。不过技能管理本来就不需要多人协作，这些代价在个人使用场景下可以接受。

2. 核心设计：技能树的层级与量化模型

2.1 三层结构：领域、能力、技能

盲目收集技能会让系统变成垃圾场。我用三层结构约束内容：

• 领域：最高层分类，比如“技术研发”“产品设计”“沟通协作”。领域数量控制在 5 到 7 个，再多说明分类标准有问题。
• 能力：领域下的细分方向，比如“技术研发”下分“后端开发”“前端开发”“数据工程”“运维”。
• 技能：最小可操作单元，比如“后端开发”下的“Redis 缓存设计与穿透处理”。

一个新内容进来，先判断能不能归到现有技能，如果归不进去，再看要不要新建技能，最后判断是否需要升级为能力甚至领域。这套规则保证系统不会因为头脑发热而膨胀。比如，“会用 Docker 跑容器”是一个技能，但当 Dockerfile 编写、Compose 编排、K8s 部署都开始出现时，就要升级成“容器化与编排”能力，并把已有技能归进去。

2.2 五级熟练度与分数映射

技能分级参考了布鲁姆教育目标分类，但做了更实操的裁剪：

1. L0 听过：只知道名词，不知道在用什么场景解决什么问题。
2. L1 了解：能讲清基本概念，看过教程，但没有独立操作过。
3. L2 会用：在指导下或照着文档完成过实际任务。
4. L3 熟练：独立解决过真实问题，知道常见坑，能讲透原理。
5. L4 精通：能根据场景做方案设计，能带人，能沉淀方法论。

评分如果给 0 到 10 分，容易陷入中间地带，反复纠结“是 6 分还是 7 分”。五级就够用，每一级的描述是行为化的，对号入座即可。库存分数直接映射：L0 为 0 分，L1 为 25 分，L2 为 50 分，L3 为 75 分，L4 为 100 分。

这里要指出一个关键策略：存量技能不超过 20 个，活跃成长技能不超过 5 个。人的精力有限，技能树不需要大而全，需要的是几个深度足够强的分支。设置上限的本质不是限制野心，而是逼自己识别优先级。每次想加入新技能前，先问自己：我愿意为它投多少时间？如果答案是“先了解一下”，那级别应该是 L1，并且标记为“探索中”，不放进度。

2.3 卡片字段设计

每个技能卡片都有一组 YAML 元数据：

--- name: Redis 缓存设计与穿透处理 domain: 技术研发 capability: 后端开发 level: L3 score: 75 status: active target: 90 effort: 40 evidence: - "项目：订单中心缓存改造" - "笔记：缓存穿透解决方案汇总" next_action: "梳理集群环境下缓存一致性方案" last_review: 2025-06-30 ---

字段解析：

• status：active（当前重点提升）、maintain（维持）、idle（暂不投入）。这个字段比 score 更真实地反映精力分配。
• effort：过去 30 天累计投入小时数，用于判断“我是不是假装在努力”。
• target：目标分数，超过 90 分的技能默认进入维护状态，不再主动追加投入。
• evidence：证据列表，只有真正做过的东西才配写在这，防止“简历型熟练度”。
• next_action：下一步具体动作，这是整个卡片最有价值的地方。如果一个技能卡片说不出下一步做啥，说明它实际没有在成长。

3. 实操搭建：在 Obsidian 里完整实现技能管理库

3.1 目录结构

skills/ ├── 0_dashboard/ │ └── 技能总览.md ├── 1_domains/ │ ├── 技术研发.md │ └── 产品设计.md ├── 2_capabilities/ │ ├── 后端开发.md │ └── 数据工程.md ├── 3_skills/ │ ├── Redis缓存设计与穿透处理.md │ └── Pandas数据处理.md └── 4_reviews/ ├── 2025-06-技能复盘.md └── 2025-07-技能复盘.md

把领域、能力、技能分成三个目录，配合命名前缀0_到4_强制排序。领域页和能力页不用维护太多内容，本质上是被 Dataview 查询的容器。技能页是核心，需要完整填写。

3.2 Templater 模板

用 Templater 插件新建模板，每次新增技能自动带出格式。模板文件存templates/SkillCard.md：

--- name: domain: capability: level: L0 score: 0 status: idle target: 50 effort: 0 evidence: [] next_action: "" last_review: <% tp.system.date("YYYY-MM-DD") %> --- ## 这个技能解决什么问题 ## 现在处在什么水平 ## 证据记录 ## 下一步行动

需要说明的是，Templater 的<% tp.system.date("YYYY-MM-DD") %>只是我选用的一个辅助方案。如果你用的是其他笔记工具，也可以用已有的模板函数或日期宏实现同样效果。

3.3 Dataview 自动汇总面板

技能总览页的核心：

TABLE domain AS 领域, capability AS 能力, choice(score >= 90, "✅", choice(score >= 75, "🟢", choice(score >= 50, "🟡", "🔴"))) AS 状态, score AS 评分, effort AS 月投入(h), next_action AS 下一步 FROM "3_skills" WHERE file.name != "模板" SORT domain ASC, score DESC

再做一个按领域的聚合视图，计算每个领域的技能数和平均分：

TABLE length(rows) AS 技能数, round(sum(rows.score) / length(rows), 0) AS 平均分, round(sum(rows.effort), 0) AS 月投入(h) FROM "3_skills" GROUP BY domain

如果评分不想用数字，也可以纯用等级字段排序。但我觉得数字更直观，L3和75 分在按表格排序时，数字优势明显。

3.4 与每日笔记联动

纯粹一个月点开一次的系统，很难坚持。我把技能追踪做进每日笔记模板，主动降低记录成本。每天写日记时顺带填三行：

## 技能投入记录 技能:: 耗时:: 产出::

然后在技能卡片里，用 Dataview 按file.path关联的笔记聚合这个月的总投入。也可以用一个独立笔记按天记录投入，用滚动词频判断是否真的持续在某个技能上投入。实际用下来，关联标记法最省事，也不用维护第二套表。

实操上，我每天只花一两分钟更新技能投入——不是精确到分钟的记录，而是“今天在 Redis 这个技能上花了 1.5 小时，做了缓存穿透的代码实验”这样的粗略记录。数据要比完美更真实。

3.5 浏览器书签与碎片信息沉淀

技能库里会积累很多参考链接，我的做法是单独建一个资源收集箱，每个技能卡片下用 Markdown 链接攒书签。但不在收集时做整理，因为整理会打断心流；每周末把收集箱里的链接，按技能归类到对应卡片下面。涉及到的判断规则：能不能说出这个链接解决的是什么问题？能说清楚就收进卡片，说不清楚就不收。这样做的副作用是资源列表质量非常高，做技术分享或者写文章时，直接从里面挑材料就行。

4. 实际运转：从建库到每周更新

4.1 每周五的“维护流程”

固定每周最后一个工作日，花 15 分钟做技能库维护。流程顺手之后，大概这个节奏：

1. 打开技能总览，扫一遍所有技能的状态（2 分钟）。
2. 对本周投入过的技能，更新effort和next_action（5 分钟）。
3. 清理一个不再投入的技能，或者升级一个已达到目标的技能（3 分钟）。
4. 在周复盘笔记里写一段技能变动说明：本周新增了什么、进展了什么、停滞了什么（5 分钟）。

这个节奏坚持三个月之后，你会自然获得一份“时间都去哪了”的精确报告。转头做季度总结时，不用再靠回忆活着，打开技能库按时间筛选就有数据。有一个让我印象很深的时刻：有一位同事说他花了大量时间在学某项技术，但我从表格里观测到的实际投入时间每月只有两小时左右。“我以为的努力”和“实际的努力”，差距就是这么真实地暴露出来。

4.2 月度复盘：从数据到调整

每月最后一天做一次完整复盘。打开技能总览表格，执行三步操作：

• 找亮点：哪个技能分数提升最多？对应的投入是什么策略？能不能复制到别的技能上？
• 找黑洞：哪个技能分数低于 75 分，却投入了超过 20 小时？说明学习方法可能有问题，比如一直在看教程但没写代码。
• 做减负：删掉或合并至少一个从来没用过的技能。

一个真实的案例：我在一个月度复盘时发现，有一项设计工具的技能投入了 12 个小时，分数却只从 L1 升到 L2。原因是大量时间花在给工具“换皮肤”和调配色上，而不是用在产出完整作品上。下个月的调整是只保留一个主题，每做一次练习必须交付一个可展示文件。一个月后，提升效果非常明显。这就是复盘的真正价值——不是看了数据，而是根据数据调整行为。

4.3 技能库怎么反哺简历和个人介绍

这是skills项目最有直接收益的点。以前写简历“技能”栏是空话堆砌，现在直接从库里拉数据，加工规则如下：

• 面试时只讲 L3 及以上的技能，因为只有这些有证据链。
• L2 技能会有策略性地放进“使用过”或“了解”区，不带水平形容词，只带上下文，比如“在订单中心项目中使用过 Redis 做缓存”。
• L4 技能的描述不只写熟练，而是写下当时解决的最难问题是什么，用结果说话。

现在每季度更新简历，打开技能库按level: L3筛一条，按evidence直接写项目经历，半个小时就能改完。详细介绍自己时也可以按照领域页里的能力排序来组织，很有条理。

5. 常见问题与避坑实录

5.1 技能树越建越细，页面数量失控

运行一段时间后，最容易出现的状况就是技能卡片越来越多，写着写着就出现Docker的Volume挂载这种细碎条目。需要判断：单看这个技能，有没有独立的练习方式和衡量标准？如果有，保留；如果只是另一个技能的一个步骤，就合并。量化标准是：占用卡片数量长期超过 60 张时，说明颗粒度太细。处理方式是每季度做一次剪枝，能合并的合并，能归档的归档。

5.2 打分失真，自我感觉和实际水平不符

最普遍的问题是“自我评分偏高”。人容易把“看过资料”当作“会了”。解决办法只有一条：分数必须由证据驱动。如果某个分数的证据列表是空的，就强制降一级。还有个辅助手段，对比score和effort：如果分数高但投入时间很低，大概率是评估系统出错了，要么是高估，要么是根本没有独立做过项目。

5.3 投入时间记录太麻烦，坚持不下去

初期我也试图记录全天时间流水，坚持不到两周就崩了。后来发现，只需要记“今天花在技能成长上的整块时间”，碎片时间直接忽略。整块时间的定义是至少 25 分钟连续投入。任何小于这个值的时间，都不算，不记录。这样记，每天最多记录三到五条，每天花不到一分钟。而且因为只记“有效学习时间”，数据对判断真实进步更有意义。

5.4 从“技能列表”变“技能资产库”的关键一步

很多人建库建到一半就放飞了，最终变成只有一堆技能名称的空壳卡片。根据我的实践，掌控流程的关键节点顺序是：

1. 先建两个核心技能卡片，不急着盖房子，先用两张卡跑通记录、评价、复盘全流程。
2. 第二周再慢慢补其他技能，补充时严格按模板，不建立无字段的裸卡。
3. 第一个月主要任务不是增加技能数量，而是调整字段设计。方案合适后，再一次性导入旧有技能。

直接导入旧有技能列表效率低，因为初期字段还不稳定，后期还得返工。我吃过的亏就是一开始从旧笔记里搬了六十多个技能，结果统一改字段时改到怀疑人生。

5.5 Obsidian 同步和跨设备注意事项

Obsidian 是纯本地库，跨设备同步我用的是 Git 私有仓库的方案。手机上只做浏览和简单编辑，不在手机上新建技能，除非临时有个非常好的想法，先存到“信息收集箱”，回头在电脑上整理。

这里有个细节：手机端显示 Dataview 表格没问题，但如果装了十几个插件，手机启动会明显变慢。我用两套配置来解决，电脑上开全插件模式，手机上关掉大部分渲染类插件，只留基础的 Dataview 和 Templater。同一个库，两套不同的.obsidian配置，用 Git 分支区分，互不干扰。

6. 这套系统的边界与后续扩展

技能管理库解决的是“知道自己在哪、下一步去哪”，它不解决“怎么学得更快”的深层方法论问题。但它的存在会让学习方法论真正落地——任何学习技巧，都得有地方记录反馈、衡量效果，才能迭代下去。

后面可以做几个方向的扩展：

• 和项目笔记打通。一个项目结束时，自动把里面用到的技能全部 mark 一遍，作为证据入库。这样能真实反映出每个项目对能力的锻炼。
• 加入“技能组合”概念。比如“Redis 缓存 + FastAPI + Docker”组合起来，代表“能独立设计一个高可用后端服务”。从单个技能跃迁到组合能力，才是市场真正买单的东西。
• 定期输出季度技能报告。因为数据都在，生成一张趋势图，发到博客或者社交媒体上，既是复盘也是建立个人品牌的一种低成本素材。

根据我的实操经验，这个系统最难的不是搭建那部分，而是坚持每周看一次。所以我把它和周五总结绑定在一起。只要有了一次正经的复盘，看到某个技能确实在涨，或者某个技能被数据证明没必要继续投入，那种对“确定性”的掌控感，会推动你持续用下去。技术层面的技巧反而不复杂，核心是把它变成习惯的一部分——技能库不是给人看的，是给未来的自己用的。