aurora-ember-bio-lab/splatstudio

Critique Skill · 5 维度专家评审

Erstelle einen eigenständigen HTML-„Design-Review-Bericht“, der jedes Artefakt in fünf Dimensionen bewertet und umsetzbare Korrekturen vorschlägt. Inspiriert vom huashu-design Experten-Kritik-Workflow.

Wann anwenden

• Nachdem der Agent (oder Benutzer) ein Artefakt erstellt hat (Deck / Prototyp / Landing Page) und der Benutzer fragt: „Was ist daran falsch?“ oder „Überprüfe dies“
• Als Selbstprüfungs-Schleife, die der Agent vor der Ausgabe auf seine eigene Ausgabe anwenden kann
• Zum Vergleichen von zwei Varianten desselben Designs

Was erzeugt wird

Ein einzelner, eigenständiger <artifact type="text/html">-Reviewbericht mit:

1. Kopfzeile – welches Artefakt überprüft wurde, Datum, Prüfer („OD · Critique skill“), zusammenfassendes Urteil in einem Satz
2. Radardiagramm (Inline-SVG, keine Bibliothek) mit den fünf Bewertungen
3. Fünf Dimensionskarten, jede mit:
   • Punktzahl 0–10 (mit Band: 0–4 Defekt · 5–6 Funktionsfähig · 7–8 Stark · 9–10 Hervorragend)
   • 1 Absatz Belege (Zitieren konkreter Elemente / Dateien / Zeilen)
   • Einem Aufzählungspunkt Beibehalten / Beheben / Schnelle Erfolge
4. Kombinierte Aktionslisten am Ende:
   • Beibehalten – Was funktioniert, nicht verändern
   • Beheben – P0-/P1-Probleme, die visuell teuer sind
   • Schnelle Erfolge – 5–15-minütige Anpassungen mit überproportionaler Wirkung

Die fünf Dimensionen

Jede Dimension ist unabhängig – ein Deck kann 9/10 für Innovation, aber 4/10 für Hierarchie sein, und der Bericht sollte dies klar sagen. Mitteln Sie keine interessanten Fehler weg.

1. Philosophiekonsistenz · 哲学一致性

Wählt das Artefakt eine klare Richtung und hält sie in jeder Mikroentscheidung ein (Chrome / Kicker / Abstand / Akzent)?

Hinweise, auf die zu achten ist:

• Gibt es eine erklärte Designrichtung (z.B. Monocle / WIRED / Kinfolk) oder ist es ein Mix aus drei Stilen?
• Bleibt das Chrome-/Kicker-Vokabular in einem Register, oder sagt Seite 3 „Vol.04 · Spring“ und Seite 7 „ABER WARTE 🔥“?
• Werden Akzent-/Serifen-/Schriftart Mono nach derselben Regel durchgängig verwendet?

0–4 Drei Stile kämpfen gegeneinander. 5–6 Eine Richtung, aber die Hälfte der Elemente driftet ab. 7–8 Kohärent, gelegentliches Abdriften auf Randseiten. 9–10 Jedes Element argumentiert für dieselbe These.

2. Visuelle Hierarchie · 视觉层级

Kann ein Fremder erkennen, was zuerst, zweitens, drittens zu lesen ist – ohne Anleitung?

Hinweise, auf die zu achten ist:

• Ist die größte Schriftart eindeutig das Wichtigste auf jeder Seite?
• Entsprechen die Rollen von Mono / Serif / Sans der Rolle der Information (Meta / Fließtext / Anzeige)?
• Gibt es viele „laute“ Elemente, die miteinander konkurrieren? Oder eine klare primäre + sekundäre + tertiäre Ebene?

0–4 Alles schreit. 5–6 Hierarchie funktioniert auf Heldenseiten, bricht aber bei Fließtexten. 7–8 Klare Ebenen, gelegentliche Kollisionen. 9–10 Das Auge bewegt sich ohne Widerstand.

3. Detailausführung · 细节执行

Die 90/10-Dinge – Ausrichtung, Zeilenabstand, Kerning bei großen Schriftgraden, Bildrahmung, Fuß-/Chrome-Politur, Randabstände.

Hinweise, auf die zu achten ist:

• Seiten mit großen Zahlen: Steht die Zahl auf der Grundlinie oder schwebt sie?
• Sind die oberen Kanten linker/rechter Spalten in grid-2-7-5 ausgerichtet?
• Sind frame-img- + Bildunterschriften-Proportionen über mehrere Seiten konsistent?
• Mono-Labels: gleicher Buchstabenabstand? gleiche Großschreibungsregel?
• Gibt es einsame <br>, die einzeilige Wortumbrüche verursachen?

0–4 Sichtbare Klebeband- und Bindfadenlösungen. 5–6 Die meisten Seiten sauber, 1–2 unsauber. 7–8 Poliert, geschultes Auge findet 2–3 Mängel. 9–10 Magazingualität – die Art von Detail, die handgesetzte Typografen nicken lässt.

4. Funktionalität · 功能性

Arbeitet das Artefakt für seinen beabsichtigten Zweck? Klickziele, Navigation, Lesbarkeit auf Präsentationsentfernung, Kopierbarkeit von Code-Blöcken, ggf. mobile Fallbacks.

Hinweise, auf die zu achten ist:

• Deck: Tastatur-/Mausrad-/Touch-Navigation funktionsfähig? Iframe-Scroll-Fallback?
• Landing: CTA oberhalb der Falte? Telefonnummer auf Mobilgeräten antippbar?
• Runbook: Code-Blöcke kopierbar, Mono-Schriftart, keine „intelligenten“ Anführungszeichen?
• Kritische Informationen aus 4 m Entfernung lesbar (Großbildschirmpräsentation)?

0–4 Visuell in Ordnung, erfüllt aber seine Aufgabe nicht. 5–6 Kernablauf funktioniert, Sonderfälle sind defekt. 7–8 Robust bei normaler Nutzung. 9–10 Defensiv konstruiert – funktioniert zuverlässig bei Iframe / Vollbild / Einfügen / Drucken.

5. Innovation · 创新性

Geht dies über den Durchschnitt hinaus? Gibt es ein Element, das die Leute näher heranholt?

Hinweise, auf die zu achten ist:

• Eine unerwartete Layout-/Bewegungs-/Typografie-Maßnahme, die nicht erforderlich war?
• Oder 100% sicher – könnte jedes Deck/Landing einer beliebigen Agentur sein?
• Ist die Innovation verdient (entspricht der Richtung) oder aufgesetzt (zufälliges WebGL in einem Kinfolk-Slow-Living-Deck)?

0–4 Generischer KI-Schrott-Durchschnitt. 5–6 Kompetent und unvergesslich. 7–8 Ein einprägsamer Moment, der Rest solide. 9–10 Mehrere Maßnahmen, die man stehlen würde – aber jede dient offensichtlich der These.

Bewertungsdisziplin (vor dem Bewerten lesen)

• Immer Belege zitieren – „Auf 4 bewertet, weil die Heldenseite Playfair-Display und Inter-Sans in derselben Zeile mischt“ ist besser als „fühlt sich inkonsistent an“. Zahlen ohne Belege werden abgelehnt.
• Nicht aufrunden – wenn Hierarchie 5 ist, weil Seite 3 defekt ist, nicht auf 7 erhöhen, weil Seiten 1 und 2 in Ordnung sind. Die Bewertung ist das schlechteste durchgängige Band.
• Nicht aufwerten – eine 7 bedeutet stark, nicht akzeptabel. Wenn jede Bewertung 7+ ist, bewerten Sie nicht kritisch.
• Innovation darf niedrig sein – 5/10 ist für Produktionslieferungen in Ordnung. Bestrafen Sie nicht angemessenen Konservatismus.

Arbeitsablauf

Schritt 1 – Artefakt beschaffen

Drei Modi:

1. Projektdatei – Benutzer sagt „Überprüfe die index.html, die ich gerade erstellt habe“: Öffnen Sie sie aus dem Projektordner.
2. Eingefügtes HTML – Benutzer hat Code in den Chat eingefügt: Lesen Sie ihn aus der Nachricht.
3. Von Ihnen in diesem Durchlauf erstellt – Sie haben gerade ein Artefakt oben ausgegeben und möchten es selbst kritisieren: Lesen Sie Ihr eigenes <artifact> erneut.

Wenn mehrere HTML-Dateien vorhanden sind, fragen Sie, welche überprüft werden soll (überprüfen Sie nicht alle).

Schritt 2 – Genug lesen, um zu bewerten

Überfliegen Sie das gesamte <style>, lesen Sie dann 6–8 repräsentative Inhaltsblöcke. Bewerten Sie nicht allein anhand der Frontmatter. Die Bewertung hängt von der ausgeführten Gestaltung ab, nicht von der erklärten Absicht.

Schritt 3 – Mit Belegen bewerten

Schreiben Sie für jede der fünf Dimensionen die Punktzahl und einen Belegabsatz von 30–80 Wörtern, der konkrete Elemente nennt. Verwenden Sie Zeilennummern, Klassennamen, Seitennummern.

Beispiel:

Dimension: Detailausführung
Punktzahl: 6 / 10
Belege: Stat-Karten auf Seite 3 sind sauber ausgerichtet (grid-6, 3×2), aber auf Seite 8 sitzt der Fuß der rechten Spalte 2vh höher als der linke, weil .callout einen oberen Rand von 3vh hat, die Abbildung jedoch nicht. Bildunterschriften verwenden auf Seite 5 Mono, aber auf Seite 7 Sans – entscheiden Sie sich für eines.

Schritt 4 – Aktionslisten erstellen

Fassen Sie die 5 Belegabsätze zusammen in:

• Beibehalten (3–5 Aufzählungspunkte) – konkrete funktionierende Dinge, die der Benutzer im nächsten Iterationsschritt nicht kaputt machen darf. Mit Klasse / Seite / Element zitieren.
• Beheben (3–6 Aufzählungspunkte) – Muss-Tun, geordnet nach eingesparter visueller Kosten pro aufgewendeter Minute. Jeder Aufzählungspunkt ≤ 1 Satz.
• Schnelle Erfolge (3–5 Aufzählungspunkte) – jeweils 5–15 Minuten, hohes Signal-Rausch-Verhältnis (z.B. „Ersetze display:flex durch grid auf Seite 4, um die Spaltenverschiebung zu beheben“).

Schritt 5 – Bericht-HTML ausgeben

Erstellen Sie eine einzelne Datei:

• Kopfzeile: Artefaktname + Prüferangabe + Datum
• Großes Radardiagramm (SVG)
• 5 Dimensionskarten in einem 1- oder 2-Spalten-Raster
• Drei Aktionslisten am Ende mit Kontrollkästchen-Funktion

Verwenden Sie das aktive DESIGN.md-Token, falls vorhanden; andernfalls verwenden Sie ein neutrales helles Thema (off-white Hintergrund, nahe-schwarzer Text, eine Akzentfarbe für Radarfülle).

Ausgabevereinbarung

<artifact identifier="critique-<artefakt-slug>" type="text/html" title="Critique · <Artefakt-Titel>">
<!doctype html>
<html>...</html>
</artifact>

Ein Satz vor dem Artefakt („Überprüft X in fünf Dimensionen, siehe Bericht unten.“) und Stopp nach </artifact> – den Bericht nicht im Chat paraphrasieren; der Benutzer liest das Artefakt.

Harte Regeln

• 5 Bewertungen, jedes Mal – Teilberichte (z.B. nur 3 Dimensionen) sind nicht erlaubt.
• Belege pro Bewertung – kein „fühlt sich falsch an“ / „muss verbessert werden“. Wenn Sie kein Element zitieren können, ist die Bewertung nicht gerechtfertigt.
• Nicht aufwerten – Gesamtmittelwert über 8 ist verdächtig; überprüfen Sie sich selbst.
• Nicht Ihr eigenes Artefakt im selben Durchlauf überprüfen – der Benutzer muss es zuerst sehen. Selbstkritik nur auf ausdrückliche Anfrage („jetzt kritisiere, was du gerade erstellt hast“).
• Nur einzelne HTML-Datei – kein externes CSS/JS. Alles inline einbetten.
• Radardiagramm ist obligatorisch – gibt dem Bericht eine erkennbare Silhouette und erlaubt dem Benutzer, schwache Achsen auf einen Blick zu erkennen.