企业官网建设流程全解析

「skills」，就一个孤零零的英文单词，连副标题都没有。我第一次拿到这个项目名的时候，第一反应是：这八成又是一个想做个人技能管理、却不知道从哪下手的实战项目。把它翻译成需求，其实就是一句话——把一个人脑子里乱七八糟的本事，整理成一份看得见、摸得着、能更新、能复盘的数据资产。

技能这个东西，很多人对它是有误区的。总觉得「我会 Python」「我懂项目管理」就是一项技能了，可真让你说出自己到了什么水平、做过什么证据能证明这个水平、下一步往哪练，大多数人的回答都是含糊的。这个项目的价值，就是干掉这种含糊。它解决三个核心问题：技能不清、水平不量化、成长不可见。适合谁用？适合想系统整理自己能力栈的开发者，适合想给团队做技能矩阵的技术管理者，也适合任何想用数据化方式记录学习进度的人。下面我就按自己实际搭建这套系统时的思路，把从需求拆解、模型设计，到代码落地和踩坑的过程完整过一遍。

1. 项目拆解：skills 到底在解决什么问题

1.1 技能管理最大的坑：感觉 vs 数据

先说一个很普遍的现状：大家写简历的时候，技能栏基本是形容词堆出来的。「熟悉」「掌握」「精通」「了解」，这些词放在一起，你自己都说不清差别。面试官问起来，也只能靠临场发挥去验证。日常学习里更乱，今天刷两道算法题，明天看两章 Kubernetes，后天又去折腾数据可视化，时间花了不少，真到三个月后复盘，你根本说不出哪块有实质长进。

这个项目要从根上解决「感觉型技能管理」。它的核心思路很简单：把技能当成数据来治理。一项技能不是一个标签，它应该包含四个信息——属于哪个领域、当前什么水平、凭什么到这个水平、接下来打算练什么。一旦这四个信息有了，技能就不再是简历上的一句空话，而是一条可以查询、可以统计、可以规划的数据记录。

1.2 三条设计原则

我给自己定过三条硬性原则，整个系统都围着它们转。

第一，可记录。每项技能必须有明确归属，不能重叠。比如「Python」和「数据分析」是两码事，前者是语言能力，后者是业务能力，放在一起统计会重复计分，雷达图也会失真。

第二，可量化。等级定义必须清晰，不许用「熟练掌握」这种暧昧词，要落在具体行为上。「能独立完成一个包含数据清洗、多表关联、可视化的完整分析任务」这才叫可量化。

第三，可行动。每条技能记录不能只有静态评价，还必须带着下一阶段目标和证据链接。没有行动指向的技能，本质上只是自我感动。

这三条原则出现的原因，就是技能管理的本质不是「盘点现状」，而是「驱动变化」。如果只是为了盘点，写一张 Excel 就够了，根本不需要做系统。既然要做系统，就必须强制自己进入一种可持续的、有反馈的复盘循环。

2. 核心设计：技能画像的建模方法

2.1 三层技能分类树

技能建模的第一个问题是分类。我试过很多种方案，最终稳定下来的是一棵三层树：领域 -> 技能 -> 证据。

领域是最高层，控制在 5~6 个，比如技术研发、数据能力、产品设计、协作管理、软技能。为什么控制在 5~6 个？因为雷达图一次展示 5~6 个维度最直观，超过 8 个维度，图形会趋于扁平，失去对比意义。

技能是中间层，挂在某个领域下面。比如技术研发下面有 Python、Linux、容器化；数据能力下面有 SQL、数据可视化、统计分析。注意，技能要拆到「可单独评估」的颗粒度，但不要拆到「知识点」的颗粒度。Python 算一项，但「Python 的 asyncio 库」不算一项，太细了没法维护，30 条技能记录就够一个人维护了。

证据是第三层，也是最容易被忽略的一层。每项技能必须关联至少一个可验证的产物，可能是完成的项目、写过的技术文章、复现过的实验报告，任何能证明你确实干过这件事的东西。这一层是整个模型的基石，后面单独说。

2.2 五级熟练度模型与行为锚点

等级打分我参考了软件工程里常用的一种技能成熟度划分思路，简化成五级：

为什么用五级而不是十级？太少没区分度，太多维护成本高，五级刚好够一个普通人的技能跨度。重点在于：每个等级都必须配一个行为锚点，也就是「什么样的证据能证明你到了这一级」。比如 Python 这一项，L3 的行为锚点是「独立交付过一个包含数据抓取、清洗、落库的完整脚本项目」，达不到，就老实承认还是 L2。

行为锚点的作用，是强行打断「自我感觉良好」这个惯性。我见过有人说自己 Python 精通，但问他最近半年写过什么独立项目，支支吾吾答不上来。有了锚点，这种虚高立刻暴露。

2.3 证据链：让每个等级都站得住脚

我设计了一个很严格的规则：没有新证据，不许改等级。换句话说，每次把一项技能从 L2 提到 L3，必须同时往证据库里添加一条记录，说明你干了什么、结果是什么、有什么可验证的产物。这一条规则直接杜绝了拍脑袋打分。

证据的形式不需要多复杂，一个标题加一个链接加两三句备注就够。我自己的习惯是：项目代码仓库链接、技术复盘文章链接、实验报告截图，都算有效证据。关键是它要可回溯，三个月后翻出来还能说清楚当时做了什么。

这条经验是真实用过之后才体会到的。最早我做版本只有「等级」字段，每周复盘直接改数字，结果一个月下来所有技能都变成了 L4，因为改数字太轻松了，人总是倾向于高估自己。引入证据链之后，每次升级都要去找一条真凭实据，动手之前就会先反问一句「我配吗」，虚高现象基本消失了。

3. 技术选型与落地实现：一套轻量级技能管理台

3.1 为什么不用重框架

有人可能会问，一个技能管理工具，是不是应该用 Django 加 PostgreSQL 做完整平台？我的意见是：杀鸡不要用牛刀。这个项目的第一使用者是你自己，不是几百人同时在线的 SaaS 产品。它要的是「开箱即用、随手维护、可视化直观」，而不是复杂的权限体系和分布式存储。重框架在这个场景下全是负担。

我最后选了 Python + Streamlit + SQLite 这套组合。Streamlit 这类数据应用框架，写几个页面脚本就能出交互界面，Radar 图、热力图、表格组件直接集成，几乎不需要前端开发。SQLite 单文件存储，备份就是复制一个文件，零运维。这套组合对个人工具来说非常合适，成本低、见效快、迭代方便。

选型标准可以概括成一句话：根据数据量级和维护频率决定技术复杂度。技能数据最多几千条，单机 SQLite 绰绰有余；个人维护，不需要并发控制；要的是快速看到结果，Streamlit 比写前后端分离省了 80% 的活。

3.2 数据模型设计

我用两张表：技能主表和证据表。

skills 表记录技能本身，字段包括 id、domain（领域）、skill_name（技能名）、level（当前等级）、target_level（目标等级）、status（进行中/已存档）和 last_reviewed（最近评估日期）。

evidence 表记录证据，字段包括 id、skill_id（外键）、title（证据标题）、link（链接）、note（备注）和 created_at（创建时间）。

外键关系上，一个技能可以有多条证据，但每次等级变更必须有至少一条新证据关联。为了强制这个约束，我在应用层做检查：提交等级更新的表单时，如果证据字段为空，直接拒绝提交。这个设计很小，但直接决定数据质量。技术上是故意不做数据库级外键约束，因为单机工具里应用层校验更灵活、报错更友好。

3.3 核心功能与关键代码

整个面板分三个页面：概览仪表盘、技能维护、证据记录。

概览仪表盘展示两个核心可视化：按领域聚合的五维雷达图，和按技能等级分组的横向条形图。技能维护页支持新增技能、修改等级、录入证据。证据记录页是一个带筛选条件的时间线列表，按最近 30 天、90 天、全部三个时间范围查看维护记录。

雷达图的代码量很少，用 Plotly 接入 Pandas 聚合结果就行。核心逻辑是先按领域分组做平均等级计算，再传给雷达图。这段才是真正的业务核心：

import pandas as pd import plotly.express as px import streamlit as st import sqlite3 def load_data(): conn = sqlite3.connect("skills.db") df = pd.read_sql("SELECT * FROM skills", conn) conn.close() return df def build_radar(df): domain_level = df.groupby("domain")["level"].mean().reset_index() fig = px.line_polar( domain_level, r="level", theta="domain", line_close=True, range_r=[0, 5], ) fig.update_traces(fill="toself") return fig df = load_data() st.plotly_chart(build_radar(df))

注意 range_r 固定在 0 到 5，不随数据自动伸缩。这样是因为雷达图上坐标轴固定，才能在不同阶段之间公平对比，否则数据略高一点，图形面积就会膨胀，产生「我变强了」的错觉。

技能维护页的表单，关键点在于等级变更时的证据校验逻辑：

def update_skill_level(skill_id, new_level, evidence_title, evidence_link, evidence_note): if not evidence_title.strip(): st.error("等级变更必须填写证据标题") return conn = sqlite3.connect("skills.db") cur = conn.cursor() cur.execute( "UPDATE skills SET level = ?, last_reviewed = date('now') WHERE id = ?", (new_level, skill_id), ) cur.execute( "INSERT INTO evidence (skill_id, title, link, note, created_at) VALUES (?, ?, ?, ?, date('now'))", (skill_id, evidence_title, evidence_link, evidence_note), ) conn.commit() conn.close() st.success("技能等级已更新")

这段代码放在项目里可能是最不起眼的，但价值最大。它把「先证明再升级」这个原则从口头落到了强制逻辑里。用户想升级却拿不出证据，就会被卡住，这是最初的 Excel 方案完全做不到的约束力。

4. 实操复盘：从零把面板跑起来

4.1 环境准备与目录规划

实操环节不能跳过环境准备。我用了一个非常轻量的目录结构：

skills/ app.py # 主入口 db.py # 数据库连接与初始化 init_data.py # 种子数据初始化 skills.db # SQLite 数据库文件 pages/ dashboard.py # 概览仪表盘 skill_form.py # 技能维护页 evidence_list.py# 证据记录页

创建虚拟环境并安装依赖，三个包就够：streamlit、pandas、plotly。SQLite 是 Python 自带的，不需要额外安装。

python -m venv venv source venv/bin/activate pip install streamlit pandas plotly streamlit run app.py

启动命令执行完，浏览器会自动打开本地页面。整个过程五分钟内能跑通，属于完全没有上手难度的方案。

4.2 种子数据初始化

系统跑起来之后，第一件事是导入种子数据。这一步非常关键，因为数据质量决定了后面所有可视化的可信度。

我写了一个 init_data.py，用 JSON 结构组织初始数据，规则是每项技能必须带一条初始证据链。一个合理的初始技能清单大概是 12~18 条，控制在能力模型的容量范围内。初始化脚本的核心逻辑是从 JSON 读取领域和技能清单，逐条插入数据库，并插入对应的初始证据记录。

这里有个实际操作细节：首次初始化时，不要一次性导入太多技能。我一开始一口气导入了 30 条，结果前两周光维护这些记录就耗掉了大部分精力，复盘变成了纯粹的体力活。后来精简成 15 条，只保留当前阶段真正在用的技能，维护体验立刻好了很多。技能管理这件事，数量规模会直接影响可持续性。

4.3 实际运行效果与调整记录

面板跑起来之后的直观效果，比预期要明显。雷达图一眼就能看出来，我在「技术研发」上的投入远超「协作管理」，这是一个自己平时完全感知不到的事实。实际上我每周都在做各种跨组协作，但雷达图明确告诉我，这块的能力评估已经滞后了。这就是可视化的价值：它不产生新数据，但让旧数据变得刺眼。

用到第二周时，我发现了原始设计的一个缺口：系统能记录「当前水平」，但没法记录「本周学过什么」。比如我周四晚上花两小时研究一个工具库，却没有任何地方可以承载这个信息。于是我加了一个学习日志字段，按日期追加内容，这样每周复盘时能清楚看到投入和产出的对应关系。这个小改动，是在实际使用后自然迭代出来的，也是真实的单机工具开发节奏——从一个最小可用版本开始，跑起来再慢慢磨。

5. 真实使用中踩过的坑

5.1 「分数通胀」问题与修正

用了一段时间后，最典型的问题是分数通胀。因为等级模型有 L1 到 L5 五档，人的心理预期会推动数值往上走：一个技能明明只是 L2 水平，但因为你每天都在做，不知不觉就想给 L3。这个现象在给自己打分和对团队成员打分时都会出现。

我的修正方式是周期校准。每三个月做一次统一校准，把每个技能等级重新对照行为锚点过一遍，凡是证据链撑不起当前等级的，一律降级。这个动作很反人性，但极其有效。实际上，从没有锚点、只有数字的那一版系统里，技能等级平均虚高了 1.2 级左右。引入行为锚点和证据链之后，平均值降下来了，这个「痛感」恰恰说明数据真实了。

5.2 工具「死掉」的几种方式

一个个人工具最常见的死法不是功能做不出来，而是做着做着没人维护。我在保存这份技能管理数据的过程中，经历过两种典型的死法。

死法一：录入成本太高。早期表单字段多到超过十个，上传一张图还要写备注，每次记录要两分钟，加上本身就想偷懒，很快就放弃了。修正思路是砍字段，最少只需填三个必填项：技能名、等级、证据标题。宁可损失一些信息，也要保住使用频率。

死法二：没有固定节奏。任何个人工具只要没有锚点时间，就会被日常琐事挤掉。我的解法是固定周日晚 30 分钟做复盘，不追求做多做全，就打开面板把这一周的学习内容和一项技能等级做了登记。坚持四周之后形成习惯，工具才真正活下来。

5.3 雷达图的维度陷阱

雷达图好看，但很容易误导。如果领域维度太少，比如只有两个领域，图形会变成一条扁平的扇形，完全看不出对比度。如果维度太多，超过八个，每个维度之间的差异会被平均掉，所有技能看起来都差不多。我把领域稳定在 5~6 个，是一个平衡点。

另一个陷阱是「追求全面覆盖」。我一度要求每个领域下至少有三项技能，导致为了凑数把一些根本不常用的技能也放了进去。后来想通了，这个系统不是用来展示「我什么都会一点」的，而是聚焦「当前阶段重点投入在哪」。不活跃的技能直接标记为已存档，不再计入雷达图。数据干净了，图才有意义。

最后说点实在的

做一个「skills」这样的项目，真正让我受益的不是那张雷达图，也不是拉起一个 Web 应用带来的成就感，而是强迫自己养成了一套「证据先行的复盘习惯」。没有新证据就别升级，每周固定时间扫一眼，技能数据才知道下一步该往哪走。这个习惯直接迁移到了工作里，现在每完成一阶段任务，我都会下意识沉淀一条记录，而不是让成果在聊天记录里凭空蒸发。

最后分享一个小技巧：给技能表加一个「活跃度」字段，最近 90 天内没有过任何证据更新的技能，面板上自动标黄。这比任何排行榜都更能戳中你——当哪个技能默默变黄的时候，你不是在盘点技能，你是在面对自己最近一段时间的真实投入分布。这份系统的价值，恰恰就藏在这些不好看的数据里。