尧图网页设计 
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因为它决定了颜色的职责分工模式色彩的工作方式Persuade说服 Experience体验色彩可以承载产品的声音voice在被选定的视觉世界召唤时可以占据大面积区域own large regionsOperate操作 Read阅读色彩主要编码动作、选择、状态、寻路与阅读层级稀有性rarity赋予强调色力量在 Operate/Read 模式下强调色accent的价值恰恰来自稀缺——到处都用等于没有强调。这也是 Live 模式 Phase B 中默认模式保留身份、仅在表达层面变化原则在色彩维度的投影见 live.md。审计先行动手前必须读什么文档要求在选择任何颜色之前完成一次系统审计。需要阅读的材料包括DESIGN.md——承载可持续的视觉决策视觉系统字段tokens——CSS 自定义属性通常是事实上的 token 系统de-facto tokens资产assets与当前主题themes——明暗两套都要看代表性状态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 是该项目色彩工作的第一公民色彩空间。系统规模应用颜色如何真正落位文档给出了七条在系统规模上应用色彩的准则让最强的颜色拥有一个深思熟虑的区域或角色而不是把微小的强调色撒得到处都是scattering tiny accents保持主行动primary action易于被发现不要把它应有的颜色花在装饰上仅当品牌色相真正产生凝聚力时才给中性色染色当服务于该世界时中性灰是合法选择在彩色表面上次级文字应从前景色或表面色推导而不是用洗白的通用灰washed-out generic gray——这条规则同时出现在 craft-floor.md 的对比度检查中在彩色表面上从该色相或前景色调出次级文字永远不要用灰色保持语义含义一致但尊重平台与领域惯例而非假设固定色相例如错误色不必永远是红色数据可视化使用不同的明度、彩度、形状、标签或图案确保颜色不是唯一的编码通道暗色模式下显式设计表面抬升与对比不要机械地反转亮色主题——同样地craft-floor 也禁止按类别挑选明暗主题应从使用场景谁、在哪、什么环境光下决定。当项目存在 token 系统时定义原始值primitive values与语义 tokensemantic tokens主题切换通常应重新映射语义角色而非替换原始值。最后一句原则性警告与层级、状态、内容或视觉世界无关的装饰性颜色不是色彩战略。对比度与感知不要只靠肉眼文档给出了一张必须遵守的 WCAG AA 最小对比度表内容WCAG AA 最小值正文body text4.5:1大字号文字large text3:1控件、图标、焦点指示controls, icons, focus indicators3:1核查要求包括不要只靠肉眼检查交互状态、遮罩/浮层overlays、图片上的文字、禁用内容与两套主题模拟常见视觉缺陷色盲/色弱模拟颜色传达的信息必须有文字、形状、图标或位置作为非颜色通道推导 OKLCH 渐变时靠近白色与黑色要降低明度变化并减少彩度——不要为了让数学均匀而在极端明度处保持高彩度优先使用显式颜色而非多层的半透明叠加alpha chains——当 alpha 使对比度依赖上下文context-dependent时用显式色值。值得注意 craft-floor 还补充了一条与色彩强相关的深度规则阴影必须带偏移与柔和模糊零偏移的彩色光晕glow/halo只是装饰——这提醒我们在引入强调色时色块承载的深度语义必须真实。验证清单调色板是否真的站得住完成着色后用文档的六项验证逐条自检每种颜色都有稳定的角色或世界特定的氛围目的注意力落在意图中的动作、内容或状态上调色板在安静、密集、交互、错误与空状态下都成立亮/暗主题各自成体系而非机械反转在所有相关状态下对比度与非颜色线索都通过结果可辨认地是这个产品而不是通用的彩色化处理。当调色板赢得自己的位置后文档规定移交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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Impeccable Colorize 指南：在既有品牌约束内为单色 UI 注入有意义的色彩系统
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因为它决定了颜色的职责分工模式色彩的工作方式Persuade说服 Experience体验色彩可以承载产品的声音voice在被选定的视觉世界召唤时可以占据大面积区域own large regionsOperate操作 Read阅读色彩主要编码动作、选择、状态、寻路与阅读层级稀有性rarity赋予强调色力量在 Operate/Read 模式下强调色accent的价值恰恰来自稀缺——到处都用等于没有强调。这也是 Live 模式 Phase B 中默认模式保留身份、仅在表达层面变化原则在色彩维度的投影见 live.md。审计先行动手前必须读什么文档要求在选择任何颜色之前完成一次系统审计。需要阅读的材料包括DESIGN.md——承载可持续的视觉决策视觉系统字段tokens——CSS 自定义属性通常是事实上的 token 系统de-facto tokens资产assets与当前主题themes——明暗两套都要看代表性状态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 是该项目色彩工作的第一公民色彩空间。系统规模应用颜色如何真正落位文档给出了七条在系统规模上应用色彩的准则让最强的颜色拥有一个深思熟虑的区域或角色而不是把微小的强调色撒得到处都是scattering tiny accents保持主行动primary action易于被发现不要把它应有的颜色花在装饰上仅当品牌色相真正产生凝聚力时才给中性色染色当服务于该世界时中性灰是合法选择在彩色表面上次级文字应从前景色或表面色推导而不是用洗白的通用灰washed-out generic gray——这条规则同时出现在 craft-floor.md 的对比度检查中在彩色表面上从该色相或前景色调出次级文字永远不要用灰色保持语义含义一致但尊重平台与领域惯例而非假设固定色相例如错误色不必永远是红色数据可视化使用不同的明度、彩度、形状、标签或图案确保颜色不是唯一的编码通道暗色模式下显式设计表面抬升与对比不要机械地反转亮色主题——同样地craft-floor 也禁止按类别挑选明暗主题应从使用场景谁、在哪、什么环境光下决定。当项目存在 token 系统时定义原始值primitive values与语义 tokensemantic tokens主题切换通常应重新映射语义角色而非替换原始值。最后一句原则性警告与层级、状态、内容或视觉世界无关的装饰性颜色不是色彩战略。对比度与感知不要只靠肉眼文档给出了一张必须遵守的 WCAG AA 最小对比度表内容WCAG AA 最小值正文body text4.5:1大字号文字large text3:1控件、图标、焦点指示controls, icons, focus indicators3:1核查要求包括不要只靠肉眼检查交互状态、遮罩/浮层overlays、图片上的文字、禁用内容与两套主题模拟常见视觉缺陷色盲/色弱模拟颜色传达的信息必须有文字、形状、图标或位置作为非颜色通道推导 OKLCH 渐变时靠近白色与黑色要降低明度变化并减少彩度——不要为了让数学均匀而在极端明度处保持高彩度优先使用显式颜色而非多层的半透明叠加alpha chains——当 alpha 使对比度依赖上下文context-dependent时用显式色值。值得注意 craft-floor 还补充了一条与色彩强相关的深度规则阴影必须带偏移与柔和模糊零偏移的彩色光晕glow/halo只是装饰——这提醒我们在引入强调色时色块承载的深度语义必须真实。验证清单调色板是否真的站得住完成着色后用文档的六项验证逐条自检每种颜色都有稳定的角色或世界特定的氛围目的注意力落在意图中的动作、内容或状态上调色板在安静、密集、交互、错误与空状态下都成立亮/暗主题各自成体系而非机械反转在所有相关状态下对比度与非颜色线索都通过结果可辨认地是这个产品而不是通用的彩色化处理。当调色板赢得自己的位置后文档规定移交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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考