No. 25: Claude Cream 从一套配色长成八类主题资产

前几天写个人站改版时，我把 Claude Cream 称为一套逐渐成形的视觉语言。那时它已经不只是 Typora 和 Obsidian 里的暖色主题，但我仍然习惯按“又支持了一个工具”来理解更新。

这两天继续整理仓库，我把 Codex、Cursor、VS Code、Zed 和图像生成规范都补了进去。等目录真正铺开，我才发现项目的性质已经变了。

现在的 Claude Cream 覆盖八类主题资产：Codex、Cursor / VS Code、Zed、Typora、Obsidian、Ghostty、Website 和 Image Generation。它不再是一套到处复制的配色，而是一套需要在不同工具里保持一致、又尊重各自规则的视觉系统。

颜色可以复制，设计意图不能靠复制自动继承。

新增平台容易，保持同一种气质更难

Claude Cream 的基础色并不复杂：暖象牙画布、琥珀金强调、暖炭灰深色，正文优先使用 PingFang SC，代码使用 JetBrains Mono。

如果目标只是“看起来差不多”，把几个十六进制颜色填进配置文件就够了。但平台并不说同一种设计语言。

Codex 的自定义主题是一行带有固定前缀的导入数据，浅色和深色需要分别维护。Zed 使用自己的主题 schema，一份文件里同时包含两个模式。Cursor 和 VS Code 共用扩展结构，还要处理普通深色、柔和深色和高对比度等五种模式。Ghostty 关心的是 16 色终端调色板，Typora 与 Obsidian 又要面对长文阅读、代码块、引用和插件样式。

同一个“强调色”，到了不同平台可能对应按钮、焦点边框、链接、活动标签或终端 ANSI 色。直接复制颜色值，只能保证它们长得像，不能保证它们承担同样的职责。

所以这次更新没有为每个平台重新发明一套配色。tokens/tokens.json 继续作为编辑器与终端主题的单一真源，浅色和深色各有 28 个语义色变量，再补上五套编辑器状态与语法高亮。平台文件负责映射，不负责自行决定颜色。

Token 的价值不在于少写几次颜色，而在于让每一次差异都有出处。

我开始接受“单一真源”也需要边界

做设计系统很容易走向另一个极端：既然有了 Token，就想让所有东西都从同一个 JSON 自动生成。

Claude Cream 没有这么做。

Codex、Cursor / VS Code、Zed、Typora、Obsidian 和 Ghostty 共享核心 Token，因为它们都在处理界面、文本、语法与交互状态。Website 保留独立的博客色板快照，图像生成规范则把网站的视觉语言翻译成构图、材质、光线和留白规则。

这种边界看起来不够“彻底自动化”，却更符合实际。编辑器里的 editor.selectionBackground 可以精确映射，封面里的“暖象牙纸张质感”却不是一个颜色值能决定的。强行把两者塞进同一套生成逻辑，只会得到一份很统一、但没人真正会用的配置。

图像生成目录这次也从单一插画模板扩展为三类：

• 编辑插画与文章封面
• 个人社交头像
• 桌面与移动端壁纸

它们共享色彩、材质和克制的编辑感，但保留不同的构图约束。头像要考虑裁切与小尺寸识别，壁纸要给桌面图标和系统组件留空间，文章封面则要给标题叠字预留安全区。

统一视觉，不等于让所有载体长成同一张图。

一个主题仓库，也需要工程验证

这轮更新里，我最在意的其实不是又多了几个目录，而是仓库第一次有了无依赖的跨平台校验脚本。

主题文件很容易出现一种隐蔽问题：单个文件语法正确，整体却已经漂移。Token 改了，某个平台忘了同步；浅色和深色缺少同名字段；Ghostty 少了一项调色板；Typora 文件名用了下划线，复制过去却无法加载。

现在运行：

python3 scripts/validate.py
git diff --check

脚本会检查 Token 结构、五种编辑器模式、Codex 导入格式、Ghostty 的 16 色索引、Typora 文件名，以及多个主题文件与 Token 的关键映射。

可访问性也被放进同一条检查链。浅色强调文字与画布、不同模式下的注释与编辑器背景，都要达到至少 4.5:1 的对比度。主题好看不能靠把文字压得足够淡，尤其是注释和链接这种每天都会读到的内容。

当然，静态校验只能证明结构、映射和部分对比度没有明显问题。它不能替代在 Codex、Zed、Cursor 或 Obsidian 里的真实视觉检查。能通过脚本，和在客户端里真的好用，是两层不同的完成标准。

安装说明也是产品的一部分

主题项目最容易被忽略的风险，往往写在 README 的复制命令里。

之前的 Ghostty 安装示例会把完整配置复制到用户目录，这可能覆盖一个人已经维护很久的终端设置。现在的做法只复制两份主题文件，再让用户把一行 theme 配置合并进现有文件。

Obsidian 的示例也不再使用我自己的本机路径，而是先定义一个可替换的 VAULT。Typora 不再通过命令强制退出应用，而是提醒先保存文档，再手动重启。

这些变化没有让主题多一种颜色，却决定了别人敢不敢照着文档安装。开源项目不能把“在我机器上能跑”包装成通用步骤，更不能为了少写两行说明，把覆盖配置和丢失未保存内容的风险交给用户。

Claude Cream 现在更像一个系统了

回头看这轮更新，新增 Codex 和 Zed 当然是最容易被看见的部分，五种 Cursor / VS Code 模式与三类图像生成模板也让资产库完整了很多。

但真正让 Claude Cream 往前走的，是一些不太像“新功能”的东西：明确哪些平台共享 Token，哪些资产只记录来源；用校验脚本守住手工映射；把对比度当成主题质量的一部分；把安装命令里的用户数据安全当成维护者责任。

这也改变了我对个人主题项目的判断。规模小，不代表可以只顾自己；没有复杂业务逻辑，也不代表不需要工程边界。只要它开始被复用，就要回答颜色从哪里来、改动怎样同步、失败会伤到什么，以及什么证据能证明这次更新没有破坏其他平台。

Claude Cream 还会继续增加平台，但接下来最重要的事已经不是把同一套颜色铺得更远，而是让每一次适配都能解释、能验证，也能安全地交到别人手里。

一套主题真正成熟的标志，不是支持了多少工具，而是换到任何工具里，都还能认出同一种判断。

项目：Claude Cream

← Writing