企业官网建设流程全解析

Impeccable Colorize 指南：在既有品牌约束内为单色 UI 注入有意义的色彩系统

【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccable

导读

本文是 Impeccable 设计语言体系下colorize子命令的完整实战指南，聚焦于一个高难度场景：在保留已确认品牌色与语义惯例的前提下，把色彩作为层级（hierarchy）、意义（meaning）与氛围（atmosphere）引入界面，而不是简单地把界面"涂上颜色"。读完本文，你将掌握 colorize 的审计前置流程、策略选择框架、OKLCH 色彩空间的推导方法、WCAG 对比度核查表，以及 Live 模式下color-amount签名参数的声明与消费方式，可以直接在现有单色产品上落地一套有系统、有角色、有验证的色彩方案。

colorize 是什么：命令定位与触发时机

在 Impeccable 的命令体系中，colorize属于Enhance（增强）类目，其官方定义为"为过于单色（monochromatic）或缺乏视觉兴趣的界面添加战略性色彩，使界面更有吸引力与表现力"。从 命令元数据 可以看到它的精确触发信号：用户提到界面"灰（gray）、沉闷（dull）、缺乏温度（lacking warmth）、需要更多颜色（needing more color）、想要更有活力或表现力的调色板"时，应路由到colorize，而不是其他子命令。

它与同类的边界在 SKILL 命令表 中清晰划定：

• bolder放大安全性或平庸的设计（尺度/饱和度/结构）；
• quieter收敛过分张扬的设计（颜色/装饰/间距）；
• typeset只动排版层级与字体；
• colorize专责色彩战略：让一个已被确认的视觉世界里，颜色开始承担层级、状态与氛围的角色。

在 Live 模式的 visitor 分类中，colorize同时被登记为合法 action（见 live 词汇表），这意味着它既可以作为独立命令运行，也可以作为浏览器内元素级变体生成动作被触发——后者遵循live.md的三变体契约，我们会在后文展开。

铁律：附加上下文与"不换世界"原则

colorize 的第一条纪律写在文档开篇的附加上下文（Additional context）中：

需要额外的上下文：既有的品牌色。引入色彩作为层级、意义与氛围；保留已确认的品牌与语义惯例；不得以"上色"之名替换一个既有的视觉世界。

这意味着 colorize默认不是重设计。它与new-work（新视觉世界/新身份创建）的分工在 new-work.md 中有明确界定："缺失 DESIGN.md 并不等于绿地项目"。只有当任务明确要求新身份（a new identity）时，才应转向new-work流程；只有当无法从材料中推断出有约束力的品牌决策时，才允许提问。换言之：能从 DESIGN.md、token、资产与现有主题中读出的品牌承诺，就是 colorize 的边界，绝不能越过。

访问者模式：先决定色彩的工作方式

在执行任何取色之前，先判断当前表面的访问者模式（Visitor mode），因为它决定了颜色的"职责分工"：

在 Operate/Read 模式下，强调色（accent）的价值恰恰来自稀缺——到处都用等于没有强调。这也是 Live 模式 Phase B 中"默认模式保留身份、仅在表达层面变化"原则在色彩维度的投影（见 live.md）。

审计先行：动手前必须读什么

文档要求在选择任何颜色之前完成一次系统审计。需要阅读的材料包括：

1. DESIGN.md——承载可持续的视觉决策（视觉系统字段）；
2. tokens——CSS 自定义属性通常是事实上的 token 系统（de-facto tokens）；
3. 资产（assets）与当前主题（themes）——明暗两套都要看；
4. 代表性状态（representative states）——hover、disabled、error、empty 等。

审计必须回答以下六个问题：

• 哪些颜色是已确认的品牌承诺（confirmed brand commitments）？
• 当前的表面色、文字色、动作色、语义色分别由什么承担？
• 哪些位置因灰度而模糊了层级或状态（grayscale obscures hierarchy or state）？
• 存在哪些对比度失败与仅靠颜色传达信息（color-only communication）的情况？
• 是否有明/暗主题或数据可视化需求？
• 任务要求的是更多颜色，还是一个新身份？

这套审计逻辑与 Live 模式 Phase A 的"身份提取（identity lock）"一脉相承：写下一句话记录屏幕上真实存在的东西——主导表面色与强调色（真实数值，而非"温暖"这类形容词）、加载的字型配对、布局拓扑、表面处理与文案语气。身份锁定后，每个变体都必须读起来是同一个品牌。

选择策略：命名四要素，构建角色而非色卡

策略必须在编辑前明确命名四个要素：

• 情绪温度（emotional temperature）——这个界面要让访客感受到什么；
• 主导关系（dominant relationship）——主色与次色的支配关系；
• 对比范围（contrast range）——明暗跨度；
• 色彩剂量（color dosage）——色彩在表面上占据的分量。

策略可以是克制的（restrained），也可以是沉浸式的（immersive），但必须服从 brief 与被选定的视觉世界，而不是某个固定的百分比规则。

随后是本文档最有价值的框架之一——构建角色（roles），而非一袋色卡（a bag of swatches）。建议的角色清单：

• 画布与抬升表面（canvas and elevated surfaces）；
• 主文字与次文字（primary and secondary text）；
• 动作、焦点与选择（action, focus, and selection）；
• 边框与分隔线（borders and separators）；
• 成功、警告、错误与信息（success, warning, error, and information）；
• 需要时的数据类别或尺度（data categories or scales）。

这一"角色优先"思路与new-work.md中的色彩战略框架直接对应（Restrained 中性色+单强调色 / Committed 单个饱和色承担 30-60% 表面 / Full palette 3-4 个具名角色 / Drenched 表面即色彩），但 colorize 的场景是在既有世界里分配角色，而非从零选择战略。

使用项目现有的色彩空间：优先 OKLCH

文档的硬性要求是：使用项目现有的色彩空间。若为新 Web 调色板，优先 OKLCH，因为其明度（lightness）与彩度（chroma）可以可预测地调整。色相（hue）的选择应来自产品意义与视觉方向，绝不要来自默认的类别联想（例如"科技=蓝色""健康=绿色"）。

OKLCH 并非空谈——Impeccable 仓库中就有完整的 OKLCH 调色板种子实现：palette.rs 实现了impeccable palette命令，从内置种子（SEEDS）中按色相桶加权选取一个种子，并输出形如oklch(L C H)的标准值。其hue_word函数将色相角度映射为人类可读的色相词（如oklch(0.67 0.13 25.0)→ "warm coral / burnt orange"），可供策略命名与沟通时直接使用。种子还可以通过--id指定、通过--from <key>或环境变量IMPECCABLE_PALETTE_SEED确定性选取（SHA-256 哈希到 [0,1) 单位区间）。这从工具链层面证明了 OKLCH 是该项目色彩工作的第一公民色彩空间。

系统规模应用：颜色如何真正"落位"

文档给出了七条在系统规模上应用色彩的准则：

1. 让最强的颜色拥有一个深思熟虑的区域或角色，而不是把微小的强调色撒得到处都是（scattering tiny accents）；
2. 保持主行动（primary action）易于被发现，不要把它应有的颜色花在装饰上；
3. 仅当品牌色相真正产生凝聚力时才给中性色染色；当服务于该世界时，中性灰是合法选择；
4. 在彩色表面上，次级文字应从前景色或表面色推导，而不是用洗白的通用灰（washed-out generic gray）——这条规则同时出现在 craft-floor.md 的对比度检查中："在彩色表面上从该色相或前景色调出次级文字，永远不要用灰色"；
5. 保持语义含义一致，但尊重平台与领域惯例，而非假设固定色相（例如错误色不必永远是红色）；
6. 数据可视化：使用不同的明度、彩度、形状、标签或图案，确保颜色不是唯一的编码通道；
7. 暗色模式下显式设计表面抬升与对比，不要机械地反转亮色主题——同样地，craft-floor 也禁止"按类别挑选明暗主题"，应从使用场景（谁、在哪、什么环境光下）决定。

当项目存在 token 系统时，定义原始值（primitive values）与语义 token（semantic tokens），主题切换通常应重新映射语义角色，而非替换原始值。最后一句原则性警告：与层级、状态、内容或视觉世界无关的装饰性颜色，不是色彩战略。

对比度与感知：不要只靠肉眼

文档给出了一张必须遵守的 WCAG AA 最小对比度表：

核查要求包括：

• 不要只靠肉眼：检查交互状态、遮罩/浮层（overlays）、图片上的文字、禁用内容与两套主题；
• 模拟常见视觉缺陷（色盲/色弱模拟）；
• 颜色传达的信息必须有文字、形状、图标或位置作为非颜色通道；
• 推导 OKLCH 渐变时，靠近白色与黑色要降低明度变化并减少彩度——不要为了让数学均匀而在极端明度处保持高彩度；
• 优先使用显式颜色，而非多层的半透明叠加（alpha chains）——当 alpha 使对比度依赖上下文（context-dependent）时，用显式色值。

值得注意 craft-floor 还补充了一条与色彩强相关的深度规则：阴影必须带偏移与柔和模糊，"零偏移的彩色光晕（glow/halo）只是装饰"——这提醒我们在引入强调色时，色块承载的"深度语义"必须真实。

验证清单：调色板是否真的站得住

完成着色后，用文档的六项验证逐条自检：

1. 每种颜色都有稳定的角色或世界特定的氛围目的；
2. 注意力落在意图中的动作、内容或状态上；
3. 调色板在安静、密集、交互、错误与空状态下都成立；
4. 亮/暗主题各自成体系，而非机械反转；
5. 在所有相关状态下，对比度与非颜色线索都通过；
6. 结果可辨认地是这个产品，而不是通用的"彩色化"处理。

当调色板赢得自己的位置后，文档规定移交impeccable polish做最终一遍打磨——colorize 管色彩战略，polish 管收尾质量，二者边界清晰。

Live 模式签名参数：color-amount 契约

当 colorize 从 Live 模式（浏览器元素级变体生成）被调用时，存在一个必须遵守的签名参数契约。每个变体都必须声明一个color-amount参数，且 CSS 必须针对var(--p-color-amount, 0.5)编写，这样用户可以在不重新生成的情况下，从当前中性版本滑动到该变体的完整色彩战略。

参数声明使用 Impeccable 的参数 schema（见 live.md 的data-impeccable-params与第 7 节参数契约）：

{"id":"color-amount","kind":"range","min":0,"max":1,"step":0.05,"default":0.5,"label":"Color amount"}

在 HTML/JSX 路径上，它以内联属性形式挂载在变体外层容器上：

<div contenteditable="false">【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccable