design-exploration

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Design Exploration

设计探索

Generate N distinct design variants for a given component, page, or section. Each variant takes a fundamentally different visual direction. Present all for comparison, then fully implement the chosen one.

为指定的组件、页面或区块生成N种差异化设计变体。每个变体采用完全不同的视觉方向。展示所有变体供用户比较，然后完整实现用户选定的方案。

When to Trigger

触发场景

1. New project

1. 新项目

The user is bootstrapping a frontend from scratch. No existing design system -- the variants define it.

用户从零开始搭建前端，没有现成的设计系统——变体将定义该系统。

2. Existing app

2. 现有应用

The user has an established design language and wants multiple approaches for a new or existing component, section, or page. Every variant must stay consistent with the app's existing patterns and tokens.

用户已有成熟的设计语言，希望为新的或现有组件、区块或页面提供多种设计方案。所有变体必须与应用现有模式和设计令牌保持一致。

Bypass: Detailed design spec provided

跳过场景：提供详细设计规范

If the user provides exact fonts, colors, hex values, border radii, and specific styling instructions -- skip Phase 2 entirely. This is an implementation request, not an exploration request. Do not suggest alternatives or inject creative direction. Read each target file, preserve all logic, apply exactly the specified changes. Go directly to Phase 3.

如果用户提供了精确的字体、颜色、十六进制值、圆角半径和具体样式说明——直接跳过阶段2。这属于实现需求，而非探索需求。请勿提供替代方案或注入创意方向。阅读每个目标文件，保留所有逻辑，严格按照指定要求修改，直接进入阶段3。

Phase 1: Research

阶段1：调研

Before designing anything:

Read the existing code -- understand every component, import, animation, and logic in the target files.
Study the design language -- globals.css, tailwind config, component library, existing patterns (spacing, colors, typography, card styles).
Identify constraints -- what must NOT change: data, logic, API calls, routing, state management.
Understand the content model -- what data is displayed, edge cases (long text, many items, empty states).
Check assets -- verify images, icons, and assets exist with correct formats (transparency, resolution, aspect ratio). If assets need preprocessing (background removal, format conversion), handle that before building variants on top of them.
Look beyond the brief -- find data values available in the codebase but not currently displayed, existing assets that could be repurposed, values that could be visualized differently (charts, progress bars, indicators instead of plain text), opportunities for grouping or layering information.

在开始设计前：

阅读现有代码——理解目标文件中的每个组件、导入项、动画和逻辑。
研究设计语言——globals.css、tailwind config、组件库、现有模式（间距、色彩、排版、卡片样式）。
识别约束条件——哪些内容绝对不能修改：数据、逻辑、API调用、路由、状态管理。
理解内容模型——展示的数据类型、边缘情况（长文本、多条目、空状态）。
检查资源——验证图片、图标等资源是否存在且格式正确（透明度、分辨率、宽高比）。如果资源需要预处理（移除背景、格式转换），需在生成变体前完成。
挖掘额外可能性——查找代码库中已存在但未展示的数据值、可重新利用的现有资源、可可视化呈现的数据（图表、进度条、指示器替代纯文本）、信息分组或分层的机会。

Phase 2: Generate Variants

阶段2：生成变体

Create exactly the number requested (default: 5). Determine mode automatically based on project state -- do not ask.

严格生成用户要求的数量（默认：5种）。根据项目状态自动判断模式，无需询问用户。

Mode A: New Project

模式A：新项目

No existing design system to follow.

Research broadly -- search for design approaches across disciplines: product design, editorial, print, architecture, fashion branding, game UI, packaging. Do not rely on memorized style lists.
Analyze context -- product purpose, audience, intended mood. A trading app has different needs than a portfolio.
If context is insufficient, ask -- what is the product, who is it for, what feeling should it evoke. Exception: if the user explicitly wants broad exploration, skip this.
Select styles optimal for this project -- each must be a plausible direction for this exact product, not a showcase of range. Respect explicit style exclusions as hard constraints. Do NOT fall into deterministic patterns of always picking the same style families.
Maximize diversity -- every variant must differ in spatial thinking, typographic voice, and emotional register. Not "same layout, different colors."

无现成设计系统可遵循。

广泛调研——跨领域搜索设计方案：产品设计、编辑设计、印刷设计、建筑、时尚品牌、游戏UI、包装设计。请勿依赖记忆中的固定风格列表。
分析场景——产品用途、受众、预期氛围。交易类应用与作品集应用的需求截然不同。
场景信息不足时询问——产品是什么、目标用户是谁、想要传递何种感受。例外情况：如果用户明确要求广泛探索，则跳过此步骤。
选择适配项目的风格——每个变体都必须是该产品的合理设计方向，而非风格展示。将用户明确排除的风格视为硬性约束。请勿陷入重复选择相同风格类别的固定模式。
最大化多样性——每个变体必须在空间布局、排版风格和情感基调上存在差异，而非“相同布局，不同颜色”。

Mode B: Existing App

模式B：现有应用

Established styles, tokens, components, and patterns exist.

Study the design system first -- globals.css, tailwind config, theme tokens, color palette, typography, spacing, animation conventions, border radii, card styles.
The app's style is the baseline -- all variants must be consistent with the existing system. You are exploring different layouts and compositions, not different design systems.
Vary structure, not identity -- differ in layout, information hierarchy, component composition, animation approach, and density. Do NOT differ in font families, color palette, or border radius unless the user explicitly asks for a style refresh.
Align with surrounding UI -- match sizing, spacing, and alignment of adjacent elements. If next to a button, match its height. If inside a card grid, follow the same padding and gap.
Style change escape hatch -- if the user explicitly asks for a style change, break from the existing system. Treat it closer to Mode A but use the current app as context.

已有成熟的样式、令牌、组件和模式。

优先研究设计系统——globals.css、tailwind config、主题令牌、调色板、排版、间距、动效规范、圆角半径、卡片样式。
以应用风格为基准——所有变体必须与现有系统保持一致。探索的是不同布局和构图方式，而非不同的设计系统。
调整结构，而非品牌调性——在布局、信息层级、组件组合、动效方案和密度上做出差异。除非用户明确要求风格更新，否则请勿修改字体族、调色板或圆角半径。
与周边UI对齐——匹配相邻元素的尺寸、间距和对齐方式。如果紧邻按钮，需匹配按钮高度；如果位于卡片网格内，需遵循相同的内边距和间距。
风格变更例外——如果用户明确要求风格变更，则可突破现有系统限制。处理方式接近模式A，但需以当前应用为上下文。

Required Differentiation

强制差异化要求

Each variant MUST differ across ALL of these axes:

Axis	Mode A (New)	Mode B (Existing)
Typography	Different font pairing per variant	Use app fonts; vary weight, size, hierarchy
Color	Different accent, background, contrast approach	Use app palette; vary application and emphasis
Layout	Grid vs. list vs. asymmetric vs. card-based vs. dense vs. airy	Different arrangement within app conventions
Mood	Distinct personality per variant, discovered through research	Distinct compositional approach, shared personality
Border/radius	Sharp vs. rounded vs. pill vs. mixed	Use app's existing radius
Motion	Different animation philosophy	Different choices within app motion conventions
Background	Solid vs. gradient vs. texture vs. pattern vs. atmospheric	Use app patterns; vary section treatments

每个变体必须在以下所有维度上存在差异：

维度	模式A（新项目）	模式B（现有应用）
排版	每个变体使用不同的字体组合	使用应用字体；调整字重、字号、层级结构
色彩	不同的强调色、背景色、对比度方案	使用应用调色板；调整色彩应用和强调方式
布局	网格式 vs. 列表式 vs. 非对称式 vs. 卡片式 vs. 紧凑式 vs. 宽松式	在应用规范内调整不同排列方式
氛围	每个变体具有独特的个性，源于调研	不同的构图方式，保持一致的品牌个性
边框/圆角	尖锐 vs. 圆润 vs. 胶囊形 vs. 混合样式	使用应用现有圆角
动效	不同的动画设计理念	在应用动效规范内做出不同选择
背景	纯色 vs. 渐变 vs. 纹理 vs. 图案 vs. 氛围感背景	使用应用图案；调整区块处理方式

Variant Rules

变体规则

No AI slop -- no generic purple-on-white, no Inter/Roboto/Arial defaults, no cookie-cutter card grids, no Space Grotesk convergence across sessions.
No gimmick styles by default -- never select neo-brutalism, terminal/hacker, retro-CRT, or vaporwave unless the user explicitly requests it. Default to styles that could ship in production.
Simplicity is valid -- if the user asks for simple/clean/minimal, deliver exactly that. Clean typography, generous whitespace, conventional layout. No decorative elements, no effects.
Responsive required -- every variant must work on mobile. Use
```
prefers-reduced-motion
```
and touch-friendly interactions.
Cross-browser safe -- avoid bleeding-edge CSS that breaks in Safari or Firefox.
Mock data only -- use realistic mock data covering edge cases. Do NOT wire up real API calls or state management during exploration. That happens in Phase 3.

拒绝AI通用化设计——避免通用的紫白配色、默认使用Inter/Roboto/Arial字体、千篇一律的卡片网格、不同会话中重复使用Space Grotesk字体。
默认不使用噱头风格——除非用户明确要求，否则绝不选择新粗野主义、终端/黑客风、复古CRT或蒸汽波风格。默认采用可投入生产的风格。
简约风格有效——如果用户要求简洁/干净/极简风格，严格按照要求交付。采用清晰的排版、充足的留白、常规布局，避免装饰元素和特效。
必须支持响应式——每个变体必须适配移动端。使用
```
prefers-reduced-motion
```
和适合触控的交互方式。
跨浏览器兼容——避免使用在Safari或Firefox中无法正常运行的前沿CSS特性。
仅使用模拟数据——变体阶段使用真实感模拟数据覆盖边缘情况。真实API调用和状态管理在阶段3实现。

Variant Presentation

变体展示

For each variant, provide:

Name -- short and evocative (e.g., "Ember", "Signal", "Nocturne")
Description -- 2-3 sentences on the aesthetic direction and why it fits
Key choices -- fonts, accent color, layout approach, motion style
What changed -- if the variant introduces new data, repurposes assets, restructures information, or deprioritizes existing data, state it explicitly
Full implementation -- working code with mock data

Implement a simple switching mechanism so the user can cycle through variants in the browser (e.g., a small floating selector, query param, or keyboard shortcut). The user must be able to compare all variants side by side or toggle between them without touching code.

每个变体需包含：

名称——简短且有辨识度（例如：“Ember”、“Signal”、“Nocturne”）
描述——2-3句话说明美学方向及适配原因
核心选择——字体、强调色、布局方案、动效风格
变更说明——如果变体引入了新数据、重新利用了资源、重构了信息或降低了某些数据的优先级，需明确说明
完整实现代码——包含模拟数据的可运行代码

实现简单的切换机制，让用户可在浏览器中循环查看变体（例如：悬浮选择器、查询参数、键盘快捷键）。用户必须能够无需修改代码即可并排比较所有变体或在变体间切换。

If All Variants Are Rejected

所有变体均被拒绝时的处理

Ask what went wrong -- style direction, layout, quality, or everything.
Ask for a reference -- website, app, Dribbble shot, screenshot.
Offer 1-2 targeted variants based on feedback, not another blind batch.
If "just make it simple" -- drop exploration. One clean, conservative design.

询问问题所在——风格方向、布局、质量还是全部不符合预期。
请求参考示例——网站、应用、Dribbble作品、截图。
根据反馈提供1-2个针对性变体，而非再次生成批量通用变体。
如果用户要求“只需简单设计”——停止探索，交付一个简洁、保守的设计方案。

Phase 3: Implementation

阶段3：实现

Once the user picks a variant:

Delete all other variants -- clean up completely:
- Search for remaining variant references, conditionals, and selection logic
- Check for orphaned files, unused imports, unused CSS classes
- Run the build to verify no broken imports
- The codebase should look like the selected variant was the only implementation
Wire up real data -- replace all mock data with real API calls, state management, and logic.
Preserve all existing functionality -- every import, handler, and logic piece from the original must survive. Only visual styling changes.
Read before writing -- always read current file content before overwriting. Never work from memory.
Verify animations -- use GPU-accelerated properties (
```
transform
```
,
```
opacity
```
) instead of layout-triggering ones (
```
top
```
,
```
left
```
,
```
width
```
,
```
height
```
). Use
```
ease-out
```
for entrances,
```
ease-in-out
```
for state changes. If an animation looks janky, simplify it.
Test responsive -- verify at mobile, tablet, and desktop breakpoints.
Verify no regressions -- run build/lint if available. Check all imports resolve.

用户选定变体后：

删除所有其他变体——彻底清理：
- 查找残留的变体引用、条件判断和选择逻辑
- 检查孤立文件、未使用的导入项、未使用的CSS类
- 运行构建命令验证无导入错误
- 代码库应看起来像是选定变体是唯一的实现方案
接入真实数据——将所有模拟数据替换为真实API调用、状态管理和逻辑。
保留所有现有功能——原始代码中的每个导入项、处理函数和逻辑必须保留。仅修改视觉样式。
先读后写——在覆盖文件前务必先阅读当前文件内容。切勿凭记忆修改。
验证动效——使用GPU加速属性（
```
transform
```
、
```
opacity
```
）而非触发重排的属性（
```
top
```
、
```
left
```
、
```
width
```
、
```
height
```
）。入场动效使用
```
ease-out
```
，状态切换使用
```
ease-in-out
```
。如果动画出现卡顿，需简化处理。
测试响应式——在移动端、平板端和桌面端断点验证效果。
验证无回归问题——如果有构建/检查工具，运行相关命令。确保所有导入项均可正常解析。

Aesthetic Standards

美学标准

These apply to every variant in every mode.

Typography -- pair a distinctive display font with a refined body font. Never default to system fonts or overused families. Each variant uses a different pairing (Mode A) or different weight/hierarchy treatment (Mode B).

Color -- commit to a dominant color with sharp accents. Timid, evenly-distributed palettes look undesigned. Use CSS variables for consistency.

Motion -- one well-orchestrated entrance sequence (staggered reveals, animation-delay) creates more impact than scattered micro-interactions. Prioritize page load and scroll-triggered moments over hover effects.

Spatial composition -- vary layouts meaningfully: asymmetry, overlap, diagonal flow, grid-breaking elements, controlled density, or generous negative space. Avoid defaulting to centered card grids.

Background and depth -- create atmosphere through gradient meshes, noise textures, geometric patterns, layered transparencies, or dramatic shadows. Solid white/gray backgrounds are a last resort, not a default.

Anti-convergence -- never converge on the same font, color scheme, or layout pattern across variants or across sessions. Each generation should feel curated by a different creative director.

以下标准适用于所有模式下的所有变体。

排版——将独特的标题字体与精致的正文字体搭配。切勿默认使用系统字体或过度使用的字体族。每个变体使用不同的字体组合（模式A）或不同的字重/层级处理方式（模式B）。

色彩——确定主导色和鲜明的强调色。模糊、均匀分布的调色板会显得缺乏设计感。使用CSS变量保证一致性。

动效——一个精心编排的入场序列（ staggered reveals、animation-delay）比零散的微交互更有冲击力。优先处理页面加载和滚动触发的动效，而非 hover 效果。

空间构图——有意义地调整布局：非对称、重叠、对角线流动、打破网格的元素、可控的密度或充足的留白。避免默认采用居中卡片网格。

背景与层次感——通过渐变网格、噪点纹理、几何图案、分层透明度或富有张力的阴影营造氛围。纯白/灰色背景是最后选择，而非默认方案。

避免趋同——在不同变体或不同会话中，绝不使用相同的字体、配色方案或布局模式。每次生成的变体应感觉像是由不同创意总监策划的。

Critical Constraints

关键约束

All data must be accounted for -- every value and metric from the original must appear in every variant. Display format may change (text to chart, number to progress bar), but nothing is silently dropped. If a variant deliberately omits or deprioritizes a data point, it MUST be called out in the variant description.
No placeholder content -- mock data during variants, real data in final implementation.
File completeness -- write the ENTIRE file. No "rest remains the same" comments.
Font imports -- update layout/entry file imports when changing fonts (next/font/google, @font-face, etc.).
Design tokens -- update CSS variables/theme tokens to match the chosen variant. Do not hardcode colors inline when the app uses a token system.

所有数据必须保留——原始内容中的每个数值和指标必须在所有变体中呈现。展示格式可调整（文本转图表、数字转进度条），但不得静默删除任何内容。如果变体刻意省略或降低某些数据的优先级，必须在变体描述中明确说明。
无占位内容——变体阶段使用模拟数据，最终实现使用真实数据。
文件完整性——编写完整文件内容。不得使用“其余内容不变”的注释。
字体导入——更换字体时需更新布局/入口文件的导入项（next/font/google、@font-face等）。
设计令牌——更新CSS变量/主题令牌以匹配选定变体。当应用使用令牌系统时，不得内联硬编码颜色值。