Impeccable colorize 指南：在单色界面上建立有层次的战略性配色系统

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 text4.5:1大文本large text3:1控件、图标、焦点指示controls, icons, focus indicators3:1配套的感知规则包括不要只靠肉眼判断逐一检查交互态、叠加层、图片上的文字、禁用内容、亮暗两套主题模拟常见视觉缺陷如色盲凡由颜色传达的信息还需要文字、形状、图标或位置作为非颜色通道冗余传递与第 6 节数据可视化规则呼应。7.1 OKLCH 色阶的推导纪律当用 OKLCH 推导色阶ramp时文档提出两点技术性约束变动明度并在接近白色与接近黑色处降低彩度——不要为了让数学上均匀而把高彩度保持到极端明度优先使用显式颜色而非一串半透明叠加层因为 alpha 会把对比度变成依赖上下文的值无法稳定校验。这两条直接服务于第 7 节开头那张表的可达成性一个接近白的表面上放着高彩度低明度的文字对比度往往不达标显式声明颜色则让每个状态的对比度都可被独立计算。8. 验证清单与交接完成铺色后按以下清单自检Verification每个颜色都有稳定的角色或服务于世界特定氛围的用途注意力落在意图中的动作、内容或状态上色板在安静、密集、交互、报错、空状态下都成立亮/暗两套主题各自是被设计过的而非机械取反所有相关状态下的对比度与非颜色线索都通过结果仍一眼是这个产品而不是某种通用的彩色化处理。当色板真正赢得自己的位置后工作交接给/impeccable polish详见 skill/reference/polish.md做最终质量收尾。这也是 Impeccable 工作流的固定节奏colorize 负责把色彩策略做对polish 负责最终一公里。9. live 模式下的签名参数color-amountcolorize是少数几个在 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 声明品牌与中性色 tokenkinpaku-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），仅供参考