默认 skill 变成了 v2 (experimental)：怎么升、怎么钉回 v1
本文所有仓库信息核对日为 2026-08-09，以上游仓库最新内容为准。
如果你几个月前装过 taste-skill，现在重跑同一条安装命令，装进来的已经不是当初那份 SKILL.md 了。README 和 CHANGELOG 都说得很明白：默认的 taste-skill（install name design-taste-frontend）现在是 v2 (experimental)，是对原始 v1 的一次 substantial rewrite。CHANGELOG 里紧跟着还有一句原文：This is a pre-release。
所以升不升、什么时候升、要不要钉回去，是个需要自己拿主意的事。下面把口径先摆清楚。
一、先把三组名字分开
这个仓库最容易把人绕晕的地方，是「文件夹名 / install name / 版本号」三样东西同时在动。
- 文件夹：
skills/taste-skill/放的是 v2 的内容，skills/taste-skill-v1/放的是原始 v1。 - install name（SKILL.md frontmatter 里的
name:字段）：前者是design-taste-frontend，后者是design-taste-frontend-v1。装的时候--skill后面填的是 install name，不是文件夹名。 - 插件包版本号：
.claude-plugin/plugin.json里version是1.0.0，marketplace.json里也是1.0.0。
注意最后这条。plugin.json 的 1.0.0 和 README 说的 v2 不是同一个东西：一个是插件包的版本号，一个是 skill 内容的版本代号。两处写法不一致是可核实的客观事实，看到它们对不上不用怀疑自己装错了；具体哪个该动、为什么没同步，我们不推断。
搞清这三组名字之后，升级和回滚就都只是「填哪个 install name」的问题。
二、升级：什么都不用改，重跑就行
README 给的升级路径是最省事的那种：已装 v1 的人，重跑同一条 install 命令即可。
npx skills add https://github.com/Leonxlnx/taste-skill
原文强调的一点是 install name 没变，所以你的脚本、CI 步骤、团队文档里那条命令都不用改，新的 SKILL.md 就地替换旧的。
这句话反过来读，才是真正需要留意的地方：install name 没变，意味着你不改任何东西也会被升上去。如果你的仓库里有一条无人值守的 npx skills add（比如放在初始化脚本或者新人环境搭建文档里），那么在你不知情的情况下，agent 读到的规则集已经从 226 行换成了 1206 行。这不是坏事，但它是一次行为面变更，值得在团队里说一声。
只想装单个 skill 时，写法是：
npx skills add https://github.com/Leonxlnx/taste-skill --skill "design-taste-frontend"
三、钉回 v1：换一个 install name
README 给的回滚方式同样是一条命令：
npx skills add https://github.com/Leonxlnx/taste-skill --skill "design-taste-frontend-v1"
README 说这会装上「原封不动的原始 SKILL.md」。CHANGELOG 里对 v1 条目的描述是：原始发布，旋钮驱动哲学、anti-slop 规则、模式名参考词汇表，保留在 skills/taste-skill-v1/，可作 design-taste-frontend-v1 安装。README 给 v1 的定位也很直白：为依赖其确切行为的项目保留。
体量上的差距值得知道一下：我们实读文件行数，taste-skill-v1/SKILL.md 是 226 行，taste-skill/SKILL.md 是 1206 行。差了五倍多。这个数字本身不说明哪个更好用。要判断差在哪，得看 CHANGELOG 自己的措辞：v1 条目写的是旋钮驱动哲学、anti-slop 规则、模式名参考词汇表三项；v2 的定位是在保留旋钮哲学的基础上「增加了结构、硬规则和 agent 真能照做的具体实现模式」。也就是说，多出来的那一千行，按 CHANGELOG 的说法主要是结构与硬规则，不是换了一套审美词汇。
还有一条与版本无关的用法，README 里也提到了：你可以直接把任意一份 SKILL.md 复制进自己项目，或者整份粘进 ChatGPT / Codex 的对话。如果你的诉求是「这份规则以后别再自己变」，把文件拷进自己仓库、纳入自己的版本控制，是最直接的做法。这属于常规工程习惯，不是该仓库文档给出的建议，写在这里供你自己判断。
四、v2 到底多了什么，才好判断该不该升
CHANGELOG 列了 v2 新增的七个章节：§0 Brief Inference（写码前先读懂现场，声明一行设计读数）、§2 Brief → Design System Map、§8 Dark Mode Protocol、§11 Redesign Protocol、§12 The Block Library (Contract)、§13 Out of Scope、§14 Final Pre-Flight Check。
其中对「升不升」这个决定最有用的是两条。
§13 Out of Scope。它明确列出了 taste-skill 不适用的场景：仪表盘、数据表格、多步表单、代码编辑器、原生移动端、实时协作 UI。如果你手上的项目正好是内部管理后台或者数据看板，这一节等于替你把结论写好了。CHANGELOG 把 §13 归在「v2 新增章节」那一组里，换句话说，钉在 v1 上的人拿不到这份边界声明，得自己判断这个 skill 该不该用在手上这个项目上。
技术栈主张的更新。CHANGELOG 写的是：Tailwind v4 为默认，v3 只在既有项目要求时用；动效库标准化到 Motion（导入路径 motion/react，Framer Motion 的更名），legacy framer-motion 包仍作别名可用；图标优先级是 Phosphor / HugeIcons / Radix / Tabler，Lucide 不建议，手绘 SVG 图标封杀。
这一条是升级前最该对照自己项目看的。你的项目要是钉在 Tailwind v3、图标库统一用 Lucide，那么升上 v2 之后，agent 拿到的规则会持续推着它往另一个方向走。这不是「不能用」，而是你得预期到会在评审里反复看到这类偏移，并决定是接受、还是在自己的 prompt 里显式覆盖。
其余几条 v2 新加的硬规则，选几条影响面大的说：
- em-dash 全面禁令（§9.G）。CHANGELOG 的措辞是 complete，覆盖范围包括标题、eyebrow、胶囊、正文、引言、署名、图注、按钮文字、alt 文本，要求用连字符或重构句子。CHANGELOG 自己给的理由是：这是 v2 之前测试中被违反最多的单一文体 Tell。
- 区块编号 eyebrow 彻底封杀，原文举的例子是
00 / INDEX、001 · Capabilities、06 · how it works这类。 - Hero Discipline：标题不超过 2 行，副文本不超过 20 词且不超过 4 行，CTA 不滚动就能看见。
- Navigation：桌面单行，高度不超过 80px。
- Section-Layout-Repetition Ban：8 个区块至少要有 4 种不同的布局家族。
- Bento Cell Count Rule：N 条内容就是恰好 N 个格子，中间和末尾都不许留空。
- 动效纪律：
window.addEventListener('scroll')、放在 React state 里的自定义滚动计算、触碰 React state 的requestAnimationFrame循环，这三种写法彻底封杀；MOTION_INTENSITY > 3时强制走 reduced motion（useReducedMotion()或@media (prefers-reduced-motion: reduce)）；还有一条叫 “Motion claimed, motion shown”，意思是声称MOTION_INTENSITY > 4的页面必须真的会动，否则就把旋钮降到 3、老老实实交一个静态页。
三个旋钮 DESIGN_VARIANCE、MOTION_INTENSITY、VISUAL_DENSITY 在 v2 里保留了，CHANGELOG 说的是「同样的精神，但扩充了预设矩阵与推断规则」；性能护栏也没变，仍然是只动 transform 和 opacity、不动画 top/left/width/height。所以升级不会让你重新学一套概念，变的是约束密度。
至于 §14 的那份交付前硬清单，条目相当多，我们另有一篇专门逐条拆，这里不铺开。
五、CHANGELOG 自己给的换默认理由
这一段值得原样转述，因为它是判断依据本身。CHANGELOG 说：v2 之前，原始 taste-skill 方向是对的，但很容易被 agent 一扫而过；生产测试显示同样的 Tell 在多次构建中反复出现，具体点名的有到处出现的 em-dash、区块编号 eyebrow、“Quietly in use at” 这类文案、装饰性圆点、用样式化 div 拼出来的假截图、坏掉的 GSAP 滚动触发器。v2 的做法是用硬规则、规范代码骨架和必须执行的 pre-flight 清单去堵这些缺口。
换句话说，v1 到 v2 的主要变化不是「审美变了」，而是从建议变成了检查项。你如果本来就觉得 v1 那版规则「agent 看了跟没看一样」，那 v2 想解决的正是你这个问题；你如果本来就对 v1 的输出满意，那 v2 多出来的那一千行主要是在收紧你没觉得有问题的地方。
六、v2 自己声明的稳定性边界
这部分不能省，它是「要不要现在升」的直接依据，而且全是仓库自述的原文口径：
- 默认 skill 明标 v2 (experimental)，CHANGELOG 原文写 This is a pre-release。
- 它成为新的默认安装，是因为项目方认为它确实比 v1 好，但仍在迭代。
- 任何 v2 实验版里都可能落地新的调整。
- API（install name、旋钮名、章节结构）将在 v2.0.0 stable 时才稳定。
- 破坏性改动（install name 重命名、章节移除）会被批量处理，并在 v2.0.0 stable 切版时明确说明。
仓库开头还给了一句自我描述：遵循 “SemVer-ish discipline”，实验性预发布自由迭代，稳定版锁定 API。
据此可以给出一个不算激进的判断路径：
- 你在拿它做一次性的新项目、落地页、demo：升，v2 想解决的重复感问题正是这类场景最痛的。
- 你有一条固化的产线，产出物要跨批次口径一致：钉 v1，或者把当前这份 SKILL.md 拷进自己仓库自己管。README 给 v1 的定位就是「为依赖其确切行为的项目保留」。
- 你的项目属于 §13 明确列出的 Out of Scope 类型：那要判断的不是升不升，而是这个 skill 该不该进你的工作流。
- 你的技术栈与 v2 的默认主张冲突（Tailwind v3、Lucide 图标）：先想清楚打算在哪一层覆盖，再决定升级时机。
七、一句必须说清的话：这些都是提示词
上面所有规则，无论是 em-dash 禁令还是导航高度不超过 80px，性质都是一样的——写在 Markdown 里、给模型读的提示词约束。这个仓库没有 src/，没有构建产物，没有运行时，不存在任何东西会在你的项目里执行这些条款。
所以「升到 v2」这个动作的真实含义是：换了一份更长、更具体的提示词。它可以提高 agent 照做的概率，不能保证结果。你不会因为装了 v2 就再也见不到 em-dash，正如你不会因为写了一份编码规范文档，代码库里就自动不出现违规。真正想要确定性的那几条，该做的是在自己的构建链或评审清单里加机械检查，让 skill 只承担前置的倾向调节。
这也是为什么本文没有出现「升级之后效果更好」这类说法——我们没有安装、也没有运行过其中任何一个 skill，能给你的只有仓库文档写了什么，以及这些文字在你的场景里意味着什么。
八、收尾
升级是重跑原命令，回滚是换一个 install name，这两件事的机械操作都很简单。难的是判断：v2 自标 pre-release 且仍在迭代，API 要到 v2.0.0 stable 才锁；它带来的不是新审美，而是一整套更硬的检查项和几条明确的技术栈主张。项目越是需要跨批次稳定的口径，越该考虑钉在 v1 或者干脆把文件拷进自己仓库；项目越是一次性的、越苦于「每次生成都长一个样」，v2 越对症。
本文依据 taste-skill 官方仓库（github.com/Leonxlnx/taste-skill）的 README、CHANGELOG、
skills/ 下的 SKILL.md 与 .claude-plugin/ 清单整理，核对日 2026-08-09。
本文内容为仓库文档口径，我们没有安装或运行过其中任何一个 skill，
文中所有规则均为写给模型的提示词约束，不构成对输出结果的保证。
skill 内容随上游更新而变动，默认 skill 当前自标为 v2 (experimental) 且仍在迭代，请以仓库最新内容为准。