8 / 6 / 4 三个旋钮：推断表、预设表与分档定义
本文所有仓库信息核对日为 2026-08-09，以上游仓库最新内容为准。
taste-skill 默认那份 skill 有 1206 行，但真正被人反复引用的只有三行 —— 三个全大写的变量，基线值 8 / 6 / 4。麻烦的是，大多数人只看见这三个数字，没看见后面那两张表和一段分档定义。不看那些，你既不知道什么时候该改这三个数，也不知道改一分到底改了什么。
一、三行配置，外加一条容易漏掉的使用说明
这三行出自 skills/taste-skill/SKILL.md（文件夹 taste-skill，install name design-taste-frontend，1206 行）的 §1。按 README 的口径，这份默认 skill 当前自标 v2 (experimental)，是对原始 v1 的一次重写；仓库里另有一份 226 行的 taste-skill-v1（install name design-taste-frontend-v1）保留原始行为，下文说的都是 v2 这一份：
DESIGN_VARIANCE: 8 -- 1 = Perfect Symmetry, 10 = Artsy Chaos
MOTION_INTENSITY: 6 -- 1 = Static, 10 = Cinematic / Physics
VISUAL_DENSITY: 4 -- 1 = Art Gallery / Airy, 10 = Cockpit / Packed Data
基线就是 8 / 6 / 4，原文的说法是：除非设计读数（Design Read）覆盖它，否则用这一组。
紧跟着还有一句，很多人没读到：不要让用户去改这个文件，覆盖值通过对话进行。也就是说，正确的用法不是打开 SKILL.md 把 8 改成 5，而是在对话里说清你要的值。这一条决定了后面所有内容的落地方式 —— 两张表不是给你查完去改文件的，是给你在对话里报数用的。
再往上翻，这份 skill 开篇有两行引文，是理解整个 §1 的钥匙：
Landing pages, portfolios, and redesigns. Not dashboards, not data tables, not multi-step product UI.
Every rule below is contextual. None of it fires automatically. First read the brief, then pull only what fits.
第二行直译过来就是「下面每一条都是按语境启用的，没有一条自动生效」。这句话是 skill 自己写的，不是我们的评价。所以 8 / 6 / 4 的准确身份是默认值，不是推荐值，更不是「照做就对了」。
二、旋钮不是连续滑条，是三段档
§7 给了这三个变量的技术定义，而且明确按 1-3 / 4-7 / 8-10 分成三段。这一节比两张表更重要，因为它把抽象数字翻译成了具体技法。
DESIGN_VARIANCE
- 1-3 Predictable：对称 CSS Grid（12 列等 fr）、等 padding、居中对齐
- 4-7 Offset：
margin-top: -2rem造重叠、混用图片比例（4:3 挨着 16:9）、左对齐标题压住居中的数据 - 8-10 Asymmetric：masonry、分数单位网格（
grid-template-columns: 2fr 1fr 1fr）、大片空域（padding-left: 20vw）
MOTION_INTENSITY
- 1-3 Static：不做自动动画，只有 CSS
:hover/:active - 4-7 Fluid CSS：
transition: all 0.3s cubic-bezier(0.16, 1, 0.3, 1)、animation-delay级联，只碰transform与opacity - 8-10 Advanced Choreography：复杂滚动触发、视差、滚动驱动动画（CSS
animation-timeline或 GSAP ScrollTrigger）。这一档原文强调 NEVER usewindow.addEventListener('scroll')，措辞是硬禁令而不是「最好别用」
VISUAL_DENSITY
- 1-3 Art Gallery：大量留白，段落间距
py-32到py-48 - 4-7 Daily App：标准 web app 间距
py-16到py-24 - 8-10 Cockpit：紧凑 padding、不用卡片盒、1px 线分隔数据，并强制所有数字用
font-mono
把基线代进去看：DESIGN_VARIANCE: 8 正好踩在 Asymmetric 档的第一格，MOTION_INTENSITY: 6 在 Fluid CSS 档的中上部，VISUAL_DENSITY: 4 在 Daily App 档的第一格。基线是「布局偏激进、动效偏克制、间距按常规 web app 走」这么一个组合。
三、推断表：先有设计读数，才有数值
§1.A 是从设计读数反推数值的表。它的输入不是你的偏好，而是 §0 那六个信号（页面类型、vibe 词、参考物、受众、既有品牌资产、隐性约束）先归纳出的一行 Design Read。
| 信号 | VARIANCE | MOTION | DENSITY |
|---|---|---|---|
| minimalist / clean / calm / editorial / Linear-style | 5-6 | 3-4 | 2-3 |
| premium consumer / Apple-y / luxury / brand | 7-8 | 5-7 | 3-4 |
| playful / wild / Dribbble / Awwwards / experimental / agency | 9-10 | 8-10 | 3-4 |
| landing page / portfolio / marketing site（默认） | 7-9 | 6-8 | 3-5 |
| trust-first / public-sector / regulated / accessibility-critical | 3-4 | 2-3 | 4-5 |
| redesign - preserve | 沿用现状 | +1 | 沿用现状 |
| redesign - overhaul | +2 | +2 | 沿用现状 |
读这张表有三个要点。
第一，最后两行是相对量。 redesign 那两行给的不是绝对值，是「在现状基础上加多少」。所以做改版时，你得先有一个对现状的读数，否则这两行没法用。
第二，最下面那一行约束优先级最高。 §0 把无障碍优先受众、公共部门、受监管行业、信任优先电商、儿童产品列为 quiet constraints，原文的表述是这些约束凌驾于审美偏好之上；§0 里另有一句更直白的：受众决定审美，不是你的品味决定。这两句合起来就是这张表的仲裁规则 —— 当「客户说要 Awwwards 那种感觉」和「这是个受监管行业的站」撞车时，按 skill 自己的口径，该赢的是后者那一行的 3-4 / 2-3 / 4-5。
第三，区间意味着还有一步没定。 表里给的多是 5-6、7-9 这样的范围，最终落哪个数，skill 没有再给公式。真要一个确定值，要么用下面的预设表，要么在对话里自己定。
四、预设表：可以直接抄，但先看它和基线对不上的地方
§1.B 是按用例给的一套确定值，省掉了区间那一步。
| 用例 | VARIANCE | MOTION | DENSITY |
|---|---|---|---|
| Landing (SaaS, mainstream) | 7 | 6 | 4 |
| Landing (Agency / creative) | 9 | 8 | 3 |
| Landing (Premium consumer) | 7 | 6 | 3 |
| Portfolio (Designer / studio) | 8 | 7 | 3 |
| Portfolio (Developer) | 6 | 5 | 4 |
| Editorial / Blog | 6 | 4 | 3 |
| Public-sector service | 3 | 2 | 5 |
| Redesign - preserve | match | match+1 | match |
| Redesign - overhaul | +2 | +2 | match |
有两处值得先说清楚，免得你查表时来回怀疑自己看错了。
一是 Landing (SaaS, mainstream) 给的是 7 / 6 / 4，而 §1 的基线写的是 8 / 6 / 4，VARIANCE 这一位两处不同。二是 Portfolio (Developer) 的 VARIANCE 是 6，而推断表里「landing page / portfolio / marketing site（默认）」那一行给的区间是 7-9，6 不在这个区间里。这两处就是仓库里的写法差异，我们只陈述，以仓库当前状态为准，不推断哪个是对的。
其余各行是能对上的：Agency 那行 9 / 8 / 3 落在 playful 行的 9-10 / 8-10 / 3-4 里，Premium consumer 那行 7 / 6 / 3 落在对应区间里，Public-sector service 的 3 / 2 / 5 也踩在 trust-first 行的边界上。
五、真正的分界不在数字，在档位
这是我认为这三张表里最有用的一条判断依据：加减一分有时候什么也没变，有时候换了整套实现手法。
因为 §7 是按 1-3 / 4-7 / 8-10 分档的，所以：
- VARIANCE 从 7 到 8，跨过了 Offset → Asymmetric 的边界，技法从「负 margin 重叠、混比例」换成「masonry、分数单位网格、20vw 空域」。前面说的基线 8 与预设表 7 那一处差异，恰好就压在这条线上。
- MOTION 从 6 到 8，跨过了 Fluid CSS → Advanced Choreography，从「transition 加 animation-delay 级联」进入滚动驱动动画的领域，同时激活那条
window.addEventListener('scroll')的硬禁令。 - DENSITY 从 4 到 3，跨过了 Daily App → Art Gallery，段距从
py-16–py-24变成py-32–py-48。预设表里 DENSITY 实际只出现 3、4、5 三个值，而 3 和 4 恰好分属两档，两档给出的间距区间没有重叠。
反过来，VARIANCE 从 8 调到 9、MOTION 从 8 调到 9，在 §7 的定义里属于同一档内部移动，skill 并没有给出更细的区分。
所以在对话里跟模型掰扯「到底是 7 还是 8」，多数时候是在问错问题。真正该问的是：**这个页面要不要非对称栅格？要不要滚动驱动动画？**决定了档，数字自然就有了。
六、移动端会把高档 VARIANCE 抹平
§7 在 DESIGN_VARIANCE 下面挂了一条 MOBILE OVERRIDE：4-10 档的非对称布局，在 < 768px 必须塌成严格单列（w-full、px-4、py-8）。
这条的实际含义是，VARIANCE 8 和 VARIANCE 5 的差别主要活在桌面宽度上，窄屏那一侧按这条规则是要收敛到同一种形态的。如果你的项目流量以移动端为主，把精力花在 VARIANCE 该定 7 还是 9 上，性价比就不高了；MOTION 和 DENSITY 反倒更值得先定。
七、顺带记一处并存的写法
VISUAL_DENSITY 的 8-10 档写的是 Cockpit / Packed Data，配套规则是紧凑 padding、1px 线分隔、数字强制 font-mono；而这份 skill 开篇的适用范围那一行写的是「不做 dashboards、不做 data tables、不做多步产品 UI」。一个是高密度仪表盘式的档位定义，一个是把仪表盘排除在外的适用范围，两种写法在同一份文件里并存。我们只记录这个差异，以仓库当前状态为准。
八、名字不许换，这条对使用者也有用
§1.C 规定：这三个是全局变量名，全文交叉引用只用这三个确切名字，并明禁自造别名，原文点名的反例是 LAYOUT_VARIANCE、ANIM_LEVEL。
这条看起来是写给 skill 内部维护用的，但对使用者同样有价值。既然覆盖值要通过对话进行，那么在对话里说「把 MOTION_INTENSITY 降到 3」，就比说「动效少一点」多两样东西：一是它能对上 §7 里 1-3 档那条明确的技术定义（无自动动画，只留 :hover / :active），二是它可复述、可回查 —— 下次同事接手，你说得出当初定的是哪个数。
九、最后，这三个数字的性质
实读这个仓库的顶层目录，里面没有 src/、没有 npm 包、没有构建产物，scripts/ 下那 4 个 .mjs 处理的是 README 的图片资源，与 skill 功能无关 —— 它就是一个纯 Markdown 规则仓库，核心资产是 skills/*/SKILL.md。所以 §1 和 §7 里的每一条 —— 包括那个全大写的 NEVER —— 都是写给模型看的提示词约束，不是 lint 规则，不是 CI 检查，也不是类型系统。写着 MOTION_INTENSITY: 6，不等于产出的代码里就不会出现滚动监听；写着 MOBILE OVERRIDE，也不等于窄屏一定会塌成单列。skill 自己开篇就说了 “None of it fires automatically”。
所以这三个旋钮真正的用途，是把「我要什么感觉」这种没法验收的描述，换成一组能报数、能复述、能对着 §7 分档去检查产物的参数。它提高的是沟通精度，不是交付确定性。要确定性，还得靠你自己那一侧的检查手段。
至于什么时候整套不该照做：命中 quiet constraints 时，按 skill 自己的口径应该直接走 trust-first 那一行，别拿基线去凑；而当需求本来就该用某个官方设计系统时，旋钮也不是主战场 —— 那部分我们另有一篇专门讲。
本文依据 taste-skill 官方仓库（github.com/Leonxlnx/taste-skill）的 README、CHANGELOG、
skills/ 下的 SKILL.md 与 .claude-plugin/ 清单整理，核对日 2026-08-09。
本文内容为仓库文档口径，我们没有安装或运行过其中任何一个 skill，
文中所有规则均为写给模型的提示词约束，不构成对输出结果的保证。
skill 内容随上游更新而变动，默认 skill 当前自标为 v2 (experimental) 且仍在迭代，请以仓库最新内容为准。