Toothpick: Den KI-Geschmack entfernen, eine Oberfläche ausliefern, die Bestand hat

Was dieser Leitfaden ist

Es gibt hier keine Regeln wie „verwende immer diese Schriftart“ oder „nie diese Farbe“. Du darfst jede Farbe, Schriftart oder jedes Layout verwenden.

Er erledigt zwei Dinge:

Hilft, den KI-Geschmack zu erkennen: Welche Entscheidungen sind gedankenlose Standardeinstellungen einer KI, und warum werden sie sofort erkannt?
Hilft, häufige Schwachstellen zu vermeiden: Die Fehler, die eine Oberfläche rau, billig oder unprofessionell aussehen lassen.

Es gibt einen Test: Wurde diese Entscheidung für dieses Produkt getroffen, oder hättest du sie für jedes Produkt getroffen? Das Zweite ist der KI-Geschmack.

Der ausdrückliche Stil des Nutzers, Markenrichtlinien und vorhandener Code haben immer Vorrang, selbst wenn das, was verlangt wird, einer der unten aufgeführten „KI-Geschmäcker“ ist.

Was der KI-Geschmack ist

Bei jeder Designentscheidung driftet eine KI zur häufigsten Option. Das geschieht in zwei Schichten.

Schicht eins, die alten Klischees: Lila-blaue Farbverläufe, Emojis als Icons, identische abgerundete Karten mit grauen Schatten, die Landingpage „zentrierte Überschrift plus drei Feature-Karten“, Texte wie „schalte grenzenlose Möglichkeiten frei“. Viele Menschen erkennen diese bereits.

Schicht zwei, so tun als ob man Geschmack hätte: Sobald die KI aufgefordert wird, „mach es nicht KI-generiert aussehen“, wechselt sie zu einem anderen, ebenso festgelegten Outfit:

Cremefarbener Papierhintergrund, große Serifenüberschrift, terrakotta- oder dunkelroter Akzent, als „warm und geschmackvoll“ getarnt
Beinahe-schwarzer Hintergrund, ein neongrüner, bernstein- oder zinnoberroter Akzent, überall Monospace, als „Hacker“ getarnt
Zeitungsstil mit schwarzen Haarlinien, null Randradius, dichten Spalten, als „schweizerisch und professionell“ getarnt
Übergroße dekorative Zahlen, Asymmetrie um der Asymmetrie willen, ein Terminal-„$“-Prompt oder ein „●“-Statuspunkt als Dekoration

Schicht zwei ist schwerer zu bemerken, weil sie „designt“ aussieht. Sie hat dasselbe Problem wie Schicht eins: Der Stil wurde aufgeklebt, nicht aus dem Produkt heraus entwickelt.

Die vollständige Liste, einschließlich warum jedes Element als KI gelesen wird und wann es tatsächlich in Ordnung ist, befindet sich in references/ai-tells.md.

Wie gute Oberflächen aussehen

references/benchmarks.md enthält Messungen von Vercel, GitHub, ChatGPT, Google und Linear sowie die chinesischen Produkte DingTalk, Juejin, WeChat Read und sspai und wie sich chinesische Oberflächen unterscheiden (stärkere Überschriften, höhere Zeilenhöhe, kleinere Schriftgrößen). Was die englischsprachigen Referenzen gemeinsam haben:

Sehr wenige Farben: fast ausschließlich Schwarz, Weiß und Grau, plus eine funktionale Farbe
Eine Schriftfamilie; Überschriften sind groß, aber nicht fett
Leichte Trennung: Weißraum, blasse dünne Umrandungen, sehr leichte Schatten, keine schwarzen Linien und schwere Schatten
Das Produkt selbst ist der Held; Dekoration ist nahe Null
Ein Blickpunkt pro Bildschirm

Dies sind eine Referenz, keine Vorlage. Ein Coffeeshop sollte nicht wie Vercel aussehen, aber er sollte genauso zurückhaltend und präzise sein, mit dem Inhalt im Vordergrund.

Die Referenz kann selbst zur neuen Standardvorlage werden. Wenn deine letzten Projekte, mit verdeckten Namen, alle als Weiß, Neutralgrau, Pill-Buttons und dünnumrandete Panels daherkommen, ist die Referenz zur Vorlage geworden. Nutze sie, um die handwerkliche Qualität zu kalibrieren: wie leicht eine Linie ist, wie weich ein Schatten, wie dünn eine Überschrift. Farbe, Material und der Held kommen aus der Liste in Schritt 2.

Arbeitsablauf

0. Zuerst den Umfang der Änderung bestimmen

Änderung	Beispiele	Welche Schritte
Klein	Eine Farb-, Abstands- oder Textänderung; eine Komponente reparieren; einen Button hinzufügen	Lies den relevanten Code und die Stilvariablen, ändere es im vorhandenen Stil, überprüfe die wenigen relevanten Einträge in `references/ai-tells.md` und liefere mit einem oder zwei Sätzen aus (nur eine Platzhalterliste, wenn es Platzhalter gibt)
Mittel	Eine neue Seite oder die Bildschirme einer neuen Funktion innerhalb eines vorhandenen Produkts	Schritt 1, ein Drei-oder-Vier-Zeilen-Plan, dann Schritte 5 bis 7. Behalte den vorhandenen Stil des Produkts bei; überspringe die Bestandsaufnahme und das Argument
Groß	Ein neues Produkt, eine Website, eine Landingpage, ein Redesign	Alle sieben Schritte

Wenn du unsicher bist, wähle die kleinere Größe; der Nutzer wird nach mehr fragen. Schreibe keinen Designplan für einen einzelnen Button.

1. Verstehen, worum es geht: zuerst das Projekt lesen, dann den Besucher

In einem vorhandenen Projekt: Lies es, bevor du etwas anfasst. Finde vor jedem Plan oder Code Folgendes heraus:
- Welche Funktionen das Projekt tatsächlich hat (lies die README, Routen, Seiten und API; rate nicht anhand von Seitentiteln)
- Vorhandene Komponenten, Stilvariablen, Icon-Set und Schriftarten. Neue UI verwendet sie; starte kein paralleles System
- Das Datenmodell und die tatsächlichen Felder, die die API zurückgibt. Baue die UI auf diesen Feldern auf
- Den vorhandenen Wortschatz im Text. Nenne dieselbe Sache weiterhin beim selben Namen
Schreibe in ein paar Zeilen auf, „was das Projekt hat“, und basiere den Plan darauf. Für alles, was du nicht lesen kannst (z. B. das Backend befindet sich nicht im Repository), frage den Nutzer oder lege deine Annahme klar dar.
Was ist das Produkt oder der Inhalt? Für wen ist es? Wenn dies unklar ist, triff eine konkrete Annahme, sag es in einem Satz und mach weiter, anstatt wiederholt zu fragen.
Bestimme den Modus dieser Seite (beurteile die Seite, nicht das Produkt: Die Homepage eines Entwicklertools ist Überzeugen, sein Dashboard ist Betreiben):

Modus	Was Erfolg für den Besucher bedeutet	Beispiele	Worauf die Designarbeit geht
Überzeugen	Entscheidet und handelt	Homepage, Landingpage, Kampagne, Preise	Ein Standpunkt und Wirkung; überzeuge mit echten Bildern
Betreiben	Erledigt eine Aufgabe	Admin, Dashboard, Editor, Einstellungen, Tools	Scanbar, konsistent, effizient; Persönlichkeit lebt in präzisen Details
Lesen	Versteht den Inhalt	Docs, Artikel, Hilfebereich, Changelog	Klare Struktur, ein angenehmes Leseerlebnis
Präsentieren	Ist in die Arbeit vertieft	Portfolio, Galerie, Fallstudien	Die Arbeit führt, das Interface tritt zurück

Passende Referenzen: Überzeugen und Präsentieren verwenden references/web.md, Betreiben verwendet references/app-desktop.md, mobil zusätzlich references/mobile.md. Projekt-READMEs und die darin enthaltenen Mindmaps oder Diagramme verwenden references/readme.md.

Verfeinerung oder Redesign? Eine Verfeinerung behält den vorhandenen Stil, Text und das Verhalten bei und ändert nur, was im Umfang liegt. Ein Redesign ersetzt das Gesamterscheinungsbild, behält aber Produktdaten, Inhalte und Funktionen. Flicke nicht halb einen neuen Stil auf den alten.

2. Bestandsaufnahme, was nur zu diesem Thema gehört

Schreibe 8–12 konkrete Dinge auf, die zu diesem Kunden und zu keinem Konkurrenten gehören: der Name und was er bedeutet, die Straße und Stadt, die Türnummer und das Ladenschild, Materialien und Farben, seine Zahlen (Sitzplätze, Höhenlage, Jahre im Geschäft), seine Einschränkungen (eine Charge pro Monat, im Winter geschlossen), seine Rituale (der Ofen wird um fünf angezündet), die gedruckten Dinge seiner Welt (Quittungen, Etiketten, Fahrpläne).

Designideen stammen aus dieser Liste, nicht von „wie Websites in dieser Branche normalerweise aussehen“. Ein Open-Source-Skill, auf den wir zurückgegriffen haben, führte Blindtests durch: Die Gewinnerseiten verwendeten Elemente aus einer solchen Liste; die Verliererseiten hatten gute Kompositionen, die auf generischen Branchenideen basierten.

3. Das Argument schreiben, bevor Abschnitte ausgewählt werden

Jeder Abschnitt einer Marketingseite sollte eine Behauptung plus ihren Beweis sein, eine Zeile pro Abschnitt:

Held: Drei Röstungen diese Woche, am Freitag versandt → Beweis: drei Tüten, das Röstdatum
Bohnen: Jede hat eine klare Herkunft und einen klaren Geschmack → Beweis: tatsächliche Herkunft, Höhenlage, Verkostungsnotizen
...

Lösche jeden Abschnitt ohne eine Behauptung. Das hält dich von der Standardstruktur „Held, Logo-Wall, drei Features, Testimonials, Preise, FAQ“ fern.

4. Einen kurzen Plan schreiben

Farbe: 4–6 Werte, jeweils mit Verwendungszweck
Schrift: Welche Schriftarten und wofür
Layout: Ein Satz zur Idee, ein einfaches ASCII-Wireframe falls nützlich, und die Ausrichtung
Held: Das überzeugendste Element auf dieser Seite und welche Assets du tatsächlich hast (gestalte nicht um Bilder herum, die es nicht gibt)
Intensität: zurückhaltend (Standard für Betreiben und Lesen), ein Held (Standard für Überzeugen: ein kräftiges Bild aus der Bestandsaufnahme, alles andere ruhig), oder ein vollständiges Konzept (siehe „Wann man sich auf ein starkes Konzept festlegt“ weiter unten)

5. Den Plan prüfen: Standard oder Wahl?

Würde ich bei einer ähnlichen Aufgabenstellung ungefähr auf denselben Plan kommen? Wenn ja, ist dieser Teil ein Standard; gehe zurück zur Liste aus Schritt 2 für Ideen.
Trifft es etwas in references/ai-tells.md? Wenn ja, ändere es, oder sei in der Lage zu sagen, warum dieses Produkt es braucht.
Gibt es mehr Dekoration als Inhalt?

Sage kurz in deiner Antwort, was du geändert hast und warum.

6. Bauen

Verwalte Farben und Abstände mit CSS-Variablen. Achte auf die Selektorspezifität, damit sich Klassen nicht gegenseitig überschreiben (besonders Abschnitts-Padding).
Beispielinhalte sind echt und spezifisch, und die Zahlen stimmen.
Wenn die Seite die Oberfläche des Produkts zeigt (z. B. der Screenshot-Platz auf einer SaaS-Homepage), baue es als echtes Fragment dieses Produkts mit echten Daten, Zahlen, die sich reimen, und einer klaren Erkenntnis. Keine grauen Blöcke und falschen Zahlen.
Handwerkliche Details sind in references/craft-details.md.

7. Das Ergebnis betrachten, in Batches korrigieren, dann eine Sache entfernen

Betrachte die echten Größen: Desktop, Telefon (ca. 375px), Dark Mode, falls vorhanden. Schau einmal hin, korrigiere alles zusammen; mache keinen Screenshot nach jeder Anpassung.
Gehe durch checklist.md.
Wie beim Blick in den Spiegel vor dem Verlassen des Hauses, entferne ein Accessoire.
Wenn du das Ergebnis nicht sehen kannst (das Modell kann keine Bilder lesen, oder es gibt keinen Browser): Tu nicht so, als hättest du hingesehen. Überprüfe stattdessen den Code: Passt der längste Text in die Spalte an jedem Bruchpunkt, wie ist das Kontrastverhältnis berechnet aus den Farbwerten, sind alle Interaktionszustände geschrieben? Sage in deiner Auslieferung, dass du es nicht in einem Browser gesehen hast, und bitte den Nutzer um einen Desktop- und einen Telefon-Screenshot für eine weitere Runde.

Zurückhaltung ist nicht Leere

Dekoration zu entfernen ist nur die Hälfte der Arbeit. Eine Seite, die ihre Labels, Linien und Karten verloren hat und nichts als Ersatz bekommen hat, wirkt dünn und kann gegen eine reichhaltigere Seite verlieren, die noch etwas KI-Geschmack hat. Die andere Hälfte ist Substanz: kräftigere Schriftskala, ganze Farbflächen, echte Bilder aus der Welt dieses Themas, jeder Abschnitt gefüllt mit seinem vollständigen Inhalt.

Wann man sich auf ein starkes Konzept festlegt

Zurückhaltung ist der Standard, nicht die Obergrenze. Ein ganzseitiges visuelles Konzept (ein Comic, eine Zeitung, eine technische Zeichnung, ein Ticket) ist genau dann richtig, wenn alle der folgenden Punkte zutreffen:

Es hat eine Quelle: Der Nutzer hat danach gefragt, oder die eigene Welt des Themas spricht diese Sprache (Zeichnungen eines Architekten, Druckfahnen einer Druckerei, ein Eisenbahnfahrplan) und du findest es in der Liste aus Schritt 2
Jedes Stilmittel wird auf Inhalt abgebildet: Schreibe die Zuordnung auf, z. B. „Geschwindigkeitslinien: Anfragen stapeln sich“, „Rasterdichte: wie schwer das Schloss ist“. Wirf jedes Stilmittel weg, das du nicht zuordnen kannst
Es bleibt lesbar: Code, Zahlen, Tabellen und Buttons können immer noch fehlerfrei gelesen und bedient werden. Das Konzept dient dem Inhalt und bringt niemanden dazu, etwas falsch zu lesen
Die Fakten ändern sich nicht: Ein neuer Stil behält alle Produktdaten, Funktionen, Zahlen und die Platzhalterliste
Es weiß, wo es aufhört: Verwende es vollständig auf der Hauptlinie und bleibe in den Details zurückhaltend; platziere kein Thema-Element in jeder Ecke

Wenn einer dieser Punkte fehlschlägt, falle zurück auf einen Helden: Verwende die Sprache nur im Helden oder einem Abschnitt. Der Unterschied zu einem Kostüm: Ein Kostüm passt zu jedem Produkt (Creme und Serife, Beinahe-Schwarz und Neon, Zeitungs-Haarlinien); ein starkes Konzept ergibt nur für dieses eine Produkt Sinn.

Wenn du auslieferst, erkläre die Designidee in ein oder zwei Sätzen, damit der Nutzer leicht umlenken kann, und füge die Platzhalterliste bei (siehe „Nichts vortäuschen, keinen Entwickler täuschen“).

Wenn der Nutzer Änderungen wünscht

Der Nutzer sagt	Es bedeutet
Kräftiger	Größerer Schriftkontrast, ganze Farbflächen, ein größerer Held. Nicht mehr Dekoration
Leiser / zu überladen	Weniger Farben und Bewegung, weniger Schriftgrößen, sekundäre Elemente entfernen
Vereinfachen	Abschnitte und Elemente ohne Behauptung löschen; das Wesentliche behalten
Mehr Feinschliff	Handwerk: Ausrichtung, Abstände, Radius, Schatten, Zustände, browser-native Teile
Ist es bereit für den Versand?	Fehler, leere Zustände, sehr lange Inhalte, andere Sprachen, Randfälle

Nichts vortäuschen, keinen Entwickler täuschen

Nutzer und Entwickler sollten gleichermaßen erkennen können, was echt ist und was noch nicht fertig ist.

Nichts vor Endnutzern vortäuschen

Keine erfundenen Logos, Kundenlogo-Walls oder Partner-Badges. Kein gefälschtes Logo aus Symbolen wie „$“, „▲“ oder „●“; ohne Logo reicht der Produktname in Klartext.
Keine erfundenen Benutzerzahlen, Zufriedenheitsraten, Wachstumszahlen, Testimonials oder Presseerwähnungen.
Überprüfe professionelle Fakten (technische Details, Standards, Vorschriften, Medizin, Finanzen, Statistik). KI schreibt diese fließend, und ihre Fehler sehen genauso fließend aus:
- Liste die professionellen Behauptungen auf der Seite auf. Recherchiere, was du in der Dokumentation oder den Standards finden kannst, und zitiere die Quelle in einem Code-Kommentar
- Was du nicht bestätigen kannst, lasse entweder weg oder liste es unter „Nicht verifiziert“ in der Platzhalterliste
- Zahlen auf der Seite müssen miteinander übereinstimmen (70 Anfragen pro Sekunde für 41 Sekunden sind 2.870 Anfragen)

Nichts, was den Entwickler täuscht

Keine erfundenen Funktionen: Jede in der Oberfläche gezeigte Funktion existiert im Projekt oder wurde ausdrücklich angefordert. Füge keine „intelligenten Empfehlungen“ oder „One-Click-Export“ hinzu, um die Seite besser aussehen zu lassen.
Mock-Daten geben sich nie als echte Daten aus: Verbinde die echte API, wenn du kannst. Wenn du nicht kannst, halte Mock-Daten an einem Ort (z. B. mock/) mit denselben Feldern wie die echte API und markiere sie im Code als Mock. Harte schöne Zahlen nicht in Komponenten, damit die Seite „fertig“ aussieht.
Keine vorgetäuschten Interaktionen: Ein Button, Formular oder Link, der nicht verdrahtet ist, darf keine Klick-Animation erhalten, die vorgibt, er funktioniere. Deaktiviere ihn und beschrifte ihn mit „nicht verbunden“ oder liste ihn in den Lieferhinweisen auf.
Demos und Konzepte, die von Grund auf neu erstellt wurden, dürfen eine fiktive Marke und Daten verwenden, aber die Seite muss sagen, dass es ein Beispiel ist.

Eine Platzhalterliste beifügen

Füge am Ende deiner Lieferung eine Platzhalterliste bei, einer pro Zeile, die klar zwischen echten und noch nicht erstellten Inhalten unterscheidet. Der Nutzer kann den Platzhaltertext oder die Daten beim nächsten Mal ersetzen, ohne suchen zu müssen.

Beispiel:

Echt: Preispakete, API-Endpunkte, Screenshot der Dashboard-Aufgabenliste
Nicht verifiziert: „SOC 2 zertifiziert“ – im Code-Kommentar markiert, nicht auf der Seite
Platzhalter: Logo-SVG, Video-URL, Schaltfläche im Teamfoto

Markdown, Code-Auszug, ... Inline-Code-Spans bleiben unberührt. Auch die Referenzliste: references/ai-tells.md, references/benchmarks.md, references/web.md, references/app-desktop.md, references/mobile.md, references/readme.md, references/craft-details.md, checklist.md.

Der Kern auf einen Blick

Nichts tun, ohne vorher zu lesen: README, Routen, API, Komponenten, Stilvariablen. Baue die Oberfläche auf echten Feldern auf und verwende den vorhandenen Wortschatz.
Bestandsaufnahme von 8–12 Dingen, die nur zu diesem Kunden gehören, nicht zur Branche.
Jeder Marketing-Abschnitt = eine Behauptung und ihr Beweis. Abschnitte ohne Behauptung löschen.
Ein kurzer Plan: Farbe (4–6 Werte mit Verwendung), Schrift (welche, wofür), Layout (ein Satz, ggf. ASCII-Wireframe), Held (das überzeugendste Asset und ob es existiert), Intensität (zurückhaltend, ein Held oder volles Konzept).
Prüfen, ob der Plan eine wirkliche Wahl ist oder nur ein Standard. Referenz für KI-Tells prüfen. Gibt es mehr Dekoration als Inhalt?
Bauen mit echten Daten und vollständigen Inhalten.
Das Ergebnis auf echten Geräten betrachten, in Batches korrigieren, ein Accessoire entfernen.

Lizenz

Dieser Skill wurde vom component-Ansatz von @magnetikonline inspiriert.

toothpick

Was ist toothpick?

In Ihrer bevorzugten KI fragen

Dokumentation