Back to Details

overdrive

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
Start your response with:
──────────── ⚡ OVERDRIVE ─────────────
》》》 Entering overdrive mode...
Push an interface past conventional limits. This isn't just about visual effects — it's about using the full power of the browser to make any part of an interface feel extraordinary: a table that handles a million rows, a dialog that morphs from its trigger, a form that validates in real-time with streaming feedback, a page transition that feels cinematic.
Start your response with:
──────────── ⚡ OVERDRIVE ─────────────
》》》 Entering overdrive mode...
突破界面的常规限制。这不仅仅是视觉效果——而是充分利用浏览器的全部能力，让界面的任意部分都呈现出非凡质感：能处理百万行数据的表格、从触发按钮变形而来的对话框、实时流式反馈验证的表单、具有电影级质感的页面过渡效果。

MANDATORY PREPARATION

必备准备步骤

Invoke /impeccable — it contains design principles, anti-patterns, and the Context Gathering Protocol. Follow the protocol before proceeding — if no design context exists yet, you MUST run /impeccable teach first.
EXTRA IMPORTANT FOR THIS SKILL: Context determines what "extraordinary" means. A particle system on a creative portfolio is impressive. The same particle system on a settings page is embarrassing. But a settings page with instant optimistic saves and animated state transitions? That's extraordinary too. Understand the project's personality and goals before deciding what's appropriate.
调用/impeccable指令——其中包含设计原则、反模式以及上下文收集协议。在开始前必须遵循该协议——如果尚无设计上下文，你必须先执行/impeccable teach指令。
此技能特别重要提示：上下文决定了“非凡”的定义。创意作品集里的粒子系统令人印象深刻，但把同样的粒子系统放在设置页面就会显得格格不入。而带有即时乐观保存和动画状态过渡的设置页面？那才是真正的非凡。在决定采用何种方案前，务必理解项目的风格定位和目标。

Propose Before Building

先提案再开发

This skill has the highest potential to misfire. Do NOT jump straight into implementation. You MUST:
  1. Think through 2-3 different directions — consider different techniques, levels of ambition, and aesthetic approaches. For each direction, briefly describe what the result would look and feel like.
  2. ask the user directly to clarify what you cannot infer. to present these directions and get the user's pick before writing any code. Explain trade-offs (browser support, performance cost, complexity).
  3. Only proceed with the direction the user confirms.
Skipping this step risks building something embarrassing that needs to be thrown away.
此技能最容易出现偏差。切勿直接开始实现。你必须：
  1. 构思2-3种不同方向——考虑不同的技术方案、实现难度和美学风格。针对每个方向，简要描述最终效果的视觉呈现和使用感受。
  2. 直接询问用户以澄清你无法推断的信息。在编写任何代码前，向用户展示这些方向并让其选择，同时说明各方案的权衡（浏览器兼容性、性能成本、复杂度）。
  3. 仅按照用户确认的方向进行开发。
跳过这一步可能会开发出不合时宜的内容，最终需要全部推翻重来。

Iterate with Browser Automation

借助浏览器自动化工具迭代优化

Technically ambitious effects almost never work on the first try. You MUST actively use browser automation tools to preview your work, visually verify the result, and iterate. Do not assume the effect looks right — check it. Expect multiple rounds of refinement. The gap between "technically works" and "looks extraordinary" is closed through visual iteration, not code alone.
技术前沿的效果几乎不可能一次就成功。你必须主动使用浏览器自动化工具预览成果，直观验证效果并反复迭代。不要假设效果符合预期——一定要检查。做好多次优化的准备。从“技术上可行”到“视觉上非凡”的差距，只能通过视觉迭代来弥补，而非仅靠代码。

Assess What "Extraordinary" Means Here

评估当前场景下“非凡”的定义

The right kind of technical ambition depends entirely on what you're working with. Before choosing a technique, ask: what would make a user of THIS specific interface say "wow, that's nice"?
合适的技术方案完全取决于你正在开发的内容。在选择技术前，先问自己：什么能让这个特定界面的用户说出“哇，太棒了”？

For visual/marketing surfaces

针对视觉/营销类页面

Pages, hero sections, landing pages, portfolios — the "wow" is often sensory: a scroll-driven reveal, a shader background, a cinematic page transition, generative art that responds to the cursor.
页面、首屏区域、着陆页、作品集——“惊艳”通常是感官层面的：滚动驱动的元素展示、着色器背景、电影级页面过渡、响应鼠标的生成式艺术。

For functional UI

针对功能性UI

Tables, forms, dialogs, navigation — the "wow" is in how it FEELS: a dialog that morphs from the button that triggered it via View Transitions, a data table that renders 100k rows at 60fps via virtual scrolling, a form with streaming validation that feels instant, drag-and-drop with spring physics.
表格、表单、对话框、导航——“惊艳”在于使用感受：通过View Transitions从触发按钮变形而来的对话框、通过虚拟滚动实现60fps渲染10万行数据的数据表格、具有即时流式验证的表单、带有弹簧物理效果的拖拽功能。

For performance-critical UI

针对性能敏感型UI

The "wow" is invisible but felt: a search that filters 50k items without a flicker, a complex form that never blocks the main thread, an image editor that processes in near-real-time. The interface just never hesitates.
“惊艳”是无形但可感知的：筛选5万条数据时毫无闪烁的搜索功能、从不阻塞主线程的复杂表单、近乎实时处理的图像编辑器。界面始终流畅无卡顿。

For data-heavy interfaces

针对数据密集型界面

Charts and dashboards — the "wow" is in fluidity: GPU-accelerated rendering via Canvas/WebGL for massive datasets, animated transitions between data states, force-directed graph layouts that settle naturally.
The common thread: something about the implementation goes beyond what users expect from a web interface. The technique serves the experience, not the other way around.
图表和仪表盘——“惊艳”在于流畅性：通过Canvas/WebGL进行GPU加速渲染以处理海量数据集、数据状态间的动画过渡效果、自然稳定的力导向图布局。
共同点：实现方式超越了用户对网页界面的预期。技术为体验服务，而非反之。

The Toolkit

工具集

Organized by what you're trying to achieve, not by technology name.
按目标分类，而非技术名称分类。

Make transitions feel cinematic

打造电影级过渡效果

  • View Transitions API (same-document: all browsers; cross-document: no Firefox) — shared element morphing between states. A list item expanding into a detail page. A button morphing into a dialog. This is the closest thing to native FLIP animations.
  • @starting-style
     (all browsers) — animate elements from 
    display: none
    to visible with CSS only, including entry keyframes
  • Spring physics — natural motion with mass, tension, and damping instead of cubic-bezier. Libraries: motion (formerly Framer Motion), GSAP, or roll your own spring solver.
  • View Transitions API（同文档：所有浏览器支持；跨文档：Firefox不支持）——状态间的共享元素变形效果。比如列表项展开为详情页，按钮变形为对话框。这是最接近原生FLIP动画的方案。
  • @starting-style
    （所有浏览器支持）——仅用CSS即可实现元素从
    display: none
    到可见状态的动画，包括入场关键帧
  • 弹簧物理效果——通过质量、张力和阻尼实现自然运动，而非使用cubic-bezier曲线。相关库：motion（原Framer Motion）、GSAP，或自行编写弹簧求解器。

Tie animation to scroll position

将动画与滚动位置绑定

  • Scroll-driven animations (
    animation-timeline: scroll()
    ) — CSS-only, no JS. Parallax, progress bars, reveal sequences all driven by scroll position. (Chrome/Edge/Safari; Firefox: flag only — always provide a static fallback)
  • 滚动驱动动画（
    animation-timeline: scroll()
    ）——纯CSS实现，无需JS。视差效果、进度条、序列展示等均由滚动位置驱动。（Chrome/Edge/Safari支持；Firefox仅在开启实验性标志时支持——务必提供静态降级方案）

Render beyond CSS

超越CSS的渲染能力

  • WebGL (all browsers) — shader effects, post-processing, particle systems. Libraries: Three.js, OGL (lightweight), regl. Use for effects CSS can't express.
  • WebGPU (Chrome/Edge; Safari partial; Firefox: flag only) — next-gen GPU compute. More powerful than WebGL but limited browser support. Always fall back to WebGL2.
  • Canvas 2D / OffscreenCanvas — custom rendering, pixel manipulation, or moving heavy rendering off the main thread entirely via Web Workers + OffscreenCanvas.
  • SVG filter chains — displacement maps, turbulence, morphology for organic distortion effects. CSS-animatable.
  • WebGL（所有浏览器支持）——着色器效果、后期处理、粒子系统。相关库：Three.js、OGL（轻量型）、regl。用于实现CSS无法完成的效果。
  • WebGPU（Chrome/Edge支持；Safari部分支持；Firefox仅在开启实验性标志时支持）——下一代GPU计算。比WebGL更强大，但浏览器支持有限。务必降级到WebGL2作为备选方案。
  • Canvas 2D / OffscreenCanvas——自定义渲染、像素操作，或通过Web Workers + OffscreenCanvas将繁重的渲染工作完全移至主线程之外。
  • SVG滤镜链——实现置换映射、湍流、形态学等有机扭曲效果。支持CSS动画。

Make data feel alive

让数据“活”起来

  • Virtual scrolling — render only visible rows for tables/lists with tens of thousands of items. No library required for simple cases; TanStack Virtual for complex ones.
  • GPU-accelerated charts — Canvas or WebGL-rendered data visualization for datasets too large for SVG/DOM. Libraries: deck.gl, regl-based custom renderers.
  • Animated data transitions — morph between chart states rather than replacing. D3's 
    transition()
    or View Transitions for DOM-based charts.
  • 虚拟滚动——仅渲染表格/列表中可见的行，适用于数万条数据的场景。简单场景无需依赖库；复杂场景可使用TanStack Virtual。
  • GPU加速图表——通过Canvas或WebGL渲染数据可视化，适用于SVG/DOM无法处理的大规模数据集。相关库：deck.gl、基于regl的自定义渲染器。
  • 数据动画过渡——图表状态间的变形过渡，而非直接替换。可使用D3的
    transition()
    或针对DOM图表的View Transitions。

Animate complex properties

动画复杂属性

  • @property
     (all browsers) — register custom CSS properties with types, enabling animation of gradients, colors, and complex values that CSS can't normally interpolate.
  • Web Animations API (all browsers) — JavaScript-driven animations with the performance of CSS. Composable, cancellable, reversible. The foundation for complex choreography.
  • @property
    （所有浏览器支持）——注册带类型的自定义CSS属性，实现渐变、颜色等CSS通常无法插值的复杂值的动画。
  • Web Animations API（所有浏览器支持）——JavaScript驱动的动画，性能与CSS动画相当。可组合、可取消、可逆转。是复杂动画编排的基础。

Push performance boundaries

突破性能边界

  • Web Workers — move computation off the main thread. Heavy data processing, image manipulation, search indexing — anything that would cause jank.
  • OffscreenCanvas — render in a Worker thread. The main thread stays free while complex visuals render in the background.
  • WASM — near-native performance for computation-heavy features. Image processing, physics simulations, codecs.
  • Web Workers——将计算任务移至主线程之外。比如繁重的数据处理、图像操作、搜索索引——任何可能导致卡顿的任务。
  • OffscreenCanvas——在Worker线程中渲染。主线程可保持空闲，同时在后台完成复杂视觉效果的渲染。
  • WASM——为计算密集型功能提供接近原生的性能。如图像处理、物理模拟、编解码器。

Interact with the device

与设备交互

  • Web Audio API — spatial audio, audio-reactive visualizations, sonic feedback. Requires user gesture to start.
  • Device APIs — orientation, ambient light, geolocation. Use sparingly and always with user permission.
NOTE: This skill is about enhancing how an interface FEELS, not changing what a product DOES. Adding real-time collaboration, offline support, or new backend capabilities are product decisions, not UI enhancements. Focus on making existing features feel extraordinary.
  • Web Audio API——空间音频、音频响应式可视化、声音反馈。需要用户触发才能启动。
  • 设备API——方向、环境光、地理位置。谨慎使用，且必须获得用户许可。
注意：此技能旨在增强界面的使用感受，而非改变产品功能。添加实时协作、离线支持或新的后端功能属于产品决策，而非UI增强。专注于让现有功能呈现出非凡质感。

Implement with Discipline

规范实现

Progressive enhancement is non-negotiable

渐进式增强是必须遵循的原则

Every technique must degrade gracefully. The experience without the enhancement must still be good.
css
@supports (animation-timeline: scroll()) {
  .hero { animation-timeline: scroll(); }
}
javascript
if ('gpu' in navigator) { /* WebGPU */ }
else if (canvas.getContext('webgl2')) { /* WebGL2 fallback */ }
/* CSS-only fallback must still look good */
每种技术方案都必须优雅降级。即使没有增强效果，用户体验也必须保持良好。
css
@supports (animation-timeline: scroll()) {
  .hero { animation-timeline: scroll(); }
}
javascript
if ('gpu' in navigator) { /* WebGPU */ }
else if (canvas.getContext('webgl2')) { /* WebGL2 fallback */ }
/* 纯CSS降级方案必须保持视觉美观 */

Performance rules

性能规则

  • Target 60fps. If dropping below 50, simplify.
  • Respect 
    prefers-reduced-motion
    — always. Provide a beautiful static alternative.
  • Lazy-initialize heavy resources (WebGL contexts, WASM modules) only when near viewport.
  • Pause off-screen rendering. Kill what you can't see.
  • Test on real mid-range devices, not just your development machine.
  • 目标为60fps。如果帧率低于50，简化实现。
  • 务必尊重
    prefers-reduced-motion
    ——这是硬性要求。提供美观的静态替代方案。
  • 仅当元素接近视口时才延迟初始化重型资源（WebGL上下文、WASM模块）。
  • 暂停屏幕外的渲染。终止不可见的内容。
  • 在真实的中端设备上测试，而非仅在你的开发机器上。

Polish is the difference

细节决定成败

The gap between "cool" and "extraordinary" is in the last 20% of refinement: the easing curve on a spring animation, the timing offset in a staggered reveal, the subtle secondary motion that makes a transition feel physical. Don't ship the first version that works — ship the version that feels inevitable.
NEVER:
  • Ignore 
    prefers-reduced-motion
    — this is an accessibility requirement, not a suggestion
  • Ship effects that cause jank on mid-range devices
  • Use bleeding-edge APIs without a functional fallback
  • Add sound without explicit user opt-in
  • Use technical ambition to mask weak design fundamentals — fix those first with other skills
  • Layer multiple competing extraordinary moments — focus creates impact, excess creates noise
从“酷炫”到“非凡”的差距在于最后20%的优化：弹簧动画的缓动曲线、序列展示的时间偏移、让过渡效果更具物理感的微妙次级运动。不要交付第一个可行版本——交付那种让人觉得本该如此的版本。
绝对禁止：
  • 忽略
    prefers-reduced-motion
    ——这是无障碍要求，而非建议
  • 交付在中端设备上会导致卡顿的效果
  • 使用前沿API却不提供可行的降级方案
  • 未经用户明确同意添加声音效果
  • 用技术前沿性掩盖薄弱的设计基础——先用其他技能解决这些问题
  • 叠加多个相互冲突的非凡效果——专注才能产生冲击力，过多则会造成视觉干扰

Verify the Result

验证成果

  • The wow test: Show it to someone who hasn't seen it. Do they react?
  • The removal test: Take it away. Does the experience feel diminished, or does nobody notice?
  • The device test: Run it on a phone, a tablet, a Chromebook. Still smooth?
  • The accessibility test: Enable reduced motion. Still beautiful?
  • The context test: Does this make sense for THIS brand and audience?
Remember: "Technically extraordinary" isn't about using the newest API. It's about making an interface do something users didn't think a website could do.
  • 惊艳测试：展示给未见过的人。他们会有反应吗？
  • 移除测试：去掉这个效果。用户体验会大打折扣，还是没人注意到？
  • 设备测试：在手机、平板、Chromebook上运行。依然流畅吗？
  • 无障碍测试：开启减少动画模式。依然美观吗？
  • 上下文测试：这符合该品牌和受众的定位吗？
记住：“技术非凡”并非指使用最新的API，而是让界面实现用户认为网站做不到的事情。