62 个复选框的 Pre-Flight Check：哪些是机械可查的

2026-08-09

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

taste-skill 默认 skill 的 SKILL.md 末尾有一节 §14 FINAL PRE-FLIGHT CHECK，原文的措辞非常硬：出码前跑这张矩阵，“THIS IS NOT OPTIONAL. Run every box. If any box fails, the output is not done.”。我们实读这份清单，数出 62 个复选框。问题是，这 62 条不是同一种东西 —— 有的写一条正则就能判死，有的必须先回答”这一页到底有几个区块”才能开始算，还有的只能靠人坐下来读一遍。搞清楚这个分层，比把 62 条背下来有用得多。

一、先把这张清单的性质说清楚

这一点必须放在最前面：§14 和 SKILL.md 里其余所有内容一样，是写给模型看的提示词约束，不是 lint 规则，不是 CI 任务，不是类型系统。它写着 “Run every box”，意思是让模型在输出前自己走一遍这个流程；它不会在你的项目里自动执行任何检查。清单末句原文是：若有任何一个复选框不能诚实打勾，页面就没做完，交付前先修好。「诚实打勾」这个措辞本身就说明了执行方式 —— 靠自觉。

所以这篇的出发点不是”背清单”，而是：这 62 条里，哪些可以从”靠自觉”挪到”靠机器”。挪得动的那部分，你可以自己接进构建链，从此不依赖模型的自觉；挪不动的那部分，就老老实实留给评审环节，别指望它自己不出错。

二、按”要不要人来判定”分三档

我们按需要多少外部信息，把这 62 个框分成三档：

档位	判定所需信息	自动化程度
A 档	只需要产物文本本身	一条模式匹配就能出结论
B 档	需要先建立页面结构模型（区块数、内容条数、布局家族）	能算，但口径要人先定
C 档	需要理解语义、意图，或需要跨项目的历史	目前只能人或模型判

下面每一档只挑与这个分层直接相关的几条来讲。em-dash 禁令的完整条文、eyebrow 上限的全部细则、完整的衬线池与被点名的全部十六进制家族，各有专门篇目在讲，这里只引与分层直接相关的那一两行。

三、A 档：只看产物文本就能判定

零 em-dash 是这一档的样板。 §9.G 把 em-dash（—）写成完全禁止：标题里禁、eyebrow / 标签 / 胶囊 / 按钮文字 / 图注 / 导航项里禁、正文里禁、引言署名里禁，作分隔符用的 en-dash（–）同样禁。页面上唯一允许的破折类字符是普通连字符 - 和数学减号（-5°C）。原文结尾写得很直接：输出里只要在用户可见处出现一个 — 或 –，就算未通过 Pre-Flight Check，必须重写。

这一条之所以值得单独拿出来，是因为它是全清单里判定逻辑最干净的一条：目标字符是确定的，允许集是确定的，阈值是零。你不需要知道这是什么页面、有几个区块、什么调性，扫一遍用户可见文本里有没有这两个字符就够了。

更有意思的是原文解释了为什么写成二元规则：历史上把 em-dash 限制表述成 “use sparingly”（少量使用）时，agent 会忽略它，所以这里的措辞被改成二元的 —— 零个。这个理由其实同时也解释了「什么样的规则容易机械化」：能被机械检查的规则，往往正是那些被逼着写成二元形式的规则。「少量使用」既治不了模型，也写不成脚本。

同一档里还有几条：

不许出现 window.addEventListener("scroll", ...)。§5.D 把它列为被禁的动画写法，理由原文是每个滚动帧都跑、易卡顿、没有批处理，替代方案是 Motion 的 useScroll()、GSAP 的 ScrollTrigger、IntersectionObserver，或 CSS 滚动驱动动画（animation-timeline: view()）。这是一个确定的 API 名字，找它比找语义容易得多。
视口稳定用 min-h-[100dvh] 不用 h-screen。同样是两个确定的类名，一个该有、一个不该有。
衬线不许是 Fraunces 或 Instrument_Serif。这两款在 §4.1 里被明确点名封杀作默认，原文称它们是 LLM 最爱的两款 display 衬线。名字是确定的字符串。
premium-consumer 色板里被点名的那批十六进制值。§4.2 列了一串被封杀作默认的暖米底色与黄铜/牛血强调色，例如背景侧的 #f5f1ea、强调侧的 #b08947。这里只举两个，是为了说明它们的形态：是可以逐字符比对的常量，不是”感觉太暖了”这种描述。

A 档的共同点很清楚：规则被写成了具体的标识符或常量。这也反过来提示了一件事 —— 你自己团队要新增规范时，如果希望它以后能自动查，就得逼自己写到这个粒度。

四、B 档：能机械计数，但要先把口径定死

这一档最有代表性的是 EYEBROW COUNT。

§4.7 里这条规则被原文称为「生产测试中被违反次数第一的规则」。所谓 eyebrow，指区块标题上方那行小号大写宽字距标签。规则本身是一个公式：每 3 个区块最多 1 个 eyebrow，hero 算 1 个，所以 9 个区块的页面最多用 3 个；如果 A 区块用了 eyebrow，接下来 2 个区块不能用。Pre-Flight 那一项写的判定方式是 count ≤ ceil(sectionCount / 3)，超了就不合格。

原文自己就说这个检查是机械的：数所有组件里 uppercase tracking（或类似小型大写等宽标签）的出现次数。§4.7 同时给了这类标签的典型 CSS 特征，text-[11px] uppercase tracking-[0.18em]、font-mono text-[10.5px] uppercase tracking-[0.22em]。

但它落不到 A 档，卡点有两个，都值得你在自己接这条检查前想清楚：

分母要人定。 sectionCount 是「这一页有几个区块」。代码里没有一个字段叫 sectionCount，你得先约定：一个 <section> 算一个？一个带标题的语义分组算一个？被 GSAP 钉住的滚动堆栈里的每张卡各算一个还是整体算一个？分母口径变了，ceil(sectionCount / 3) 的结论就跟着变。
分子要人定。 数 uppercase tracking 是一个近似判据。规则针对的是「小号大写宽字距标签」这类视觉物，而不是这两个 utility 本身。一个用 CSS 变量或组件封装写出来的 eyebrow 一样是 eyebrow，只是不带这两个词。

所以这条的正确做法是：先在项目里把 eyebrow 做成一个具名组件，把区块做成一个具名容器，然后计数才有意义。 规则给了公式，公式落地要靠你自己的代码结构配合，这一步没人替你做。

同一档里还有几条同样是「先建模、再计数」：

Bento 格数必须恰好等于内容条数（3 条 → 3 格，5 条 → 5 格），中间或末尾出现空格子就算规划错了。能不能算，取决于你的数据源里是不是真有一个条目数组。
跑马灯一页最多一条。§5 里这是强制项，理由原文是两条及以上读起来就是懒惰填充。前提同样是「什么算一条跑马灯」在你的组件命名里是确定的。
锯齿布局最多连续 2 个区块，第 3 个连续图文分栏直接算 Pre-Flight Fail；以及区块布局不许重复，8 个区块的落地页至少要用 4 种不同的布局家族。这两条要求你先给每个区块打上「布局家族」的标签 —— 标签本身没法从 JSX 里可靠推断出来。
导航桌面端单行且高度上限 80px（默认区间 64-72px）。80px 这个数是硬的，能不能查取决于高度是写在样式里的常量还是渲染出来才知道。
hero 顶部内边距最多 pt-24。类名形式的写法能查，改成任意值语法或变量就不好查了。

五、C 档：只能靠人或模型读一遍

有些框不管怎么建模都自动化不了，它们判定的是意图。

COPY SELF-AUDIT 是最典型的一条。§4.9 要求宣布任务完成前重读页面上每一个可见字符串，包括标题、副标题、eyebrow、按钮文案、正文、图注、alt 文本、页脚文字、错误信息，标出四类问题：语法坏掉的、指代不清的、像 AI 幻觉的、像 LLM 在硬凹深刻的。原文的结论是那句「AI 生成的可爱文案比无聊文案更糟」。这四类里没有一类能写成模式匹配。

NO DUPLICATE CTA INTENT 也一样。规则是同一页出现两个意图相同的 CTA 就算 Fail，原文举的同意图例子是 Get in touch、Contact us、Let's talk、Start a project、Reach out 全属于”联系”意图，要求选一个标签，导航、hero、页脚都用它。字符串各不相同，冲突在语义层。你能做的只是把全页 CTA 文案抽出来列一张表，判定这一步还是人的。

「动效有动机」 同理。§5 里 MOTION MUST BE MOTIVATED 是强制项：加动画前先问这个动画在传达什么，有效答案是层级、叙事、反馈、状态转换，无效答案是”看着酷”，一句话说不清理由就砍掉这个动画。理由说得清说不清，机器不知道。

还有一类特别值得注意：清单里有两条要求「与上一个项目不同」。衬线纪律那条要求不是 Fraunces / Instrument_Serif，且与上个项目不同款；premium-consumer 色板那条要求不落进被点名的暖米黄铜家族，且与上个同类项目不同家族。这两条的判定依据根本不在当前这份产物里 —— 一次代码检查看不到你上一个项目用了什么。它需要一份跨项目的历史记录，而这份记录得你自己维护。

六、三条卡在中间的：能算，但不在静态文本里

有几条不是判不了，而是判定时机不在静态检查阶段：

BUTTON CONTRAST CHECK 与 FORM CONTRAST CHECK。规则给了确定的数值门槛：WCAG AA 最低 4.5:1（正文）、3:1（18px 以上大字）。颜色是静态 token 时这是纯计算；但规则同时点名了照片背景上的 ghost 按钮，要求加背板、遮罩层或描边 —— 底色是一张图片，对比度就不是两个色值相减能得出的了。
CTA BUTTON WRAP BAN。规则是桌面端按钮文字必须一行放下，折成 2-3 行直接算 Pre-Flight Fail，修法二选一：缩短文案（主 CTA 最多 3 个词、理想 1-2 个）或加宽按钮。「有没有换行」必须渲染到桌面宽度才知道。倒是「主 CTA 是不是超过 3 个词」这半条可以静态数。
Core Web Vitals。§6.D 给的目标是 LCP < 2.5s、INP < 200ms、CLS < 0.1，并要求宣布页面完成前跑一次 Lighthouse。这是运行时测量，天然不属于文本检查。

这三条的启示是：一张交付前清单其实横跨了三个执行阶段 —— 静态文本、渲染后、运行时。把它们塞在同一张表里逐个”打勾”，实际执行时必然会被拆开。你如果想自己搭一套，第一步就是按阶段重排，而不是按原文顺序照抄。

七、一处需要说清的仓库现状

§12 THE BLOCK LIBRARY 里有一条纪律写着：每个 block 必须通过 §14 Pre-Flight Check。§12.A 还给出了 skills/taste-skill/blocks/ 下按 hero / feature / social-proof / pricing / cta / footer / navigation / portfolio / transition 分类的目录树。

而我们实读仓库，skills/taste-skill/ 目录下目前只有 SKILL.md 一个文件，上面那棵 blocks/ 目录树在当前仓库里并不存在。§12 自己的状态行写的是 “Status: schema defined here. Blocks will be added iteratively.”。两处并存，以仓库当前状态为准。这里只陈述这个差异，不做推断。

对读这张清单的人来说，这件事的实际含义只有一条：§14 目前唯一确定的作用对象是模型直接生成的页面，而不是一批已经存在、已经逐个过检的现成 block。

八、怎么用这 62 个框

我们的建议就三句话。

A 档接进你自己的构建链。 这些规则已经被写成具体的标识符和常量了，判定条件是零歧义的，交给机器比交给自觉可靠。注意这是通用工程做法，不是这个仓库的官方文档内容 —— SKILL.md 交付的是写给模型的规则文本，不是一份可执行的检查程序，怎么把规则变成检查得你自己实现。

B 档先定口径，再谈自动化。 区块怎么算、eyebrow 怎么认、布局家族怎么打标，这些约定一旦落到组件命名上，count ≤ ceil(sectionCount / 3) 这类公式才有落地的可能。约定不定下来，公式就永远停在纸面上。

C 档老实留给评审。 文案自审、CTA 意图去重、动效动机、跨项目的字体与色板轮换，这几类是真的需要一个人读一遍。清单能帮你的是别漏项，判定还得你自己下。

最后回到第一节那句话：这 62 个框是提示词，不是保障。模型走没走完这张矩阵，你从产物上看不出来；你能确定的，只有那些被你自己搬进构建链里的部分。

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