来源：nevertoday/zhongguo-traditional-colors 类型：传统色数据、色卡与静态设计工具库 · 2026-10-13 所读 main 分支清单：742 张色卡 / 742 个色名（非固定发行版规格） 许可需注意：README 仍写 MIT，但 LICENSE 是 GPLv3、package.json 标 GPL-3.0-or-later，不能直接按 MIT 复用
一句话定性
一个用图片当载体的中国传统色色卡库——把"中国色"从干巴巴的 HEX 数字，变成"看得见、拿得走、能讲出处"的实物图卡。
本质是视觉化的色彩词典加配色工作台，不是国家色彩标准或传统色考据定本。打个比方：它像一本带工具的色彩图鉴。色名、HEX 和图卡便于沟通，但要“讲出处”，还得另补原始文献、器物或馆藏资料，不能由古风画面倒推历史真实性。
逻辑全景图
触发层
- 谁需要：国风设计师 / 视频片头 / 插画师 / 想做带东方味 PPT 的人
- 痛点：搜"暮山紫"只看到 HEX 数字，不知道长啥样、不知道配啥色
- 需求：色名 + 色值 + 视觉效果 + 文化气质，一站式拿走
核心层（数据 → 渲染 → 包装，三步走）
- 数据源：742 色主表（
docs/chinese-color-master-list.md），格式为色名 + HEX，是本项目内部的规范数据源，不等于有逐色历史考证。主表 - 图卡与清单：当前 images.js 声明 742 张图，文件名已是
001-乳白.png这类编号加色名，不再是旧稿的 UUID 命名。图片清单 - README 介绍图卡含色值、配色备注和气质词，这些适合设计参考 - Swift + Vision 脚本负责提取文字及其置信度、位置；OCR 不测量像素颜色，也不验证色名的历史出处，不能称为“校色认证” - 旧文件名前缀不足以证明每张图的生成方式；本次没有逐张图卡质量审计 - 静态站点：
index.html+ 图片清单，提供搜索、配色生成、场景预览、shadcn 主题与终端配色等工具；当前 README 链接的站点是 colors.xiaoxiaodong.ai，不把 GitHub Pages 当唯一入口 - 全量高清图通过 Release ZIP 分发；浏览器工具不等于整个资源包已包含在 clone 中 - 自动化脚本（已不止旧稿列出的 6 个）
-
build-manifest.mjs：扫图，生成图片清单 -build-readme.mjs：扫图，自动重写 README 预览区 -package-images.mjs：打成 ZIP 走 Release -verify-manifest-join.mjs：检查编号、色名与清单对应关系 -ocr-color-cards.swift：OCR 文字提取工具，不是色彩计量工具
当前 README 还自述包含 8,904 套配色组合及 10 个独立 Agent Skills；组合来自项目的配色规则，不能读成 8,904 套历史配方。README
输出层
- 在线浏览站
- 单图下载（点缩略图拿原图）
- 全量 ZIP（GitHub Release 附件；README 称源图片集约 998 MB，不能与 ZIP 压缩后体积混为一谈）
- 元数据：HEX / RGB / CMYK / 推荐配色 / 气质关键词
卡点层
- 图卡和文字不是互相认证：OCR 可能误读，文字正确也不说明色块像素、CMYK 或历史出处正确
- 历史缺失报告不能照搬：旧稿链接的 docs/missing-colors.md 本次返回 404，只能记为未核验；当前清单已声明 742 张，不能继续说缺 204 色
- 下载规模变化：完整图集走 Release，先看当前附件和网络/存储预算，别照抄 708 MB
- 传统色本来就没"标准答案"——同名"暮山紫"在不同朝代/器物/资料里可能差几个色阶
升级路线图
| 段位 | 标志 | 具体动作 |
|---|---|---|
| 入门段（能用） | 把它当色卡素材库 | 下载 ZIP → 选 5 个喜欢的色（如「十样锦」「暮山紫」「缃绮」「天水碧」「鸦青」）→ 做一个国风小图试试 |
| 进阶段（用好） | 不只抄 HEX，区分设计联想与史料 | 按色相和使用场景收藏；“唐风暖色”“宋风冷色”只能是个人创作联想，不能据此给颜色断代。需要历史说明时补具体文献/器物来源 |
| 高手段（用活） | 从"用别人的色卡"升级到"建自己的色卡系统" | 借鉴本项目的结构（主表 + OCR 校对 + 静态站点 + 自动化脚本），套到自己的领域 |
高手和普通人的本质差距：普通人搜"中国色"→ 截图保存；高手把"颜色"抽象成 「命名 + 视觉 + 元数据 + 出处」四元组，让色卡变成可检索的知识。
场景迁移
底层逻辑一句话：「内容数据 + 视觉资源 + 元数据 + 静态站点 + 自动化脚本」五件套。把它从"颜色"换成别的，一样能套。
迁移 1：地方菜系色卡库
- 颜色 → 菜品照片
- 元数据：菜名 / 主要食材 / 烹饪方式 / 地域 / 味型
- 同样的痛点：搜"九转大肠"只看到文字，不知道长啥样
- 注意变量：菜品图的视觉一致性比色卡难（光线、摆盘），需要统一拍摄规范
迁移 2：古乐器音色库
- 颜色 → 音频波谱图
- 元数据：乐器名 / 调式 / 代表曲目 / 出土朝代
- 同样的痛点：搜"筑"只看到文字，听不到声
- 注意变量：音频不能像图片一样用缩略图预览，需要用波谱/频段图替代
迁移 3：私人品牌色卡管理
- 把这个仓库 fork 一份
- 把色主表换成你的
brand-colors.md - 把脚本里的扫描路径指向你的图片
- 可以沿用静态站的思路建团队色库；数据清理、许可澄清和部署仍要时间，本文没有“5 分钟”实测
部署评估
收益
- 当前有 742 个色名及对应图卡可供筛选，但不把它们说成全部“考据过”
- 整套架构是“内容数据 + 静态站点 + 自动化脚本”，不要求业务后端，仍有托管、带宽和维护成本
- 数据主表和清单便于再加工，但先处理许可口径不一致，不把“能下载”当成无条件再分发
注意事项
- HEX 是屏幕色值的表达，不是印刷标准答案；RGB/CMYK 转换受色彩空间、ICC 配置、纸张油墨与材料影响，实物制作要打样校色
- 项目已有编号加色名的文件名，二次整理时保留编号和 HEX 关联
- 配色、对比度检查可以辅助筛选，不能保证所有字号、背景和交互状态都满足可访问性要求
- 许可冲突待澄清：LICENSE 是 GPLv3，package.json 为 GPL-3.0-or-later，但 README 尾部仍写 MIT。商业复用、改造分发及图卡素材的授权范围应向维护者确认；GPL 并非禁止商业使用，也不能把整个仓库默认当成 MIT
风险
- 依赖当前在线站点和 Release 附件，长期使用应保存版本与来源记录
- 使用前核对主表、图卡文字和实际色块；涉及历史或文化阐释时另查第一手出处，不能只凭肉眼判断“考据正确”
一句话总结
这个项目的灵魂，是把"文化的命名"和"技术的色值"焊死在同一张图上——让"暮山紫"不再是字典里的三个字，而是一张你能直接拖进 Figma 的色卡。
资料核对（2026-10-13）
本次读取官方 README、742 色主表、图片清单头部与样例、package.json、LICENSE 和 OCR 源码。未下载全量图集、运行站点或做屏幕/印刷测色；旧缺失报告访问失败不代表其历史内容已被证伪。