写码之前先说一句「Reading this as…」：§0 的六个信号

2026-08-09

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

taste-skill 默认那份 skill（文件夹 taste-skill，install name design-taste-frontend，我们实读 1206 行）里，第 0 节干的事非常反直觉：它不让模型先写代码，也不让模型先选字体，而是要求先输出一句话——「Reading this as: ……」。这句话是全篇后续所有规则的开关。

一、§0 为什么存在

skills/taste-skill/SKILL.md 在 §0 里给出的立论，大意是：大多数 LLM 的设计输出之所以差，不是因为模型不会写 CSS，而是因为它直接跳到了一个默认审美，没有先读懂需求。

这个立论和这份 skill 开篇的两行引文是配套的。原文第一行划定了适用范围：

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.

「没有一条自动生效」——这句话是钥匙。它意味着后面那上千行规则不是一份必须逐条执行的清单，而是一个按语境取用的池子。而决定从池子里取哪些的，就是 §0 的设计读数。读数错了，后面取的规则全都是错的；读数对了，很多规则根本不该触发。

二、六个信号，各自在判断什么

§0.A 列了六个要先读的信号。逐个说一下它们各自解决什么问题、你自己下判断时该怎么用。

1. Page kind（页面类型）。原文给的分类是 landing（细分为 SaaS / consumer / agency / event）、portfolio（细分为 dev / designer / creative studio）、redesign（细分为 preserve 还是 overhaul）、editorial / blog。这一项的价值在于它的细分粒度：同样是 landing，SaaS 和 agency 的合理输出完全是两个东西；同样是 redesign，“preserve”（保留现状）和 “overhaul”（推倒重来）是两条完全相反的路。你在描述需求时如果只说「做个落地页」，等于把这一层细分全留给模型去猜。

2. Vibe words（调性词）。原文列举了用户可能用到的词：minimalist、calm、Linear-style、Awwwards、brutalist、premium consumer、Apple-y、playful、serious B2B、editorial、agency-y、glassy、dark tech。这份词表本身就是一个提示——它告诉你，这套规则是靠这类词被激活的。你说「做得好看点」，命中不了任何一条；你说「Linear-style」，才有明确的下游动作。

3. Reference signals（参照信号）。指用户贴的 URL、截图、点名的产品、正在对标的品牌。这一项和第 2 项的差别在于精确度：调性词是一个方向，参照物是一个坐标。

4. Audience（受众）。原文举的三种受众很有意思：B2B 采购评审组、有设计品味的消费者、扫简历的招聘方。而这一条下面跟着一句原文态度很硬的话——受众决定审美，不是你的品味决定。这句话是写给模型的，但对人同样成立：一个给采购评审组看的页面做成 Awwwards 风，问题不在审美，在于对象错了。

5. 已存在的品牌资产。logo、色彩、字体、摄影。原文特意强调，对 redesign 而言这些是起点素材，不是可选输入。这是一条容易被忽略的约束——很多人做重设计时会把已有品牌资产当成「可以参考一下的东西」，而这里把它定成了地基。

6. Quiet constraints（安静的约束）。原文列的是：无障碍优先的受众、公共部门、受监管行业、信任优先的电商、儿童产品。叫「安静」，因为这些约束通常不会被写在需求里，但一旦存在就凌驾于审美偏好之上（原文原话就是这个意思）。

这六条里，第 4 和第 6 是优先级最高、也最容易被跳过的两条。前四条基本能从对话里直接读到，第 5 条看素材有没有，唯独第 6 条常常没人提——没人会在需求单上写「我们是受监管行业」。如果你是需求方，这一条值得主动说；如果你是执行方，这一条值得主动问。

三、那一行 Design Read 长什么样

§0.B 的要求是：出码之前必须先输出一行 “Design Read”，格式是固定的：

“Reading this as: <page kind> for <audience>, with a <vibe> language, leaning toward <design system or aesthetic family>.”

skill 里给了三个示例，照抄如下：

“Reading this as: B2B SaaS landing for technical buyers, with a Linear-style minimalist language, leaning toward Tailwind utilities + Geist + restrained motion.”
“Reading this as: solo designer portfolio for hiring managers, with an editorial / kinetic-type language, leaning toward native CSS + scroll-driven animation + custom typography.”
“Reading this as: redesign of a public-sector service site, with a trust-first language, leaning toward GOV.UK Frontend or USWDS.”

对照句式看会更清楚：这一行里有四个槽位，前三个直接对应六个信号里的三项——page kind、audience、vibe；第四个槽位（design system or aesthetic family）不是信号本身，而是从前面几项推出来的落地方向。剩下三项信号（参照信号、品牌资产、安静的约束）不单独占槽位，但会影响最后那个槽位填什么。

这一行的真正用处，是把「猜」变成「可反驳」。 模型如果先声明「我把它读作面向技术采购方的 B2B SaaS 落地页」，你一眼就能看出读错了，一句话就能纠回来；它要是闷头把整个页面写完你才发现方向不对，返工成本完全不是一个量级。所以哪怕你不用这份 skill，把这个动作抄进自己的提示词里也是划算的——要求模型先声明它的理解，再开工。

四、需求含糊的时候，只许问一个问题

§0.C 是这一节里最反直觉的一条：需求含糊时，只问一个问题，不要猜。原文明确要求问恰好一个澄清问题，绝不一次甩一串问题，而且只在设计读数真的会分叉时才问。给的示例问句是：

“Should this feel closer to Linear-clean or Awwwards-experimental?”

同时还有另一半约束：能从上下文自信推断出来时，不要问，直接声明设计读数然后继续。

这条规则的判断依据其实很清楚。用过 AI 写前端的人都被那种「先给我一份十问需求问卷」的开场折磨过，那种问法把成本全推给了用户，而且大多数问题的答案对最终输出没有区分度。这里的取舍是：只问那个会让设计读数分叉的问题。你注意看那个示例问句的形式——它不是开放题，是一道二选一，而且两个选项分别指向调性词表里的两个极端。这种问法回答成本极低，信息量却足够定方向。

反过来，什么时候不该照做？如果你的场景是长期协作、需求方就在旁边、返工成本很低，那多问几个问题并不亏。这条规则真正针对的是「一次性对话里要出结果」的场景。

五、§0.D 点名的六个「LLM 默认反射」

§0.D 叫 Anti-Default Discipline，明列了六个不许当默认反射的东西，原文把它们称作 “the LLM defaults”：

AI 紫渐变
深色 mesh 背景上的居中 hero
三个等宽的功能卡
到处糊玻璃拟态
到处用无限循环的微动画
Inter + slate-900

这份清单值得单独拿出来看，因为它其实是一份症状表。这六样东西没有一样是「错的」——紫渐变本身不难看，Inter 是一款好字体，等宽三卡片是成熟布局。它们被点名，是因为它们是在没读需求的情况下会自动冒出来的东西。也就是说，§0.D 封杀的不是这些元素，而是「不经判断就用它们」这个行为本身。

这一点对你有个直接用途：下次看到 AI 生成的页面，可以拿这六条当自查表。如果一个页面同时命中三条以上，通常说明模型走的是默认反射路径，而不是从你的需求推出来的。

顺带一提，Inter + slate-900 在这里是作为「一个成对出现的默认组合」被点名的，被封的是这个组合的自动触发，不是这款字体本身。字体相关的规则在这份 skill 的后面另有段落（例如 §3.A 规定字体一律走 next/font 或自托管 @font-face + font-display: swap，生产环境绝不用 <link> 引 Google Fonts），我们另有一篇专门写字体那一块，这里不铺开。

六、设计读数怎么落到后面的数值上

§0 之后紧接着是 §1 的三个旋钮：DESIGN_VARIANCE、MOTION_INTENSITY、VISUAL_DENSITY，基线是 8 / 6 / 4（原文：除非设计读数覆盖，否则用这组）。

这三个旋钮的完整档位定义和用例预设表我们另有一篇专讲，这里只引与 §0 直接相关的两行——因为它们正好演示了「信号如何变成数值」：

设计读数里的信号	VARIANCE	MOTION	DENSITY
minimalist / clean / calm / editorial / Linear-style	5-6	3-4	2-3
trust-first / public-sector / regulated / accessibility-critical	3-4	2-3	4-5

第一行对应的是第 2 个信号（调性词），第二行对应的是第 6 个信号（安静的约束）。把它们和基线 8/6/4 对比着看：一句 “minimalist” 就能把 VARIANCE 从 8 压到 5-6、MOTION 从 6 压到 3-4；而一旦命中「受监管 / 无障碍关键」，压得更狠，VARIANCE 掉到 3-4，同时 DENSITY 反而从 4 升到 4-5。

这就是 §0 那句「先读懂需求」的实际重量：它不是一句方法论口号，它直接改变了后面所有布局与动效规则的档位。也正因如此，读数错一次，后面上千行规则会整体走偏，而不是只错一个细节。

另外 §1.C 有一条容易被忽略的约束：这三个是全局变量名，全文交叉引用只用这三个确切名字，原文明禁自造别名（如 LAYOUT_VARIANCE、ANIM_LEVEL）。你如果要在自己的提示词里复用这套机制，名字别改——一改，skill 后面所有引用这三个名字的段落就对不上了。

七、必须说清的一件事：这些是提示词，不是工程保障

这一节不能省。

skills/taste-skill/SKILL.md 是一份 Markdown，仓库里没有任何东西会去执行它。§0 要求的「先输出一行 Design Read」是一条写给模型看的指令，不是一个会拦在你构建流程前面的检查。模型可能照做，也可能跳过直接开写；就像 §0.D 里那六条禁令是「告诉模型不要这么干」，而不是「装了之后你的页面里就不会出现紫渐变」。

指令和结果之间隔着一个「模型听不听话」的问题，这个问题这份文档解决不了，我们也没有任何数据能说它有多大概率被遵守——本文全部内容来自仓库文档与源码，我们没有安装或运行过其中任何一个 skill。

所以正确的用法是：把 §0 当成一个结构化的需求澄清流程来读。它的价值不在「装上就生效」，而在于它把「一个有经验的设计师接活时会先问什么」这件事写成了六条可以照着走的检查项。这六条你自己走一遍，价值和让模型走一遍是一样的；甚至更可靠，因为你走的时候不存在听不听话的问题。

另外提醒一句版本口径：默认这份 skill 自标为 v2 (experimental)，README 原文说 “It is still iterating”。§0 的具体条目随上游更新可能变动，看到和本文对不上时，以仓库当前内容为准。

八、能带走的三句话

第一，开工前先声明理解。不管用不用这份 skill，让模型（或者你自己）先写一行「我把这个需求读作 X，面向 Y，调性 Z」，是成本最低的纠偏点。

第二，六个信号里，受众和安静的约束最容易漏。前者决定审美方向对不对人，后者会直接把整套档位往下压。

第三，规则是写给模型的，不是给你的构建链的。要确定性，得在自己的流程里加校验；这份文档能做的只是调整倾向。

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