Aktualisiert 15. Juli 2026

Warum KI-Dark-Modes falsch aussehen: Inversion vs. Ableitung

Bitte einen Coding-Assistenten, einem Projekt „Dark Mode hinzuzufügen”, und lies dir den Diff an, den er produziert. Das Muster ist bemerkenswert konsistent: weiße Hintergründe werden fast schwarz, helle Grautöne werden dunkle Grautöne, dunkler Text wird heller Text, der Marken-Akzent behält seinen exakten Hex-Wert, und die Box-Schatten bleiben genau dort, wo sie waren. Bitte einen Bildgenerator um „die Dark-Mode-Version” eines Dashboards, und er führt dasselbe Manöver in Pixeln aus. Beide sehen in einer Thumbnail-Ansicht plausibel aus. Keines von beiden übersteht den Kontakt mit echter Nutzung.

KI-Dark-Modes sehen falsch aus, weil das Modell eine Inversion vornimmt — die Werte des hellen Themes in gespiegelte Positionen getauscht — während ein funktionierendes Dark Theme eine Ableitung ist: eine zweite Palette, berechnet aus denselben Marken-Ausgangsfarben, mit einer eigenen Helligkeitsrampe, die aus einem tiefen Boden aufsteigt statt aus einem gespiegelten, mit Chroma, das für einen dunklen Grund neu geplant statt übernommen wird, mit Kontrast, der für jede Text- und Flächen-Paarung neu berechnet wird, und mit einer neuen Elevations-Logik, in der erhöhte Flächen heller werden statt Schatten zu werfen. Diese Unterscheidung ist das Rückgrat unseres Dark-Mode-Guides; dieser Artikel handelt davon, was passiert, wenn eine KI im Spiel ist.

Was macht eine KI eigentlich, wenn du sie um Dark Mode bittest?

Sie reproduziert das aggregierte Erscheinungsbild der dunklen Interfaces, mit denen sie trainiert wurde — nicht die Konstruktion irgendeines bestimmten. Das ist der intuitive Schlüssel zum ganzen Versagen: Das Modell hat sehr viele dunkle UIs gesehen und weiß, wie sie typischerweise aussehen; es hat nie die Entscheidungen ausgeführt, die ein gutes hervorgebracht haben. Also matcht die Ausgabe ein Muster — dunkler Grund, heller Text, gleicher Akzent — und zwei Dinge fehlen konstruktionsbedingt. Das erste ist die Berechnung: Nichts prüft, ob der mittelgraue Sekundärtext gegen den neuen Hintergrund noch die Kontrast-Untergrenze erreicht, weil das Modell plausible Werte generiert, statt sie zu verifizieren. Das zweite ist die Stabilität: Jede Antwort wird neu gesampelt, sodass zweimaliges Bitten um „Dark Mode” zwei leicht unterschiedliche Themes zurückgibt — dieselbe Instabilität, die über eine längere Sitzung KI-generierte Interfaces vom Markenkurs abdriften lässt. Was du bekommst, ist ein Bild eines Dark Themes, in Code oder in Pixeln.

Warum erzeugt Inversion ein kaputtes Theme?

Weil die internen Beziehungen eines hellen Themes das Spiegeln nicht überstehen — ein Versagen mit drei verschiedenen Gesichtern, im Detail auseinandergenommen in Dark Mode ist keine Inversion:

  • Die Rollen-Logik kippt komplett. Ein Rahmen im hellen Theme liegt etwas dunkler als seine Fläche und liest sich als gezeichnete, eingelassene Linie; spiegle die Helligkeit, und er liegt etwas heller und wirkt erhaben. Manche Beziehungen sollen kippen — dunkler Text auf Hell wird zu Recht heller Text auf Dunkel — während andere es nicht dürfen, und die Inversion kann den Unterschied nicht erkennen.
  • Elevation verliert ihr Signal. Schatten sind auf einem dunklen Grund kaum wahrnehmbar — es gibt fast nichts Dunkleres mehr — also signalisieren Dark Themes Höhe, indem sie erhöhte Flächen heller machen. Die Inversion schleppt die Schatten sinnlos mit und erzeugt nichts von dieser Aufhellung.
  • Farbe versickert. Wahrgenommene Farbigkeit wird relativ zur Umgebung beurteilt: Derselbe Chroma-Wert wirkt gegen Fast-Schwarz deutlich matter als gegen Weiß — das ist der Grund, warum Farben im Dark Mode ausgewaschen wirken, wenn ihre Werte unverändert übernommen werden.

Eine KI, die gebeten wird, „es dunkel zu machen”, reproduziert alle drei, weil ein Dark Theme von außen wie eine Inversion aussieht — die Entscheidungen, die es zu etwas anderem machen, sind im fertigen Artefakt unsichtbar, also sind sie auch in den Trainingsdaten unsichtbar.

Was bedeutet stattdessen Ableitung?

Ableitung behält die Ausgangsfarben und führt die Konstruktion der Palette für einen dunklen Kontext erneut aus. Die dunkle Rampe ist keine Spiegelung der hellen: Sie folgt ihrer eigenen Helligkeitskurve, wobei sich die Schritte der Hintergrund-Klasse in OKLCH um L ≈ 0,13–0,19 einpendeln — eine tiefe neutrale Zone, nicht das reine Schwarz, das eine Spiegelung aus einem fast-weißen Start erzeugt. Chroma wird neu geplant statt kopiert: um rund 20 % gegenüber den hellen Werten angehoben, um die Dämpfung eines dunklen Grundes auszugleichen, begrenzt durch das, was der Farbraum (Gamut) bei jeder Helligkeit zulässt. Semantische Rollen werden neu abgeleitet statt neu verwiesen — Text-, Rahmen- und Zustandsfarben werden gegen die neuen Flächen gewählt, wobei die Kontrast-Untergrenzen dort neu geprüft werden, weil eine Paarung, die auf Weiß bestanden hat, nichts über Fast-Schwarz beweist. Und die Elevation wird auf der Aufhellungs-Konvention neu aufgebaut statt auf ererbten Schatten.

Nichts davon ist exotisch; es ist Arithmetik — und genau das ist der Punkt. Es ist berechenbar, weil die Palette in einem perzeptiven Farbmodell lebt: Die OKLCH-Helligkeit bildet ab, wie hell eine Farbe tatsächlich erscheint (das Modell baut auf Björn Ottossons OKLab-Arbeit auf), sodass „eine neue Rampe ableiten und jede Paarung neu prüfen” eine Berechnung ist, keine Sitzung mit dem bloßen Auge. Ein generatives Modell sampelt, was ein Dark Theme plausibel sein könnte; eine Ableitung berechnet, was dein Dark Theme ist.

Öffne eine helle Palette neben ihrem abgeleiteten dunklen Zwilling im Scale Composer — dieselbe Ausgangsfarbe auf beiden Seiten, und die Unterschiede, die dieser Artikel beschreibt, sind in den Werten ablesbar: der tiefe-aber-nicht-schwarze Boden, das angehobene Chroma, die neu gewählten Text-Schritte.

Eine helle Palette und ihr abgeleitetes dunkles Gegenstück nebeneinander im Scale Composer, das die eigene Helligkeitsrampe des Dark Themes und angepasstes Chroma statt gespiegelter Werte zeigt

Gilt das auch für KI-generierte Bilder dunkler UIs?

Ja — dasselbe Versagen, ein anderes Medium. Prompte einen Bildgenerator mit „derselbe Screen, Dark Mode”, und er malt in Richtung seiner Vorannahme für dunkle Interfaces: reinschwarze Gründe, Akzente, die wie ein Gaming-Dashboard glühen, grellweißer Text. Das ist ein Look, keine Ableitung — und meist nicht dein Look. Negationen retten es nicht: Diese Generatoren klammern sich oft an genau das Substantiv, das du verbietest, sodass „Dark Mode, aber nicht reines Schwarz” trotzdem beim Schwarz landet. Beschreibe das abgeleitete Theme stattdessen positiv, als Prompt-Vokabular: „tief-neutraler grauer Hintergrund; erhöhte Panels etwas heller als der Grund; weicher gebrochen-weißer Text; das Markenblau etwas kräftiger als in der hellen Version.” Diese Formulierungen sind keine Stimmungswörter — sie sind die tatsächlichen Entscheidungen eines abgeleiteten Dark Themes, ausgedrückt in einer Sprache, der ein Bildmodell folgen kann.

Wie bekommst du ein korrektes Dark Theme aus einer KI heraus?

Teile die Arbeit entlang der Linie auf, an der jede Seite stark ist. Leite die dunkle Palette deterministisch ab, exportiere die design tokens mit den hellen und dunklen Rollen-Sets nebeneinander, und übergib der KI die Datei mit einer einzigen Dauer-Anweisung: Referenziere die Rollen, erfinde nie Werte. Ein Coding-Modell ist wirklich gut darin, ein System über Dutzende Komponenten hinweg anzuwenden; es driftet, wenn es das System entscheiden soll — die wiederkehrende Form des ganzen Problems KI und Design-Systeme. Bei Bildern ist dieselbe Datei die Vokabular-Quelle: Die Töne des Dark Themes haben ebenfalls Namen und Werte, und sie gehören genauso in den Prompt wie die helle Palette.

Leite das Hell-Dunkel-Paar aus deiner eigenen Markenfarbe ab — füge eine Ausgangsfarbe ein, erhalte beide Themes mit neu geprüftem Kontrast, und exportiere das Paar als eine Datei: die deterministische Hälfte des Workflows, bereit zur Übergabe an das Modell, das die Screens baut.

Weiterlesen