企业官网建设流程全解析

说实话，我一直有个毛病：学东西的时候很爽，学完就忘。尤其是这几年跨度拉得比较大，前端、后端、运维、算法都碰过一点，等真到做技术方案，或者跟人聊自己能力边界的时候，经常就是“这个我了解一点，那个我碰过一两个项目”，听起来像个万金油，可细问下去全是一团浆糊。后来我给自己定了一条规矩：凡是投入过整块时间学习的技能，必须有一个“家”。这个家不是在线笔记，也不是 Excel 大表，而是一个用 Git 管理的 skills 小仓库。这篇就当是搭完之后补的一笔账，把当时为什么这么设计、每个字段怎么定、脚本怎么跑、后来踩了哪些坑，一次性说清楚。

1. 为什么我把技能放进“仓库”而不是一张清单表

1.1 技能管理最大的坑不是记录，而是“过期”

以前我也用过各种方式维护技能列表，最早是桌面上一个 TXT，后来是 Typora 里的 Markdown 长文，再后来甚至专门建了个在线表格，列上技能名、掌握程度、最近使用时间。问题很快就出现了：表格里的内容永远停留在填进去的那一天。三个月后回看，有的技能早就被新框架替代，有的技能我已经做了好几个项目却忘了补充，还有的“掌握程度”是我拍脑袋写的，回过头自己都不信。

之所以从“清单”转向“仓库”，核心是想利用 Git 的版本管理能力。技能不是静态数据，它是会生长、会退化、会重构的东西。今天写下的“熟悉”，三个月后可能是“精通”，也可能因为长期不用变成“了解”。仓库天然支持每次修改留痕，我能看到某一个技能在过去一年里被更新过几次，最近一次复核是什么时候。这种时间维度的记录，是普通表格给不了的。

另外，仓库天然适合做关联。一个技能不是孤立的，它依赖底层基础，也会支撑上层应用；它会产生项目证据、踩坑记录、复盘笔记。表格里塞这些东西会非常痛苦，而一个目录结构可以把所有相关材料都挂在一起。

1.2 目录结构怎么设计：按领域，再按技能分层

我前后重构了三版目录结构。第一版把所有技能平铺在一个文件夹里，文件名是“技能名.md”，结果不到一个月就找不到东西了。第二版按“前端、后端、算法、工程效率”分了大类，但一个技能经常横跨多个分类，归属关系模棱两可。最终定下来的结构长这样：

skills/ ├── README.md ├── _templates/ │ └── skill.md ├── engineering/ │ ├── distributed-systems/ │ │ ├── index.md │ │ ├── evidence/ │ │ │ ├── project-order-service.md │ │ │ └── book-notes-consistency.md │ │ └── retrospectives/ │ │ └── 2025-03-leason.md │ ├── message-queue/ │ │ ├── index.md │ │ └── evidence/ │ └── observability/ │ ├── index.md │ └── evidence/ └── languages/ ├── go/ │ ├── index.md │ └── evidence/ └── python/ ├── index.md └── evidence/

核心原则是两个：一个技能对应一个文件夹，而不是一个文件；每个技能下面再分index.md、evidence/、retrospectives/三块。

一个技能一个文件夹，最大的好处是挂载能力。技能会不断积累证据，项目链接、代码片段、读书笔记、录屏演示，这些东西如果全塞进一个 Markdown，文件会膨胀到完全没法看。放进子文件夹后，index.md只负责描述“这个技能是什么、我现在处于什么水平、下一步要干什么”，而所有支撑材料都放在证据目录里。

retrospectives/是我后加的。最初没这个目录，后来发现光记录“会什么”没用，还需要记录“怎么学会的”和“栽在哪儿了”。复盘内容挂在具体技能下面，比单独建一个复盘文档真实得多，因为它是围绕技能成长记录的，而不是那种泛泛的月度总结。

1.3 每个技能文件夹里的“证据链”设计

index.md是一个技能的总入口。这里面只放元信息和当前结论，详细内容全部外链到证据目录。我坚持一个原则：任何结论都必须在 5 分钟内找到出处。比如写了“熟练使用消息队列”，那证据目录里必须能找到至少一个线上问题的排查记录，或者一个相关的生产项目链接。

evidence/里的每条记录，我统一用这样的命名格式：类型-主题.md。类型可以是project、article、debug、talk。这样排序之后，一眼就能看到这个技能是偏实践还是偏理论。一个技能如果只有article没有project，我就会在复盘时问自己：是不是只是看过资料，并没有真正上手？

这套结构本质上就是把“技能”当成一个微型项目来运营。它有现状描述、有过程证据、有回溯资料，维护起来不费劲，但信息密度远高于传统的技能清单。我后来给团队分享这套做法的时候，有同事说这很像一个“个人能力的代码仓库”，我倒觉得更像一个长期维护的“能力资产台账”。

2. 技能条目的字段设计与熟练度评估

2.1 给每个技能写一张“身份证”

为了让脚本能自动处理，每个index.md顶部都放了一段 YAML front matter。这段元数据就是技能的身份证。我最终保留的字段不多，删掉了很多花哨的东西，留下来的都是每季度复盘时真正会看的：

--- name: 分布式系统设计 domain: engineering level: 3 status: active tags: [架构, 一致性, 高可用, 分布式事务] summary: 能独立完成中小型分布式系统的方案设计和核心模块开发 evidence: - type: project title: 订单服务拆分与数据一致性改造 date: 2025-02 ref: evidence/project-order-service.md - type: debug title: 跨机房调用超时问题排查 date: 2025-01 ref: evidence/debug-timeout-case.md depends_on: - 消息队列 - 数据库事务 - 网络编程基础 next_action: 梳理分布式事务中 TCC 与 SAGA 的适用边界，输出一份对比清单 last_reviewed: 2025-04-01 ---

字段含义拆开说。

name和domain不用解释，但要注意domain必须和顶层目录一致，脚本校验时会拿这个字段跟路径比对，防止目录和内容对不上。

level是熟练度等级，0 到 4 的整数。这个字段是脚本统计的关键维度，后面详细讲。

status有三个值：active表示当前在持续使用或学习，maintenance表示基本不主动学了但还能维护旧项目，archived表示已经废弃或明确不会再碰。这个字段非常关键，它让我能区分“我会的”和“我正在用的”，避免仓库变成一堆死技能的大杂烩。

summary必须写具体。我踩过坑，一开始写“熟悉分布式系统”，后来发现这句话毫无信息量。改成“能独立完成中小型分布式系统的方案设计和核心模块开发”之后，至少能说明边界在哪里。

evidence是数组，每条记录指向一个具体证据文件。这是个强制项，如果一个技能条目里没有至少一条证据，我不会给它评级。

depends_on记录前置技能，方便从依赖关系反向推导学习路径。next_action是下一步具体的行动，每季度更新一次，没有下一步行动的计划，最终都会被归档。

2.2 熟练度分级：如何写出不心虚的等级

level这个字段看着简单，实际操作时最容易变成自欺欺人的地方。我根据一个经典的技能获得模型，把熟练度拆成了五个等级，每个等级都绑定明确的判断标准：

这套标准解决了一个核心问题：等级不再是“我感觉自己还行”，而是“我有没有对应的材料”。如果我在一个技能下标了level: 3，那我必须能在证据目录里翻出一个架构方案或者一次跨系统的故障复盘。没有这些，评级就是站不住脚的。

后来我还加了一条硬性规则：升级前必须把新增的证据先放进仓库，再改level，顺序不能反。先有事实，后有结论。这样才能保证每次打开仓库看到的状态，都是经过验证的状态。

2.3 技能之间的依赖与关联怎么维护

depends_on字段最初是拿来凑模板的，后来发现它比等级还有用。技能不是孤岛，它一定基于某些更基础的能力。比如“分布式系统设计”依赖“消息队列”“数据库事务”“网络编程基础”，那我在学新技能的时候，就能顺着依赖关系检查基础是否扎实。

这个字段也帮我处理了一个很现实的问题：有些技能会过时，但它的底层不会过时。比如某个分布式事务处理方案，具体框架可能不火了，但“事务隔离级别”“冲突检测理论”这些基础能力仍然有价值。所以归档技能时，我不会把依赖基础一起归档，只归档上层方案本身。

依赖字段还有一层用途：团队内部想做技术分享时，可以从仓库里挑一条依赖链，整理成一个系列课程。比如“从网络编程到消息队列再到分布式事务”，这就是一个现成的进阶路径，不用现编大纲。

3. 让仓库跑起来：自动统计、复盘节奏与团队共享

3.1 用脚本自动生成技能盘点，而不是手工数数

仓库一旦超过 20 个技能条目，手工维护统计就有难度了。我写了一个简单的 Python 脚本，专门干三件事：统计当前各等级技能的数量，找出超过 6 个月没复核的条目，检查有没有缺少证据字段的非法条目。

核心逻辑并不复杂，解析 front matter 之后做分组和过滤：

import os import re from collections import Counter from datetime import datetime, date import yaml SKILLS_ROOT = "./skills" LEVEL_NAMES = {0: "了解", 1: "进阶", 2: "胜任", 3: "精通", 4: "专家"} def parse_index(path): with open(path, encoding="utf-8") as f: content = f.read() m = re.match(r"^---\n(.*?)\n---", content, re.S) if not m: return None return yaml.safe_load(m.group(1)) def scan(): stats = Counter() stale = [] invalid = [] today = date.today() for root, dirs, files in os.walk(SKILLS_ROOT): if "index.md" not in files: continue if "_templates" in root or ".git" in root: continue meta = parse_index(os.path.join(root, "index.md")) if not meta: invalid.append((root, "front matter 缺失")) continue stats["total"] += 1 stats["level_" + str(meta.get("level", -1))] += 1 if not meta.get("evidence"): invalid.append((root, "缺少 evidence")) reviewed = meta.get("last_reviewed", "") try: last = datetime.strptime(reviewed, "%Y-%m-%d").date() if (today - last).days > 180: stale.append((meta.get("name"), reviewed)) except ValueError: invalid.append((root, f"last_reviewed 格式错误: {reviewed}")) return stats, stale, invalid if __name__ == "__main__": stats, stale, invalid = scan() print("== 技能统计 ==") print(f"总技能数: {stats['total']}") for level in range(5): print(f" {LEVEL_NAMES[level]}: {stats['level_' + str(level)]}") print("\n== 超过 6 个月未复核 ==") for name, reviewed in stale: print(f" {name} (上次复核 {reviewed})") print("\n== 非法条目 ==") for path, reason in invalid: print(f" {path}: {reason}")

这个脚本我放在仓库的scripts/目录下，每个月跑一次。跑完之后，我会重点关注两件事：一是stale列表，超过 6 个月没复核的技能，要么赶紧补材料，要么认真考虑是不是该降级或归档；二是invalid列表，这通常说明当时偷懒没写完整。

顺手也加了个清点命令：

python scripts/skill_stats.py

输出结果可以直接粘进月度复盘文档里，省掉了打开每个文件翻状态的麻烦。整个自动化流程不追求花哨，就是为了让盘点这件事成本降到最低，不然仓库初期热度一过，所谓的维护就彻底断了。

3.2 月度复盘和季度校准：怎么保持仓库鲜活

光搭仓库不维护，跟那些“建了十几天就再也没打开过”的个人 wiki 没有区别。我的维护节奏是两层的：月度轻量复盘，季度深度校准。

月度复盘固定在每月最后一个工作日，只花 15 分钟。流程很固定：跑一遍统计脚本，把新增技能补上，把过时状态改掉，检查有没有卡住很久的next_action。这个动作的重点不是“优化”，而是“保新鲜”。只要每个技能的状态都是这个月内看过的，仓库就不会失真。

季度校准则要做一次全面体检。我会把每个技能都打开看一眼，重点回答几个问题：这个技能最近一个季度有没有产生新的证据？如果没有，是完全没有使用场景，还是只是忘了记录？上一次标level的证据现在还成立吗？summary里的描述还符合实际情况吗？这些问题不需要全回答“是”，但回答“否”的时候必须写清楚原因。

季度校准的产出，我会同步更新到 README 的“当前关注领域”段落里。这个段落只写 3 到 5 个核心方向，一旦重点关注列表超过 5 个，等于没有重点。有一段时间我把 8 个方向都列了上去，结果每个都浅尝辄止。后来强制自己只留 3 个，学习深度明显不一样。

3.3 从个人仓库到团队技能地图

这个仓库最初是私有仓库，后来我换了家公司，带了两个新同学，发现团队里也有技能盘点需求。于是我把这套结构稍微改了一下，作为团队技能地图的底稿。

团队版和自用版有三个差异：

第一，level不再由个人自评，而是由个人提交证据、主教练复核后确认。把等级判断和证据校验分开，能明显减少自评偏高的情况。第二，每个人的仓库通过分支管理，定期合并到一个公共只读仓库里，所有人可以看到团队整体的能力分布，但不会直接改别人的条目。第三，团队版不记录next_action，这属于个人计划，放团队仓库容易给别人造成“催进度”的压迫感。

团队共享之后，最实用的一个场景是做人力盘点。新项目启动的时候，从仓库里筛level >= 2且status: active的人选，比临时组织一轮技术摸底快得多，而且因为证据都是平时积累的，选出来的人相对靠谱。除了人员选择，还能输出一条技能学习的推荐路径。团队里新同学问“想学分布式系统，应该从哪开始”，我直接把依赖链发给他，按顺序学就行，不用重新问一遍“你基础怎么样”。

团队版本要注意权限和隐私问题。每个人的技能仓库里可能包含未公开项目的证据，合并到公共仓库之前要做一轮脱敏，把项目代号替换成通用描述，比如“某金融服务项目”这种级别。这一步不能省，我自己就见过同事因为直接把内部项目细节写进团队共享页，闹出过不愉快。

4. 踩过的坑：技能仓库从搭建到养活的实录

4.1 误区一：还没想清楚分类，就先建了一堆空文件夹

第一次搭仓库的时候，我按“后端开发、前端开发、算法、项目管理、软技能、英语、写作”先建了一堆顶层目录，每个目录里再建若干子目录，一共二十多个空文件夹。理论上挺整齐的，实际完全没用。因为技能不是规划出来的，是长出来的。

后来我改了策略：第一版仓库里只放我当时真正在用的五个技能。先跑一个月，等新技能出现时再决定它属于哪个领域，如果现有分类都放不下，再新建领域目录。这套做法更符合实际的成长节奏。技能是跟随项目和兴趣生长出来的，应该让结构适配内容，而不是强行把内容塞进预设的格子里。

现在回头看，空文件夹充其量是个美好的愿望，它是给“未来的自己”看的，而不是给“现在的自己”用的。

4.2 误区二：把仓库写成了简历，而不是能力台账

还有一个比较隐蔽的坑：不知不觉就会把summary写成“职位描述”。比如写“负责订单系统的架构设计和技术选型，提升系统稳定性”，这是简历语言，它描述的是岗位职责，不是能力本身。仓库里应该写的是“能独立设计订单系统的双中心架构，能说清一致性和可用性之间的取舍”，这才是能力描述。

简历语言的问题在于，它把场景和结果放在了前面，而能力语言把边界和方法放在了前面。每次季度复盘看到那种简历味的条目，我就感觉自己又在骗自己。后来专门加了个检查规则：如果summary里出现“负责”这个词，就说明写歪了。不是说不能写项目经历，而是项目经历应该进evidence，不是进summary。

4.3 误区三：记录和评估分离，有材料却标了低等级

这个坑是反过来的。有一个技能我维护了大量笔记和实验记录，但等级一直停在 1。季度复盘时发现，这个技能其实已经在真实项目里跑了大半年，却因为“感觉还不够深入”迟迟没有升级。

后来想明白了一件事：等级是对当前证据的反映，不是对完美状态的追求。如果证据已经表明能独立完成真实项目，那就应该升到 2。至于“还不够深入”这种感受，不应该阻碍等级更新，而应该写进next_action里，成为下一步的学习目标。

所以我现在每次改level时，都会跟自己说：先翻证据，再评级。证据够了就升，不够就降，感受不参与决策。

4.4 如何避免仓库变成僵尸仓库

仓库搭完三个月，最容易进入冷宫。我的经验是：技能仓库必须有固定的“入口”和“出口”事件。所谓入口事件，就是每完成一个项目、每读完一本技术书，都要顺手往对应技能下挂一条证据，不需要写长文，三五行说清楚干了什么、学到什么就算合格。所谓出口事件，就是每月的复盘会上必须输出一份技能统计报告，这份报告不产给仓库自己，而是要分享出来。

一旦仓库被嵌进了日常流程，而不是一个孤立任务，它就不太容易死掉。如果你只是心血来潮建了个仓库，然后指望靠意志力每天维护，大概率坚持不过两周。给它找几个自然的入口和出口很重要。

我自己现在养成了一个习惯：新项目开始前，先看一眼目标技能下的depends_on和evidence，确认哪些是本项目可能用到但还没有证据的，然后在项目进行中有意识地收集这些材料。项目结束之后，顺手往仓库里丢几条证据，这个项目才算真正在能力账本里落了地。

最后再分享一个小技巧。如果某个技能长期没有新的证据、状态也维持不了，不要硬撑，果断标成archived或者降级。仓库的价值在于真实，不在数量。一个只有 15 个技能但每条都有证据、状态都鲜活的仓库，远远好过一个列了 80 个技能却有一半是两三年前拍脑袋填的仓库。这个道理，放到任何个人成长记录上都是通用的。