米色 + 黄铜 + 浓缩咖啡：被逐个 hex 点名封杀的高端消费色板

2026-08-09

本文所有仓库信息核对日为 2026-08-09，以上游仓库最新内容为准。

taste-skill 默认 skill（文件夹 taste-skill，install name design-taste-frontend，当前自标 v2 experimental）的 §4.2 里有一段东西，读法和这个仓库大多数规则都不一样。它不是「注意品牌调性」「少用暖色」这种可以各自解读的原则，而是把十六个具体的十六进制值摊在那里，逐个点名封杀。

一、这条规则原文长什么样

它的名字叫 PREMIUM-CONSUMER PALETTE BAN，标注为强制（mandatory），并且原文自称是「第二高频复发的 AI tell」。

它管的范围写得很清楚：premium-consumer 类需求 —— 炊具、健康养生、手作、奢品、传承工艺、DTC 家居等等。规则说，面对这类需求，LLM 的默认反射是暖米 / 奶油底 + 黄铜 / 陶土 / 牛血红 / 赭石 + 浓缩咖啡色或墨黑文字。然后它把这套反射拆成三组，逐个列出：

角色	被点名封杀作默认的 hex	原文给的归类
背景	`#f5f1ea`、`#f7f5f1`、`#fbf8f1`、`#efeae0`、`#ece6db`、`#faf7f1`、`#e8dfcb`	暖纸 / 奶油 / 白垩 / 骨色
强调	`#b08947`、`#b6553a`、`#9a2436`、`#9c6e2a`、`#bc7c3a`、`#7d5621`	黄铜 / 陶土 / 牛血 / 赭石
文字	`#1a1714`、`#1a1814`、`#1b1814`	浓缩咖啡 / 暖近黑

十六个值。注意背景那七个之间、文字那三个之间的差别有多小 —— #1a1714 和 #1a1814 只差一位，而两个都被单独列了出来。清单是怎么攒出来的，原文没有交代，我们也不去猜；但它写到这个粒度这件事本身，就决定了它的读法和别的规则不一样。

原文给的理由只有一句，但很重：你做过的每一个 premium-consumer 站点都用这套色板，品牌因此变得隐形。

二、为什么值得写到 hex 这个粒度

这是判断这条规则该不该照做的第一个依据。

同一节里的其它规则都停在原则层：「最多 1 个强调色」「默认饱和度低于 80%」「一个项目一套色板，不许在暖灰和冷灰之间来回摆」。这些话你可以按自己的理解执行，执行结果因人而异。而 hex 清单是没有解释余地的 —— 一个色值要么在名单上，要么不在。

对模型来说，这个差别是实打实的。「避免陈词滥调的暖色调」这种指令，模型完全可以一边点头一边输出 #f5f1ea，因为它并不觉得自己在用陈词滥调。而把 #f5f1ea 写出来，就把「什么算陈词滥调」这件事从模型的自我判断里拿走了。

同一份 §4 里还有另一条规则用了类似手法：§4.1 的 SERIF DISCIPLINE 直接点名 Fraunces 和 Instrument_Serif 两款 display 衬线，原文称这是 LLM 最爱的两款，并把「创意需求 = 衬线」这套默认心智模型说成「生产测试中被测得最多的一个 AI tell」。本文这条则自称「第二高频复发的 AI tell」。这类自我排序的说法在 §4 里不止一处（§4.7 的 EYEBROW RESTRAINT 还自称是「生产测试中被违反次数第一的规则」），都是文档自述的口径，看看就好，不必去排名次。衬线那条我们另有一篇专门讲。

三、先确认你的需求在不在射程内

这条规则只管 premium-consumer 这一类需求。你在做 B 端控制台、开发者工具站、政务信息页，这十六个 hex 跟你没关系，照着挑背景色也没有违反任何东西。

这一点值得单独强调，因为规则清单读多了容易产生一种错觉，觉得凡是被点名的值就是「不好的颜色」。原文不是这个意思。它封杀的是在特定需求类型下的默认反射，不是这些颜色本身 —— 规则原文给的理由是这套色板让品牌变得隐形，不是说某个色值不好。#f5f1ea 就是个暖白，问题在于「一接到炊具需求就伸手去拿它」这个动作。

所以照做与否的第一步是自问：我这个页面，是不是那种「一想就想到工艺感、温暖、手作、传承」的东西？是，这条规则对你成立；不是，翻过去看下一条。

四、七套替代方案，重点在「轮换」而不是「换一个默认」

原文给了七套默认替代，并明确要求「轮换，不许复用」：

Cold Luxury：银灰 + 铬 + 烟灰
Forest：深绿 + 骨色 + 琥珀强调
Black and Tan：真正的近黑 + 暖棕褐，锐利对比，不带米色
Cobalt + Cream：饱和蓝对单一中性色，不带黄铜
Terracotta + Slate：暖锈红对冷灰，不带黄铜
Olive + Brick + Paper：柔橄榄加砖红强调
纯单色 + 单个饱和亮点：灰白 + 灰黑 + 一个亮色（电光蓝、翠绿、亮粉等）

紧跟着是 Palette-rotation rule：上一个 premium-consumer 项目若用了米色 + 黄铜家族，这一个必须换家族，不许连着出两次同款暖工艺色板。

这条轮换规则才是这一节真正的机制。如果只给替代清单，结果只会是把默认从米色 + 黄铜换成 Forest，然后每一个养生品牌都变成深绿加骨色 —— 问题一点没解决，只是换了个壳。加上轮换要求，规则的目标就从「别用这套色」变成了「别有固定的那一套」。

对你的实际影响是：这七套不是让你从中挑一个最喜欢的，而是让你记住上次用了哪个。而「上次用了哪个」这条信息，SKILL.md 里没有任何地方存 —— 这个仓库是纯 Markdown 规则文件，没有 src/、没有构建产物、没有任何运行时来记录你的项目历史。规则写了这条要求，执行这条要求的记账工作落在你身上。

五、Override 的两个口子

规则给了明确的例外路径，只有两条，满足其一即可：

品牌需求文档里明确点名了这些颜色；或者
品牌确实是 vintage / artisan / warm-craft，并且你能说清为什么是这套颜色配这个品牌。

第二条的后半句是关键。它要的不是「这个品牌感觉挺手作的」，而是一段能讲出口的理由。原文还专门把一种情况排除掉了：「因为这是炊具需求」就去默认反射它，是被禁的。

也就是说，需求所属的品类本身不构成理由。这个区分很细但很实用 —— 走 override 路径的正确姿势，是在你的 prompt 或需求文档里把颜色写死（口子一），或者把品牌与色板的对应关系讲明白（口子二）。你只是心里觉得该用米色，那不是 override，那就是默认反射。

同一节的 THE LILA RULE 用的是完全一样的结构：默认不许自动上「AI 紫 / 蓝色辉光」，但品牌明确要紫色就大方用，只是要执行到位。两条规则的 override 都建立在同一个前提上 —— 信息来自需求方，而不是来自模型的自动补全。

六、一处并存的写法

有个细节读的时候会顿一下：被封杀的强调色家族里，原文明写包含「陶土」（clay，#b6553a 一组）；而七套替代方案里，第五套叫 Terracotta + Slate，terracotta 就是陶土。

这两处在同一节内并存。差别写在替代方案的限定语里 —— Terracotta + Slate 的描述是「暖锈红对冷灰，不带黄铜」，而被封杀的是陶土色出现在「暖米底 + 黄铜」那一整套组合里。两处写法不同，以仓库当前状态为准；我们不推断哪一处更准确，也不据此评价什么。你自己用的时候知道有这么个并存点就行。

七、★ 这十六个 hex 写得再具体，也不会有任何东西去匹配它

这是全篇最需要带走的判断。

taste-skill 的仓库里没有 src/，没有构建产物，没有运行时。SKILL.md 从头到尾是 Markdown，是写给模型看的提示词约束。所以「#f5f1ea 被封杀」这句话的性质，是一条指令，不是「装了之后你的 CSS 里不会出现 #f5f1ea」这个结果。中间隔着模型会不会照做的问题。

这一点在颜色这条规则上格外容易误会，恰恰因为它写得太像 lint 规则了。十六个精确到位的 hex，摆出来的样子简直就是一份可以直接喂给静态检查的黑名单。但仓库里并没有那个检查器，规则也没说要有。

所以怎么用它，取决于你要什么：

你要的是提高概率 —— 让模型下次接到炊具落地页需求时，不那么容易伸手去拿米色 + 黄铜。这条规则直接对着这个目标去，用就是了。
你要的是确定性 —— 交付前必须保证产物里没有这十六个值。那你得自己在构建链里加一步检查，把这份清单转成 grep 或 stylelint 的规则。这是我们给的通用工程做法，不是 taste-skill 仓库里的内容，规则文本本身不提供这一层。

顺带说一句，真要做这层机械检查也要留神：这十六个 hex 是「作为默认」被封杀的，走了 override 的项目里它们是合法的。所以检查规则得能被显式豁免，否则会把正当用法一起拦下来。

八、还有一条相邻规则会一起咬你

§4.7 里的 Bento Background Diversity 有一句直接相关的话：奶油底上再放奶油底、里面只有排版的 bento 网格，即使页面其余部分不错，读起来仍然是无聊的 AI 默认。它要求任何多格网格里至少有 2-3 个格子有真实视觉变化 —— 真图、贴合品牌的渐变（不是 AI 紫）、图案或有色背景。

把这两条并起来看就明白了：色板这条管的是选什么颜色，bento 那条管的是选定之后页面上有没有别的东西。一个 premium-consumer 落地页如果既走了米色默认，又是清一色奶油底卡片堆排版，那是同时踩了两条。反过来，就算你按 §4.2 换成了 Forest，整页六个绿底白卡照样过不了 bento 那一关。

九、收尾

这条规则的价值不在那十六个色值本身，而在它示范了一种写法：当你发现某个默认行为反复出现，最有效的约束不是讲道理，是把它具体到没法各自解读的程度。你自己在写团队的 AI 编码规范时，这个思路可以直接搬。

至于米色加黄铜好不好看 —— 规则从头到尾没说它难看，只说了它让品牌变得隐形。这两件事不一样。

本文依据 taste-skill 官方仓库（github.com/Leonxlnx/taste-skill）的 README、CHANGELOG、 skills/ 下的 SKILL.md 与 .claude-plugin/ 清单整理，核对日 2026-08-09。本文内容为仓库文档口径，我们没有安装或运行过其中任何一个 skill，文中所有规则均为写给模型的提示词约束，不构成对输出结果的保证。 skill 内容随上游更新而变动，默认 skill 当前自标为 v2 (experimental) 且仍在迭代，请以仓库最新内容为准。文中提到的构建链检查做法为通用工程实践，非该项目官方文档内容，请结合自身环境评估。