Back to Details

i-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.
开始你的响应时首先输出以下内容：
──────────── ⚡ 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.
页面、首屏区域、落地页、作品集——「惊艳感」通常来自感官体验：滚动驱动的展示效果、shader背景、电影级页面转场、响应光标交互的生成艺术。

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万行数据的表格、支持流式校验响应极快的表单、带spring physics的拖拽交互。

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加速渲染、数据状态间的动画过渡、可自然收敛的力导向图布局。
核心共同点：实现层面的某些表现超出了用户对Web界面的常规预期，技术为体验服务，而不是反过来。

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
    到可见的动画，包括进入关键帧。
  • Spring physics——基于质量、张力、阻尼的自然动效，而非贝塞尔曲线。相关库：motion（原Framer Motion）、GSAP，也可以自行实现spring求解器。

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)
  • Scroll-driven animations（
    animation-timeline: scroll()
    ）——仅用CSS实现，无需JS。视差效果、进度条、展示序列都可以由滚动位置驱动。（Chrome/Edge/Safari支持；Firefox：仅flag开启支持——一定要提供静态降级方案）

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（全浏览器支持）——shader特效、后处理、粒子系统。相关库：Three.js、OGL（轻量版）、regl，用于实现CSS无法表达的特效。
  • WebGPU（Chrome/Edge支持；Safari部分支持；Firefox：仅flag开启支持）——下一代GPU计算能力，比WebGL性能更强但浏览器支持度有限，始终要提供WebGL2的降级方案。
  • Canvas 2D / OffscreenCanvas——自定义渲染、像素操作，或者通过Web Workers + OffscreenCanvas把重渲染任务完全移出主线程。
  • SVG filter chains——可实现位移图、湍流、形态学等有机变形效果，支持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.
  • Virtual scrolling——针对有上万条数据的表格/列表，仅渲染可视区域内的行。简单场景无需额外库，复杂场景可使用TanStack Virtual。
  • GPU加速图表——针对SVG/DOM无法承载的超大数据集，使用Canvas或WebGL渲染数据可视化内容。相关库：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——空间音频、音频响应式可视化、声音反馈，需要用户手势触发才能启用。
  • Device APIs——方向感应、环境光、地理定位，谨慎使用且始终需要获得用户授权。
注意：该技能的核心是优化界面的体验感受，而非改变产品的功能定位。添加实时协作、离线支持或者新的后端能力属于产品决策，不属于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-only fallback must still look good */

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%的优化：spring动画的缓动曲线、错峰展示的时间偏移、让过渡更具物理真实感的微妙次级动效。不要上线第一个可运行的版本——要上线体验自然流畅的最终版本。
绝对禁止：
  • 忽略
    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，而是指让界面实现了用户原本认为网站做不到的效果。