Hero 必须装进首屏：2 行标题、20 词副文本、4 个元素上限

2026-08-09

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

大多数「AI 味落地页」的病灶其实集中在同一块地方：首屏。taste-skill 默认 skill（文件夹 taste-skill，install name design-taste-frontend）的 SKILL.md 里，§4.7 Layout Discipline 把 Hero 这件事拆成了一组能数出来的硬指标——2 行、20 词、4 个元素、pt-24、80px。这篇就把这几个数字逐个拆开：它卡的到底是什么，什么时候该照做，什么时候该走 override。

一、这一节写的是硬规则，但不是没有出口

§4.7 在原文里是被标成硬规则的：违反其中任意一条，就算是交付了坏活。§4 开篇给的整体立场则是另一种口吻——LLM 默认会出陈词滥调，要主动覆盖这些默认，而每条规则都有一条按语境的 override 路径。所以读 §4.7 时，「硬规则」这个标签和「有 override」这个前提是同时成立的，别只记住其中一半。

读这一节的正确姿势也就不是「学几个审美建议」，而是「拿到一份验收清单」。清单上每一条都能用眼睛数出来，不需要品味参与：标题几行、副文本几个词、首屏里有几个文本元素、顶部留了多少 padding、导航是不是折行了。

二、Hero 必须装进首屏，这句话被拆成了三个可数项

原文的主条是：Hero 必须装进首屏。桌面端标题最多 2 行，副文本最多 20 个词，CTA 不滚动就能看到。文案太长了，处置办法是减小字号或者砍文案。

这里有一句原文的定性值得单独拎出来：如果你没法用 20 个词的副文本说清价值主张，那说明价值主张不清楚，不是规则太紧。这句话决定了这条规则该怎么用——它把「写不下」重新定义成了内容问题，而不是排版问题。你如果发现自己在跟 20 这个数字较劲，规则的意思是回去改文案，不是回去改 max-width。

顺带说一处仓库内部的措辞差异：主条里副文本写的是「最多 20 个词且最多 3-4 行」，而下面 HERO STACK DISCIPLINE 那一项里写的是「最多 20 词、最多 4 行」。两处对行数上限的写法不同，词数上限一致。只陈述这个差异，以仓库当前状态为准。

三、4 行标题永远是字号错误

紧跟着主条的是 Hero 字号纪律，这条给的是判断依据而不是口号。

原文要求字号与图片尺寸一起规划：hero 资产很大、标题又超过 6 个词的时候，别从 text-7xl / text-8xl 起步。它给的默认合理区间是——多数 hero 用 text-4xl md:text-5xl lg:text-6xl；只有标题在 3-5 个词时才用 text-6xl md:text-7xl。

然后是这一节最好用的一句判据：4 行的 hero 标题永远是字号错误，不是文案长度错误。

这句话的实用价值在于它给了一个明确的归因方向。你看到首屏标题折成 4 行，按规则应当先怀疑字号档位选高了，而不是先去砍词。反过来说，如果字号已经落在 text-4xl md:text-5xl lg:text-6xl 这一档还是 4 行，那才轮到文案。

另有一处可以对照着看：§4.1 给 Display / Headlines 的默认类串是 text-4xl md:text-6xl tracking-tighter leading-none，中断点上直接跳到了 text-6xl；而 §4.7 的 hero 区间在 md 上写的是 text-5xl，lg 才到 text-6xl。两节给的刻度不同，适用范围一个是通用标题、一个是 hero 专项。差异如此，不作推断。

还有一条容易在 hero 上翻车的强制项在 §4.1：ITALIC DESCENDER CLEARANCE。display 字号用斜体、而且词里带 y g j p q 这类下伸字母时，leading-[1] 或 leading-none 会把下伸部分切掉；规则要求最少用 leading-[1.1]，并在外层元素加 pb-1 或 mb-1 预留，上线前逐个斜体词过一遍。之所以在讲 hero 的篇里提它：原文举的正是 “and spatial design” 这种在标题里斜体强调一个词的动感手法，而 §4.1 给 display 的默认类串里恰好带着 leading-none。清除规则原文标的是强制，点名的就是 leading-[1] / leading-none 这两种写法，所以标题里一旦出现带下伸字母的斜体词，行高就不能停在默认串上。

顺便，同一节的 EMPHASIS RULE 也管着这件事：要在标题里强调某个词，用同一款字体的斜体或粗体，不要为了视觉趣味往无衬线标题里塞一个随机衬线词。原文把混家族强调称为外行做法。

四、4 个文本元素上限，和被点名赶出去的五类东西

HERO STACK DISCIPLINE 是这一节里信息量最大的一条。原文一句话定调：hero 是一个瞬间，不是功能清单。允许的文本元素总共最多 4 个：

Eyebrow（小号大写标签）或品牌条或都不要——这一格只能选零个或一个
标题（最多 2 行）
副文本（最多 20 词、最多 4 行）
CTA（1 个主 + 最多 1 个次）

被明确禁止出现在 hero 内部的，原文列了五类，还带着例句：

CTA 下方的小标语，例如 “Works with GitHub, GitLab, and self-hosted Git”
信任微条，例如 “Used by engineering teams at…”
定价预告，例如 “Free for solo, $10/user for teams”
功能要点列表
社交证明头像行

处置方式统一：全部移到 hero 正下方的独立区块。另有一条单列的规则说得更死——“Used by” / “Trusted by” 的 logo 墙属于 hero 下方，绝不在 hero 内部。

还有一条兜底：同一个 hero 里若既有 eyebrow 又有 CTA 下标语，砍掉标语；既有品牌条又有标语，也砍掉标语。原文的说法是，一个 hero 最多一个小文本元素。

为什么这一条值得单独重视？因为这五类东西每一个单看都「有道理」——加个集成清单显得成熟，加行信任微条显得有客户，加句定价显得坦诚。它们不是被审美否决的，是被首屏预算否决的：位置只有那么多，四个格子已经排满了。你要判断该不该照做，问的不该是「这句话有没有用」，而是「它有没有必要挤在滚动之前」。

这里可以顺带引 §4.7 里 EYEBROW RESTRAINT 的一行——hero 算 1 个 eyebrow。这条规则整体是「每 3 个区块最多 1 个 eyebrow」，它的 Pre-Flight 检查是机械的：数所有组件里 uppercase tracking 这类小型大写标签的出现次数，若 count > ceil(sectionCount / 3) 就判不合格。之所以要在 hero 篇里提这一行，是因为你在 hero 顶上放的那个 eyebrow 会占掉整页配额里的一个名额，紧接着的两个区块就不能再用了。这条规则原文自称是生产测试中被违反次数第一的，它的完整口径我们另有一篇专门讲。

五、`pt-24` 与 80px：两个卡上界的数字

HERO TOP PADDING CAP（强制）：桌面端 hero 顶部内边距最多 pt-24（≈6rem）。原文给的理由很具体——再多就会让 hero 内容浮在视口中段，读起来像布局 bug，而不是刻意的留白。想要更多呼吸感，办法是加大字号或资产尺寸，不是加顶部内边距。

导航侧有两条与首屏直接相关的：桌面端导航必须单行渲染，在 lg（1024px）放不下就精简标签、砍次要项，或者收进汉堡菜单，桌面两行导航算坏设计；导航高度上限桌面最大 80px，默认 64-72px，原文特意点了一句：不要吃掉 15% 视口的巨型 agency 导航条。

这两组数字放在一起看，指向的是同一件事：首屏那点垂直空间是有预算的，导航和顶部 padding 都是在跟标题、副文本、CTA 抢位置。规则的做法是给抢位置的那几方各设一个上界，而不是去规定内容该占多少。至于这几个上界加起来在你的视口高度下还剩多少——SKILL.md 没有给这样一个总预算公式，我们也不替它算。

顺带说一处会撞车的地方：改版场景里，§11.F 把主导航标签列进了「绝不悄悄改动」的清单（未经用户明确批准不得修改），而 §4.7 修导航折行的办法之一恰恰是精简标签、砍次要项。两条规则在同一个场景下会对上，文档没写谁优先，我们也不替它裁；只如实转述 §11.F 的原措辞——这份清单上的东西未经用户明确批准不得修改。另外，在 §11.D 的现代化杠杆排序里，「Hero 与关键区块重构」排在第 5 位，前面还有字体、间距、色彩、动效四级——也就是说，改版时它并不是首选动作。

六、CTA 那一格：两条强制规则，外加一条视觉底线

hero 的第 4 个格子是 CTA，而 §4.5 里有两条强制规则直接管着它。

CTA BUTTON WRAP BAN（强制）：桌面端按钮文字必须一行放下。原文举的反例是 “VIEW SELECTED WORK” 折成 2-3 行——那样按钮就是坏的。修法二选一：缩短文案（主 CTA 最多 3 个词，理想 1-2 个），或者加宽按钮（不要人为给 CTA 设 max-width）。桌面端换行 CTA 直接算 Pre-Flight Fail。

NO DUPLICATE CTA INTENT（强制）：同一页出现两个意图相同的 CTA 也算 Pre-Flight Fail。原文举的同意图例子是 Get in touch + Contact us + Let's talk + Start a project + Reach out 这一串，全是「联系」意图；处置是选一个标签，导航、hero、页脚都用它。这条对 hero 的实际影响是跨区块的：你在 hero 里写的 CTA 文案，会连带锁死导航按钮和页脚按钮的措辞。

还有一条不在文本层面，但同样卡 hero：§4.8 明写 Hero 需要真实视觉，原文的判定是「文字 + 渐变色块不是 hero，是占位符」。同一节还给了资产优先级——环境里有图像生成工具就必须用它做区块专属资产，其次用真实网络图片（https://picsum.photos/seed/{descriptive-seed}/{w}/{h} 这类占位摄影是被明确接受的默认），两条路都走不通时留下明确标注的占位槽并直接告诉用户缺哪几张图，而不是拿手绘 SVG 或 div 假截图糊上。

七、什么时候不该照做

规则给了几处明确的出口，这才是这一节可用的关键。

居中 hero 不是一律禁的。 §4.3 的 ANTI-CENTER BIAS 是有条件的：DESIGN_VARIANCE > 4 时才要求避免居中 Hero / H1，改走 Split Screen（50/50）、左内容右资产、非对称留白或滚动钉住结构。它的 override 写得很清楚——editorial / manifesto / 发布公告类需求，信息本身就是设计时，居中 hero 可以。

整类界面根本不在射程内。 §13 OUT OF SCOPE 明确列出这个 skill 不是用来做仪表盘、高密度产品 UI、后台管理面板、数据表格、多步表单向导、代码编辑器、原生移动端和实时协作 UI 的。你的页面属于这些类别时，按原文的要求应该明确说出来并指向正确的工具，只把营销页 / 关于页 / 落地页的部分应用到适用的界面上。管理后台的顶部区域套「hero 4 元素上限」，从一开始就用错了地方。

改版和新建走的不是同一条路。 §11.A 要求先判模式：Greenfield 才取 §1 基线；Redesign - Preserve 是先审计、提取品牌 token、渐进演化；Redesign - Overhaul 才把视觉当 greenfield 做但保留内容与信息架构。原文说，模式判错是改版输出变差的最大单一来源；含糊时只问一次即可。

八、最后，这些规则的性质

必须说清楚：以上每一条——2 行、20 词、4 个元素、pt-24、80px、Pre-Flight Fail——都写在 skills/taste-skill/SKILL.md 这份 Markdown 里，它是写给模型看的提示词约束。taste-skill 仓库里没有 src/、没有构建产物，没有任何东西会在你的项目里执行这些检查。「桌面端换行 CTA 算 Pre-Flight Fail」是一条要求模型自查的指令，不是一个会在 CI 里亮红的门禁。

所以这些数字对你最稳的用法，其实是当验收清单而不是当保障：交付前自己对着数一遍标题几行、副文本几个词、hero 里躺着几个文本元素。想要确定性，就得在自己的构建链里加机械校验（这属于通用前端工程做法，不是该仓库文档里的内容）。

另外，默认 skill 自标是 v2 (experimental)，README 原文也说 “It is still iterating”。上面这些数字是我们核对日当天仓库里的写法，不是不会变的常量。

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