Impeccable colorize 配色指南在既有品牌世界里引入有策略的颜色【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccable背景上下文执行 colorize 前需要先获取并确认现有品牌颜色作为额外上下文existing brand colors。Impeccable 的colorize命令技能定义见 SKILL.md用于为过于单调、灰暗、缺乏视觉兴趣的界面引入有策略的颜色把颜色当作**层级hierarchy、意义meaning与氛围atmosphere**来使用而不是在上色的幌子下替换整个视觉世界。读完本篇你将掌握 colorize 的完整工作流——从 visitor mode 判定、选色前审计、策略命名到 OKLCH 色阶推导、WCAG 对比验证、系统尺度应用以及 Live 模式下的color-amount签名参数契约同时你会看到这些规则如何在仓库的 Rust 实现crates/foundation/src/color.rs、crates/context/src/palette.rs与工程质量地板craft-floor.md中得到落地。一、colorize 的定位与核心原则在 Impeccable 的命令体系中colorize属于Enhance增强类命令。其在 command-metadata.json 中的定义为Add strategic color to features that are too monochromatic or lack visual interest, making interfaces more engaging and expressive. Use when the user mentions the design looking gray, dull, lacking warmth, needing more color, or wanting a more vibrant or expressive palette.即当用户提到设计看起来灰、沉闷、缺少温度、需要更多颜色、想要更鲜明更有表现力的调色板时触发。触发场景明确、目标单一——为既有界面加入有策略的颜色。colorize 的第一条铁律写在文档开头引入颜色作为层级、意义与氛围。保留已确认的品牌与语义惯例不要借上色之名替换一个视觉世界。这句话定义了命令的边界保留品牌承诺已确认的 brand colors 是约束不是素材保留语义惯例成功/警告/错误/信息的既有语义色不能因好看而被改写不是身份替换如果任务真正要求的是一个全新身份new identitycolorize 不负责这件事应转入 new-work.md。从源码结构看这套保留 vs 替换的分界与 SKILL.md 中Refinement preserves; redesign replaces的原则一脉相承colorize 属于 refinement默认保留既有身份只有用户显式要求重建时才进入 departure 模式。二、先定 visitor mode颜色在这块表面上承载什么动手选色之前必须先回答一个问题这块表面的访客成功长什么样Impeccable 将其划分为四类 mode见 SKILL.mdcolorize 文档将其归并为两种颜色策略模式组合颜色的职责Persuade Experience营销、活动、作品集、画廊颜色可以承载声音voice当所选视觉世界需要时可以占有大面积区域设计即产品颜色是说服与体验的一部分Operate Read应用 UI、仪表盘、文档、帮助颜色主要用于编码动作、选中、状态、寻路与阅读层级此时稀缺性赋予强调色力量——颜色用得越少单一强调色越有力同一块表面必须二选一且 mode 只在对应的 surface brief 中持久化。这也是后续一切颜色决策的前提在 Operate 界面上把大面积区域染成氛围色与在 Persuade 页面上使用克制点缀一样都是策略错位。三、选色前先审计读什么、找什么先审计再选色是 colorize 的固定步骤。在执行任何颜色编辑之前需要读取以下输入DESIGN.md视觉系统字段若缺失则从 CSS 变量、计算样式与兄弟组件提取身份tokens原始色值与语义 token若项目有 token 系统assets真实资源避免在占位色上做决策当前主题light/dark 各一套代表性状态hover、disabled、loading、error、empty 等。在此基础上逐项识别对应文档原文六条清单哪些颜色是已确认的品牌承诺当前的表面、文本、动作与语义角色分别是什么哪些位置灰度掩盖了层级或状态存在哪些对比失败与纯颜色传达color-only communication问题是否存在亮/暗主题或数据可视化要求任务要的是更多颜色还是一个全新身份。审计结论决定后续分支若需要全新身份使用 new-work.md只有当无法从现有材料推断出有约束力的品牌决策时才向用户提问。换言之推断优先、提问兜底。四、选择策略先命名意图再动笔colorize 要求在任何编辑之前先命名四个设计意图情绪温度emotional temperature这片颜色是冷、暖、中性还是混合主导关系dominant relationship主色与表面、强调色之间是什么关系对比范围contrast range从最亮到最暗的跨度颜色剂量color dosage颜色覆盖多少面积、出现多少次。策略可以是克制的restrained也可以是沉浸式的immersive但必须服从 brief 与所选视觉世界而不是套用一个固定百分比规则不超过 X% 的彩色这类教条被明确否决。构建角色而非一袋色卡这是 colorize 的核心方法论调色板不是一堆好看的色值而是一组职责明确的角色roles。文档列出八类角色canvas 与抬升表面elevated surfaces主文本与次级文本动作、焦点与选中action / focus / selection边框与分隔线成功、警告、错误与信息语义色需要时的数据类别或刻度。每一类角色都应能在界面上找到自己的职位描述没有角色的颜色就是装饰而与层级、状态、内容或视觉世界无关的装饰不是颜色策略文档原话。色彩空间优先 OKLCH使用项目现有的色彩空间——不要为了现代而强行改写既有体系对于全新的 web 调色板优先 OKLCH因为它的lightness明度与 chroma彩度可以可预测地独立调整色相hue从产品含义与视觉方向中选择绝不从默认的类别联想中选比如金融蓝、健康绿这种默认映射是被明确否定的。仓库对此提供了直接的工具支撑impeccable palette命令crates/context/src/palette.rs内置了由 palette_data.rs 生成的 100 个种子seed每个种子都以oklch(L C H)三元组为核心并附带一句 mood氛围与一句 strategy策略提示。例如Seed { id: seed-201, l: 0.647, c: 0.262, h: 0.3, mood: sealing-wax crimson — one confident stamp of red on pristine white paper, strategy: Pure white surface lets a high-chroma crimson primary do all the brand work, paired with a hue-shifted warm coral accent for hierarchy without competing saturation }种子通过--id seed直接选取或用--from key对 key 做 SHA-256 哈希后加权挑选hash_unit与weighted_pick实现于 palette.rs也可通过环境变量IMPECCABLE_PALETTE_SEED指定。输出会给出oklch(L C H)原值、色相的自然语言描述hue_word如 pure red、teal、cobalt / indigo以及一条示例策略。这正呼应了色相从产品含义出发的原则——种子提供的是方向与参考最终 hue 仍由产品含义裁定。五、在系统尺度上应用颜色colorize 不追求这里加一点、那里加一点而是强调**系统尺度system scale**上的应用。文档给出七条操作性规则让最强的颜色拥有一个刻意的区域或角色而不是散落成小碎点scattering tiny accents保持主操作易被发现——不要把它专属的颜色花在装饰上中性色染色要克制只有当品牌色调真正创造凝聚力时才给中性色染色当灰符合该视觉世界时中性灰是完全有效的选择彩色表面上的次级文本从前景色或表面色派生而不是用洗过的泛灰washed-out generic gray保持语义含义一致但尊重平台与领域惯例不要假定固定的语义色相平台惯例优先于个人偏好数据可视化中颜色不能是唯一编码——同时使用明度、彩度、形状、标签或图案保证色弱用户也能区分暗色模式要显式设计表面高度与对比不要机械地反转亮色主题。当项目存在 token 系统时还应先定义原始值primitives与语义 tokensemantic tokens主题切换通常只重映射语义角色——即亮暗主题共享同一组原始色值通过语义 token 指向不同的原始值而不是为暗色主题另起一套颜色。六、对比与感知用计算验证而非肉眼颜色策略是否成立最终要落到计算过的前景/背景对比上。colorize 文档给出的 WCAG AA 最低门槛如下内容WCAG AA 最低对比正文文本body text4.5:1大号文本large text3:1控件、图标、焦点指示controls, icons, focus indicators3:1并且强调不要只依赖肉眼判断。需要检查的状态包括交互状态hover/active/focus、叠加层overlays、图片上的文字、禁用内容disabled content、以及亮暗两套主题还应模拟常见视觉缺陷色盲/色弱。凡是用颜色传达的信息必须同时有文本、形状、图标或位置作为冗余通道。源码中的对比与中性判断这些规则在仓库中有直接的 Rust 实现crates/foundation/src/color.rs它们支撑着 Impeccable 的检测器在编辑后自动核查颜色质量relative_luminance与contrast_ratio按 WCAG 相对亮度公式计算对比度——正是上面表格三条门槛的度量函数is_neutral_color用正则解析rgb/rgba、oklch/lch/oklab/lab、hsl/hwb等多种写法通过 max-min 差RGB 阈值 30或彩度阈值OKLCH 阈值 0.02、HSL 饱和度阈值 10 等判定某颜色是否中性——用于识别该有颜色却灰掉的区域has_chroma(c, threshold 30)判断颜色是否带彩度get_hue从 RGB 计算色相角支撑色相族划分composite_color_over与parse_color_mix处理半透明叠加与color-mix()——对应文档中优先显式颜色而非半透明叠加链的规则。工程地板 craft-floor.md 对颜色提出了与 colorize 一致的硬性检查Contrast: body and placeholder text ≥4.5:1, large text ≥3:1. On colored surfaces tint secondary text from that hue or the foreground; never gray.正文与占位文本 ≥4.5:1大号文本 ≥3:1彩色表面上的次级文本从该色调或前景色派生绝不用灰。当项目的设计钩子hook开启时这些机械检查会在编辑时自动执行colorize 需要与检测结果协同。OKLCH 色阶推导的要点文档对 OKLCH ramp 的推导给出两条明确约束变化 lightness并在接近纯白与纯黑时降低 chroma不要为了数学上的均匀在极端明度处维持高 chroma高彩度在极亮/极暗处是感知错误不是精确。另一个关键建议优先显式颜色而不是一串半透明叠加层——因为 alpha 会让最终对比变得依赖上下文叠在什么上面就是什么无法稳定通过对比验证。这正是composite_color_over这类函数存在的意义把叠加结果算出来再验证算出来的实色。七、验证清单与交接颜色全部落地后按以下五项逐条验证对应文档原文每个颜色都有一个稳定的角色或一个属于该视觉世界的氛围用途注意力落在预期的动作、内容或状态上调色板在安静、密集、交互、错误与空状态下都成立亮暗主题各自被独立构图而非机械反转对比与非颜色线索在所有相关状态下通过最终结果可被认出是这款产品而不是通用的彩色化处理。当调色板证明了自己的位置后交接给/impeccable polish做最终质量收尾。八、Live 模式下的 colorizecolor-amount 签名参数当 colorize 从live 模式被调用时存在一个强制契约每个 variant 都必须声明一个color-amount参数。CSS 必须基于var(--p-color-amount, 0.5)编写这样用户可以在中性与该 variant 的完整颜色策略之间连续滑动而无需重新生成。参数定义文档原文 JSON{id:color-amount,kind:range,min:0,max:1,step:0.05,default:0.5,label:Color amount}这是一个range类型的滑块min0、max1、step0.05、默认值 0.5。滑块在浏览器中以零成本驱动 CSS 变量--p-color-amount你的作用域 CSS 里写作var(--p-color-amount, 0.5)。除color-amount外最多再添加两个 variant-specific 参数例如 palette调色板选择、temperature冷暖或 tint behavior染色行为。所有参数都必须遵循 live.md 的参数契约。live 模式下 colorize 的完整行为结合 live.md 可以还原 colorize 在 live 会话中的完整语义每次 colorize 调用三个 variant 必须是不同的色相家族并且变化彩度与对比策略different hue family each; vary chroma and contrast strategy——这与上文每个 variant 从不同主轴上做文章的原则一致参数是设计的一部分在规划三个 variant 时就要为每个 variant 命名 2–3 个参数旋钮而不是事后补装参数预算按元素的视觉体量缩放叶级/微型元素按钮、图标、裸标题0 参数小型组合简单卡片、带标签输入框≤5 个视觉子元素0–1 个中型组合区块、导航簇6–15 个目标 2 个大型组合hero、整个区域16 个目标 2–3 个硬上限 4 个。color-amount是 colorize 的 MUST 参数在预算内强制占位且不可重复参数声明写在 wrapper 属性data-impeccable-params上组件预览路径则写在componentDir/params.json按 variant 编号键控schema 相同接受accept时浏览器回传当前参数值impeccable live-accept将其写成兄弟注释!-- impeccable-param-values SESSION_ID: {color-amount:0.7} --随后的 carbonize 清理会把滑块值烘焙进源码——range参数替换为字面量或更新变量的默认值。因此live 模式下的 colorize 工作流是规划三个不同色相家族与彩度/对比策略的 variant → 每个 variant 声明color-amount 至多两个辅助参数→ 用var(--p-color-amount, 0.5)编写 CSS → 交付后由用户实时滑动参数预览 → 接受后将参数值烘焙为永久形式。结语colorize 的全部规则可以浓缩为一句话颜色在 Impeccable 里是系统的角色分配不是装饰的剂量游戏。从 visitor mode 判定、选色前审计、策略命名到 OKLCH 色阶、WCAG 计算验证、语义 token 重映射再到 live 模式下必须携带的color-amount签名参数——每一步都在回答同一个问题这个颜色在这个界面上负责什么 而 crates/foundation/src/color.rs 的对比/中性/色相判定函数、crates/context/src/palette.rs 的 OKLCH 种子库与 craft-floor.md 的地板检查共同把这份设计判断落成了可计算、可验证、可复用的工程能力。【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccable创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考