历史作品 · 交互 UI 设计师 这里住的是设计师做过的真实交付作品——每份作品都是一次已经验证过的设计系统 / 视觉方案 / 组件库,也是下次接类似项目的最佳参照源。 1. 为什么要有这个库 1.1 设计系统可跨项目复用 设计师一号位做到第 3 个 APP 项目时会发现:Button / Input / Card / Modal 这些原子组件在每个项目里其实 80% 相同。历史作品库是公司级设计 token 基线的原料来源。 1.2 视觉风格的"家族相似性" 即使是不同客户的项目,同一个设计师做出来的东西往往有"家族相似性"。把这些作品放一起可以看出: - 哪些是可提炼的个人风格 - 哪些是应该打破的路径依赖 - 哪些组件的使用频率高到应该进公司基线 1.3 跨岗位的"案例库" AI PM 和全栈工程师也会读这里: - AI PM 想看"上次那个深色主题的 IA 如何映射到视觉" - 工程师想看"上次那个 Agent 驱动界面的状态集是怎么处理的" 1.4 设计师自身升级的实证 从 v1.0 升级到 v1.1 时,拿同类项目的新旧设计系统对比——这就是自我验证的证据。 2. 谁往这里写 只有 CKO 可以往这里写。 2.1 写入时机 项目 status=已交付 后,CKO 在蒸馏流程的第 5 步走"路径 B 公司脑库建设"时: 1. 把 02_项目/项目_XXX/交付物/02_设计层/ 下所有设计师产出的文档和文件复制一份到这里 2. 原件留在项目盒子里不动 3. 添加一份"作品说明"文件,记录复制来源与特殊价值 2.2 写入后不允许修改 历史作品是只读归档——"那次项目的状态就是那次的状态"。 3. 命名规范 YYYY-MM-DD_项目名_交付类型.md 或 目录 4. 每个作品的配套文件 每份复制的作品旁边都要有一份 _作品说明.md: --- work: 2026-04-15_示例项目_设计系统.md from_project: 02_项目/项目_示例/ project_type: APP类 delivered_at: 2026-04-15 distilled_at: 2026-04-16 distilled_by: CKO figma_link: {若有} --- ## 项目背景 {这个项目当时是为什么启动的} ## 这份作品的特殊价值 {为什么这份值得进历史作品库} - 例:第一次尝试蜡笔手绘风的设计系统 - 例:首次引入"黑猫 IP 驱动的状态集"创新 - 例:设计系统中的情绪化动效首次落地 ## 视觉风格关键词 {用 5–8 个词描述这套视觉} - 例:蜡笔手绘 / 圆润 / 温暖 / 低饱和 / 插画驱动 / IP 陪伴感 ## 使用提示 {下次类似项目的人应该怎么用这份} - 例:设计系统的 token 命名可直接借鉴 - 例:IP 资产**不能**跨项目复用(C2 物理隔离) - 例:动效 duration 偏慢,适合放松类产品,不适合效率类 ## 可复用部分 - [x] 设计系统 token 结构 - [x] 组件原子库(Button/Input/Card) - [x] 状态集 5 态方法论 - [ ] 具体色板(品牌专属,不可复用) - [ ] IP 资产(客户专属,不可复用) ## 踩过的坑 {这份作品在项目过程中遇到的问题与教训} - 例:一开始没做状态集直接画正常态,后期返工 - 例:动效规格没写参数只写描述,工程师实现偏差 ## 关联蒸馏记录 `01_部门/档案部/首席知识官CKO/蒸馏记录/{项目_YYYY-MM-DD}.md` 5. 组织方式 历史作品/ ├── 2026-04-15_示例项目_设计系统.md ├── 2026-04-15_示例项目_设计系统_作品说明.md ├── 2026-04-15_示例项目_高保真/ ├── 2026-04-15_示例项目_状态集/ ├── 2026-04-15_示例项目_design-tokens.json ├── 2026-04-20_示例产品_设计规范.md ├── 2026-04-20_示例产品_设计规范_作品说明.md ├── ... └── _索引.md · 按项目类型 + 视觉风格的双维索引 5.1 _索引.md 示例结构 ## 按项目类型 ### APP 类 - 2026-04-15 示例项目(ADHD 待办 APP · 蜡笔手绘风) - [设计系统](2026-04-15_示例项目_设计系统.md) - [高保真](2026-04-15_示例项目_高保真/) - [状态集](2026-04-15_示例项目_状态集/) - [design-tokens](2026-04-15_示例项目_design-tokens.json) ### Web 后台类 - 2026-04-20 示例产品(SaaS 后台 · 扁平专业风) - [设计规范](2026-04-20_示例产品_设计规范.md) ## 按视觉风格 ### 手绘 / 插画风 - 2026-04-15 示例项目 ### 扁平专业风 - 2026-04-20 示例产品 ### 拟物 / 质感风 - (暂无) ## 按交付类型 ### 设计系统 - 2026-04-15 示例项目 - 2026-04-20 示例产品 ### 状态集 - 2026-04-15 示例项目 6. 跨岗位访问规则 AI PM / 全栈工程师 / 运营 / CKO 都可以读这里,但: ❌ 不允许从这里复制修改后当作新项目的交付物——C2 物理隔离 ❌ 不允许借鉴客户 A 项目的具体品牌资产到客户 B 项目(logo / IP / 色板) ✅ 可以借鉴结构、方法论、token 命名规则、状态集思路等抽象能力 ✅ 可以学习"某个组件是怎么处理 edge case 的" 7. 公司级设计 token 基线的沉淀路径 这是设计师一号位 v1.1 的核心升级目标: 第 1 个项目:历史作品里有 1 套 token 第 3 个项目:能看出 Button / Input / Card 在 3 个项目里的相似度 第 5 个项目:CKO 蒸馏出"公司级 atoms 基线",写进 方法论/ 第 10 个项目:新项目可以基于基线起步,只定义"项目专属的色板 + 字体" 8. 红线 ❌ 不允许设计师自己往这里写(只有 CKO 有写权限) ❌ 不允许事后修改历史作品(归档即冻结) ❌ 不允许删除(即使项目失败,失败作品也保留——失败的设计更值钱) ❌ 不允许把未经 CKO 蒸馏的草稿复制进来 ❌ 不允许省略 _作品说明.md(孤件无法复用) ❌ 不允许跨客户共享品牌资产 / IP / logo