Lightdash Data App 前端设计指南如何在沙箱约束下打造具有鲜明设计风格的生产级界面【免费下载链接】lightdashAgentic BI. Analytics at the speed of code ⚡️项目地址: https://gitcode.com/GitHub_Trending/li/lightdash导读本文基于 Lightdash 数据应用Data App沙箱模板中的frontend-design技能文档展开系统讲解在lightdash/query-sdk React Tailwind 的受控环境里如何设计并实现一眼可辨、拒绝 AI 通用审美的生产级前端界面。你将掌握以设计思维驱动视觉方向的完整方法、五维前端美学准则排版、色彩、动效、空间构成、背景细节的落地要点以及在此沙箱特有的 CSP 与明暗主题约束下webfont 不可用、必须跟随宿主 Lightdash 的 light/dark 模式如何正确使用系统字体栈、CSS 变量与语义化主题令牌。文中所有结论均以 sandboxes/data-apps/template 模板中的真实文件为佐证。一、技能定位frontend-design在 Data App 生成管线中的角色sandboxes/data-apps/template是 Claude Code 在构建数据应用时写入代码的项目模板也是生产环境中 E2B 沙箱的基础镜像。模板 README 明确了生成管线skill.md user prompt → Claude Code → writes into src/ → vite build → dist/其中skill.md是追加给 Claude Code 的系统提示词描述可用的依赖包、预置组件、沙箱封锁规则以及所连接 Lightdash 项目的语义层上下文。而 frontend-design 技能文档 正是被skill.md在 Visual Design 一节显式引用、用于驱动应用视觉方向的关键技能——模板原文明确写道Use thefrontend-designskill before writing any UI code. It drives the aesthetic direction — pick a distinctive look forthisapp rather than defaulting to generic shadcn-on-dark-mode.也就是说frontend-design负责这个应用长什么样而skill.md负责数据查询、SDK 用法与平台契约。技能文档的目标用户是构建网页组件、页面或应用时的生成 Agent其产出物必须满足生产级、可用、视觉上令人印象深刻且令人难忘、审美观点连贯、每个细节都经过精雕细琢。二、设计思维Design Thinking编码之前先确立大胆的视觉方向技能文档强调在写任何代码之前先理解上下文并承诺一个 BOLD大胆的审美方向。它给出四个必须回答的问题维度要回答的问题Purpose 目的这个界面解决什么问题使用者是谁Tone 基调选定一个极端方向例如极简brutally minimal、极繁混乱maximalist chaos、复古未来retro-futuristic、有机/自然organic/natural、奢华精致luxury/refined、玩趣playful/toy-like、编辑/杂志editorial/magazine、粗野主义brutalist/raw、装饰艺术/几何art deco/geometric、柔和粉彩soft/pastel、工业/功利industrial/utilitarian等。文档同时强调这些只是灵感来源最终应设计出一个忠于所选方向的专属风格。Constraints 约束技术需求框架、性能、可访问性。Differentiation 差异化什么让这个界面令人难忘人们会记住的那一件事是什么文档给出了一条关键准则原文加粗强调Choose a clear conceptual direction and execute it with precision. Bold maximalism and refined minimalism both work — the key is intentionality, not intensity.选择一个清晰的概念方向并精确执行。大胆的极繁与克制的极简都成立——关键在于有意为之而非强度堆砌。确定方向后再实现可运行的代码HTML/CSS/JS、React、Vue 等要求生产级、可正常运作、视觉上醒目且令人印象深刻、具备连贯的审美立场、每个细节都被精心打磨。三、前端美学五维准则Frontend Aesthetics Guidelines技能文档将界面美学拆解为五个可执行的维度这也是文章的核心骨架3.1 排版Typography—— 系统字体栈的个性表达这是本技能中最具沙箱特色的约束在此沙箱中 webfont 无法加载。应用 iframe 的 CSP 会拦截外部样式表因此 Google Fonts 的import或注入的link会在运行时失败并静默回退永远不要输出 webfont 引入代码。正确的做法是从本就在场的字体中构建有性格的排版用ui-serif/ Georgia 作为展示性标题压在一个朴素的 sans 正文字体上用ui-monospace呈现数据与标签营造数据感需要玩趣感时用ui-rounded通过字重对比、字号跳变、letter-spacing、small-caps小型大写、大小写来制造反差。文档给出的示例组合Georgia 标题 等宽字体标签Georgia-headline-over-mono-labels读起来就像经过设计。同时要求在多次生成之间轮换不同的字体配对避免所有产物千篇一律。模板佐证skill.md 的 Visual Design 一节重申了这一 CSP 约束并补充了同样的要求Never emit one. Distinctive typography here comes from expressive system-stack pairings与技能文档完全一致。3.2 色彩与主题Color Theme—— 用 CSS 变量保证一致性致力于一个连贯的美学方向使用CSS 变量保持一致性主色 锐利强调色的组合优于小心翼翼、均匀分布的平庸调色板Dominant colors with sharp accents outperform timid, evenly-distributed palettes。在 Lightdash 数据应用模板中色彩令牌的真实载体是 src/index.css:root与.dark两个块分别定义了--background、--foreground、--card、--popover、--primary、--muted、--accent、--destructive、--border、--chart-1~--chart-5等全套 oklch 颜色值。模板在main.jsx中强制先导入./index.css与./chart-overrides.css再导入./App并注释说明原因:root与.dark特异性相等后出现者生效——若应用自行导入的样式表覆盖了二者之一就会把应用钉死在单一模式下。3.3 动效Motion—— 高冲击时刻优先用动画实现效果与微交互HTML 场景优先纯 CSS 方案React 场景在可用时使用 Motion 库模板依赖中可见lucide-react的Loader2animate-spin即是轻量动画示例聚焦高冲击时刻一次精心编排的页面加载、带animation-delay的 staggered reveals交错显现比散落的微交互更能带来愉悦感使用滚动触发scroll-triggering与出人意料的 hover 状态。3.4 空间构成Spatial Composition—— 拒绝网格呆板出人意料的布局不对称Asymmetry、重叠Overlap、对角线流动Diagonal flow、打破网格的元素Grid-breaking elements要么慷慨留白generous negative space要么受控密度controlled density。3.5 背景与视觉细节Backgrounds Visual Details—— 营造氛围与深度不要默认使用纯色背景要为页面营造氛围与层次应用与整体美学匹配的上下文效果与纹理渐变网格gradient meshes、噪点纹理noise textures、几何图案geometric patterns、多层透明度layered transparencies、戏剧性阴影dramatic shadows、装饰边框decorative borders、自定义光标custom cursors、颗粒覆盖层grain overlays。四、红线清单永远不要使用通用 AI 审美技能文档明确列出NEVER清单所有内容都使用平淡无奇的默认无衬线字体栈俗套的配色方案特别是白色背景上的紫色渐变可预测的布局与组件模式缺乏上下文特色、千篇一律的饼干模具设计。同时要求创造性解读做出真正为上下文而设计的选择任何两次生成的设计都不应相同在浅色/深色主题、不同字体、不同美学之间主动变化永远不要收敛到常见选择例如 Space Grotesk 字体上。五、复杂度匹配原则让实现强度与美学愿景对齐技能文档给出了一条重要的工程判断准则IMPORTANTMatch implementation complexity to the aesthetic vision. Maximalist designs need elaborate code with extensive animations and effects. Minimalist or refined designs need restraint, precision, and careful attention to spacing, typography, and subtle details.即极繁设计需要大量动画与效果来支撑其代码复杂度极简/精致设计则需要克制、精确并在间距、排版与细微细节上倾注心力。优雅来自把愿景执行到位Elegance comes from executing the vision well而不是盲目堆砌。六、仓库源码佐证约束从何而来令牌如何生效6.1 CSP 与明暗模式的平台契约skill.md 提供了技能文档之外最关键的运行约束佐证宿主决定明暗模式Lightdash 在应用启动及用户切换主题时通过把darkclass 放在html上通知应用。应用必须同时保证:root完整浅色值与.dark完整深色值两套令牌任何classNamedark …、手动向html添加dark、在:root放深色值都会把应用钉死在单一模式——对另一半观众而言就是坏掉了。内联样式的陷阱style{{ background: #0f0d17 }}这类内联十六进制色值同样会把应用钉死因为内联样式绕过了 Tailwind 与令牌体系。文档明确指出inline styles are the most common way this rule gets broken内联样式是此规则最常见的破坏方式。正确写法是var(--background)/var(--foreground)或使用工具类。CSS 变量存完整颜色禁止hsl(var(--x))包裹模板令牌是oklch(…)原始值所有消费方Tailwind 工具类、浮动表面 chrome、自定义 CSS都以var(--x)读取。不要写裸的H S% L%三元组也不要写hsl(var(--x))——这两种写法来自另一种 shadcn 约定在此模板中会产生被浏览器静默丢弃的非法 CSS。6.2 图表配色必须来自CHART_COLORSsrc/lib/theme.ts 导出了 9 个图表色令牌CHART_COLORS[0..8]底层为chart-overrides.css中定义的--chart-1~--chart-9镜像原生 Lightdash 图表调色板。规则是多系列图表按索引循环CHART_COLORS[i % CHART_COLORS.length]单系列用CHART_COLORS[0]——确保生成应用的图表与原生 Lightdash 仪表盘视觉一致。frontend-design自选的强调色、背景色、字体色与此相互独立。6.3 语义化 shadcn 令牌与浮动表面 chrome界面骨架surface、文字、边框必须使用语义化令牌bg-background、bg-card、text-foreground、text-muted-foreground、text-destructive、border等禁止硬编码 hex浮动表面DropdownMenuContent、PopoverContent、DialogContent以及自定义 Recharts tooltip 外层的视觉 chrome 由模板托管——chart-overrides.css会把--background向--foreground混合保证在深浅两种主题下都有对比度。因此不要给浮动表面添加bg-*、border-*、shadow-*或内联背景/边框/阴影样式自定义 Recharts tooltip 必须用 src/lib/floating.tsx 导出的ChartTooltipSurface包裹否则 tooltip 是裸的、无样式的 div在图表上呈透明状darkclass 必须留在html上由 Lightdash 设置Radix 门户渲染到document.body应用内部的div classNamedark装不住门户化的菜单/弹窗/popover浮动表面会漏到另一种模式去如需在 JS 中读取当前模式唯一受支持的方式是useColorScheme()light | dark宿主切换时重渲染。禁止从 DOM 自行推导document.documentElement.classList.contains(dark)只在首帧正确、之后永久过期也禁止用matchMedia((prefers-color-scheme))那报告的是操作系统的偏好从第一帧就是错的。6.4 令牌重定义的落点index.css而不是新样式表src/main.jsx 的导入顺序是index.css→chart-overrides.css→App。由于:root与.dark特异性相等、后声明者胜出若把浅色值拆到组件导入的styles/theme.css而把.dark留在index.css两套令牌就会顺序错乱导致应用被钉死在一侧。正确做法是就地编辑index.css中已有的:root与.dark块并让二者始终保持完整确需独立文件时必须把两个块都完整搬入且不得重排main.jsx中的导入顺序。6.5 与相邻技能的协同sdk-features 技能 中的follow-host-theme能力与本文主题直接相关SDK 会把darkclass 放到html上因此通过令牌风格化一切的应用无需任何代码即可跟随宿主主题旧应用需要做的往往是反向操作——移除钉死单模式的东西去掉 shell 上的classNamedark …、把深色值从:root移入.dark、保证两套令牌完整。模板还提供 reusable-visualization 技能构建宿主喂数据、自身不发起查询的可复用可视化。skill.md特别指出可复用可视化没有页面外壳来承载bg-background text-foreground应把令牌放到图表自身的根元素上跟随宿主配色是平台契约对可复用可视化同样生效。七、落地清单将技能转化为可审查的输出综合技能文档与模板约束一次合格的生成应通过以下自检设计方向先行编码前已明确 Purpose / Tone / Constraints / Differentiation并选定一个可被精确执行的审美方向零 webfont全文无 Google Fontsimport或link字体个性全部来自系统栈配对令牌驱动所有 surface、文字、边框使用语义化 shadcn 令牌自定义主题色只改index.css中的:root/.dark块两套完整且在步调上保持一致无内联 hex、无hsl(var(--x))包裹、无 JS 分支配色双模式正确浅色与深色下文字可读、表面保持对比、无颜色在对方模式下隐形图表配色合规系列颜色来自CHART_COLORS按索引循环浮动表面不越权不给 DropdownMenuContent / PopoverContent / DialogContent 加背景/边框/阴影自定义 tooltip 用ChartTooltipSurface包裹复杂度匹配愿景极繁设计有足够的动画与细节支撑极简设计以克制与精确取胜差异化可感知产物不是默认无衬线堆砌、不是紫色渐变白底、不是可预测布局两次生成之间方向有变化。结语frontend-design技能解决的是数据应用生成管线中最难量化的一环在不引入任何外部资源、且必须同时适配宿主明暗主题的沙箱里做出有立场、有记忆点、生产可用的界面。它的方法论先定方向、五维准则、红线清单、复杂度匹配与 Lightdash 模板的令牌体系index.css双模式 oklch 令牌、CHART_COLORS图表色、ChartTooltipSurface浮动表面互为表里前者提供审美判断后者保证设计在平台契约内不会退化为风格化的 bug。对任何在受限 iframe 环境中做数据类前端的人来说这套用系统字体栈构建个性、用语义令牌承载主题、用动效与空间制造记忆点的组合都是一份可以直接复用的工程范式。【免费下载链接】lightdashAgentic BI. Analytics at the speed of code ⚡️项目地址: https://gitcode.com/GitHub_Trending/li/lightdash创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Lightdash Data App 前端设计指南：如何在沙箱约束下打造具有鲜明设计风格的生产级界面
Lightdash Data App 前端设计指南如何在沙箱约束下打造具有鲜明设计风格的生产级界面【免费下载链接】lightdashAgentic BI. Analytics at the speed of code ⚡️项目地址: https://gitcode.com/GitHub_Trending/li/lightdash导读本文基于 Lightdash 数据应用Data App沙箱模板中的frontend-design技能文档展开系统讲解在lightdash/query-sdk React Tailwind 的受控环境里如何设计并实现一眼可辨、拒绝 AI 通用审美的生产级前端界面。你将掌握以设计思维驱动视觉方向的完整方法、五维前端美学准则排版、色彩、动效、空间构成、背景细节的落地要点以及在此沙箱特有的 CSP 与明暗主题约束下webfont 不可用、必须跟随宿主 Lightdash 的 light/dark 模式如何正确使用系统字体栈、CSS 变量与语义化主题令牌。文中所有结论均以 sandboxes/data-apps/template 模板中的真实文件为佐证。一、技能定位frontend-design在 Data App 生成管线中的角色sandboxes/data-apps/template是 Claude Code 在构建数据应用时写入代码的项目模板也是生产环境中 E2B 沙箱的基础镜像。模板 README 明确了生成管线skill.md user prompt → Claude Code → writes into src/ → vite build → dist/其中skill.md是追加给 Claude Code 的系统提示词描述可用的依赖包、预置组件、沙箱封锁规则以及所连接 Lightdash 项目的语义层上下文。而 frontend-design 技能文档 正是被skill.md在 Visual Design 一节显式引用、用于驱动应用视觉方向的关键技能——模板原文明确写道Use thefrontend-designskill before writing any UI code. It drives the aesthetic direction — pick a distinctive look forthisapp rather than defaulting to generic shadcn-on-dark-mode.也就是说frontend-design负责这个应用长什么样而skill.md负责数据查询、SDK 用法与平台契约。技能文档的目标用户是构建网页组件、页面或应用时的生成 Agent其产出物必须满足生产级、可用、视觉上令人印象深刻且令人难忘、审美观点连贯、每个细节都经过精雕细琢。二、设计思维Design Thinking编码之前先确立大胆的视觉方向技能文档强调在写任何代码之前先理解上下文并承诺一个 BOLD大胆的审美方向。它给出四个必须回答的问题维度要回答的问题Purpose 目的这个界面解决什么问题使用者是谁Tone 基调选定一个极端方向例如极简brutally minimal、极繁混乱maximalist chaos、复古未来retro-futuristic、有机/自然organic/natural、奢华精致luxury/refined、玩趣playful/toy-like、编辑/杂志editorial/magazine、粗野主义brutalist/raw、装饰艺术/几何art deco/geometric、柔和粉彩soft/pastel、工业/功利industrial/utilitarian等。文档同时强调这些只是灵感来源最终应设计出一个忠于所选方向的专属风格。Constraints 约束技术需求框架、性能、可访问性。Differentiation 差异化什么让这个界面令人难忘人们会记住的那一件事是什么文档给出了一条关键准则原文加粗强调Choose a clear conceptual direction and execute it with precision. Bold maximalism and refined minimalism both work — the key is intentionality, not intensity.选择一个清晰的概念方向并精确执行。大胆的极繁与克制的极简都成立——关键在于有意为之而非强度堆砌。确定方向后再实现可运行的代码HTML/CSS/JS、React、Vue 等要求生产级、可正常运作、视觉上醒目且令人印象深刻、具备连贯的审美立场、每个细节都被精心打磨。三、前端美学五维准则Frontend Aesthetics Guidelines技能文档将界面美学拆解为五个可执行的维度这也是文章的核心骨架3.1 排版Typography—— 系统字体栈的个性表达这是本技能中最具沙箱特色的约束在此沙箱中 webfont 无法加载。应用 iframe 的 CSP 会拦截外部样式表因此 Google Fonts 的import或注入的link会在运行时失败并静默回退永远不要输出 webfont 引入代码。正确的做法是从本就在场的字体中构建有性格的排版用ui-serif/ Georgia 作为展示性标题压在一个朴素的 sans 正文字体上用ui-monospace呈现数据与标签营造数据感需要玩趣感时用ui-rounded通过字重对比、字号跳变、letter-spacing、small-caps小型大写、大小写来制造反差。文档给出的示例组合Georgia 标题 等宽字体标签Georgia-headline-over-mono-labels读起来就像经过设计。同时要求在多次生成之间轮换不同的字体配对避免所有产物千篇一律。模板佐证skill.md 的 Visual Design 一节重申了这一 CSP 约束并补充了同样的要求Never emit one. Distinctive typography here comes from expressive system-stack pairings与技能文档完全一致。3.2 色彩与主题Color Theme—— 用 CSS 变量保证一致性致力于一个连贯的美学方向使用CSS 变量保持一致性主色 锐利强调色的组合优于小心翼翼、均匀分布的平庸调色板Dominant colors with sharp accents outperform timid, evenly-distributed palettes。在 Lightdash 数据应用模板中色彩令牌的真实载体是 src/index.css:root与.dark两个块分别定义了--background、--foreground、--card、--popover、--primary、--muted、--accent、--destructive、--border、--chart-1~--chart-5等全套 oklch 颜色值。模板在main.jsx中强制先导入./index.css与./chart-overrides.css再导入./App并注释说明原因:root与.dark特异性相等后出现者生效——若应用自行导入的样式表覆盖了二者之一就会把应用钉死在单一模式下。3.3 动效Motion—— 高冲击时刻优先用动画实现效果与微交互HTML 场景优先纯 CSS 方案React 场景在可用时使用 Motion 库模板依赖中可见lucide-react的Loader2animate-spin即是轻量动画示例聚焦高冲击时刻一次精心编排的页面加载、带animation-delay的 staggered reveals交错显现比散落的微交互更能带来愉悦感使用滚动触发scroll-triggering与出人意料的 hover 状态。3.4 空间构成Spatial Composition—— 拒绝网格呆板出人意料的布局不对称Asymmetry、重叠Overlap、对角线流动Diagonal flow、打破网格的元素Grid-breaking elements要么慷慨留白generous negative space要么受控密度controlled density。3.5 背景与视觉细节Backgrounds Visual Details—— 营造氛围与深度不要默认使用纯色背景要为页面营造氛围与层次应用与整体美学匹配的上下文效果与纹理渐变网格gradient meshes、噪点纹理noise textures、几何图案geometric patterns、多层透明度layered transparencies、戏剧性阴影dramatic shadows、装饰边框decorative borders、自定义光标custom cursors、颗粒覆盖层grain overlays。四、红线清单永远不要使用通用 AI 审美技能文档明确列出NEVER清单所有内容都使用平淡无奇的默认无衬线字体栈俗套的配色方案特别是白色背景上的紫色渐变可预测的布局与组件模式缺乏上下文特色、千篇一律的饼干模具设计。同时要求创造性解读做出真正为上下文而设计的选择任何两次生成的设计都不应相同在浅色/深色主题、不同字体、不同美学之间主动变化永远不要收敛到常见选择例如 Space Grotesk 字体上。五、复杂度匹配原则让实现强度与美学愿景对齐技能文档给出了一条重要的工程判断准则IMPORTANTMatch implementation complexity to the aesthetic vision. Maximalist designs need elaborate code with extensive animations and effects. Minimalist or refined designs need restraint, precision, and careful attention to spacing, typography, and subtle details.即极繁设计需要大量动画与效果来支撑其代码复杂度极简/精致设计则需要克制、精确并在间距、排版与细微细节上倾注心力。优雅来自把愿景执行到位Elegance comes from executing the vision well而不是盲目堆砌。六、仓库源码佐证约束从何而来令牌如何生效6.1 CSP 与明暗模式的平台契约skill.md 提供了技能文档之外最关键的运行约束佐证宿主决定明暗模式Lightdash 在应用启动及用户切换主题时通过把darkclass 放在html上通知应用。应用必须同时保证:root完整浅色值与.dark完整深色值两套令牌任何classNamedark …、手动向html添加dark、在:root放深色值都会把应用钉死在单一模式——对另一半观众而言就是坏掉了。内联样式的陷阱style{{ background: #0f0d17 }}这类内联十六进制色值同样会把应用钉死因为内联样式绕过了 Tailwind 与令牌体系。文档明确指出inline styles are the most common way this rule gets broken内联样式是此规则最常见的破坏方式。正确写法是var(--background)/var(--foreground)或使用工具类。CSS 变量存完整颜色禁止hsl(var(--x))包裹模板令牌是oklch(…)原始值所有消费方Tailwind 工具类、浮动表面 chrome、自定义 CSS都以var(--x)读取。不要写裸的H S% L%三元组也不要写hsl(var(--x))——这两种写法来自另一种 shadcn 约定在此模板中会产生被浏览器静默丢弃的非法 CSS。6.2 图表配色必须来自CHART_COLORSsrc/lib/theme.ts 导出了 9 个图表色令牌CHART_COLORS[0..8]底层为chart-overrides.css中定义的--chart-1~--chart-9镜像原生 Lightdash 图表调色板。规则是多系列图表按索引循环CHART_COLORS[i % CHART_COLORS.length]单系列用CHART_COLORS[0]——确保生成应用的图表与原生 Lightdash 仪表盘视觉一致。frontend-design自选的强调色、背景色、字体色与此相互独立。6.3 语义化 shadcn 令牌与浮动表面 chrome界面骨架surface、文字、边框必须使用语义化令牌bg-background、bg-card、text-foreground、text-muted-foreground、text-destructive、border等禁止硬编码 hex浮动表面DropdownMenuContent、PopoverContent、DialogContent以及自定义 Recharts tooltip 外层的视觉 chrome 由模板托管——chart-overrides.css会把--background向--foreground混合保证在深浅两种主题下都有对比度。因此不要给浮动表面添加bg-*、border-*、shadow-*或内联背景/边框/阴影样式自定义 Recharts tooltip 必须用 src/lib/floating.tsx 导出的ChartTooltipSurface包裹否则 tooltip 是裸的、无样式的 div在图表上呈透明状darkclass 必须留在html上由 Lightdash 设置Radix 门户渲染到document.body应用内部的div classNamedark装不住门户化的菜单/弹窗/popover浮动表面会漏到另一种模式去如需在 JS 中读取当前模式唯一受支持的方式是useColorScheme()light | dark宿主切换时重渲染。禁止从 DOM 自行推导document.documentElement.classList.contains(dark)只在首帧正确、之后永久过期也禁止用matchMedia((prefers-color-scheme))那报告的是操作系统的偏好从第一帧就是错的。6.4 令牌重定义的落点index.css而不是新样式表src/main.jsx 的导入顺序是index.css→chart-overrides.css→App。由于:root与.dark特异性相等、后声明者胜出若把浅色值拆到组件导入的styles/theme.css而把.dark留在index.css两套令牌就会顺序错乱导致应用被钉死在一侧。正确做法是就地编辑index.css中已有的:root与.dark块并让二者始终保持完整确需独立文件时必须把两个块都完整搬入且不得重排main.jsx中的导入顺序。6.5 与相邻技能的协同sdk-features 技能 中的follow-host-theme能力与本文主题直接相关SDK 会把darkclass 放到html上因此通过令牌风格化一切的应用无需任何代码即可跟随宿主主题旧应用需要做的往往是反向操作——移除钉死单模式的东西去掉 shell 上的classNamedark …、把深色值从:root移入.dark、保证两套令牌完整。模板还提供 reusable-visualization 技能构建宿主喂数据、自身不发起查询的可复用可视化。skill.md特别指出可复用可视化没有页面外壳来承载bg-background text-foreground应把令牌放到图表自身的根元素上跟随宿主配色是平台契约对可复用可视化同样生效。七、落地清单将技能转化为可审查的输出综合技能文档与模板约束一次合格的生成应通过以下自检设计方向先行编码前已明确 Purpose / Tone / Constraints / Differentiation并选定一个可被精确执行的审美方向零 webfont全文无 Google Fontsimport或link字体个性全部来自系统栈配对令牌驱动所有 surface、文字、边框使用语义化 shadcn 令牌自定义主题色只改index.css中的:root/.dark块两套完整且在步调上保持一致无内联 hex、无hsl(var(--x))包裹、无 JS 分支配色双模式正确浅色与深色下文字可读、表面保持对比、无颜色在对方模式下隐形图表配色合规系列颜色来自CHART_COLORS按索引循环浮动表面不越权不给 DropdownMenuContent / PopoverContent / DialogContent 加背景/边框/阴影自定义 tooltip 用ChartTooltipSurface包裹复杂度匹配愿景极繁设计有足够的动画与细节支撑极简设计以克制与精确取胜差异化可感知产物不是默认无衬线堆砌、不是紫色渐变白底、不是可预测布局两次生成之间方向有变化。结语frontend-design技能解决的是数据应用生成管线中最难量化的一环在不引入任何外部资源、且必须同时适配宿主明暗主题的沙箱里做出有立场、有记忆点、生产可用的界面。它的方法论先定方向、五维准则、红线清单、复杂度匹配与 Lightdash 模板的令牌体系index.css双模式 oklch 令牌、CHART_COLORS图表色、ChartTooltipSurface浮动表面互为表里前者提供审美判断后者保证设计在平台契约内不会退化为风格化的 bug。对任何在受限 iframe 环境中做数据类前端的人来说这套用系统字体栈构建个性、用语义令牌承载主题、用动效与空间制造记忆点的组合都是一份可以直接复用的工程范式。【免费下载链接】lightdashAgentic BI. Analytics at the speed of code ⚡️项目地址: https://gitcode.com/GitHub_Trending/li/lightdash创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
