履历数据建模

问题

多数个人简历系统都有同一个问题：

• 简历是一份文档
• 项目是一堆独立描述
• 作品是一组链接
• 工作经历和项目经历经常重复书写

短期看能用，长期看会很快失控：版本越来越多，文案越来越不一致，更新成本越来越高。

建模目标

一个可维护的履历系统，至少要解决三件事：

统一主数据源

分离结构化信息与叙事内容

让同一份内容服务多个展示视图

建模方案

公司容器 + 项目内容

公司是一级节点，项目挂在公司下；独立项目收进 kind: personal 的「个人项目」容器。这样可以用同一套结构表达：

• 某些项目来自全职工作场景
• 某些项目是独立主导完成，不依附雇主

公司只承载公司级信息（名称、职位、时间、简介），项目承载具体成果，避免同一段经历写在两处。

详细与精简字段分工

同一条经历拆成两组字段：

• 精简展示：elevator_pitch、key_highlights
• 详细展示：description、highlights

这样概览页和详情页都能复用同一份数据，而不是分别维护两套文案。

默认值减少重复

案例展示配置只写无法推导的字段（色调、指标、标签），其余走默认值：

• slug = 项目 id
• source = content/works/{id}.md
• title = 项目名
• summary = elevator_pitch
• year 由 period 派生
• featured / priority 复用项目字段

Markdown 与 YAML 分层

YAML 适合保存：

• 结构稳定的履历事实
• 排序、筛选、标签、优先级
• 可派生的页面数据

Markdown 适合保存：

• 简历交付物
• 案例正文
• 深度说明

长期收益

这种建模方式的最大价值，不是“看起来整齐”，而是降低长期维护成本：

• 更新一条经历时，只改一处主数据
• 新增一个项目时，只改 career.yaml 一处
• 需要不同版本简历时，可以基于同一套内容派生
• 作品、履历、简历之间关系更清晰，不会互相污染

适用场景

这套方法不只适合个人履历站，也适合：

• 个人作品集
• 顾问 / 自由职业者案例库
• 团队成员能力档案
• 求职与职业内容管理系统