同一个仓库里，Fraunces 一边被封杀一边被推荐：taste-skill 的内部口径冲突
本文所有仓库信息核对日为 2026-08-09，以上游仓库最新内容为准。
如果你把 taste-skill 仓库里的几个 skill 一起装上，会遇到一个有点尴尬的情况：同一款字体，在一份 SKILL.md 里被点名封杀，在另一份 SKILL.md 里出现在推荐清单上。这不是谁看花了眼，是仓库当前状态里两处可核实的文本。这篇把差异逐处摆出来，然后说清楚：面对这种情况，你自己该怎么判断。
一、先把两处原文摆在一起
第一处在默认 skill。skills/taste-skill/SKILL.md（文件夹名 taste-skill，install name design-taste-frontend，1206 行，当前自标 v2 (experimental)）的 §4.1 里有一节 SERIF DISCIPLINE，这是 v2 版式规则里语气最重的一段。它明确点名封杀两款字体作为默认：Fraunces 和 Instrument_Serif，原文的说法是”LLM 最爱的那两款 display 衬线”。
第二处在 skills/stitch-skill/SKILL.md（install name stitch-design-taste，184 行）。它的第 3 步”确立排版规则”先封杀了一批通用衬线（Times New Roman、Georgia、Garamond、Palatino），紧接着给了一份正面清单：editorial / 创意语境确实需要衬线时，只用有辨识度的现代衬线——Fraunces、Gambarino、Editorial New 或 Instrument Serif。
同一个仓库、同一个 skills/ 目录，两份文件对同样两款字体给出了相反方向的指示。这是仓库当前状态里可核实的客观事实。至于哪一份”是对的”、为什么会这样，我们不推断，也不拿它去评价这个项目。
二、两边的限定条件确实不一样
摆完原文，有一层客观差别值得如实指出：v2 那条封杀的措辞是”作为默认”（as defaults），它同时给了衬线可被接受的条件；stitch 那条则是”当语境确实需要衬线时”的候选池。两句话各自带的前提不同，字面上不是一句对一句的正面撞击。
但这层区别对使用者的意义有限。这些文件的读者是模型，不是人。当一个 agent 把两份 SKILL.md 都读进上下文，它同时看到的就是”Fraunces 被点名封杀”和”Fraunces 在推荐名单里”两段文本，而这两份 SKILL.md 各自都没有写明遇到冲突时以哪一份为准。
说到这里就够了，再往下就是猜测。
三、Instrument Serif 还出现在第三个地方
同一款字体在这个仓库里的第三次露面，在 minimalist-skill（install name minimalist-ui，85 行）。它的 §3 排版架构给 hero 标题与引言指定的 editorial 衬线字体栈原文是：
font-family: 'Lyon Text', 'Newsreader', 'Playfair Display', 'Instrument Serif', serif;
也就是说，被 v2 点名封杀作默认的其中一款，出现在另一个 skill 为 hero 标题指定的字体栈里。
顺带一提，brutalist-skill（install name industrial-brutalist-ui，92 行，skills/llms.txt 那行标了 Beta）的 §3.3 把高对比衬线（Playfair Display、EB Garamond、Times New Roman）定位成”艺术性打断”，要求极其克制地使用，并且必须经过半调滤镜、1-bit 抖动这类重度后处理；而 stitch 那份把 Times New Roman、Garamond 直接放进了封杀清单。这两处的适用语境不同（一个是”极克制且重度后处理”，一个是”封杀”），字体名也不完全相同（EB Garamond 与 Garamond 字面不是同一个名字），是否该算同一款，我们不做判断。
四、Inter 的情况更热闹
衬线只是一处，字体这条线上口径最分散的其实是 Inter。把仓库里提到它的地方并排放，是这样：
| 文件夹 | install name | 对 Inter 的原文口径 |
|---|---|---|
taste-skill（v2） | design-taste-frontend | 不建议作为默认，但给了 override 路径 |
gpt-tasteskill | gpt-taste | 排版栈里写死 NEVER Inter |
soft-skill | high-end-visual-design | 列进 “ABSOLUTE ZERO” 的被禁字体 |
minimalist-skill | minimalist-ui | §2 绝对负面约束：不用 Inter、Roboto、Open Sans |
stitch-skill | stitch-design-taste | 高级 / 创意语境下被封杀 |
brutalist-skill | industrial-brutalist-ui | §3.1 宏观排版最佳字体里列了 Inter (Extra Bold/Black) |
这张表是本篇为这一个问题临时拼的，不是仓库里现成的表。它值得看的只有最后两行的对照：五份文件按不同强度把 Inter 排除，brutalist-skill 把它列进推荐。
还有一处在 v2 文件内部：§4.1 说 Inter 不建议作默认，同一节里的无衬线 display 池子列了 Inter Display，已知搭配那行写的是 Cabinet Grotesk + Inter Tight。这三个名字字面不同，是否算同一款字体家族，我们同样不判断，只如实指出它们同处一节。
五、这些规则的性质，决定了差异会怎么表现
这一节是本篇真正想让你带走的东西。
taste-skill 的 SKILL.md 是写给模型看的提示词约束，不是 lint 规则、不是 CI 检查、不是构建期的类型系统。“禁止把 Fraunces 作默认”是一条指令，不是”装了这个 skill 之后你的代码里就不会出现 Fraunces”的结果。这一点在这篇里格外要紧：既然规则只是文本，它们彼此之间是否一致，就不会像代码那样有 lint 或 CI 去校验，冲突时听谁的也不由任何一层工程逻辑决定。哪一条真的影响到输出，取决于你装了哪几个 skill、这次对话把哪一段读进了上下文。
所以正确的期待不是”装上就不会用错字体”，而是”我知道这堆文本里有相反的两句，我自己得有个判断”。
六、落到你的场景：该按哪条走
v2 §4.1 那节其实已经把判断依据给全了，它不是简单地说”别用衬线”，而是给了两条可接受条件——满足其一，衬线就是合理选择：
- 品牌需求文档里字面点名了某款衬线字体；
- 审美家族确实属于 editorial / luxury / publication / manuscript / heritage / vintage，并且你能说清为什么是这款衬线配这个品牌。
反过来，v2 明写的是：创意 agency、设计工作室、现代品牌、premium consumer、作品集、生活方式这些场景，默认走无衬线 display；“感觉有创意、高级、编辑感”不构成用衬线的理由，原文说这套”创意需求 = 衬线”的心智模型是生产测试里被测得最多的一个 AI tell。
拿这两条去看第一节那处冲突，路径就清楚了：如果需求文档白纸黑字写了要 Fraunces，那走的是第 1 条，v2 自己的封杀是针对”默认反射”的，不是禁止任何情况下使用；如果你只是觉得这个项目”该有点编辑感”就伸手去拿它，那正是这条规则想拦的动作，此时 stitch 那份清单不构成理由。
v2 还给了一个衬线池子，供确有理由用衬线时轮换，并要求不许连续两个项目复用同一款——PP Editorial New、GT Sectra Display、Reckless Neue 都在里面。这里只举三款，是因为它们和被点名的那两款处在同一个位置：都是 display 衬线，池子存在的意义就是给”默认反射”提供替代。完整池子有二十来款，我们另有一篇专门列。
Inter 那条同理，v2 给的 override 是：用户明确要中性 / 标准 / Linear 风格，或者需求是公共部门、无障碍优先的站点。落在这两种情况里，Inter 是可接受的；不在这两种情况里而顺手用它，才是这条规则针对的对象。
七、不是处处不同：一处对齐，另一处不对齐
也别把这个仓库想成一盘散沙。stitch-skill 第 1 步定义氛围时给的默认基线是 Variance 8、Motion 6、Density 4，与 taste-skill v2 的三个旋钮基线一致——这是两份文件明确对齐的地方。
但同一份 stitch 文件的第 8 步”编码动效哲学”又写着：每个活跃组件都应该有一个无限循环态（Pulse、Typewriter、Float、Shimmer）。而 taste-skill v2 的 §5 原文写的是 “Not every card needs an infinite loop”，并要求信息型区块就让它静着。这是本仓库里第二处方向相反的表述，处理方式和字体那处一样：陈述差异，不推断原因。
八、收尾
这篇没打算给这个仓库下结论。能确定的只有三件事：仓库里存在几处方向相反的规则文本；这些文本是提示词而不是工程保障，没有仲裁机制；而 v2 自己给出的 override 条件，已经足够你判断某条规则在你的场景里该不该照做。
看到两份文件打架时，别去猜作者的意图，回到”我这个项目属于哪一类”这个问题上——那才是这些规则原本想让你回答的。
本文依据 taste-skill 官方仓库（github.com/Leonxlnx/taste-skill）的 README、CHANGELOG、
skills/ 下的 SKILL.md 与 .claude-plugin/ 清单整理，核对日 2026-08-09。
本文内容为仓库文档口径，我们没有安装或运行过其中任何一个 skill，
文中所有规则均为写给模型的提示词约束，不构成对输出结果的保证。
skill 内容随上游更新而变动，默认 skill 当前自标为 v2 (experimental) 且仍在迭代，请以仓库最新内容为准。