Impeccable colorize 指南：在单色界面上建立有层次的战略性配色系统
【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccable
本文面向使用 Impeccable 设计技能的开发者与设计 Agent，完整讲解colorize命令的运作方式：它如何在既有品牌约束下，把色彩作为"层级、意义与氛围"引入单色界面，而不是用一批色板冲淡已确认的视觉世界。读完你将掌握从品牌审计、角色建模、OKLCH 调色、WCAG 对比度校验到 live 模式color-amount参数的完整实战流程，并能在不改动品牌承诺的前提下让色彩真正服务于操作、阅读与情感表达。
1. colorize 在 Impeccable 命令体系中的位置
在 Impeccable 技能的命令表中，colorize属于Enhance（增强）类别，定位是"为单色 UI 添加有策略的色彩"（Add strategic color to monochromatic UIs）。与之并列的增强命令包括animate（动机性动效）、typeset（排版层级）、layout（间距与视觉层级）、delight（个性与记忆点）、overdrive（突破常规）等，完整命令表见 skill/SKILL.src.md。
需要强调一条边界：colorize处理的是"在既定世界里加色"，而不是"换一个世界"。命令文档在开篇的附加上下文提示中明确要求：colorize必须有已确认的品牌色作为输入（existing brand colors），并警告"不要在给视觉世界上色的名义下替换掉它"。如果任务真正要求的是一个全新的视觉身份，应当改走 skill/reference/new-work.md 的完整新世界流程，而不是用colorize去越权重构。
2. 前置约定：色化必须由已确认的品牌承诺驱动
colorize 的核心原则可以浓缩为一句话：
把色彩引入为层级（hierarchy）、意义（meaning）与氛围（atmosphere），同时保留已确认的品牌与语义约定；不得借"上色"之名替换既有视觉世界。
这意味着任何colorize会话都建立在"现存色彩中哪些是品牌承诺"之上。仓库中的 DESIGN.md 正是这类承诺的典型载体——它记录了完整的 OKLCH 色彩 token（如kinpaku-gold: oklch(84% 0.19 80.46)、verdigris-patina: oklch(70% 0.12 188)），并以多条规则约束新色（如The OKLCH-Only Rule：新颜色一律用 OKLCH 声明，hex 只出现在第三方示例或导入资产中）。colorize 的工作方式与之完全一致：先承认并继承这类 token，再谈加色。
3. 访问者模式决定色彩的语气与剂量
Impeccable 把界面按"访问者成功的样子"划分为 Persuade / Operate / Read / Experience 四种模式。colorize对两种模式组合给出截然不同的用色方针：
| 模式组合 | 色彩职责 |
|---|---|
| Persuade + Experience（营销落地页、作品集等"设计即产品"的表面） | 色彩可以承载品牌声音，在所选世界需要时拥有大面积区域——大色块是允许的、甚至是应当的 |
| Operate + Read（应用、仪表盘、文档等以任务与阅读为中心的表面） | 色彩主要编码动作、选中、状态、寻路与阅读层级；正因为大面积是灰阶，克制的点缀（accent）才具有力量（Rarity gives an accent force） |
换句话说：同样一团颜色，放在 Persuade 页面上可以铺满一个区域成为"声音"，放在 Operate/Read 界面上则应稀缺地出现在主行动、当前态与关键状态上。这一结论与 skill/SKILL.src.md 中"Operate 表面品牌活在精确细节里"的取向一致。
4. 选色之前的审计：先把现状读透
文档要求在选择任何颜色之前，先读取DESIGN.md、token、既有资产、当前主题与有代表性的状态，并逐项识别：
- 哪些颜色是已确认的品牌承诺（不可替换）；
- 当前表面（surface）、文字（text）、动作（action）与语义（semantic）角色各由什么承担；
- 哪些地方灰阶掩盖了层级或状态（这正是本命令要解决的问题）；
- 是否存在对比度失败与纯靠颜色传递信息的问题；
- 是否存在亮/暗主题或数据可视化需求；
- 判断任务到底是"想要更多颜色"还是"想要一个新身份"。
最后一条的判定很关键：如果结论是新身份，则必须转交 skill/reference/new-work.md。只有"无法从现有材料推断出有约束力的品牌决定"时才允许提问——能推断就不问。
5. 选择色彩策略：先命名意图，再动手
在开始编辑前，文档要求先命名四件事：
- 情感温度（emotional temperature）——希望用户感受到什么情绪；
- 主导关系（dominant relationship）——色与色、色与内容之间谁是主角；
- 对比范围（contrast range）——层级跨多大反差；
- 色彩剂量（color dosage）——用多少色、铺多大面积。
策略可以克制（restrained）也可以沉浸（immersive），但必须服从简报与所选世界，"而不是某个固定的百分比规则"。
5.1 建立角色（roles），而不是一堆色板
文档的措辞很明确：Build roles, not a bag of swatches。一套严肃的配色至少要为以下角色各就各位：
- 画布（canvas）与抬升表面（elevated surfaces）；
- 一级与二级文本（primary / secondary text）；
- 动作、焦点与选中（action / focus / selection）；
- 边框与分隔（borders / separators）；
- 成功、警告、错误与信息（success / warning / error / information）；
- 按需的数据类别或刻度（data categories / scales）。
5.2 使用项目的色彩空间，新 Web 色板优先 OKLCH
文档要求沿用项目现有的色彩空间；若需新建 Web 色板，优先 OKLCH，理由是"明度（lightness）与彩度（chroma）可以被可预期地调节"。色相（hue）必须从产品含义与视觉方向中选择，而不是从某个默认的品类联想（例如"科技必用蓝、健康必用绿"）去套。仓库自身的 DESIGN.md 即使用 OKLCH 表达整条中性色与品牌色阶（如neutral-100到neutral-22、light-*亮色系列），可作为参考范例。
6. 系统级铺色的七条执行规则
色彩在单个控件上好看并不够，colorize要求把颜色当作系统来铺。原文档给出了七条可逐条执行的原则：
- 让最强色拥有一个深思熟虑的区域或角色，而不是把细小点缀撒得到处都是（Let the strongest color own a deliberate region or role）；
- 让主行动易于被发现：不要把主行动的颜色花在装饰上；
- 只在品牌色相确实能创造凝聚力时才给中性色染色；服务于世界的纯灰依然有效；
- 在彩色表面上，次级文字应从前景或表面色相派生，而不是使用褪色的通用灰；
- 保持语义含义一致，但同时尊重平台与领域惯例，不要假定固定的色相值；
- 数据可视化要用明度、彩度、形状、标签或图案做区分，让颜色不是唯一的编码通道；
- 暗色模式要显式设计表面抬升与对比，不要机械地把亮色主题"取反"。
当项目拥有 token 系统时，还应定义primitive（原始值）与 semantic tokens（语义 token）两层结构；主题切换通常只重映射语义角色，而不是逐个改原始色值。这条在 DESIGN.md 中同样有迹可循：组件层（button-primary、card）引用的都是{colors.kinpaku-gold}这类语义引用，而非手写 OKLCH 字面量。
文档同时给出一个负向判据："与层级、状态、内容或视觉世界毫无关系的装饰，不是色彩策略。"
7. 对比度与感知：按 WCAG 校验，而非靠眼睛
文档要求对每一对计算出的前景/背景组合做对比度验证，并给出最小门槛表：
| 内容 | WCAG AA 最低对比度 |
|---|---|
| 正文文本（body text） | 4.5:1 |
| 大文本（large text） | 3:1 |
| 控件、图标、焦点指示（controls, icons, focus indicators） | 3:1 |
配套的感知规则包括：
- 不要只靠肉眼判断；
- 逐一检查交互态、叠加层、图片上的文字、禁用内容、亮暗两套主题；
- 模拟常见视觉缺陷（如色盲）；
- 凡由颜色传达的信息，还需要文字、形状、图标或位置作为非颜色通道冗余传递（与第 6 节数据可视化规则呼应）。
7.1 OKLCH 色阶的推导纪律
当用 OKLCH 推导色阶（ramp）时，文档提出两点技术性约束：
- 变动明度，并在接近白色与接近黑色处降低彩度——不要为了让数学上均匀而把高彩度保持到极端明度；
- 优先使用显式颜色而非一串半透明叠加层，因为 alpha 会把对比度变成"依赖上下文"的值，无法稳定校验。
这两条直接服务于第 7 节开头那张表的可达成性：一个接近白的表面上放着高彩度低明度的文字，对比度往往不达标；显式声明颜色则让每个状态的对比度都可被独立计算。
8. 验证清单与交接
完成铺色后，按以下清单自检（Verification）：
- 每个颜色都有稳定的角色或服务于世界特定氛围的用途；
- 注意力落在意图中的动作、内容或状态上；
- 色板在安静、密集、交互、报错、空状态下都成立；
- 亮/暗两套主题各自是"被设计过的"，而非机械取反；
- 所有相关状态下的对比度与非颜色线索都通过；
- 结果仍一眼是这个产品，而不是某种通用的"彩色化"处理。
当色板真正赢得自己的位置后，工作交接给/impeccable polish（详见 skill/reference/polish.md）做最终质量收尾。这也是 Impeccable 工作流的固定节奏：colorize 负责把色彩策略做对，polish 负责最终一公里。
9. live 模式下的签名参数：color-amount
colorize是少数几个在 Impeccable live 变体模式（skill/reference/live.md）中有强制参数契约的命令之一。契约要求：当从 live 模式调用时，每个变体都必须声明一个color-amount参数，用于让用户在不重新生成的前提下，把变体从"近中性"平滑推到"该变体的完整色彩策略"。
9.1 参数 Schema
{"id":"color-amount","kind":"range","min":0,"max":1,"step":0.05,"default":0.5,"label":"Color amount"}字段语义与 live 参数通用契约一致：kind: "range"表示滑块控件，运行时驱动 CSS 变量--p-color-amount，取值范围0（无色彩/近中性）到1（完整色彩策略），步长0.05，默认0.5。
9.2 编写 CSS 的方式
变体的样式必须针对var(--p-color-amount, 0.5)编写，使用默认值 0.5 作为降级兜底：
.variant-accent { color: oklch(84% calc(0.19 * var(--p-color-amount, 0.5)) 80.46); }这样用户拖动滑块即实时改变彩度输出，而无需触发生成（零再生成成本）。关于参数与 CSS 变量绑定的更完整写法（range/steps/toggle三种 kind、data-impeccable-params声明方式、接受后的碳化清理规则），见 skill/reference/live.md 的参数章节。
9.3 参数数量约束
文档明确了两层上限：
- 每个变体至多增加两个变体专属参数，候选例如：palette（色板）、temperature（色温）、tint behavior（染色行为）；
- 所有 live 参数必须遵守 skill/reference/live.md 的参数契约（0–4 个每变体、按视觉体量缩放、每种 kind 的字段集合）。
也就是说color-amount是签名参数（signature parameter），每个 colorize 变体必带，而 palette / temperature 等是可选的补充，且受总量硬上限约束，不允许重复的旋钮。
10. 仓库中的延伸佐证
- OKLCH 声明纪律：根级 DESIGN.md 以 OKLCH 声明品牌与中性色 token（
kinpaku-gold、verdigris-patina、neutral-*、light-*等），并写明"OKLCH-Only"规则，印证 colorize"沿用项目色彩空间、优先 OKLCH"的取向。 - 技能命令总表：skill/SKILL.src.md 的 Commands 表收录
colorize，归入 Enhance 类别并链接到本命令参考文档。 - live 参数契约：skill/reference/live.md 详细定义了参数 schema、
var(--p-<id>, default)编写方式与接受后的清理流程，是color-amount落地时的完整上下文。 - 新身份分流：当审计结论是需要全新视觉世界而非加色时，skill/reference/new-work.md 提供完整的替代流程。
结语
colorize的方法论可以浓缩为一个判断链：先承认品牌承诺 → 按访问者模式确定剂量 → 把颜色建模成角色而非色板 → 系统级铺色 → 用 WCAG 数值而非肉眼验收 → 在 live 模式用color-amount旋钮交付可调性。它既不是"给灰阶界面随便上个色"，也不是"用色彩推翻原有设计"——而是在不破坏已确认视觉世界的前提下，让颜色成为层级、意义与氛围的可靠载体。
【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccable
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
