sheleg-design

SHELEG 设计

概述

页面之所以有电影感，并非因为动画很多，而是因为由单一事实来源（测得的滚动位置）驱动许多开销低、分层、可独立降级的响应。将滚动状态集中到一个存储中；各层每帧读取它，并以自己的方式响应。没有任何内容交叉淡化——元素会重新部署。每一层都能降级为平静的静态状态。

首先阅读，以下所有内容均以此为前提： CREATIVE_DIRECTOR.md — 决策层：界面的用途，以及什么情况能证明它失败；设计方向和模式（重新设计从衡量被替换的内容开始，更新则修改一个令牌）；如何通过 npx sshlg-skills pack design --lane <lane> 衡量并选用工具；何时分成两个工具阵容互不重叠的变体，并先写好评估标准；将对齐度和可衡量的质量作为两个独立问题；以及记录所有这些内容的设计总监记录。Agent 进行设计时的失败模式不是丑陋，而是看似合理，而这份文档会拒绝这种结果。

**必读参考资料——电影感设计路径：**在实现滚动驱动页面之前，阅读 SHELEG_DESIGN.md — 架构、形变数学、DOM↔WebGL 桥接、构建流程（§11）和文件映射。 产品界面工作无需阅读此文档；但有一条规则会在此重申：当工具包的动效令牌与 SHELEG 默认值不同时，以工具包为准。

**制作任何动画前必读：**阅读 MOTION_DOCTRINE.md。SHELEG_DESIGN.md 说明如何构建动效；动效准则则说明是否应该构建动效——其中的频率表会禁用高重复路径上的动画，缓动树和 ease-in 禁令、时长上限、禁止形式，以及减少动态效果的约定。

提出任何无障碍声明前必读：阅读 ACCESSIBILITY_EVIDENCE.md — 声明依据的标准（带编号、版本、级别、单位和例外情况的 WCAG 标准，或平台启发式规则），截图能证明或不能证明 DOM 和辅助技术哪些方面，以及判定约定：缺少工具时为 NOT_RUN，绝不能是 PASS，且任何检查都不得安装扫描器来完成自身检查。 这种关联是按范围限定，而非通过路由器转发：设计工艺门槛中的对比度行和渲染评审会在各自声明的范围内使用这些判定——这属于现有能力，无需新增路由器或入口。质量凭证会将两类行分开：视觉评判（渲染效果如何）与 WCAG 符合性（注明所依据标准、范围明确的计算检查）。而在评审中修复的渲染，必须在有预算上限的范围内，使用相同的前后对照矩阵进行评判（CREATIVE_DIRECTOR.md）；尚未解决的观察结果仍应保持未解决，不能改称已交付。仅凭一瞥无法得出符合性结论——若凭证中出现这种结论，就会被拒绝，因为“看起来无障碍”不过是借用了标准名称的截图声明。

触发词

“build a landing page” / “сделай лендинг”、“design a landing” / “дизайн лендинга”、“mobile screen” / “мобильный экран”、“dashboard style” / “стиль дашборда, сделай дашборд, админка”、“scroll animation” / “скролл-анимация, анимации”、“design tokens, style pack” / “дизайн-токены”、“light/dark theme” / “светлая/тёмная тема”、“figma variables” / “переменные фигмы, фигма в код, макеты”、“palette, colors” / “палитра, цвета”、“typography, font” / “типографика, шрифт”、“how it looks, make it prettier” / “выглядит, красиво, красивее”、“visual reference” / “визуальные референсы”、“investor deck as a web page” / “веб-презентация”、“redesign” / “редизайн, свёрстай, вёрстка”。

适用场景

• 以动态效果为明确目标的落地页／营销页／主视觉页；与滚动联动的粒子或 WebGL 背景（3D 引擎：web3d-dev）；与滚动联动的图表、分步流程、轨道、视差效果
• 现有滚动页面显得紧张、卡顿或不同步
• 需要固定视觉系统的产品 UI——仪表板、管理后台、内部／开发工具、令牌、浅色／深色模式——仅使用 style-pack，通过 workbench
• AI 产品界面：聊天和 Agent UI、流式输出、运行日志、模型错误、生成内容和确认状态（AI_PRODUCT_PATTERNS.md）
• 通过 Figma 边界迁移视觉系统（FIGMA_BRIDGE.md）
• 需要将动态效果导出为渲染文件——发布视频、功能循环视频、社交媒体剪辑（MOTION_PRODUCTION.md），其中会点名两种程序化视频工具

切勿将电影感动态效果层应用于： 产品 UI、文档站点、静态内容站点，或视觉系统和文案尚未完成的任何页面。产品 UI 只采用 style-pack 部分，不采用其他内容。

核心模式——五项原则，依序执行

1. 统一时钟。 所有动态效果都基于同一个经过测量的滚动状态；任何图层都不自行测量滚动，因此图层之间永远不会不同步。
2. 逐帧读取，少量通知。 高频使用者（WebGL／canvas／轨道）以命令式方式读取存储，不触发框架渲染；只有粗粒度的动作／章节变化才通知框架。
3. 先保持，再重新部署。 在一个章节中保持约 80% 的队形，然后以短促、错开相位、沿弧线弯曲的波形进行变形。禁止交叉淡化。
4. 让动态效果有据可依。 只有能随时间叙述状态的仪表才使用滚动控制；悬停和按下效果须处于规范规定的区间内，入场效果经测量后可以超出区间，但两者都不能成为内容的门槛。
5. 降级为平静模式。 减少动态效果／粗略指针／不支持 WebGL 时，都应退化为静态且完全易读的页面。效果只是锦上添花，绝不能成为依赖项。

风格包

视觉识别来自风格包。选择前，请阅读风格包索引；然后完整阅读选定的风格包，并从 styles/tokens/<pack>.css 复制其令牌层。不要转录令牌表，也不要根据截图推断数值。

生成的工具包会提供组件状态：

npx sheleg-design-skill --kit <pack>

生成的 src/styles.css 是核心风格包未定义状态的权威依据。扩展风格包的工具包必须与其 ## Components 部分保持一致。如果无法访问 npx——没有 node 或注册表——也不会因此受阻：选定的风格包及其 styles/tokens/<pack>.css 中的令牌层仍可通过阅读提供规则，但只有工具包才能生成的组件状态此时属于未经验证——应明确说明，而不要将直接读取的状态说成经工具包检查。要编写风格包，请从 styles/STYLE_PACK_TEMPLATE.md 开始，并在同一次更改中提交其令牌文件。

校准——先明确可观察目标，再用数值简写

风格包回答的是采用哪种风格，而不是程度如何。即使使用同一个风格包，面向受监管的保险公司和设计工作室的两个落地页，也不是同一个页面。

首要约定是为此场景设定一组可观察目标——第二位读者可以在渲染结果中核查的内容：阅读宽度、无需滚动超出所属首屏即可触达的 CTA、同时可见的备选项数量、键盘状态的呈现方式，以及每一处刻意留白的用途。同一份简报中的两位独立执行者，必须能够通过相同的可观察锚点解释密度或变化程度——单独一个数字做不到，因此，没有锚点的数字不能作为依据。

三个数值可作为可选简写，表达相同意图——它们是偏好提示，不是质量衡量标准（摘自 Leonxlnx/taste-skill，MIT，声明）：

• DESIGN_VARIANCE 1–10——1 表示完全对称，10 表示刻意采用不对称设计，且各个版块各不相同。
• MOTION_INTENSITY 1–10——1 表示静态，10 表示具有电影感和实体感。
• VISUAL_DENSITY 1–10——1 表示画廊墙，10 表示驾驶舱。

基准值为 7 / 5 / 4。 开始制作前，先说明这些数值并用一句话阐明理由；不要要求用户编辑文件，也不要悄悄偏离已说明的数值。每个已说明的数值都应附带一个正例或反例（“密度 5——类似风格包自带的仪表盘参考，而不是营销页主视觉”），或者在首次渲染后根据已接受的方向得出——在任何内容都不存在之前就定下的数字毫无约束力。相同数字并不能让不同平台任务趋于一致：安静的仪表盘、面向消费者的聊天界面，以及采用大号无障碍文本的界面，都可以标注密度 5，却需要呈现出三种不同的渲染结果，因为它们的锚点各不相同。此外，用户明确提出的要求优先于基准值和任何风格下限——这些数值用于调整默认设置，绝不会凌驾于简报之上。令牌约定保持不变（数值取自风格包）；在此约定内的构图仍有开放选择，这些提示仅供参考，并非评分尺度。

根据简报判定数值

简报描述	VARIANCE	MOTION	DENSITY
极简、平和、编辑风、“像 Linear 一样安静”	5–6	3–4	2–3
高端消费品牌、以品牌为主导、“感觉很昂贵”	7–8	5–7	3–4
代理机构、作品集、实验性、追逐奖项	9–10	7–9	3–4
落地页／营销页，没有其他信号	7	5	4
产品 UI：仪表盘、管理后台、内部工具	4–5	2–3	6–8
以信任为先：受监管领域、公共部门、临床场景	3–4	2–3	4–5
演示文稿	5–6	1–2	3–4
重新设计，保留现有品牌形象	匹配	匹配	匹配
重新设计，明确要求全面改版	+2	+2	匹配

若同时符合两行且数值不一致——界面类型优先于氛围；风格取向仅在动态和装饰方面优先；频率表限制 MOTION_INTENSITY 的上限： CALIBRATION.md。

工艺标准——按顺序定义“完成”

当任何人都能通过提示词做出原型时，工艺就是唯一剩下的差异化因素。背景：设计师对这个词（WORD）对自己的含义进行排序（Figma，《State of the Designer 2026》，n=906，一项关联调查 — https://www.figma.com/blog/state-of-the-designer-2026/）：视觉润色 58% · 深思熟虑的问题解决 47% · 清晰直观的 UX 36% · 情感与愉悦感 35% · 一致性 15%。**这些百分比表示某个定义被选中的频率——58% 证明的是调查中的关联，而非因果效应或工作顺序。**以下关卡顺序源自依赖关系（只有前一关成立，后一关才有意义），是本套件自行制定的决策，而非研究结论：

1. 任务——简报中提到的核心工作确实可用。如果简报中的主要任务有问题，应先修复该任务，无论设计令牌是否完美。
2. 状态——流程和状态已确定；如果尚未确定，就停下来先做决定（结构是 super-ux 的一半）。
3. 可用性——界面能够使用：键盘、对比度、文本缩放——这是本系列委托处理、且绝不跳过的环节。
4. 系统——视觉决策集中在一处（令牌层、SCENES 注册表），其他所有内容都从那里读取。
5. 润色——无一例外地应用本套件：使用令牌，而非字面值；差异中任何地方都不应有临时添加的十六进制颜色、圆角或字号。
6. 情感——只使用有依据的动效（原则 4），绝不以牺牲第 1–5 项为代价。
7. 一致性——在每个屏幕上都使用同一种缓动、一套时长、一个强调色，以及每种用途一个原子组件。

按需加载——套件层不负责决定的内容

• 场景深度——六个层次（SURFACE_COMPOSITION.md），在为电影感页面编写 CSS 之前阅读。所有内容都在同一平面上，是任何缓动都无法弥补的问题。

• 图表——角色约定与 dataviz 交接说明，位于同一文件中；在任何套件中绘制图表之前阅读。各套件的令牌名称并不统一，未定义的自定义属性会静默回退，而不会报错。

• 移动端界面（MOBILE_SURFACES.md）——适用于简报要求原生应用屏幕或移动 Web 视图的情况，而非只需折叠内容的桌面页面。文档要求将平台目标与原型渲染器分开，不接受浏览器模型作为原生体验的证明，并补充第六条规则——这是任何套件都未涵盖的规则：字号比例应随视口宽度变化，而非随用户的文本大小设置变化。

• 布局与字体工艺（LAYOUT_CRAFT.md，TYPE_CRAFT.md）——在组织页面或设置字号比例之前阅读。可移植的部分：通过观察得出，绝不靠调节——未经校准的轴值只是一个无人能核验的数字。

• 视觉审查（VISUAL_REVIEW.md）——在接受截图或渲染后的副本之前阅读。先核验画面，再根据项目政策检查可见文本。

• 视觉底线（SLOP_MARKERS.md）——发布之前阅读，无论是否使用套件：标记要有理由和例外，其中包括三种默认外观。npx sheleg-design-skill --lint <dir> 会检查机器可检测的部分。

• 总监记录与奖项标准（templates/director-record.md，ADA_RUBRIC.md）——旗舰作品渲染之前阅读；使用 --check-record <file> 检查。

• 知识来源（KNOWLEDGE_PROVENANCE.md）——当某条规则受到质疑或被复制时阅读。

设定视觉语言——不变量已锁定，方向轴仍开放

在保留品牌的前提下设定或修订视觉语言时，先按照 VISUAL_EXPLORATION.md 中的流程划分：锁定不变量（品牌色、徽标、无障碍要求）与开放方向轴（构图、字体层级、控件结构、动效目的）；对于尚未明确的简报，渲染两到三个方向；对于明确的决策，只渲染一个方向——而精确复现 Figma 设计时不生成任何方向。仅有现成的令牌文件，并不能让任何方向自动封闭。

在多个方案包之间做选择——实际挂载，不要凭空想象

当多个方案包都可能适用于某个产品时，不要争论，直接渲染出来。

将候选方案包挂载到现有且已有内容的页面上——使用真实的页眉、真实的数据和真实的信息密度——通过 ?variant=<pack> 搜索参数切换，并在浏览器中对比。只有令牌层会改变，标记不变。

使用占位内容的临时路由就像真空：每个方案包看起来都不错，也正因如此，它什么都无法确定。如果确实还没有已有内容的页面，那么现在做选择还为时过早——先根据简报所指向的风格基调，为页面采用相应的方案包；等页面有了真实内容后再重新评估。如果简报完全没有提供线索，产品 UI 默认使用 workbench，营销页面默认使用 showroom：两者都足够克制，之后切换只需调整布局，无须改变产品身份。（以前的说法是“默认方案包”，却没有指定具体方案，这算不上后备方案。）

挂载遵循语义令牌契约。 各方案包的令牌名称并不统一，因此对比时绝不直接替换原始 CSS：每个方案包的令牌文件都以 @adapter 区块结尾，将十个语义角色（--sem-surface、--sem-surface-raised、--sem-text、--sem-text-muted、--sem-line、--sem-primary、--sem-on-primary、--sem-positive、--sem-caution、--sem-negative）映射到该方案包自己的令牌；如果方案包没有对应概念，则将角色声明为 @absent。任何角色若既未映射，也未声明，都会在渲染前阻止对比，因为未定义的自定义属性不会报错，只会静默回退——而基于静默回退进行的对比，比较的其实是回退值。这里不意味着可以直接替换 CSS：组件仍使用各方案包自己的令牌。

对比记录的内容，以及何时整个对比尚未就绪： STYLE_PACK_INDEX.md。

对比脚手架不是交付物：记录决策的同一项变更中，也要将它移除。

AI 驱动的产品界面

AI 界面并非普通界面：大模型会流式输出，有时也会出错，而界面必须如实呈现这两种情况。流式状态、置信度、引用、纠正和拒绝的呈现方式统一收录于 AI_PRODUCT_PATTERNS.md。产品中包含大模型时，请加载该文档。

组件层 — 风格包决定令牌，组件套件负责渲染

风格包是令牌层和一组规则，不包含按钮。 因此，每个产品 UI 都需要做出第二项决策，而风格包刻意不替你做出这项决策：由哪个组件套件来绘制控件。

默认使用 shadcn/ui，每个项目只需回答一次这个问题。 像 ux-foundation 提出 Figma 问题那样来询问——只在设计工作开始时询问一次，绝不针对每个屏幕重复询问——并将答案记录在风格包的记录处：安装了 super-ux 时，记录在屏幕记录的 Design system 一行；未安装时，则记录在任何用于记录风格包的文件中。默认答案为是；已有组件层的项目已经做出选择，单纯因为偏好而迁移组件层不属于设计决策。

它与组件套件组合使用，而非相互竞争，问题出在映射上：未定义的自定义属性会静默回退，而令牌重映射只是六个维度之一——因此，仅映射颜色的组件套件仍会呈现其初始外观。工作机制及具体由谁负责： COMPONENT_LAYER.md。

适用边界 — 产品 UI，而非沉浸式表层。 仪表板、管理面板、内部工具、聊天和 Agent 界面：都适用，默认答案也是肯定的。滚动驱动的落地页：不适用——那里没有可复用的控件，制作工作是定制滚动效果和 WebGL，使用组件套件只会让主视觉区看起来像设置页面。

可选 — Figma（设计 ↔ 代码）

操作 Figma 文件——将风格包发布为变量，或基于设计进行构建——请从 FIGMA_BRIDGE.md 开始。它规定了约定，以及打开工具前必须了解的一条规则：设计师和利益相关者会查看画框，因此在其中绘制就是发布；创建文件时必须指定明确的目标位置，不能靠猜。

可选 — Claude Design（design-sync）

如果可以使用 /design-sync，就能将风格包推送到 claude.ai/design，让设计 Agent 基于此风格包的令牌构建，而非使用自身的默认值。约定及其未涵盖的部分：DESIGN_SYNC_BRIDGE.md。

真实案例参考（Refero、Lazyweb、Mobbin）

风格包确定的是外观，而非优质屏幕应包含什么。新的设计或品牌重设计应先调研真实产品——关注内容和结构，绝不照搬视觉效果（DESIGN_SYNC_BRIDGE.md §4）；如果没有调研结果，也要记录。

应用风格包及反复出现的错误

确定风格包和校准后，工作的开展顺序及常见失败清单： APPLYING.md。