design-taste-frontend-v2-experimental

Name: design-taste-frontend-v2-experimental
Author: leonxlnx

github.com/leonxlnx设计与 UI104.4k19.5k 次安装4 天前更新

代码仓库

关于 design-taste-frontend-v2-experimental

面向编码 Agent 的前端设计技能，先分析需求再为落地页、作品集和改版选择视觉方向与实现规范。通过情境化规则和设计参数，减少通用化的页面输出。

主要功能

01分析需求与受众
02选择设计方向和参数
03设计系统使用指引
04React 与 Tailwind 规范
05无障碍与响应式规则

适用场景

01规划 SaaS 落地页
02制作设计师或开发者作品集
03改版现有网站
04在设计需求中落实无障碍约束

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/leonxlnx/taste-skill --skill design-taste-frontend-v2-experimental

安装后在 Claude Code 中输入/design-taste-frontend-v2-experimental确认已加载。

附带文件agents/openai.yaml

详细介绍

tasteskill：反臃肿前端技能

落地页、作品集和改版项目。不适用于仪表板、数据表或多步骤产品 UI。以下每条规则都取决于具体情境，不会自动触发。先阅读需求说明，再挑选适用的规则。

0. 推断需求（先读懂情境，再做其他事）

在编写代码或调整参数之前，先推断用户真正想要什么。大多数 LLM 设计结果都很糟糕，因为模型没有先读懂情境，就直接套用默认审美。

0.A 先读取这些信号

页面类型——落地页（SaaS／消费级／代理商／活动）、作品集（开发者／设计师／创意工作室）、改版（保留现状还是全面改造）、编辑内容／博客。
用户使用的风格关键词——“极简”“平和”“Linear 风格”“Awwwards”“粗野主义”“高端消费级”“Apple 风格”“活泼”“严肃的 B2B”“编辑风”“代理商风”“玻璃质感”“暗色科技”。
参考信号——用户提供的 URL、粘贴的截图、提到的产品、正在与其竞争的品牌。
受众——B2B 采购评审组、注重设计的消费者，还是快速浏览作品集的招聘人员。审美应由受众决定，而不是你的个人偏好。
现有品牌素材——Logo、颜色、字体、摄影素材。对于改版项目，这些是起点，而非可选输入（见第 11 节）。
隐性约束——以无障碍为先的受众、公共部门、受监管行业、以信任为先的商业场景、儿童产品。这些约束优先于审美偏好。

0.B 生成内容前，先用一句话给出“设计判断”

编写任何代码之前，用一句话说明：“我的判断是：这是面向 <audience> 的 <page kind>，采用 <vibe> 风格，倾向于 <design system or aesthetic family>。”

判断示例：

“我的判断是：这是面向技术买家的 B2B SaaS 落地页，采用 Linear 风格的极简语言，倾向于 Tailwind 工具类 + Geist + 克制的动效。”
“我的判断是：这是面向招聘经理的独立设计师作品集，采用编辑风／动态字体语言，倾向于原生 CSS + 滚动驱动动画 + 定制字体。”
“我的判断是：这是公共部门服务网站的改版，采用以信任为先的设计语言，倾向于 GOV.UK Frontend 或 USWDS。”

0.C 如果需求说明含糊，只提一个问题，不要猜

仅当设计判断确实存在明显分歧时，才提出且只提出一个澄清问题，绝不要一次抛出多个问题。例如：“你希望整体更接近 Linear 式的简洁，还是 Awwwards 式的实验性？”

如果你能根据上下文有把握地推断，就不要提问。直接说明设计判断并继续。

0.D 避免默认套路

不要默认使用：AI 紫色渐变、深色网格背景上的居中主视觉、三个等宽功能卡片、无处不在的通用玻璃拟态、无穷循环的微动画、Inter + slate-900。这些都是 LLM 的默认套路。应根据设计判断，有意识地跳出这些套路。

1. 三个调节参数（核心配置）

给出设计判断后，设置三个参数。以下所有布局、动效和信息密度决策都受它们约束。

DESIGN_VARIANCE: 8——1 = 完美对称，10 = 艺术式混沌
MOTION_INTENSITY: 6——1 = 静态，10 = 电影感／物理效果
VISUAL_DENSITY: 4——1 = 艺术馆／疏朗，10 = 驾驶舱／数据密集

基准值： 8 / 6 / 4。除非设计判断要求调整，否则使用这些值。不要让用户编辑此文件——调整应通过对话进行。

1.A 推断设计刻度（阅读设计描述 → 确定刻度值）

信号	VARIANCE	MOTION	DENSITY
“极简 / 清爽 / 宁静 / 编辑风 / Linear 风格”	5-6	3-4	2-3
“高端消费品 / Apple 风格 / 奢华 / 品牌”	7-8	5-7	3-4
“活泼 / 狂野 / Dribbble / Awwwards / 实验性 / 代理商风格”	9-10	8-10	3-4
“落地页 / 作品集 / 营销网站（默认）”	7-9	6-8	3-5
“信任优先 / 公共部门 / 受监管 / 无障碍至关重要”	3-4	2-3	4-5
“重新设计 - 保留”	与现有设计匹配	+1	与现有设计匹配
“重新设计 - 全面改造”	+2	+2	与现有设计匹配

1.B 用例预设

用例	VARIANCE	MOTION	DENSITY
落地页（SaaS、大众市场）	7	6	4
落地页（代理商 / 创意）	9	8	3
落地页（高端消费品）	7	6	3
作品集（设计师 / 工作室）	8	7	3
作品集（开发者）	6	5	4
编辑内容 / 博客	6	4	3
公共部门服务	3	2	5
重新设计 - 保留	匹配	匹配+1	匹配
重新设计 - 全面改造	+2	+2	匹配

1.C 刻度如何驱动输出

将这些值（或用户覆盖的值）用作全局变量。本文档中的交叉引用均指向这些确切的变量名——切勿自行发明 LAYOUT_VARIANCE 或 ANIM_LEVEL 之类的别名。

2. 简述 → 设计系统映射

确定设计方向（第 0 节）和刻度（第 1 节）后，选择合适的基础。已有官方包的功能，不要自行编写 CSS。不要把审美趋势说成官方系统。

2.A 何时选用真正的设计系统（使用官方包）

简述呈现为……	选用	原因
Microsoft / 企业 SaaS / 仪表板	`@fluentui/react-components` 或 `@fluentui/web-components`	官方 Fluent UI、Microsoft 设计令牌，已处理无障碍
类似 Google 的 UI、Material 风格产品	`@material/web` + Material 3 令牌	官方系统，可通过 Material Theming 设置主题
IBM 风格的 B2B / 企业分析	`@carbon/react` + `@carbon/styles`	官方 Carbon，数据密集型模式成熟
Shopify 应用界面	`polaris.js` Web 组件 / Polaris React	Shopify 管理界面必需
Atlassian / Jira 风格产品	`@atlaskit/*` + `@atlaskit/tokens`	官方 Atlassian 设计系统
GitHub 风格的开发工具 / 社区页面	`@primer/css` 或 `@primer/react-brand`	官方 Primer；营销用途选 Brand 变体
英国公共部门服务	`govuk-frontend`	法规 / 监管要求
美国公共部门 / 信任优先	`uswds`	同上
快速构建本地企业 / 代理商 MVP	Bootstrap 5.3	简单、快速、可靠
现代无障碍 React 基础	`@radix-ui/themes`	原语组件 + 精致主题
自行维护组件的现代 SaaS	shadcn/ui（`npx shadcn@latest add ...`）	代码由你掌控，易于定制；切勿直接交付默认状态
基于 Tailwind 的现代 SaaS / AI 营销	Tailwind v4 实用类 + `dark:` 变体	独立开发者和小团队构建的默认选择

诚实原则：如果简述符合上述某个系统的特征，就安装并使用其官方包。不要手动重建其 CSS。不要导入系统的设计令牌，却又覆盖其中 90%。

**每个项目只用一个系统。**不要在同一个组件树中混用 Fluent React 和 Carbon。不要在 Material 3 应用中导入 shadcn/ui 组件。

2.B 当设计方向是一种美学风格，而非系统

对于这些设计方向，没有唯一的官方包。请使用原生 CSS + Tailwind + 维护中的组件库进行构建。请在代码注释中如实说明哪些内容借鉴了灵感，哪些是官方材料。

美学风格	诚实的实现方式
玻璃拟态／「磨砂玻璃」	使用 `backdrop-filter`、多层边框和高光覆盖层。为 `prefers-reduced-transparency` 提供纯色填充后备方案。
Bento（Apple 风格的网格卡片）	使用不同单元格尺寸的 CSS Grid。没有任何单一库拥有这一风格。
粗野主义	使用原生 CSS、等宽字体和粗犷边框。没有可用的库。
编辑风／杂志风	使用衬线字体、不对称网格和充裕的留白。没有可用的库。
暗黑科技／黑客风	使用等宽字体 + 霓虹强调色、终端元素。没有可用的库。
极光／网格渐变	使用 SVG 或多层径向渐变。没有可用的库。
动态排版	使用原生 CSS 动画、滚动驱动动画；劫持滚动时使用 GSAP。没有可用的库。
Apple Liquid Glass	Apple 仅针对 Apple 平台提供相关文档。没有官方的 `liquid-glass.css`。 Web 实现是使用 `backdrop-filter` + 多层边框 + 高光效果进行的近似。请明确标注为近似实现。

3. 默认架构与约定

除非设计分析选择了真正的设计系统（第 2.A 节），否则默认采用以下方案：

3.A 技术栈

框架： React 或 Next.js。默认使用 Server Components（RSC）。
- RSC 安全性： 全局状态仅适用于 Client Components。在 Next.js 中，将 providers 包装在 "use client" 组件中。
- 交互隔离： 任何使用 Motion、滚动监听器或指针物理效果的组件，都必须是独立的叶子组件，并在顶部添加 'use client'。Server Components 仅渲染静态布局。
样式： 默认使用 Tailwind v4。仅当现有项目要求时才使用 Tailwind v3。
- 对于 v4：不要在 postcss.config.js 中使用 tailwindcss 插件。请使用 @tailwindcss/postcss 或 Vite 插件。
动画： Motion（原名为 Framer Motion 的库）。从 motion/react 导入（import { motion } from "motion/react"）。framer-motion 包仍可作为旧版别名使用；新代码优先使用 motion/react。
字体： 始终使用 next/font（Next.js），或使用 @font-face + font-display: swap 自托管。生产环境中切勿通过 <link> 链接 Google Fonts。

3.B 状态

局部 UI 使用 useState / useReducer。
仅在需要避免深层 props 传递时使用全局状态，例如 Zustand、Jotai 或 React context。
切勿使用 useState 跟踪由用户输入驱动的连续值（鼠标位置、滚动进度、指针物理效果、磁性悬停）。请使用 Motion 的 useMotionValue / useTransform / useScroll。每次变化都会让 useState 重新渲染 React 树，并且在移动设备上会导致效果失效。

3.C 图标

允许使用的库（按优先级排序）： @phosphor-icons/react、hugeicons-react、@radix-ui/react-icons、@tabler/icons-react。
不建议使用： lucide-react。仅当用户明确要求，或项目已依赖它时才可使用。
切勿手工绘制 SVG 图标。 如果缺少某个图形符号，请安装第二个库，或使用基本图形组合；不要从头绘制图标路径。
每个项目使用同一套图标。 不要在同一个组件树中混用 Phosphor 和 Lucide。
全局统一 strokeWidth（例如 1.5 或 2.0）。

3.D Emoji 政策

默认不建议在代码、标记和可见文本中使用 Emoji。请用图标库中的图形替代符号。例外： 仅当用户明确要求轻松俏皮、聊天风格或原生社交风格时，才允许使用 Emoji；即便如此，也应有意地少量使用。

3.E 响应式与布局机制

统一断点（sm 640、md 768、lg 1024、xl 1280、2xl 1536）。
使用 max-w-[1400px] mx-auto 或 max-w-7xl 限定页面布局宽度。
**视口稳定性：**全高 Hero 区块绝不使用 h-screen。务必使用 min-h-[100dvh]，避免移动设备上布局跳动（iOS Safari 地址栏）。
**优先使用网格，避免 Flex 数学计算：**绝不使用复杂的 Flexbox 百分比计算（w-[calc(33%-1rem)]）。务必使用 CSS Grid（grid grid-cols-1 md:grid-cols-3 gap-6）。

3.F 依赖项验证（强制）

导入任何第三方库之前，先检查 package.json。如果缺少该包，先输出安装命令。绝不假设某个库已存在。

4. 设计工程指导原则（偏差纠正）

大模型默认会采用陈词滥调。请主动覆盖这些默认做法。每条规则都提供了适应上下文的覆盖路径。

4.1 排版

**展示文字／标题：**默认使用 text-4xl md:text-6xl tracking-tighter leading-none。
**正文／段落：**默认使用 text-base text-gray-600 leading-relaxed max-w-[65ch]。
无衬线字体选择：
- 不建议作为默认选择：Inter。优先选择 Geist、Outfit、Cabinet Grotesk、Satoshi，或适合品牌的衬线字体。
- **例外：**如果用户明确要求中性／标准／Linear 风格，或项目需求是公共部门／无障碍优先网站，则可以使用 Inter。
值得了解的搭配：Geist + Geist Mono、Satoshi + JetBrains Mono、Cabinet Grotesk + Inter Tight、GT America + IBM Plex Mono。
衬线字体规范（非常不建议作为默认选择）：
- 非常不建议将衬线字体作为任何项目的默认字体。“感觉有创意／高端／有编辑感”并不是选择衬线字体的理由。Agent 默认认为“创意需求 = 衬线字体”，这是在生产评审中最常见、也最容易被识别出的 AI 痕迹。
- 只有在以下条件之一明确成立时，才可以使用衬线字体：
  - 品牌需求中明确点名衬线字体；或
  - 美学风格确实属于编辑／奢华／出版物／手稿／传统／复古，并且你能说明这种衬线字体为何适合这个特定品牌
- 对于其他所有情况（创意机构、设计工作室、现代品牌、高端消费品牌、作品集、生活方式），默认使用无衬线展示字体（Geist Display、ABC Diatype、Söhne Breit、Cabinet Grotesk Display、Migra Sans、GT Walsheim、Inter Display、PP Neue Montreal）。无衬线展示字体并不“乏味”——它们之所以是默认选择，正如黑色是时尚界的默认色一样。
- 强调规则（相关）：若要在标题中强调某个词（例如动态的“and spatial design”风格），请使用同一字体的斜体或粗体。不要为了增加视觉趣味，在无衬线标题中随意插入一个衬线词（反之亦然）。混用不同字体家族来强调显得很不专业。正确做法是在同一字体家族中使用斜体／粗体强调。
- 特别禁止作为默认选择：Fraunces 和 Instrument_Serif（这是大模型最偏爱的两款展示衬线字体）。
- 如果有充分理由使用衬线字体（如上所述，情况罕见），请从以下字体池中轮换选择，不要在连续项目中重复使用同一款衬线字体：PP Editorial New、GT Sectra Display、Cardinal Grotesque、Reckless Neue、Tiempos Headline、Recoleta、Cormorant Garamond、Playfair Display、EB Garamond、IvyPresto、Migra、Editorial Old、Saol Display、Söhne Breit Kursiv、Domaine Display、Canela、Schnyder、Tobias、NB Architekt、ITC Galliard。
**斜体下伸部留白（强制）：**在展示文字中使用斜体，且单词包含下伸字母（y g j p q）时，leading-[1] 或 leading-none 会裁掉下伸部分。至少使用 leading-[1.1]，并在包裹元素上添加 pb-1 或 mb-1 留白。交付前检查展示标题中的每个斜体词。

4.2 色彩校准

最多使用 1 种强调色。默认饱和度低于 80%。
**紫丁香规则：**不建议默认采用“AI 紫色／蓝色光晕”美学。不要自动添加紫色按钮光晕，也不要随意使用霓虹渐变。使用中性色基底（Zinc／Slate／Stone），搭配高对比度的单一强调色（翠绿、电光蓝、深玫红、焦橙等）。
**例外：**如果品牌或设计要求明确指定紫色／紫罗兰色／紫丁香色，就大胆使用。但要有明确意图：配色保持一致，中性色协调，渐变有所节制。不要用千篇一律的 AI 渐变糊弄。
**每个项目只用一套配色。**同一项目中不要在暖灰和冷灰之间摇摆。
**色彩一致性锁定（强制）：**页面选定强调色后，整张页面都要使用该颜色。暖灰色调的网站不能在第 7 个区块突然出现蓝色 CTA。玫红色调的网站不能在页脚出现青绿色状态徽章。选定一种强调色并锁定，交付前审核每个组件。
禁止采用高端消费品配色（强制，第二常见的 AI 痕迹）：
- 对于高端消费品设计要求（炊具、健康养生、手工艺品、奢侈品、传统工艺、DTC 家居用品等），大模型默认会采用暖米色／奶油色 + 黄铜色／陶土色／牛血红／赭黄色 + 浓缩咖啡色／墨色深色文本。具体来说，以下十六进制色系不得作为默认背景和强调色：
  - 背景：#f5f1ea、#f7f5f1、#fbf8f1、#efeae0、#ece6db、#faf7f1、#e8dfcb（均为“暖纸色／奶油色／粉笔色／骨色”）
  - 强调色：#b08947、#b6553a、#9a2436、#9c6e2a、#bc7c3a、#7d5621（均为“黄铜色／陶土色／牛血红／赭黄色”）
  - 文本：#1a1714、#1a1814、#1b1814（均为“浓缩咖啡色／暖调近黑色”）
- 禁止将这套配色作为高端消费品设计要求的默认选择。你之前交付的每个高端消费品网站都用了这套配色，品牌辨识度荡然无存。
- 默认替代方案（轮换使用，不要重复）：
  - **冷调奢华：**银灰色 + 铬色 + 烟灰色（想想 Tesla、Apple Watch Hermes 去皮革版）
  - **森林：**深绿色 + 骨色 + 琥珀色强调色（想想 Filson、Patagonia 高端系列）
  - **黑与棕：**纯粹的黑灰色 + 暖棕色，鲜明对比，不用米色
  - **钴蓝 + 奶油色：**饱和蓝色搭配单一中性色，不用黄铜色
  - **陶土色 + 石板灰：**暖锈色搭配冷灰色，不用黄铜色
  - **橄榄绿 + 砖红色 + 纸色：**柔和橄榄绿搭配砖红色强调色
  - **纯单色 + 单一饱和亮色：**灰白色 + 黑灰色 + 一种亮色强调色（电光蓝、翠绿、亮粉色等）
- **配色轮换规则：**如果上一个生成的高端消费品项目使用了米色 + 黄铜色系，这次就必须换用其他色系。不要连续两次交付相同的暖调手工艺配色。
- **例外：**只有当品牌要求明确指定这些颜色，或者品牌形象确实属于复古／手工艺／暖调工艺风格，且你能说明这套特定配色为何适合这个特定品牌时，才可以使用米色 + 黄铜色 + 浓缩咖啡色配色。仅仅因为“这是炊具设计要求”就默认选择这套配色是被禁止的。

4.3 布局多样化

**避免居中偏差：**当 DESIGN_VARIANCE > 4 时，避免使用居中 Hero／H1 区块。强制采用“分屏”（50/50）、“左对齐内容／右对齐素材”、“非对称留白”或滚动固定结构。
**例外：**对于编辑风格／宣言／发布公告类设计要求，若信息本身就是设计的一部分，可以使用居中 Hero。

4.4 质感、阴影与卡片

仅在层级关系确实需要通过高度来体现时使用卡片。否则使用 border-t、divide-y 或留白进行分组。
使用阴影时，阴影色调应与背景色调一致。浅色背景上不得使用纯黑投影。
对于 VISUAL_DENSITY > 7：禁止使用通用卡片容器。数据指标应在简洁的布局中留有呼吸感。
形状一致性锁定（强制）： 为页面选择一种圆角规格并始终遵循。可选方案：全部直角（圆角为 0）、全部柔和圆角（12-16px）、全部胶囊形（交互元素使用完整圆角）。只有在规则有明确说明（例如“按钮为完整胶囊形，卡片为 16px，输入框为 8px”）且全页面始终遵循时，才允许混用。方形布局中出现圆角按钮，或胶囊按钮页面中出现方形卡片，都是设计缺陷。

4.5 交互式 UI 状态

LLM 默认只实现“静态成功状态”。务必实现完整的状态流程：

加载： 使用与最终布局形状匹配的骨架屏。避免使用通用圆形加载指示器。
空状态： 精心设计，并说明如何填充内容。
错误状态： 清晰呈现，放在行内（表单）或上下文中（仅瞬时错误使用 toast）。
触觉反馈： 在 :active 状态下，使用 -translate-y-[1px] 或 scale-[0.98] 模拟按压效果。
按钮对比度检查（强制，无障碍）： 发布任何按钮前，确认按钮文字在按钮背景上清晰可读。白色按钮搭配白色文字、带 text-white 标签的 bg-white CTA、在无边框情况下背景透明且与页面背景相同的按钮，均禁止。检查每个 CTA：对比度至少符合 WCAG AA（正文为 4.5:1，大号文字 18px 及以上为 3:1）。摄影背景上的幽灵按钮也适用同一规则（使用背景底色、遮罩或描边）。
CTA 按钮换行禁令（强制）： 桌面端按钮文字必须保持在一行。如果像“VIEW SELECTED WORK”这样的标签换成 2 或 3 行，按钮即存在缺陷。修复方式：缩短标签（主要 CTA 最多 3 个词，最好为 1-2 个词），或加宽按钮（不要人为限制 CTA 的 max-width）。桌面端 CTA 换行属于发布前检查失败。
禁止重复 CTA 意图（强制）： 同一页面上，两个 CTA 不得表达相同意图。意图相同的示例：“Get in touch” + “Contact us” + “Let's talk” + “Start a project” + “Start something” + “Reach out”都表示“联系”意图 → 选择一个标签，并在页面各处（导航、主视觉、页脚）统一使用。同样，“Try free” + “Get started” + “Sign up free”都表示“注册”意图；“View work” + “See selected work” + “Browse projects”都表示“作品集”意图。每种意图只用一个标签。
表单对比度检查（强制，无障碍）： 表单输入框、占位符文字、焦点环、辅助文字和错误文字，相对于所在区块背景都必须符合 WCAG AA 对比度要求。近白色表单中的浅色占位符、白色表单置于白色页面区块中、对比度低于 4.5:1 的表单标签，均禁止。发布前检查每个表单。

4.6 数据与表单模式

标签置于输入框上方。辅助文字可选，但必须出现在标记中。错误文字置于输入框下方。输入块使用标准 gap-2。
永远不要用占位符代替标签。

4.7 布局规范（硬性规则。违反任何一条都会导致交付内容存在缺陷）

首屏主视觉必须完整显示在初始视口中。 桌面端标题最多 2 行，副文案最多 20 个单词且最多 3～4 行，CTA 无需滚动即可看到。如果文案太长：缩小字号或删减文案。如果无法用 20 个单词的副文案描述价值主张，说明价值主张不够清晰，而不是规则太严。绝不能让主视觉溢出，导致用户必须滚动才能找到 CTA。
主视觉字号规范。 同时规划字号和图片尺寸。如果主视觉素材较大，且标题超过 6 个单词，不要一开始就用 text-7xl/text-8xl。大多数主视觉建议使用 text-4xl md:text-5xl lg:text-6xl；标题只有 3～5 个单词时才使用 text-6xl md:text-7xl。主视觉标题出现 4 行，永远是字号错误，不是文案长度问题。
主视觉顶部内边距上限（强制）： 桌面端主视觉顶部内边距最大为 pt-24（≈6rem）。超过这个值会让主视觉内容悬在视口中央，看起来像布局错误，而非刻意留白。如果主视觉需要更多呼吸空间，请增大字号或素材尺寸，而不是增加顶部内边距。
主视觉内容堆叠规范（最多 4 个文本元素）。 主视觉是一个完整的瞬间，不是功能列表。允许的文本元素总数最多为 4 个：
1. 眉题（小号大写标签）或品牌条，或者都不选——最多选一个
2. 标题（最多 2 行，见上文）
3. 副文案（最多 20 个单词，最多 4 行）
4. CTA（1 个主要 CTA + 最多 1 个次要 CTA）
- 主视觉中禁止出现： CTA 下方的小字标语（“兼容 GitHub、GitLab 和可自托管 Git”）、信任背书小条（“深受……工程团队使用”）、价格预告（“个人用户免费，团队用户每人每月 $10”）、功能项目列表、社交证明头像行。所有这些内容都应移至主视觉正下方的专属版块。
- 如果同一个主视觉中既有眉题，又有 CTA 下方的标语，请删除标语。如果既有品牌条，又有标语，也请删除标语。每个主视觉最多只能有一个小型文本元素。
“使用者”/“信赖者”标志墙应放在主视觉下方，绝不能放在主视觉内。 主视觉用于呈现价值主张和主要 CTA。标志墙应作为紧接其后的独立版块。不要把信任标志塞进与主视觉文案相同的弹性布局行中。
桌面端导航必须单行显示。 如果项目在 lg（1024px）断点下无法容纳，请缩短标签、移除次要项目或改用汉堡菜单。桌面端导航分成两行属于设计错误。
导航高度上限：桌面端最多 80px，默认 64～72px。 不要使用占据视口 15% 的超大“代理公司风格”导航栏。
Bento 网格必须有节奏变化，不能单方面重复。 不要连续堆叠 6 行“左侧图片、右侧文本”。应变化构图：交替使用全宽功能行、不对称尺寸的卡片和纵向分隔。
Bento 单元格数量规则（强制）： Bento 网格的单元格数量必须与内容数量完全一致。3 个项目 → 3 个单元格（1+2 拆分、2+1 拆分或不对称三列）。5 个项目 → 5 个单元格（2+3、3+2、主卡片+4 个等）。如果网格中间或末尾有空单元格，说明规划有误。请重新调整网格形状，不要放入空白卡片。
禁止重复使用版块布局。 一个版块使用某种布局类型后（例如三列图片卡片、全宽引言、文本与图片拆分），该类型在页面中最多出现一次。“精选项目”不能看起来像“我们的业务”。包含 8 个版块的落地页至少应使用 4 种不同的布局类型。
锯齿交替布局上限（强制）。 交替使用“左图右文”和“左文右图”的锯齿布局很普通。连续使用这种图文拆分布局最多 2 个版块。第 3 个连续的图文拆分版块属于上线前检查失败。请用全宽版块、纵向堆叠版块、Bento 网格、跑马灯或其他布局类型打破这种模式。
眉题使用克制（强制，是生产测试中违反次数最多的规则）。 “眉题”指位于版块标题上方、采用小号大写字母和宽字距的标签（例如 FOUR COLORWAYS、SELECTED WORK、THE HARDWARE、Git-native task management）。典型的 CSS 特征：text-[11px] uppercase tracking-[0.18em]、font-mono text-[10.5px] uppercase tracking-[0.22em]。每个由 AI 构建的网站都会在每个版块标题上方添加眉题，形成千篇一律的模板节奏。硬性规则：
- 每 3 个版块最多使用 1 个眉题。 主视觉也算 1 个版块。因此，包含 9 个版块的页面最多可使用 3 个眉题。
- 如果版块 A 有眉题，接下来的 2 个版块就不能再使用眉题。
- 上线前检查是机械式的： 统计所有版块组件中 uppercase tracking（或类似的、位于标题上方的小型大写等宽字体标签）出现的次数。如果次数 > ceil(版块数量 / 3)，则判定输出失败。
- 眉题的替代方案： 直接删除。仅有标题就足够。如果需要为版块分类，版块在页面中的位置本身就能说明类别，无需标签。
禁止拆分式标题（强制）。 禁止默认使用“左侧大标题 + 右侧小段说明文字”的版块标题模式（左列 col-span-7/8，右列 col-span-4/5，小段正文悬在右侧列中）。每个版块都应只有一个聚焦的信息。如果确实需要同时展示标题和说明文字，请纵向排列（标题在上，正文在下，最大宽度 65ch）。只有在存在真正的构图理由时，才使用拆分式标题模式（例如右侧列承载视觉内容或交互元素，而非填充文字）。
Bento 背景多样性（强制）。 Bento 和功能网格版块不能全是 6 张白底白字卡片。任何多单元格网格中，至少 2～3 个单元格需要有真正的视觉变化：真实图片、符合品牌风格的渐变（不要用 AI 紫色）、图案或带色调的背景。奶油色背景配奶油色卡片、内部只有排版文字的 Bento 网格会显得乏味，像 AI 的默认产物，即使页面其他部分做得不错也一样。
必须为每个版块明确指定移动端折叠方式。 对于每个多列布局，都要在同一个组件中声明 < 768px 时的回退方案。不要假设“能正常运行，Tailwind 会处理”。

4.8 图像与视觉素材策略

落地页和作品集是视觉产品。只有文字、用虚假截图占位的 div 页面，都是粗制滥造。

视觉素材优先级：

优先使用图像生成工具。 如果环境中有任何图像生成工具（generate_image、MCP 图像工具、IDE 集成的生成工具、OpenAI 图像工具等），你就必须使用它来创建符合具体版块需求的素材：主视觉照片、产品图、纹理背景、氛围图。生成的图像宽高比要与版块匹配。不要因为手写 CSS 感觉更快就跳过这一步。
其次使用真实网络图片。 没有图像生成工具时，使用真实摄影素材。可接受的默认来源：
- https://picsum.photos/seed/{descriptive-seed}/{w}/{h}，用于占位摄影图片（seed 应描述版块内容，例如 marrow-cookware-kitchen）
- 简介中提供的真实素材库或品牌 URL
- 明确允许时使用开放许可来源（通过直接 URL 引用 Unsplash、Pexels）
最后的办法：告知用户。 如果两种方式都不可行，不要用手写 SVG 插画或基于 div 的“虚假截图”填满页面。请留下标注清晰的占位位置（``），并在回复末尾说明：“此页面需要在以下位置添加真实图片：[list of placements]。请生成或提供这些图片。”

极简风格的网站也需要真实图片。 纯文字页面不叫极简主义，而是未完成的工作。即使是 Linear 风格的编辑式网站，也至少需要 2-3 张真实图片（主视觉、一张产品或生活方式图片、一张辅助图片）。如果简介要求克制风格，可以生成黑白极简摄影；不要因为整体风格简约就完全跳过图片。

用于社会认同的真实公司徽标。 如果简介要求展示“信赖我们的客户 / 使用我们的产品 / 客户”徽标墙，不要默认使用纯文本字标（<span>Acme Co</span>）并排展示。请使用真实的 SVG 徽标：

来源：Simple Icons（任何颜色均可使用 https://cdn.simpleicons.org/{slug}/ffffff，或使用 simple-icons npm 包）。涵盖大多数知名品牌。
替代方案： 技术栈徽标可使用 devicon（@svgr/cli 或 CDN）。
品牌名称是虚构的？那就同时制作一个 SVG 标志。 生成简洁的字母组合（圆圈内一个字母、两个字母的连字、抽象字形），并以内联 <svg> 绘制，使其与页面风格一致。虚构品牌使用纯文字字标会显得很普通。
务必确保徽标在浅色和深色模式下都能正常显示（深色背景上用白色、浅色背景上用黑色，或使用单色主题变量）。
仅徽标规则（强制）： 徽标墙里只能放徽标。不要在每个徽标下方标注行业或类别（不要使用 Vercel 加下方的 hosting，Stripe 加下方的 payments，或 Cloudflare 加下方的 infra）。徽标本身就能建立信任，标签不会提供用户本来不知道的信息。可选：为屏幕阅读器提供品牌名称作为 alt 文本，也可链接到品牌网站。仅此而已。

手写插画：

使用图标库中的 SVG 图标：可以（参见第 3.C 节）。
手写装饰性 SVG（自定义插画、徽标、标志）：强烈不建议，不要默认采用。仅在以下情况可接受：
- 简介明确要求绘制（例如“给我画一个 SVG 徽标”）
- 这是一个简单的几何标志（正方形、圆形、展示字体中的字标）
- 你确信成品质量足够好

禁止使用基于 div 的虚假截图。 使用 <div> 矩形、虚假任务列表、虚假仪表板或虚假终端窗口手工搭建“产品预览”，是明显的坏做法。如果需要展示产品：

有真实截图 URL 时，请使用它
使用图像工具生成一张
使用真实组件预览（在页面中嵌入实际的 UI 小型版本）
或完全跳过预览，改用编辑式摄影图片

主视觉必须有真实图像。 只有文字和渐变色块不算主视觉——那只是占位内容。

4.9 内容密度

落地页的关键在于第一印象，而不是通读全文。尽可能精简。

**每个版块的默认内容结构：**简短标题（≤ 8 个词）+ 简短副段落（≤ 25 个词）+ 一个视觉素材或一个 CTA。超出部分必须符合版块的用途。
**不要设置数据堆砌型版块。**20 行的出版物表格、30 行的奖项列表、营销页面上庞大的定价矩阵，都属于错误的布局。可以改用：
- 展示排名前 3-5 的亮点 + “查看完整列表”链接
- 跑马灯 / 轮播，用于展示更多内容
- 如果数据本身就是产品，则另设独立页面
**长列表需要换用其他 UI 组件，而不是继续加长列表。**默认使用带项目符号的 <ul> 或 divide-y 分隔的行，是最省事的选择。如果项目超过 5 个，可以考虑以下方案：
- 分组后的双栏布局
- 每项配有图片和标签的卡片网格
- 如果项目可分类，则使用标签页 / 手风琴
- 水平滚动吸附胶囊按钮
- 用于展示内容丰富的列表（客户评价、标志、功能）的轮播
- 用于展示“大量无需逐项关注的内容”的跑马灯 10 行规格表每行下方都加一条细线，是最糟糕的默认做法。可以将各行分为 2-3 组，并稀疏使用分隔线；也可以改用每项规格一张卡片的布局。
**特别是规格表（Marrow 炊具模式）。**在炊具 / 硬件 / 服装 / 手工艺品需求中，长产品规格表的每一行都加上 border-b，是 AI 的默认做法。禁止采用。具体替代方案：
- **双栏卡片网格：**每项规格单独放在一张卡片中，显示规格名称、数值（大号展示数字）和一行说明“这为何重要”。桌面端采用双栏，移动端采用单栏。
- **水平滚动吸附胶囊按钮：**每项规格都做成一个胶囊按钮，用户可以滑动浏览。
- **分组：**将 10 项规格分为 3 个逻辑分组（例如“材料”“烹饪”“保修”），每组只使用一条柔和的分隔线和一个分组标题。
- **重点与其他项分开：**将 3-4 项重点规格做成大型展示卡片，其余规格折叠在“查看完整规格”展开项下。
**文案自查（发布前必须完成）：**在宣布任何任务完成之前，重新阅读页面上的每一处可见文本（标题、副标题、眉题、按钮标签、正文文案、说明文字、替代文本、页脚文字、错误消息）。标记任何存在以下问题的文案：
- 语法错误（“过去免费”、“两个方案，但只有一个诚实”、“不合语境的‘摆到桌面上’”）
- 指代不清（没有前文铺垫，却说“我们打算继续保持这种状态”）
- 听起来像 AI 幻觉（俏皮但错误的文字游戏、生硬且不合逻辑的比喻、“优雅的虚无”之类的表达）
- 像大模型在刻意显得深刻（被动攻击式的谦逊、虚假的匠人标签、故作诗意的微观元话语）重写所有标记的文案。如果不确定文案是否说得通，就换成直白、实用的句子。AI 生成的俏皮文案比平淡的文案更糟糕。
**虚假精确的数字会被标记。**像 92%、4.1×、48k、5.8 mm、13.4 lb 这样的数字，要么：
- 来自真实数据（需求说明、品牌指南、公开指标）——可以使用
- 明确标注为模拟数据（“模拟”“示例”“样本数据”）——可以使用
- 是 AI 虚构出来的规格点缀——禁止使用。不要伪造品牌并未宣称的工程精度。
**每个页面只采用一种文案语气。**不要在同一个版面中混用技术风格的等宽文本（“47 项任务 · 每天 0.6 次上下文切换”）、编辑风格的散文和营销式有力文案，除非品牌语调明确要求如此。

4.10 引言与评价

引言正文最多 3 行。绝不能有 6 行。如果原始引言更长 → 请删减。落地页上的引言是摘录，不是完整评价。
对于字号很小的情况（例如页脚风格的评价），行数上限可以稍微放宽。原则是：“一眼就能看完。”
引言文字中不要使用 em dash 作为装饰（表示长停顿、营造动感的 em dash、以 em dash 开头的项目符号）。请参阅第 9.G 节：完全禁止使用 em dash。
署名：姓名 + 职务 +（可选）公司。绝不能只写姓名（“- Sarah”）。
引号：使用真正的排版引号（“ ”），也可以完全不加。不要使用直的 ASCII 引号（"）。

4.11 页面主题锁定（浅色 / 深色模式一致性）

页面只有一种主题。各个区块不能切换主题。

如果页面采用深色模式，所有区块都必须采用深色模式。不能在深色区块之间插入暖纸色调的浅色模式区块（反之亦然）。用户滚动时不能觉得自己突然进入了另一个网站。
例外：如果需求明确要求使用“色块叙事”或“滚动时切换主题”效果，并且这是经过精心设计的构图（整页只切换一次主题，且过渡鲜明，而不是随意交替），则允许使用一次。
默认行为：在页面级别选择浅色、深色或自动（prefers-color-scheme）模式，并保持一致。同一主题系列内可以使用不同的区块背景色调（bg-zinc-950 与 bg-zinc-900 相邻）；但在 bg-zinc-950 页面中途切换到 bg-amber-50 就是不恰当的。
使用内置主题功能的设计系统（Radix Themes、带有 <Theme> 的 shadcn/ui）时，在 layout.tsx 或页面根节点设置一次主题。不要让各个区块单独覆盖主题。

5. 情境感知的主动运用

这些是工具，不是默认设置。只有当设计解读表明需要时才使用。它们都不会自动触发。

液态玻璃 / 毛玻璃效果： 适合高端消费品、Apple 风格、奢侈品牌或媒体叠加层的氛围。不适合仪表盘、公共部门或“平平无奇的 B2B”场景。使用时，不要只加 backdrop-blur：还要添加 1px 内边框（border-white/10）和微妙的内阴影（shadow-[inset_0_1px_0_rgba(255,255,255,0.1)]），营造真实的边缘折射效果。在 prefers-reduced-transparency 下提供纯色填充的回退样式。
磁吸微物理效果： 当 MOTION_INTENSITY > 5 且设计需求体现高端 / 活泼 / 工作室风格时使用。必须在 React 渲染周期之外，仅使用 Motion 的 useMotionValue / useTransform 实现。绝不使用 useState。参见第 3.B 节。
持续的微交互（脉冲、打字机、浮动、闪烁、轮播）：当 MOTION_INTENSITY > 5 且该部分确实能从动效中受益时使用（状态指示器、实时信息流、AI 感）。不是每张卡片都需要无限循环。 如果某个部分只是提供信息，就保持静止。应用弹簧物理效果（type: "spring", stiffness: 100, damping: 20）——不要使用线性缓动。
“声称有动效，就得展示动效。” 如果 MOTION_INTENSITY > 4，页面就必须实际动起来：至少要有 Hero 入场过渡、关键部分的滚动显现，以及 CTA 的悬停物理效果。声称 MOTION_INTENSITY: 7 的静态页面就是有问题。反过来，如果当前工作范围内无法交付可用的动效，就把数值调到 3，交付干净的静态页面。绝不要只做一半、最终导致动效出问题（ScrollTrigger 截断、入场抖动、缺少清理逻辑）。
动效必须有明确目的（强制）。 添加任何动画之前，先问：“这个动画传达了什么？”合理的答案包括：层级（将注意力引向恰当的内容）、叙事（按照符合叙事的顺序展示内容）、反馈（确认用户操作）、状态转换（展示发生了变化）。不合理的答案是：“看起来很酷”。仅仅因为可以使用 GSAP 就到处用 GSAP，是业余做法。每个 ScrollTrigger、每个跑马灯、每个固定定位部分都需要有理由。如果无法用一句话说清理由，就删掉动画。
每页最多一个跑马灯（强制）。 横向滚动的文字跑马灯（“徽标无尽滚动”“宣言横向滚动”“动态文字条”）每页最多使用一次。同一页面有两个或更多跑马灯，会显得像偷懒凑数。挑选最能服务内容的那个部分使用跑马灯；其他部分则采用不同的布局。
GSAP 粘性卡片堆叠模式（使用滚动堆叠时）。 “滚动时堆叠卡片”必须是真正的粘性堆叠，而不是依次显现的列表。下文第 5.A 节提供了标准代码框架。常见问题：触发器在滚动到一半时才触发，而不是固定在视口顶部。解决方法：使用 start: "top top"，而不是 start: "top center" 或 "top 80%"。
GSAP 横向平移模式（使用横向滚动劫持时）。 第 5.B 节提供了标准框架。常见问题：动画在部分固定之前就已开始，导致用户看到半张幻灯片。解决方法相同：使用 start: "top top"，固定外层容器，并让内部轨道随滚动进度移动。

5.A 粘性卡片堆叠 - 标准骨架

"use client";
import { useRef, useEffect, useId, type ReactNode } from "react";
import { gsap } from "gsap";
import { ScrollTrigger } from "gsap/ScrollTrigger";
import { useReducedMotion } from "motion/react";

gsap.registerPlugin(ScrollTrigger);

export function StickyStack({ cards }: { cards: ReactNode[] }) {
  const ref = useRef<HTMLDivElement>(null);
  const reduce = useReducedMotion();
  const instanceId = useId().replace(/:/g, "");
  const cardClass = `stack-card-${instanceId}`;
  const innerClass = `stack-card-inner-${instanceId}`;

  useEffect(() => {
    if (reduce || !ref.current || cards.length <= 1) return;
    const ctx = gsap.context(() => {
      const cardEls = gsap.utils.toArray<HTMLElement>(`.${cardClass}`);
      cardEls.forEach((card, i) => {
        if (i === cardEls.length - 1) return;
        ScrollTrigger.create({
          trigger: card,
          start: "top top",                              // pin at viewport top
          endTrigger: cardEls[cardEls.length - 1],
          end: "top top",
          pin: true,
          pinSpacing: false,
          anticipatePin: 1,
          invalidateOnRefresh: true,
        });
        const inner = card.querySelector(`.${innerClass}`);
        if (!inner) return;
        gsap.to(inner, {
          scale: 0.92,
          opacity: 0.55,
          ease: "none",
          scrollTrigger: {
            trigger: cardEls[i + 1],
            start: "top bottom",
            end: "top top",
            scrub: true,
            invalidateOnRefresh: true,
          },
        });
      });
    }, ref);
    return () => ctx.revert();
  }, [reduce, cards.length, cardClass, innerClass]);

  return (
    <div ref={ref} className="relative">
      {cards.map((card, i) => (
        <div
          key={i}
          style={{ zIndex: i + 1 }}
          className={`${cardClass} relative min-h-[100dvh] flex items-center justify-center`}
        >
          <div className={`${innerClass} w-full flex items-center justify-center will-change-transform`}>
            {card}
          </div>
        </div>
      ))}
    </div>
  );
}

关键点：start: "top top"、pin: true，除最后一张卡片外，其他卡片都要固定；缩放／透明度变换由下一张卡片的滚动触发器驱动（因此，下一张卡片到来时，上一张卡片会缩小）。切勿在同一个元素上同时使用 CSS position: sticky 和 pin: true：原生粘性定位引擎和 ScrollTrigger 的 position: fixed 会在交接时相互冲突（抖动、跳动、坐标漂移）。被固定的元素也不能同时是应用变换的元素——固定外层卡片并为内部包装器添加动画，否则缩放补间会扰乱固定位置的测量结果。使用 useId 为每个实例的卡片类设置作用域，避免同一页面上的两个卡片堆叠互相选中；按递增顺序设置 zIndex。在 prefers-reduced-motion 下，组件会渲染为普通列表：不固定、不应用变换，并且所有内容都可访问。

5.B 水平平移 - 标准骨架

"use client";
import { useRef, useEffect, type ReactNode } from "react";
import { gsap } from "gsap";
import { ScrollTrigger } from "gsap/ScrollTrigger";
import { useReducedMotion } from "motion/react";

gsap.registerPlugin(ScrollTrigger);

export function HorizontalPan({ children }: { children: ReactNode }) {
  const wrap = useRef<HTMLElement>(null);
  const track = useRef<HTMLDivElement>(null);
  const reduce = useReducedMotion();

  useEffect(() => {
    if (reduce || !wrap.current || !track.current) return;
    const ctx = gsap.context(() => {
      const getDistance = () =>
        Math.max(0, track.current!.scrollWidth - wrap.current!.clientWidth);
      gsap.to(track.current, {
        x: () => -getDistance(),
        ease: "none",
        scrollTrigger: {
          trigger: wrap.current,
          start: "top top",                              // pin starts when section top hits viewport top
          end: () => `+=${getDistance()}`,               // scroll distance = track width minus viewport, recomputed on refresh
          pin: true,
          scrub: 1,
          anticipatePin: 1,
          invalidateOnRefresh: true,
        },
      });
    }, wrap);
    return () => ctx.revert();
  }, [reduce]);

  return (
    <section
      ref={wrap}
      role="region"
      aria-label="Horizontal content track"
      tabIndex={reduce ? 0 : undefined}
      className={`relative w-full ${reduce ? "overflow-x-auto scroll-smooth" : "overflow-hidden"}`}
    >
      <div
        ref={track}
        className={`flex h-[100dvh] w-max items-center ${reduce ? "snap-x snap-mandatory" : ""}`}
      >
        {children}
      </div>
    </section>
  );
}

关键点：start: "top top"、pin: true、end: "+=${getDistance()}"（滚动长度 = 所需的水平移动距离），scrub: 1。固定包装器，让内部轨道随着用户垂直滚动而水平滑动。x 和 end 必须基于函数计算，并与 invalidateOnRefresh: true 配合使用；只计算一次的 distance 不会重新计算——调整窗口大小后，它会移动过头，进入空白区域（或者轨道刚好能容纳时完全不移动）。轨道上保留 w-max，并确保每个面板不会收缩（使用 shrink-0 或显式设置宽度）：否则，溢出压缩会缩小 scrollWidth，导致该区域被固定却没有水平移动。在 prefers-reduced-motion 下，确保每个面板都可访问：将包装器改为 overflow-x-auto 并添加滚动吸附点，而不是保留 overflow-hidden。

5.C 滚动进入视口时交错显示 - 标准骨架（更轻量的替代方案）

对于简单的“项目进入视口时显示”（无需固定），优先使用 Motion 的 whileInView，而不是 GSAP——更轻量，也不需要 ScrollTrigger：

"use client";
import { motion, useReducedMotion } from "motion/react";

export function RevealStagger({ items }: { items: string[] }) {
  const reduce = useReducedMotion();
  return (
    <ul className="grid gap-6">
      {items.map((item, i) => (
        <motion.li
          key={item}
          initial={reduce ? false : { opacity: 0, y: 24 }}
          whileInView={{ opacity: 1, y: 0 }}
          viewport={{ once: true, amount: 0.3 }}
          transition={{
            duration: 0.6,
            delay: i * 0.06,
            ease: [0.16, 1, 0.3, 1],
          }}
        >
          {item}
        </motion.li>
      ))}
    </ul>
  );
}

适用于：功能列表、用户评价网格、Logo 墙，以及任何只需要“滚动时进入”的内容。将 GSAP 留给真正需要固定／滚动联动的场景。

5.D 禁止的动画模式

禁止使用 window.addEventListener("scroll", ...)。它会在每个滚动帧运行，容易造成卡顿，也没有批处理。请使用 Motion 的 useScroll()、GSAP 的 ScrollTrigger、IntersectionObserver 或 CSS scroll-driven animations（animation-timeline: view()）。
禁止在 React 状态中使用 window.scrollY 自定义计算滚动进度。 原因相同：每一帧都会重新渲染。
禁止使用会触及 React 状态的 requestAnimationFrame 循环。 请改用 motion 值（useMotionValue + useTransform）。
布局过渡： 对可见状态变化（列表重新排序、模态框展开、路由间共享元素）使用 Motion 的 layout 和 layoutId 属性。不要为了“保险”而给静态内容添加 layout 属性——这会增加测量开销。
交错编排： 对需要按顺序显示的内容，使用 staggerChildren（Motion）或 CSS 级联（animation-delay: calc(var(--index) * 100ms)）。使用 staggerChildren 时，父级（variants）和子级必须位于同一个客户端组件树中。

6. 性能与无障碍防护规则

6.A 硬件加速

仅为 transform 和 opacity 添加动画。切勿为 top、left、width、height 添加动画。
谨慎使用 will-change: transform——仅用于确实会添加动画的元素。

6.B 减少动态效果（必须）

任何 MOTION_INTENSITY > 3 的动态效果都必须遵循 prefers-reduced-motion 设置。 此要求不可妥协。
在 Motion 中：使用 useReducedMotion() 包裹，并降级为静态效果。
在 CSS 中：将动画限制在 @media (prefers-reduced-motion: no-preference) 内，或在 @media (prefers-reduced-motion: reduce) 下提供禁用动画的覆盖规则。
无限循环、视差、滚动劫持和磁吸物理效果在减少动态效果模式下都必须变为静态／即时效果。

6.C 深色模式（所有面向用户的页面均为必需项）

从一开始就为两种模式进行设计。除非用户明确要求，否则绝不只发布浅色模式或深色模式。
使用 Tailwind dark: 变体或 CSS 变量来定义令牌。每个项目选择一种策略。
此处不要规定具体的深色模式颜色。以设计简报为准。在两种模式下均保持视觉层级、品牌识别度和 WCAG AA 对比度（正文达到 AAA）。
遵循 prefers-color-scheme: dark。默认使用系统偏好，除非品牌坚持使用某一种模式。

6.D Core Web Vitals 目标

LCP < 2.5s。主视觉图片必须使用 next/image priority 或预加载。
INP < 200ms。将繁重工作移出主线程。
CLS < 0.1。为图片、字体和嵌入内容预留空间。
在宣布页面完成前运行 Lighthouse。

6.E DOM 开销

仅将颗粒／噪点滤镜应用于固定的、带有 pointer-events-none 的伪元素（例如 fixed inset-0 z-[60] pointer-events-none）。绝不可应用于滚动容器——持续的 GPU 重绘会严重损害移动设备的 FPS。
留意包体积。Motion 并不轻量。Three.js 体积很大。对所有非首屏内容进行延迟加载。

6.F 谨慎使用 Z-Index

绝不可随意堆用 z-50 或 z-10。Z-index 只能用于系统级层叠上下文（粘性导航栏、模态框、叠加层、颗粒效果）。在项目常量文件中记录 z-index 层级。

7. 拨盘定义（技术参考）

DESIGN_VARIANCE（等级 1-10）

1-3（规整）： 对称 CSS Grid（12 列、等分 fr 单位）、等距内边距、居中对齐。
4-7（错落）： 使用 margin-top: -2rem 叠放，采用不同的图片宽高比（4:3 与 16:9 并列），左对齐的标题搭配居中的数据。
8-10（非对称）： 瀑布流布局、使用分数单位的 CSS Grid（grid-template-columns: 2fr 1fr 1fr）、大面积留白区（padding-left: 20vw）。
移动端覆盖： 对于等级 4-10，md: 以上的非对称布局在 < 768px 的视口下必须折叠为严格的单列布局（w-full、px-4、py-8）。

MOTION_INTENSITY（等级 1-10）

1-3（静态）： 不使用自动动画。仅使用 CSS :hover 和 :active 状态。prefers-reduced-motion 本身就是默认模式。
4-7（流畅 CSS）： transition: transform 0.3s cubic-bezier(0.16, 1, 0.3, 1), opacity 0.3s cubic-bezier(0.16, 1, 0.3, 1)（明确列出属性；绝不可使用 transition: all，它还会动画化 GPU 之外的布局属性，参见 6.A）。加载入场时使用级联的 animation-delay。
8-10（高级编排）： 复杂的滚动触发展现、视差效果、滚动驱动动画（CSS animation-timeline 或 GSAP ScrollTrigger）。使用 Motion hooks。绝不可使用 window.addEventListener('scroll')——这是严格禁令，而非“尽量避免”。允许的替代方案见第 5.D 节。

VISUAL_DENSITY（等级 1-10）

1-3（艺术画廊）： 大量留白。区块间距很大（py-32 到 py-48）。质感精致、简洁。
4-7（日常应用）： 标准 Web 应用间距（py-16 到 py-24）。
8-10（驾驶舱）： 紧凑内边距。不使用卡片框；用 1px 线条分隔数据。强制要求：所有数字均使用 font-mono。

8. 深色模式规范

默认支持双模式。除非设计简报要求模拟印刷品的编辑风格，否则绝不假设仅使用浅色模式。

8.A 令牌策略（选择一种并坚持使用）

Tailwind dark: 变体（实用优先项目的默认选择）：每个颜色工具类都配对对应的深色变体（bg-white dark:bg-zinc-950、text-gray-900 dark:text-gray-100）。
CSS 变量（适用于 shadcn/ui、Radix Themes 或带有主题功能的组件库）：定义语义令牌（--surface、--surface-elevated、--text-primary、--accent），并在 [data-theme="dark"] 或 @media (prefers-color-scheme: dark) 下替换其值。

8.B 此处不要规定具体颜色

由简报和品牌决定。本技能仅强制以下要求：

对比度——正文至少达到 WCAG AA 标准，主视觉文案以 AAA 为目标。
层级一致——浅色模式下有效的视觉层级，在深色模式下也必须有效。如果 CTA 在浅色模式下醒目，在深色模式下也要醒目。
忠于品牌——主品牌色应保持可识别。不要为了适配深色模式而降低品牌色的饱和度。
不要使用纯 #000000 或纯 #ffffff——应使用近黑色（zinc-950、接近黑色的暖灰色）和近白色。纯色值会失去层次感。

8.C 默认模式

除非品牌另有要求，否则遵循 prefers-color-scheme。如果任一模式会削弱品牌的关键表达，则添加手动切换开关。

8.D 完成前在两种模式下测试

开发期间，分别在两种模式下打开页面。不要只在一种模式下查看页面就发布。

9. AI 痕迹（禁止使用的模式）

除非简报明确要求，否则避免以下特征。

9.A 视觉与 CSS

**默认情况下禁止使用霓虹色 / 外发光。**应使用内边框或微妙的染色阴影。
**禁止使用纯黑色（#000000）。**使用近黑色、zinc-950 或炭灰色。
**禁止使用过度饱和的强调色。**降低饱和度，使其与中性色协调。
禁止在大型标题中大量使用渐变文字。
**禁止使用自定义鼠标光标。**这种做法过时、不利于无障碍访问，也会影响性能。

9.B 排版

**默认避免使用 Inter。**参见第 4.1 节。可通过覆盖规则使用。
**禁止使用只会大声叫嚷的超大 H1。**通过字重和颜色控制层级，而不是一味放大字号。
**衬线字体限制：**衬线字体适用于编辑、奢华或出版风格，不适用于仪表盘。

9.C 布局与间距

**采用数学上精准的内边距和外边距。**不要让元素悬浮在不协调的间隔中。
**禁止使用三列等宽功能卡片。**禁止使用通用的“三张相同卡片横向排列”功能区。可改用双列交错布局、不对称网格、滚动固定布局或横向滚动布局。

9.D 内容与数据（“Jane Doe”效应）

禁止使用通用姓名。“John Doe”“Sarah Chan”“Jack Su”→改用有创意、真实且符合当地习惯的姓名。
**禁止使用通用头像。**不要使用 SVG“鸡蛋”头像或 Lucide 用户图标→使用可信的照片占位图或专门设计的样式。
**禁止使用虚假完美的数据。**避免 99.99%、50%、1234567。使用自然、不规整的数据（47.2%、+1 (312) 847-1928）。
禁止使用初创公司风格的泛泛品牌名。“Acme”“Nexus”“SmartFlow”“Cloudly”→创作符合情境、高端且听起来真实的名称。
禁止使用空洞的动词。“Elevate”“Seamless”“Unleash”“Next-Gen”“Revolutionize”→只使用具体的动词。

9.E 外部资源与组件

**禁止手工绘制 SVG 图标。**使用 Phosphor / HugeIcons / Radix / Tabler。只有在明确要求时才使用 Lucide。
默认强烈不建议手工绘制装饰性 SVG（参见第 4.8 节）。
**禁止使用基于 div 拼凑的假截图。**不要用 <div> 矩形拼出假的产品界面来模拟截图。应使用真实图片、生成的图片，或省略预览。
**禁止使用失效的 Unsplash 链接。**使用 https://picsum.photos/seed/{descriptive-string}/{w}/{h}、生成的照片占位图或实际素材。
**shadcn/ui 自定义：**允许，但默认状态下绝不可直接使用。应根据项目美学自定义圆角、颜色、阴影和排版。
**达到可用于生产环境的整洁度：**代码应在视觉上整洁、令人印象深刻，并经过细致打磨。

9.F 生产测试中的痕迹（绝对禁止）

这些模式源自真实的 LLM 生成落地页测试。它们是模型试图“做出设计感”时默认采用的特征。除非简报明确要求其中某项，否则一律严格禁止。

主视觉与页面顶部

主视觉中禁止出现版本标签。V0.6、v2.0、BETA、INVITE-ONLY PREVIEW、EARLY ACCESS、ALPHA——默认情况下禁止作为眉题使用。只有当简报明确要求介绍产品发布或预览状态时才可使用。
**禁止使用“品牌名 · No. 01”样式的副眉题。**例如“Marrow · No. 01 · The 6-quart”这类微型元信息行。不要使用。 章节编号与微标签
不要使用带章节编号的眉题。 00 / INDEX、001 · Capabilities、002 · Featured commission、06 · how it works、05 · The honest table 均禁止。眉题应以直白的语言点明主题，而不是列出编号。
不要在图片或便当式布局区块上使用 01 / 4 这类分页标记。 用户数得出来，就不需要标记。
不要使用 Scroll · 001 Capabilities 这类滚动提示。 一个简单的箭头或“Scroll”就够了，不要加章节编号前缀。
不要将 Index of Work, 2018 - 2026 这类范围标签用作眉题。 直接说明章节主题即可。

分隔符与圆点

中点（·）要节制使用。 元数据条中每行最多使用 1 个。不要把它当作所有内容的默认分隔符（“foo · bar · baz · qux · quux”）。如需使用一组分隔符，优先考虑换行、细线或分栏。
不要在每个列表、导航项或徽章前使用装饰性色点。 默认禁止在“ONE Q4 SLOT OPEN”前、每个导航链接前或每个任务行前加彩色圆点。只有圆点确实表示语义状态（例如服务状态或可用性标记），且使用克制时才可接受。

破折号与字体装饰

禁止使用 em dash（—）作为设计元素，也禁止在任何其他地方使用。 完整且不可协商的禁令见下文第 9.G 节。标题、眉题、胶囊标签、正文、引文、署名、说明文字、按钮文字和替代文本中都不得出现 em dash 字符。请使用普通连字符（-）。
不要默认使用通过 <br> 拆行并斜体强调的标题作为“设计手法”。例如“for thirty<br>years.”这类拆分。标题首先应自然流畅，只有在设计要求时才玩创意。
不要使用旋转文字（例如将“INDEX OF WORK, 2018 - 2026”旋转 90°）。这是代理机构作品集的陈词滥调。只有在设计要求明确指向代理机构、Awwwards 或实验性风格，且旋转文字确实有助于构图时，才可使用。
不要将十字线或细线网格用于装饰。 仅仅为了让页面“看起来有设计感”而绘制的纵横线一律禁止。只有在用于组织实际内容时才可使用。

虚假的产品预览

不要在首屏使用基于 div 的虚假产品界面（用样式化 div 搭建的虚假任务列表、虚假终端或虚假仪表盘）。这是 LLM 设计痕迹中最明显的一种。请使用真实截图、生成图像、真实组件预览，或完全不使用。
不要在虚假截图中添加虚假的版本页脚（例如“v0.6.2-rc.1”“last sync 4s ago · main”）。毫无意义，还会暴露出 AI 生成的痕迹。

营销文案痕迹

不要使用“Quietly in use at”或“Quietly trusted by”这类社交证明标题。 请使用自然表达，例如“Trusted by”“Used at”“Customers include”；如果 Logo 已足够说明问题，也可以完全省略标题。
不要在引文、博客或侧边栏板块使用“From the field”“Field notes”“Currently on the bench”“On our desks”“Loose plates”这类诗意标签。 这显得刻意卖弄匠人气质。请使用直白的功能性标签（如“Testimonials”“Latest writing”“Now working on”），或省略标签。
不要在正文中使用“We respect the French ones”这类假谦逊的行业引用。 这类表达刻意卖俏，也很像 AI 写的。
除非设计要求明确围绕某个地点、时区分布式工作室，否则不要在页眉或页脚使用天气或地点信息条（例如“LIS 14:23 · 18°C”）。
不要在眉题下方添加微型元数据句。 例如放在章节标题下方的“Each of these is a feature we ship today, not a roadmap promise. The list will stay short on purpose.”这类句子只会造成杂乱。眉题、标题和正文已经足够。
不要使用通用步骤标签。 禁止使用“Stage 1 / Stage 2 / Stage 3”“Step 1 / Step 2 / Step 3”“Phase 01 / Phase 02 / Phase 03”“Pass One / Pass Two / Pass Three”。实际步骤内容本身就是标签。如果必须展示流程，请直接使用“Install”“Configure”“Ship”这类动词加名词的表达，而不要写成“Stage 1: Install”。 胶囊、标签和版本标记
图片上不得叠加胶囊、标签或标记。 不要在照片上用带有 Brand · 02、PLATE · BRAND、Field notes - journal 等标签的 <span> 叠层。要么让图片本身传达内容，要么在图片正下方添加说明文字（放在图片之外）。
不得将照片署名说明作为装饰。 在图库／picsum 图片下方添加 Field study no. 12 · Ines Caetano、Plate 03 · House archive、Frame XII · 35mm 之类的文字，显得矫揉造作。只有在照片确有摄影师且已获得许可时，才允许署名。否则，省略说明文字，或使用一行功能性说明（“6 夸脱容量，鼠尾草绿。”）。
营销页面不得在页脚标注版本信息。 v1.4.2、Build 0048、last sync 4s ago · main 之类的页脚文字属于 CLI／开发工具占位内容，不应出现在着陆页内容中。营销／着陆／作品集页面一律禁止。
不得将“Reservation 412 of 800”这类实时库存计数作为装饰。 只有在需求明确规定为数据真实的限量发售候补名单时才可使用。

装饰性文字条

主视觉底部不得添加装饰性文字条。 像 BRAND. MOTION. SPATIAL.、TYPE / FORM / MOTION、DESIGN · BUILD · SHIP、ESTD. 2018 · LISBON · BRAND. MOTION. SPATIAL. 这样的横跨主视觉底部的小号等宽大写文字条，是代理机构作品集的陈词滥调。默认禁止。只有在文字条包含真实、可导航的链接（固定底部导航），或真实状态信息（Cookie 横幅、文档站点中的构建信息）时才可使用。
区块标题右上方不得悬浮副文案。 常见模式：区块标题是巨大且左对齐的标题，同一区块标题栏的右上角则悬浮着一小段解释文字，与其他内容没有明确的对齐关系。这种悬浮文字一眼就能看出问题。应将副文案直接放在标题下方，或采用清晰的两栏标题栏（左侧：标题；右侧：对齐的正文），不要把小段文字放在角落。

列表、分隔线和评分

长列表／规格表的每一行不得同时使用 border-t 和 border-b。 选择一种方式（行间底边框，或分组顶部边框），并谨慎使用。每行都加细线的 10 行规格表是最偷懒的布局——替代 UI 组件请参见第 4.9 节。
不得使用带填充背景轨道的评分／进度条作为对比图示。 如需展示“X 项中的 Y 项”这类对比，优先使用数字加小图标，或不带背景轨道的微型行内进度条。在进度条轨道上叠加部分填充的宽大 bg-zinc-200 区块，是着陆页上的仪表盘 UI 杂物。

地区、时间、滚动提示

99% 的需求中，禁止使用地区／城市名称／时间／天气文字条。 主视觉中的“Lisbon, working with founders”、页脚中的“1200-690 Lisbon, Portugal”、导航栏中的“Lisbon 14:23 · 18°C”，都是代理机构作品集的装饰性标志。仅当需求明确说明工作室面向全球且工作与时区相关，或品牌聚焦旅行，或确有实体场所时才可使用。页脚中提及一次联系地址没有问题，但不要使用营造氛围的地区文字条。
禁止使用滚动提示。 Scroll、↓ scroll、Scroll to explore、Scroll to walk through it、动画鼠标滚轮图标等。用户还没有滚动时，看到的就是主视觉。他们知道如何滚动。视口底部不需要标签。
默认不得添加装饰性状态圆点。 导航项、列表行、徽章或状态标签前的彩色圆点都是一眼就能看出的问题。只有在表达真实的语义状态（实际服务器状态的实时指示器、实时可用性标记）时才可使用，并且每个页面区块最多一个。

9.G 禁用 EM-DASH（最常被违反的一条 Tell）

完全禁止使用 EM-DASH（—）。 这是 LLM 标志性的文风拐杖，也是生产测试中最明显的视觉 Tell。没有“有限使用”的例外，没有“符合自然语言频率”的例外，也没有“正文中可以使用”的例外。一个都不行。

标题中禁止使用。 使用句号或逗号。
眉题、标签、胶囊按钮、按钮文本、图片说明和导航项中禁止使用。 改用换行、分栏或细线。
正文中禁止使用。 重新组织句子：拆成两个句子并用句号，或用逗号、括号或冒号。
引文署名中禁止使用。 使用带空格的普通连字符（-），或换行并将姓名设为较细字重。
作为分隔符使用时，也禁止使用 en-dash（–）。 日期范围（2018-2026）使用连字符。数字范围（€40-80k）使用连字符。

页面上唯一允许使用的破折号字符：

普通连字符 -（用于复合词、范围和标记语言中的分隔线）
数学中的负号（-5°C）

如果输出中有任何一个用户可见的 — 或 –，则未通过上线前检查，必须重写。

这条规则不可妥协。过去，Agent 曾忽视“尽量少用”这类表述中的 EM-DASH 限制。这里的要求是非此即彼：一个 EM-DASH 都不能有。

10. 参考词汇（Agent 应了解的模式名称）

这是一份词汇表，不是组件库。Agent 应了解这些模式名称，以便能够讨论它们、在设计时考虑它们，并在设计判断需要时采用它们。实现方式和代码示例位于模块库（第 12 节），并将逐步补充。

Hero 范式

非对称分栏 Hero - 一侧放置文本，另一侧放置素材，留出充足的留白。
编辑宣言式 Hero - 大字号文本，不使用素材，近似海报风格。
视频 / 媒体遮罩 Hero - 将文字镂空作为遮罩，叠加在视频背景上。
动态字体 Hero - 以动画排版为主要视觉元素。
帷幕揭示 Hero - Hero 的各部分在滚动时像帷幕一样揭开。
滚动固定 Hero - Hero 保持固定，内容在其后滚动。

导航与菜单

Mac OS Dock 放大效果 - 边缘导航，悬停时图标平滑放大。
磁吸按钮 - 向光标方向吸附。
黏稠菜单 - 子项像黏稠液体一样分离。
Dynamic Island - 形态变化的状态 / 警报胶囊。
上下文径向菜单 - 在点击位置展开的圆形菜单。
浮动速选菜单 - FAB 以弹簧动效展开为弧形次级操作。
大型菜单揭示 - 全屏下拉菜单，内容依次淡入。

布局与网格

Bento 网格 - 不对称的卡片分组（Apple 控制中心）。
瀑布流布局 - 错落排列的网格，没有固定行高。
色彩网格 - 边框 / 卡片带有微妙的渐变动画。
分屏滚动 - 两个部分朝相反方向滑动。
粘性堆叠分区 - 分区在滚动时固定并堆叠。

卡片与容器

视差倾斜卡片 - 根据鼠标坐标追踪产生 3D 倾斜效果。
聚光边框卡片 - 光标经过时边框发光。
玻璃拟态面板 - 磨砂玻璃质感，带有内部折射效果。
全息箔片卡片 - 悬停时呈现虹彩变化。
Tinder 滑动卡片堆叠 - 实体卡片堆叠，可滑走卡片。
形态变化模态框 - 按钮展开为自己的对话框。

滚动动画

粘性滚动堆叠 - 卡片固定并像实体一样堆叠。
横向滚动接管 - 垂直滚动 → 横向平移。
Locomotive / 序列滚动 - 视频 / 3D 序列与滚动条同步。
缩放视差 - 中央背景图像在滚动时缩放。
滚动进度路径 - SVG 线条沿滚动路径绘制。
液态滑动转场 - 页面转场效果如黏稠液体。

画廊与媒体

穹顶画廊 - 3D 全景画廊。
Coverflow 轮播 - 带倾斜边缘的 3D 轮播。
拖拽平移网格 - 可无限拖动的画布。
手风琴图片滑块 - 悬停时展开的窄条。
悬停图片轨迹 - 鼠标经过时弹出的图片轨迹。
图片故障效果 - 悬停时 RGB 通道偏移。

字体排版与文本

动感跑马灯 - 滚动时反向移动的无尽文本带。
文本蒙版显现 - 巨型文字作为视频的透明窗口。
文本扰乱效果 - 加载或悬停时呈现矩阵风格的解码效果。
圆形路径文字 - 沿旋转圆圈弯曲的文字。
渐变描边动画 - 带流动渐变的描边文字。
动感字体网格 - 字母躲避光标。

微交互与效果

粒子爆炸按钮 - 操作成功时，CTA 碎裂成粒子。
液态下拉刷新 - 像分离水滴一样的重新加载指示器。
骨架屏闪光 - 在占位符上移动的光线反射。
方向感知悬停按钮 - 填充效果从光标所在的准确方向进入。
点击涟漪效果 - 从点击坐标向外扩散的波纹。
SVG 线条动态绘制 - 矢量图实时自行绘制。
网格渐变背景 - 有机的熔岩灯色块。
镜头虚化景深 - 虚化背景 UI，突出前景操作。

动画库选择

Motion（motion/react） - UI、Bento 和状态变化动画的默认选择。
GSAP + ScrollTrigger - 用于整页滚动叙事和滚动劫持。将其隔离在专用的叶节点组件中，并使用 useEffect 清理。
Three.js / WebGL - 用于画布背景和 3D 场景。遵循同样的隔离规则。
绝不要在同一组件树中混用 GSAP / Three.js 与 Motion。 它们会争抢同一帧。

11. 重新设计规范

此技能适用于从零构建和重新设计。错误判断模式是导致重新设计效果不佳的最大原因。

11.A 检测模式（第一步）

从零构建 - 没有现有网站，或已批准全面改版。根据第 1 节设定基准。
重新设计 - 保留 - 在不破坏品牌的前提下进行现代化改造。先审核，提取品牌令牌，逐步演进。
重新设计 - 全面改版 - 在现有内容基础上采用新的视觉语言。视觉上按从零构建处理；保留内容和 IA。

如果情况不明确，只问一次：“这次重新设计应该保留现有品牌，还是从视觉上从头开始？”

11.B 动手前先审核

提出更改方案前，记录当前状态：

品牌令牌 - 主色 / 强调色、字体组合、Logo 处理方式、圆角。
信息架构 - 页面树、主导航、关键转化路径。
内容区块 - 已有内容、发挥作用的内容、填充内容。
需要保留的模式 - 标志性交互、易识别的主视觉、文案风格。
需要淘汰的模式 - AI 套路痕迹、损坏的布局、失效链接、通用图库图片、性能陷阱。
现有网站的设计参数 - 推断当前的 DESIGN_VARIANCE / MOTION_INTENSITY / VISUAL_DENSITY。这是你的起点，而非基准。
SEO 基线 - 当前排名页面、Meta 标题、结构化数据、OG 卡片。SEO 迁移是重新设计的首要风险。

11.C 保留规则

除非用户提出要求，否则不要更改信息架构。 保持页面 slug、锚点 ID 和主导航标签稳定，维护 SEO 和肌肉记忆。
应用第 4.2 节前，先提取品牌颜色。 如果品牌原本就是紫色，就继续保持紫色——应用 LILA 规则的覆盖要求。
除非用户提出要求重写，否则保留文案风格。 视觉现代化 ≠ 内容重写。
保留现有的无障碍优化。 不要破坏焦点状态、替代文本、键盘导航和对比度。
尊重现有分析事件。 不要重命名下游跟踪所依赖的按钮、表单字段或区块 ID。

11.D 现代化杠杆（按优先级排序）

按顺序应用——满足需求后即停止：

字体排版焕新 - 单位风险带来的视觉提升最大。
间距与节奏 - 增加区块内边距，调整垂直节奏。
色彩重新校准 - 降低饱和度，统一中性色，同时保留品牌强调色。
动效层 - 为现有组件添加符合 MOTION_INTENSITY 的微交互。
首屏与关键区块重组 - 使用第 10 节的术语重构漏斗顶部。
完整替换区块 - 仅在现有区块无法挽救时采用。

11.E 决策树：定向演进还是全面重新设计

信息架构、内容和 SEO 状况良好 → 定向演进（杠杆 1-4）。以约 40% 的风险获得约 70% 的价值。
视觉债务属于结构性问题（信息架构混乱、没有设计系统、移动端体验糟糕）→ 全面重新设计，并严格保留内容。
品牌本身正在改变 → 从零开始构建。

11.F 绝不可悄然更改的内容

未经用户明确批准，绝不可修改：

URL 结构 / 路由 slug。
主导航标签。
表单字段名称或顺序（会破坏分析数据和自动填充）。
品牌标志或文字标识。
现有法律声明 / 同意 / Cookie 文案。

12. 区块库（约定 - 在此逐步添加实现）

参考术语表（第 10 节）为模式命名。区块库通过实际 props、实际动效规范和实际代码示例来实现这些模式。

**状态：**此处已定义架构。区块将逐步添加。请勿自行创建新区块，必须遵循此架构。

12.A 文件位置

skills/taste-skill/blocks/
  hero/
    asymmetric-split.md
    editorial-manifesto.md
    kinetic-type.md
    ...
  feature/
    bento-grid.md
    sticky-scroll-stack.md
    zig-zag.md
    ...
  social-proof/
  pricing/
  cta/
  footer/
  navigation/
  portfolio/
  transition/

12.B 必需的 Frontmatter

---
name: asymmetric-split-hero
category: hero
dial_compatibility:
  variance: [6, 10]
  motion: [3, 10]
  density: [2, 5]
when_to_use: "Landing pages with one strong asset and one strong message. Default hero for SaaS, agency, premium consumer."
not_for: "Editorial / manifesto launches where the message IS the design."
stack: ["react", "next", "tailwind", "motion"]
---

12.C 必需的正文部分

视觉示意图 - 简短的 ASCII 图或布局说明。
Props API - 组件接口。
代码示例 - 最小可运行实现（默认使用服务端组件，动效使用客户端岛屿）。
移动端回退方案 - 明确说明 < 768px 时的折叠规则。
动效变体 - 每个 MOTION_INTENSITY 区间对应一个变体（1-3、4-7、8-10）。明确说明减少动态效果时的回退方案。
深色模式说明 - 此区块专属的 token 策略。
反模式 - 此区块常见的错误做法。
参考案例 - 生产环境中真实案例的链接。

12.D 区块库规范

每个文件只包含一个区块。不得在一个文件中放置多个区块。
每个区块都必须能独立运行（放入页面后即可渲染）。
每个区块都必须通过预检（第 14 节）。
依赖第 2.A 节设计系统的区块，存放于 blocks/<category>/<name>--<system>.md 下（例如 feature/bento-grid--material.md）。

13. 不适用范围

此技能不适用于：

仪表板 / 密集型产品 UI / 管理面板（使用第 2.A 节中的 Fluent、Carbon、Atlassian 或 Polaris）。
数据表格（使用 TanStack Table 或 AG Grid）。
多步骤表单 / 向导（使用表单专用模式；此技能无法改善它们）。
代码编辑器（使用 Monaco / CodeMirror 及其官方皮肤）。
原生移动应用（直接使用 Apple HIG / Material）。
实时协作 UI（在线状态、光标、支持 OT - 属于不同的问题类别）。

如果需求属于以上任一类型，请明确说明，指出合适的工具；仅在适用的界面上使用此技能中有关营销页 / 关于页 / 落地页的部分。

14. 最终预检

输出代码前运行此检查矩阵。这是最后一道过滤关。

这不是可选项。请逐项检查。任何一项未通过，都表示输出尚未完成。

附录 - 有真实来源支持的参考资料

以下各节为随附的参考内容。它们为第 2 节中提到的每个设计系统提供真实的安装命令、权威文档链接和可用的入门代码片段。请以此为依据，确保决策符合生产实践，而非训练数据中的臆想。

附录 A - 各设计系统的安装命令

# Material Web (Material 3)
npm install @material/web

# Fluent UI React (v9)
npm install @fluentui/react-components

# Fluent UI Web Components (framework-free)
npm install @fluentui/web-components @fluentui/tokens

# IBM Carbon
npm install @carbon/react @carbon/styles

# Radix Themes
npm install @radix-ui/themes

# shadcn/ui (open code, owned components)
npx shadcn@latest init
npx shadcn@latest add button card badge separator input

# Primer CSS (GitHub product/devtool UI)
npm install --save @primer/css

# Primer Brand (GitHub marketing UI)
npm install @primer/react-brand

# GOV.UK Frontend
npm install govuk-frontend

# USWDS (US Web Design System)
npm install uswds

# Atlassian Design System (Atlaskit)
yarn add @atlaskit/css-reset @atlaskit/tokens @atlaskit/button @atlaskit/badge @atlaskit/section-message @atlaskit/card

# Bootstrap 5.3
npm install bootstrap

# Shopify Polaris Web Components (Shopify apps only)
# Add this to your app HTML head:
#   <meta name="shopify-api-key" content="%SHOPIFY_API_KEY%" />
#   <script src="https://cdn.shopify.com/shopifycloud/polaris.js"></script>

附录 B - 权威来源（重新发明之前请先阅读）

Material Web

Fluent UI

Carbon

Shopify Polaris

Atlassian

Primer

GOV.UK

USWDS

Bootstrap

Tailwind

Radix

shadcn/ui

原生 CSS / W3C 标准

Apple Liquid Glass（仅限 Apple 平台）

附录 C - Apple Liquid Glass：诚实的 Web 近似实现

不要将随意的 CSS 代码片段视为 Apple 官方的 Liquid Glass 实现。

什么是官方内容

Apple 在《Human Interface Guidelines》和面向 Apple 平台的开发者文档中介绍了 Liquid Glass。它是一种用于 Apple 平台 UI 的动态材质。Apple 的原生实现属于 Apple 平台 API 和系统组件，不是公开的 Web CSS 包。

什么不是官方内容

Apple 并未为普通网站提供 liquid-glass.css。

Web 近似效果可以使用：

backdrop-filter
透明背景
分层边框
高光叠加层
渐变
动效
高对比度回退方案

但这属于 Web 磨砂玻璃效果近似实现，并非 Apple 官方 Liquid Glass。请在注释中将其标注为近似实现。

更安全的 Web 近似实现框架

.liquid-glass-web-approx {
  position: relative;
  isolation: isolate;
  overflow: hidden;
  border-radius: 999px;
  border: 1px solid rgb(255 255 255 / .32);
  background:
    linear-gradient(135deg, rgb(255 255 255 / .30), rgb(255 255 255 / .08)),
    rgb(255 255 255 / .12);
  backdrop-filter: blur(24px) saturate(180%) contrast(1.05);
  -webkit-backdrop-filter: blur(24px) saturate(180%) contrast(1.05);
  box-shadow:
    inset 0 1px 0 rgb(255 255 255 / .48),
    inset 0 -1px 0 rgb(255 255 255 / .12),
    0 18px 60px rgb(0 0 0 / .18);
}

.liquid-glass-web-approx::before {
  content: "";
  position: absolute;
  inset: 0;
  z-index: -1;
  border-radius: inherit;
  background:
    radial-gradient(circle at 20% 0%, rgb(255 255 255 / .55), transparent 34%),
    linear-gradient(90deg, rgb(255 255 255 / .18), transparent 42%, rgb(255 255 255 / .14));
  pointer-events: none;
}

.liquid-glass-web-approx::after {
  content: "";
  position: absolute;
  inset: 1px;
  border-radius: inherit;
  border: 1px solid rgb(255 255 255 / .14);
  pointer-events: none;
}

@media (prefers-color-scheme: dark) {
  .liquid-glass-web-approx {
    border-color: rgb(255 255 255 / .18);
    background:
      linear-gradient(135deg, rgb(255 255 255 / .16), rgb(255 255 255 / .04)),
      rgb(15 23 42 / .42);
    box-shadow:
      inset 0 1px 0 rgb(255 255 255 / .22),
      0 18px 60px rgb(0 0 0 / .42);
  }
}

@media (prefers-reduced-transparency: reduce) {
  .liquid-glass-web-approx {
    background: rgb(255 255 255 / .96);
    backdrop-filter: none;
    -webkit-backdrop-filter: none;
  }
}

重要： prefers-reduced-transparency 在不同浏览器中的支持并不一致，请进行测试。即使没有模糊效果，也始终要确保对比度足够。

附录结束。 上方的安装命令是实际依据。Apple Liquid Glass 框架是已注明的近似实现，并非 Apple 发布的包。要查看各设计系统的权威文档，请参阅该系统的官方文档（链接见第 2 节和附录 B）。

支持 Markdown

登录后评论