taste-skill 前端设计 skill
src/、没有 npm 包、没有构建产物，
核心资产是 skills/ 下十三份 SKILL.md。
因此没有任何东西会在你的项目里执行这些规则——
「禁止使用 em-dash」是一条写给模型看的指令，不是「装了之后代码里就不会出现 em-dash」的结果，
中间隔着模型会不会听话。需要确定性保障的场景，该在自己的构建链里加检查。
另外，默认 skill 当前自标为 v2 (experimental)、仍在迭代，
brutalist-skill 标着 (Beta)。核对日 2026-08-09。
本专题共 25 篇。内容依据
官方仓库
的 README、CHANGELOG、skills/ 下的 SKILL.md 与 .claude-plugin/ 清单整理。
本专题内容为仓库文档口径，
我们没有安装或运行过其中任何一个 skill，
因此不涉及安装效果、生成画面质量与使用手感的任何描述。
许可条款请以官方 LICENSE 原文为准。
taste-skill 到底是什么：一个没有 src/ 的纯 Markdown 规则仓库
很多人以为 taste-skill 是个前端库或 npm 包，克隆下来才发现里面既没有 src/ 也没有构建产物，核心资产就是十三份 SKILL.md。这篇讲清它的仓库结构、安装方式、install name 与文件夹名的关系，以及最关键的一点：这些规则是写给模型看的提示词，不是会在你项目里自动生效的工程保障。
认识它、装对它
这个仓库没有 src/、没有 npm 包，核心资产是十三份 SKILL.md。这一组讲清它到底是什么、怎么装、为什么 --skill 后面填文件夹名会失败，以及默认 skill 从 v1 换成 v2 (experimental) 之后怎么升、怎么钉回去。
装不上是因为你用了文件夹名：taste-skill 十三个 skill 的 install name 对照
`--skill` 后面要填的是 SKILL.md frontmatter 里的 install name，不是 GitHub 上看到的文件夹名。taste-skill 十三个 skill 有十个两者对不上。本文给出完整对照表、为什么不能靠去后缀猜、填错时的自查动作，以及什么时候问题不出在名字上。
默认 skill 变成了 v2 (experimental)：怎么升、怎么钉回 v1
taste-skill 的默认 skill 已经换成了 v2，而 v2 在 CHANGELOG 里自标 pre-release。这篇讲清升级和回滚各自是哪一条命令、install name 与文件夹名在这件事上的对应关系、v2 相对 v1 具体多了哪些硬规则和技术栈主张，以及什么样的项目更该钉在 v1 上。
13 个 skill 怎么挑：出代码的和只出图的是两回事
taste-skill 的 skills/ 目录下有十三份 SKILL.md，README 把它们分成「出代码」和「只出参考图」两类，但列在同一张表里很容易被当成十三个平级选项。这篇按输出物、职责层级和适用处境给出挑选路径，并把叠加多个 skill 时会撞上的几处口径差异先摊开讲清楚。
v2 的骨架：先读懂需求，再动手
v2 最大的变化是在写码之前加了两道前置——先输出一行「设计读数」判断这是什么页面、给谁看，再用三个旋钮把方差、动效、密度定下来。这一组还讲需求命中官方设计系统时该装哪个包，以及玻璃拟态、Bento、Apple Liquid Glass 这类「没有官方包的审美」该怎么诚实实现。
写码之前先说一句「Reading this as…」：§0 的六个信号
taste-skill 默认 skill 的第 0 节要求模型动手写代码前先输出一行「Reading this as…」的设计读数，而这行话是从六个信号推出来的。本文拆开这六个信号各自在判断什么、需求含糊时为什么只允许问一个问题、被点名的六个「LLM 默认反射」是哪些，以及它们为什么只是提示词约束而非工程保障。
8 / 6 / 4 三个旋钮：推断表、预设表与分档定义
taste-skill 默认 skill 的核心配置只有三行，基线是 8/6/4。这篇把它的推断表、用例预设表和分档技术定义并排摆开，讲清这三个数字该怎么覆盖、哪一档的加减一分会真的改变实现手法、以及预设表与基线对不上的那两处差异。
需求像 Fluent 就装 Fluent：§2 的十二行映射表与诚实规则
taste-skill 默认 skill 的 §2 给了一张十二行的映射表，把「需求读起来像什么」直接映射到具体的官方设计系统包，并配了两条硬规则：命中就装官方包不许手抄 CSS，一个项目只用一套体系。这篇讲清这张表该怎么读、什么时候该照做、什么时候它压根不适用，以及它作为提示词约束的性质边界。
没有 liquid-glass.css：审美潮流与官方设计系统的分界
客户说想要 Apple 那种 Liquid Glass 质感，你去搜官方 CSS 包，搜不到。taste-skill 的 §2 把这类需求单独划了一张表：有官方包的照官方包装，没有官方包的老实承认是近似。这篇讲清这条分界线画在哪、八种常见审美各自落在哪一侧，以及怎么判断你的需求该走哪一边。
默认技术栈：Tailwind v4、`motion/react`、四个图标库与 RSC 隔离
taste-skill 默认 skill 的 §3 定了一套默认技术栈：Tailwind v4、从 `motion/react` 引入的 Motion、四个允许的图标库与 RSC 交互隔离。本文拆开每条默认的原文口径、生效前提与仓库给出的 Override 路径，并说清哪些能落成工程检查、哪些只是提示词。
硬规则：那些被点名封杀的默认反射
衬线字体、米色加黄铜的高端消费色板、每个区块都顶一个 eyebrow、8 个区块用同一种布局、拿 div 拼假截图——这些是 SKILL.md 里被逐条写死的模型默认反射。这一组逐个拆规则的判断依据和 override 路径，不是照抄条文。
★ 「创意需求就该用衬线」是被测最多的 AI tell
taste-skill v2 的 SERIF DISCIPLINE 是 §4 版式部分语气最重的一条规则，它封杀的不是衬线字体本身，而是模型「创意需求 = 衬线」这个默认反射。这篇拆开它的两道例外闸门、被点名的两款字体、同家族强调规则，以及唯一一条能机械核查的斜体下伸空间要求，帮你判断什么时候该照做、什么时候该走 override。
米色 + 黄铜 + 浓缩咖啡：被逐个 hex 点名封杀的高端消费色板
taste-skill 默认 skill 的颜色一节里有一条很反常的规则，它不讲原则，直接把十六个十六进制值列出来逐个封杀。这篇讲清这条规则管的是哪类需求、七套替代色板怎么轮换、Override 的两个口子分别要满足什么，以及最要紧的一点：这些 hex 写得再具体，也只是写给模型看的提示词，不会有任何东西去替你做匹配。
Hero 必须装进首屏：2 行标题、20 词副文本、4 个元素上限
taste-skill v2 的 §4.7 把 Hero 写成可数的硬规则——标题最多 2 行、副文本最多 20 词、文本元素不超过 4 个、顶部内边距最多 pt-24、导航最高 80px。这篇逐条拆这些数字卡的是什么、五类元素为什么被赶出首屏、哪些情况走 override，以及它们终究只是写给模型的提示词。
★ 每三个区块最多一个 eyebrow：一条能机械计数的规则
taste-skill v2 把「区块标题上方那行小号大写标签」的数量写成了一条带公式的硬规则：count ≤ ceil(sectionCount / 3)。这篇讲清 eyebrow 指什么、规则的三个分句各管什么、公式的分母该怎么数，以及它终究只是写给模型的提示词而不是校验器。
8 个区块至少 4 种布局：锯齿上限与 bento 格数精确规则
taste-skill 默认 skill 的 §4.7 Layout Discipline 里有几条能数出来的布局规则：一页 8 个区块至少要用 4 种布局家族、图文分栏最多连续 2 个、bento 格数恰好等于内容条数。本文给出原文口径，说清怎么数、跟哪些规则连动、什么场景不该套，以及它们为什么只是提示词不是校验。
落地页是视觉产品：图片优先级三档与被禁的 div 假截图
taste-skill v2 的 §4.8 给视觉资产排了一个三档优先级：有生成工具就必须生成、其次用真实图片、最后一档是明确告诉用户缺图，而不是拿 div 拼一个假仪表盘糊过去。这篇把三档的判定条件、logo 墙的 LOGO-ONLY 硬规则、手绘 SVG 的三种例外拆开讲，并说清它们在什么场景下该照做。
动效纪律与起飞前检查
em-dash 禁令为什么被写成零容忍的二元规则、两个 GSAP 规范骨架里 start 参数写错会毁掉什么、62 个复选框的 Pre-Flight Check 里哪些是机械可查的。
★ 零个 em-dash：为什么这条禁令被写成了二元规则
taste-skill 的默认 skill 里有一条完全不留余地的禁令：输出里出现一个 em-dash 就算没做完。这篇讲清这条规则的确切条文、它自己给出的立法理由（写成"少用"时模型会无视），它挂在 Pre-Flight 上的判定方式，以及这类二元表述什么时候值得抄进你自己的提示词、什么时候必须落到机械校验里。
`start: "top top"` 写错就毁了：两个 GSAP 规范骨架逐行读
taste-skill 的 §5 给了两段可以直接粘贴的 GSAP 代码，一段做滚动卡片堆，一段做横向平移。这篇把这两段骨架逐行拆开，讲清每个字段在骨架里的位置、原文标出的关键点、为什么大多数滚动动效其实不该用 GSAP，以及这些规则的真实性质：它们是写给模型的提示词，不是会在你项目里执行的检查。
62 个复选框的 Pre-Flight Check：哪些是机械可查的
taste-skill 默认 skill 的 §14 是一张 62 个复选框的交付前检查表，原文要求逐个跑完。但这 62 条并不在同一个层级上：有的只看产物文本就能判定，有的要先把区块数、内容条数建模出来才能计数，还有一批只能靠人读一遍。这篇把它们分成三档，说清每一档能自动化到什么程度、卡在哪里。
其余 skill：各管一件事
gpt-taste 让模型模拟一次 Python 随机来打破布局惯性、output-skill 专治交半成品、minimalist 与 brutalist 与 soft 三个视觉方向各有一套硬参数、redesign-skill 管既有项目的审计与修复优先级、三个 imagegen skill 只出图不写代码。
改版不是重写：redesign-skill 的审计清单与七步修复优先级
taste-skill 仓库里的 redesign-skill 是少见的一份写给「已经有代码的项目」的规则文件，178 行，明写不要从零重写。这篇拆开它的九类审计清单该怎么读、七步修复优先级为什么排成这个顺序、哪几条在你的项目里应该走 override，以及它和 taste-skill v2 §11 Redesign Protocol 的分工在哪。
模型老是交半成品：full-output-enforcement 的禁用模式清单
让模型写 5 个组件，它给 3 个再补一句「剩下的照这个模式来」。taste-skill 里有个 49 行的 output-skill 专治这件事。这篇拆开它的三类禁用模式、三步执行流程和 token 上限断点协议，并说清哪些条目你能变成自己流程里的机械检查，哪些只能靠人眼看。
让模型模拟一次 Python 随机：gpt-taste 的 `<design_plan>` 预检
taste-skill 里有个只有 74 行的 skill，要求模型写任何 UI 代码前先输出一个 <design_plan> 块，在里面「模拟执行」一段 Python 随机脚本来抽版式。这篇拆开五项预检各自在管什么、哪几项事后能人工核对、哪几项只能靠模型自述，以及它与仓库内其它 skill 的字体口径差在哪。
一个区块一张图：三个只出图不写代码的 skill 怎么分工
taste-skill 仓库里有三个 skill 明写「不写代码」，只产参考图。这篇按仓库文档口径讲清 imagegen-frontend-web、imagegen-frontend-mobile 和 brandkit 各自约束什么、章节结构差在哪，以及「一个区块一张图」这条硬输出规则会如何改变你和写代码那一步的交接方式。
minimalist / brutalist / soft：三种视觉方向的硬参数对照
taste-skill 里有三个体量接近（85 / 92 / 98 行）却方向完全相反的视觉 skill。这篇把它们在字体、配色 hex、圆角、阴影、动效时长和间距上的硬参数摆在一起对照，说清为什么它们不能混装，以及从你的页面类型倒推该挑哪一个。所有规则均为写给模型的提示词，不是自动生效的工程检查。
边界与诚信
同一个仓库里 Fraunces 一边被封杀一边被推荐，research/ 目录援引了一堆研究却没给出处链接。这一组只陈述可核实的差异，不推断原因，也不拿它去评价项目质量。
同一个仓库里，Fraunces 一边被封杀一边被推荐：taste-skill 的内部口径冲突
taste-skill 的默认 skill 把 Fraunces 和 Instrument_Serif 点名封杀作默认，同一个 skills/ 目录下的 stitch-skill 却把这两款列进推荐衬线清单。Inter 的情况更热闹，六份文件给了三种口径。这篇把能核实的差异逐处摆出来，说清这些规则的性质，以及你该按哪条判断自己的场景。
`research/` 目录讲了什么，以及为什么不能拿它当结论
taste-skill 仓库里有一个 research/ 目录，装着一整套关于「大模型为什么输出不完整」的分析，里面有实验编号、百分比和参数表，看起来很像论文综述。这篇先如实转述它写了什么，再说清三条不能拿它当结论的理由：出处清单没有出处、第三方 API 参数需要回官方核、以及原因分析推不出规则有效。
想让 AI 写出的前端不再一眼看出是 AI 写的？
从提示词工程到 Agent 工作流，站内有成体系的 AI 编程教程与课程。