★ 每三个区块最多一个 eyebrow：一条能机械计数的规则
本文所有仓库信息核对日为 2026-08-09，以上游仓库最新内容为准。
taste-skill 默认 skill（文件夹 taste-skill，install name design-taste-frontend）的 v2 版本里，绝大多数规则是拿审美判断说事的：什么叫「内容密度合理」、什么叫「经过细致打磨」，最后都得有人拍板。但有一条不是。它给了一个公式：count ≤ ceil(sectionCount / 3)。这条规则管的是 eyebrow，而 SKILL.md 在这条规则名旁边直接标了一句——「生产测试中被违反次数第一的规则」。
一、先说清 eyebrow 是哪个东西
SKILL.md 给的定义是：eyebrow 指区块标题上方那行小号、大写、宽字距的标签。原文举的例子是 FOUR COLORWAYS、SELECTED WORK、THE HARDWARE、Git-native task management 这一类。
它还顺手给了典型的 CSS 特征，这一点比定义本身更有用：
text-[11px] uppercase tracking-[0.18em]
font-mono text-[10.5px] uppercase tracking-[0.22em]
十一像素上下、uppercase、tracking 拉到 0.18em 到 0.22em 这个区间。如果你在自己或模型产出的页面里搜这两串特征，搜到的多半就是 eyebrow。
原文给出的问题描述是：每个 AI 做的站点都在每一个区块标题上加 eyebrow，于是所有页面产出同一种模板节奏。注意这里被指认为问题的不是「用 eyebrow」，而是「每个区块都用」——被盯上的是频率，不是这个元素本身。
二、这条规则其实是三个分句
很多人只记住了第一句，但它一共有三个分句，各管一件事，缺哪个都不完整。
第一句是总量。 每 3 个区块最多 1 个 eyebrow，hero 算 1 个。原文自己举的算例是：9 个区块的页面最多用 3 个。
第二句是间隔。 如果 A 区块用了 eyebrow，接下来 2 个区块不能用。
第三句是检查方式。 原文原话是 Pre-Flight 检查「是机械的」：数所有组件里 uppercase tracking（或类似的小型大写等宽标签）的出现次数，若 count > ceil(sectionCount / 3)，输出判不合格。
同一条约束在 §14 的 Pre-Flight 清单里也有对应的一行，措辞是 EYEBROW COUNT（机械计数），同样写了 count ≤ ceil(sectionCount / 3) 和「hero 算 1」。也就是说规则正文和终检清单在这一条上是对得上的。
三、把公式展开来看，比记一句话管用
ceil 是向上取整，所以配额并不是「区块数除以三」那么直觉。按公式算一遍：
| 区块数 | eyebrow 上限 |
|---|---|
| 3 | 1 |
| 4 | 2 |
| 5 | 2 |
| 6 | 2 |
| 7 | 3 |
| 8 | 3 |
| 9 | 3 |
| 12 | 4 |
有两处容易算错。一是 4 个区块的配额是 2 不是 1，向上取整在这里是放宽而不是收紧；二是 hero 占掉的那一个是从这个总额里扣的，不是额外附送的。一个 6 区块的落地页，只要 hero 用了 eyebrow，剩下 5 个区块里就只剩 1 个名额。
还有一件事得自己先定死：sectionCount 到底怎么数。同一个页面，你按「五个内容区块」数还是把 hero 和页脚都算上按八个数，上限就在 2 和 3 之间跳。规则给的是公式，分母的口径得你自己在项目里统一，否则同一页两个人算出两个答案。
四、总量达标不等于合规
第一句和第二句是两条独立的约束，这一点在实际写页面时最容易翻车。
举个例子：9 个区块的页面，你在第 1、第 2、第 3 个区块各放了一个 eyebrow，总数是 3，正好等于 ceil(9 / 3) 的上限，总量这一关过了。但第二句管的是分布——A 用了之后接下来 2 个区块不能用，这个排法直接违反。
反过来，第 1、第 4、第 7 个区块各一个，总量同样是 3，间隔也满足。两种排法在总量上完全一样，落到页面节奏上是两回事：前者是页面开头连着三顶小帽子，后者才是原文想要的那种稀疏节奏。
这里还有一处值得留意的口径差：Pre-Flight 那一步描述的动作是数出现次数并与上限比较，也就是它落到检查上的形态主要是总量这一半。间隔那一半写在规则正文里，但它不是一个计数动作。你要是打算把这条规则变成自己流程里的一步检查，得知道数个数只覆盖了其中一半。
五、检查的是 CSS 特征，不是语义角色
再看一遍那句检查描述：数的是 uppercase tracking（或类似的小型大写等宽标签）在所有组件里的出现次数。
按这个字面口径，被计数的是写法。如果一个真正意义上的 eyebrow 换了别的实现方式（比如走 font-variant: small-caps、字距不用 tracking- 这类工具类、或者干脆做成图片），那么按这段描述去数，它不一定会被数进去。反过来，uppercase tracking 这套写法在页面上如果还有别的用途，数的时候也要自己判断它算不算「标题上方的微标签」。
说这一点不是为了挑刺，而是因为它直接决定你怎么用这条规则：它是给人和模型做粗筛的口径，不是一个精确的静态分析器。 想要那种精确性，只能自己在构建链里写检查，而这属于你自己项目的工程建设，不是这个仓库提供的东西。我们实读这个仓库的顶层目录，它没有 src/、没有 npm 包、没有构建产物；scripts/ 下确实有 4 个 .mjs，但那几个是处理 README 图片资源的，与 skill 功能无关。核心资产就是 skills/*/SKILL.md 这些 Markdown 文件本身——你装进去的是文字，不是一段会在你项目里跑起来的检查程序。
六、就算在配额内，eyebrow 也有一堆写法被点名
数量之外，SKILL.md 的 §9.F 还单独封杀了几类 eyebrow 的内容。这几条和本篇的配额规则是叠加关系：你哪怕只用了一个 eyebrow，写成下面这些样子照样过不了终检。
- 区块编号型：
00 / INDEX、001 · Capabilities、002 · Featured commission、06 · how it works、05 · The honest table全部被禁。原文要求 eyebrow 用平实语言说明主题，而不是列序号。 - hero 里的版本标签：
V0.6、v2.0、BETA、INVITE-ONLY PREVIEW、EARLY ACCESS、ALPHA作 eyebrow 被禁，只有当需求明确就是关于产品发布或预览状态时才可接受。 Brand · No. 01式子标签：像 “Marrow · No. 01 · The 6-quart” 这种微元信息行，原文让直接跳过。- 年份区间型：
Index of Work, 2018 - 2026这类范围标签作 eyebrow 被禁，直说这个区块是什么。 - eyebrow 下面的微元句子：坐在区块标题下面的那种自说自话的补充句被判为杂物，原文的表述是 Eyebrow + Headline + Body 就够了。
- em-dash：§9.G 的禁令明确覆盖 eyebrow、标签、胶囊、按钮文字、图注、导航项，一个都不许有。
七、hero 那一层还有一道更紧的约束
hero 不只是「占掉一个名额」这么简单。§4.7 的 HERO STACK DISCIPLINE 规定 hero 最多 4 个文本元素，第一项写的是：Eyebrow 或品牌条或都不要——选零个或一个。原文还补了一句，一个 hero 最多一个小文本元素；既有 eyebrow 又有 CTA 下方小标语的，砍掉标语。
所以 hero 里的 eyebrow 同时受两条规则夹击：一条管它在全页配额里占的位置，一条管它在 hero 内部和品牌条、标语之间的互斥关系。
八、那么什么时候该照做
先把这条规则的性质说清，这是判断的前提：SKILL.md 是一份写给模型看的提示词文档，这条规则是一条指令，不是一个装上就自动生效的校验器。「每 3 个区块最多 1 个 eyebrow」的意思是「告诉模型别这么干」，不是「你的页面里从此不会出现第四个 eyebrow」。中间隔着模型听不听话这个问题。
在这个前提下，几个可以自己拿主意的判断点：
如果你的痛点正是「模型产出的落地页节奏一模一样」，那这条规则是直接冲着这个问题去的，而且它是整份清单里少有的、你能自己复算一遍的条目。别的条目像「内容密度合理」「Copy Self-Audit 重读每一个可见字符串」，最后都得靠人判断；这一条你数得清。
如果你要的是确定性，那规则文本给不了。真要机械保障，得把这个计数做进自己的检查环节。这一条本身反而是个好起点，因为它的口径已经写成了可执行的形式：数什么、和什么比、超了怎么判，三样都在。
如果你只是想少写两行标签，原文其实给了最省事的答案：干脆不要。原话大意是标题本身就够了；如果你觉得需要给区块分个类，区块在页面上的位置本身已经完成了分类，不需要额外的标签。这个替代方案不需要你算任何数。
顺带说一处可以如实陈述的差异：§4 开篇的立场是每条规则都配一条按语境的 override 路径，同一节里的无衬线字体建议、LILA RULE、ANTI-CENTER BIAS、PREMIUM-CONSUMER PALETTE BAN 也确实各自写了 Override 分支；而 EYEBROW RESTRAINT 这一条底下列的是总量、间隔、检查方式和替代做法四项，没有单列 override 分支。两处写法不同，以仓库当前内容为准。
九、一句话收尾
这条规则值得单拎出来讲，不是因为 eyebrow 有多重要，而是因为它示范了一种把审美偏好写成可核查约束的方式：给定义、给 CSS 特征、给公式、给检查动作、给替代方案。至于它在你的页面上会不会真的生效，那取决于你把它放在流程的哪一环——放在提示词里是一个概率，放进自己的检查里才是一道闸。
本文依据 taste-skill 官方仓库（github.com/Leonxlnx/taste-skill）的 README、CHANGELOG、
skills/ 下的 SKILL.md 与 .claude-plugin/ 清单整理，核对日 2026-08-09。
本文内容为仓库文档口径，我们没有安装或运行过其中任何一个 skill，
文中所有规则均为写给模型的提示词约束，不构成对输出结果的保证。
skill 内容随上游更新而变动，默认 skill 当前自标为 v2 (experimental) 且仍在迭代，请以仓库最新内容为准。