8 个区块至少 4 种布局：锯齿上限与 bento 格数精确规则

2026-08-09

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

taste-skill 的规则里有大量「要有品味」式的软性表述，但 §4.7 Layout Discipline 是个例外：这一节里有好几条能直接数出来的规则——8 个区块的落地页至少 4 种布局家族、图文分栏最多连续 2 个、bento 格子数恰好等于内容条数。能数，就意味着你可以自己判断某个页面到底违没违反，而不是靠感觉吵架。

以下规则全部出自默认 skill（文件夹 taste-skill，install name design-taste-frontend）当前的 v2 版 SKILL.md 的 §4.7；仓库里另有保留原始行为的 v1（文件夹 taste-skill-v1，install name design-taste-frontend-v1），本文不涉及它的口径。§4.7 原文对自己的定位很硬：这一节是硬规则，违反任意一条就是交付了坏活。

一、四条可数的约束，先摆原文口径

规则	原文约束	判定动作
Section-Layout-Repetition Ban	一种布局家族在一页里最多出现一次；8 个区块的落地页至少要用 4 种不同的布局家族	数页面上用了几种家族
ZIGZAG ALTERNATION CAP（强制）	左图右文 / 左文右图交替的图文分栏，最多连续 2 个区块；第 3 个连续图文分栏算 Pre-Flight Fail	数连续段的长度
BENTO CELL COUNT RULE（强制）	bento 网格的格子数恰好等于你有的内容条数	看有没有空格子
Bento Background Diversity（强制）	任何多格网格里至少 2-3 个格子要有真实视觉变化	数有视觉的格子

另外 §4.7 还给了 bento 本身的节奏要求：不许堆 6 个「左图右文」行，要交替全宽功能行、非对称瓦片尺寸、纵向断点。

Pre-Flight 是这个 skill 的交付前检查清单，完整清单另有一篇专门讲，这里只用到「某某项算 Fail」这层含义。

二、什么算「一种布局家族」

原文举的例子是三列图卡、全宽引言、图文分栏，并且给了一句很具体的反例：Selected commissions 不能和 What we do 长得一样。

从这几个例子能读出判断依据：家族是按骨架分的，不是按内容主题分的。两个区块一个讲案例一个讲服务，内容毫不相干，但只要都是「左边一张图、右边一段文」，在这条规则眼里它们就是同一个家族，第二次出现就已经越线。

打断的手段原文也直接给了：全宽区块、纵向堆叠区块、bento 网格、跑马灯，或者其它布局家族。

有一处原文没有交代、我们也不替它补：布局家族计数时 hero 算不算一个区块。相邻的 eyebrow 规则里明写了「hero 算 1 个」，但那是数 eyebrow 的口径，不能直接搬到数布局家族上。

三、锯齿上限那条，和上一条并不严丝合缝

ZIGZAG ALTERNATION CAP 的原文措辞是：这种左右交替的锯齿布局等于平庸，图文分栏模式最多连续 2 个区块，第 3 个连续的算 Pre-Flight Fail。

注意这里的限定词是连续。而上一条 Section-Layout-Repetition Ban 说的是一种布局家族在一页里最多出现一次。把两条并排放，对「图文分栏」这同一个家族允许出现的次数，两条给的口径不一致：一条按总数限一次，一条按连续段限两个。以仓库当前状态为准，我们不推断哪条是后加的、也不猜作者的意图。

对实际使用的影响很直接：如果你要把这套规则变成团队里的成文标准，这一处得自己先拍板取哪个口径，不能指望照抄就自洽。取严的那条（一页只出现一次）显然不会同时违反另一条，这是你在两个口径之间做选择时唯一确定的事。

四、bento 格数：先有内容条数，再有网格

BENTO CELL COUNT RULE 是这一节里最容易验收的一条，原文连例子都排好了：

3 条内容 → 3 格（1+2、2+1 或非对称三元组）
5 条内容 → 5 格（2+3、3+2、hero+4 等）

中间或末尾出现空格子，原文的判定是「说明你规划错了」，处置是重塑网格，不许贴一块空瓦片。

这条规则真正扭转的是决策顺序。常见做法是先看着版面觉得四宫格好看，画完再想办法凑第四条内容，凑不出来就塞一块空白或者一句可有可无的话。这条规则把顺序倒过来：网格是内容条数的函数。所以它约束的其实不是 CSS，是你手上到底有几条值得单独占一格的信息。

紧接着的 Bento Background Diversity 又补了一刀：多格网格不能是 6 张白底白卡里塞文字，至少 2-3 个格子要有真实视觉变化——真图、贴合品牌的渐变（原文特意排除了 AI 紫）、图案、有色背景。原文的判断标准写得很不留情面：奶油底上再放奶油底、里面只有排版的 bento，即使页面其余部分不错，读起来仍是无聊的 AI 默认。

这一条的落地成本在图片供给上，得跟 §4.8 的视觉资产优先级一起看：环境里有图像生成工具就必须用它按区块生成资产；没有就用真实摄影来源，可接受的默认包括 https://picsum.photos/seed/{descriptive-seed}/{w}/{h} 这种带描述性 seed 的占位；两条路都走不通时，原文要求留下明确标注的占位槽并告诉用户「这里需要真图」，而不是用手绘装饰 SVG 或 <div> 假截图把格子填满。换句话说，你没有图，就凑不满 Bento Background Diversity，这时候正确的动作是把缺口说出来，不是拿假东西补。

五、这几条能不能 override

§4 开篇的立场是每条规则都有一条按语境的 override 路径，但要注意具体条目之间差别很大。同在 §4 里的 ANTI-CENTER BIAS 就写得很清楚：DESIGN_VARIANCE > 4 时避免居中 Hero 和 H1，而 editorial、manifesto、发布公告这类需求下，信息本身就是设计时，居中 hero 可以接受——override 的触发条件是白纸黑字写着的。

本篇这几条布局规则不一样：ZIGZAG ALTERNATION CAP、BENTO CELL COUNT RULE、Bento Background Diversity 在原文里都标成强制，并且没有给出对应的 override 描述。所以别自己给它们发明豁免条件，那不是原文的内容。

真正决定「这套规则该不该套在你身上」的，是 §13 OUT OF SCOPE。原文明确列了这个 skill 不适用的场景：仪表盘、高密度产品 UI、后台管理面板（指向 Fluent、Carbon、Atlassian 或 Polaris），数据表格（指向 TanStack Table 或 AG Grid），多步表单和向导，代码编辑器（指向 Monaco / CodeMirror 及其官方皮肤方案），原生移动端（指向 Apple HIG / Material），以及实时协作 UI。原文还要求：需求属于这几类时要明确说出来、指向正确的工具，只把营销页 / 关于页 / 落地页那部分规则应用到适用的界面上。

这才是判断依据的落点。你在做一个内部管理后台的列表页，「8 个区块至少 4 种布局」根本不该出现在评审意见里——不是你违反了它，是它本来就不管这块。

六、跟布局规则连着动的三处

一是内容密度。 §4.9 规定长列表超过 5 条就要换一个 UI 组件，而不是把列表拉更长，给的替代包括 2 列分组、图加标签的卡片网格、可分类时用 Tabs 或 accordion、横向 scroll-snap 胶囊、广度型内容用轮播或跑马灯。原文还有一句判断很硬的话：10 行规格 + 每行一条发丝线是最糟的默认。这条和布局多样性是同一个思路的两面——布局家族的多样性来自内容分组的多样性，内容不分组，布局只能重复。

二是密度旋钮对卡片的限制。 §4.4 写着 VISUAL_DENSITY > 7 时通用卡片容器被禁，数据指标要在朴素布局里呼吸。如果你打算靠「卡片网格」这个家族去打断连续的图文分栏，就得先看这条旋钮读数，否则打断锯齿的同时违反了另一条。

三是移动端。 §4.7 要求移动端塌陷必须逐区块显式声明：每个多列布局都要在同一个组件里写明 < 768px 的回退，不许假设「Tailwind 会处理的」。布局家族越多，需要显式声明的塌陷规则就越多——这是采纳「8 个区块 4 种布局」的真实代价，值得在排期时算进去。

顺带一提，同样以区块数为分母的还有 eyebrow 那条机械计数规则（count ≤ ceil(sectionCount / 3)），原文称它是生产测试中被违反次数第一的规则，我们另有一篇专门讲它。

七、最后说清这些规则的性质

这一点在每篇讲 taste-skill 规则的文章里都得重复一次：SKILL.md 是写给模型看的提示词，不是会在你项目里执行的工程保障。「bento 格数恰好等于内容条数」是一条指令，不是「装了之后就不会出现空瓦片」的结果。中间隔着模型会不会照做这一层。

有意思的是，原文自己就把 eyebrow 那条写成了机械计数的形式——数所有组件里 uppercase tracking 类标签的出现次数，超过阈值就判不合格。这说明这类规则天然是可核验的：布局家族数、连续锯齿段长度、bento 空格子，都是能在代码评审甚至脚本里判定的东西。至于要不要把它们变成自己构建链里的检查，那属于你自己的工程决策，不是这个仓库提供的能力，我们也没有安装或运行过其中任何一个 skill，不对任何一种做法的效果下结论。

把这一节当成一份可以逐条打勾的评审清单来用，而不是当成装上就会生效的开关，你对它的期待才是对的。

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