multi-evaluator

Multi-Evaluator Design-Verbesserungsschleife

Runden unabhängiger Überprüfungen, bis das Produkt bereit für Menschen ist: Jede Journey erzielt von jedem Prüfer eine Bewertung von 9 oder besser, kein hochgradiger Fehler ist offen, die Prüfer stimmen innerhalb eines Punktes überein und das hält zwei Runden in Folge an. Ein einstimmiges 10 ist ein Hinweis, den Auftrag doppelt zu überprüfen, nicht das Ziel. KI-Bewertungen sind ein starkes Signal, kein Beweis: Wenn die Schleife „bereit“ sagt, testen echte Erstanwender das Produkt, und wo sie der KI widersprechen, gewinnen die Menschen.

Alles läuft über ein einziges Kommandozeilen-Tool, scripts/eval_loop.py (neben dieser Datei), sodass eine Person, dieser Agent oder jeder andere Agent die gleichen Ergebnisse erhält. Jeder Befehl akzeptiert --dir <Review-Ordner>, und status --json sagt immer, wo die Schleife steht und was als nächstes zu tun ist. Erfordert Python 3.9 oder höher, Node.js 18 oder höher und Google Chrome oder Chromium. Nichts weiter zu installieren.

Im Folgenden bedeutet LOOP python3 <Ordner dieser Fähigkeit>/scripts/eval_loop.py.

Bevor Sie beginnen (jede mStack-Fähigkeit)

• Wenn ~/.mstack/config.json multi-evaluator unter "disabled" aufführt oder die Person gesagt hat, sie nicht für diese Aufgabe zu verwenden, arbeiten Sie auf die übliche Weise.
• Wenn ~/.mstack/learned/multi-evaluator.md existiert, lesen Sie es: Es enthält die akzeptierten Verbesserungen dieser Person, und sie haben Vorrang vor dieser Datei.
• Wenn die Schleife endet (oder stoppt), zeichnen Sie privat auf, wie es gelaufen ist: python3 <mstack-Fähigkeitsordner>/scripts/mstack.py log multi-evaluator --outcome erreicht|teilweise|nicht-erreicht --needed-user "..." --stalled "..." (die mStack-Fähigkeit liegt neben dieser).

1. Journeys und Kriterien zuerst

Vor jeder Überprüfung: Mit der Person vereinbaren, was eine reale Person von Anfang bis Ende können muss.

1. LOOP init --dir design-review --name "<Produkt>" --start "<Befehl, der es startet, mit {port}>" --cwd <sein Ordner> (oder --url <Adresse> für etwas, das bereits läuft, z. B. eine Staging-Site).
2. Füllen Sie design-review/mstack-eval.json mit der Person aus. Siehe references/config.md für jedes Feld:
   • about und persona: Was das Produkt ist und wer es beurteilt. Halten Sie die Designrichtung und etwaige Einschränkungen aus about heraus und in rules: Diese werden den Prüfern als „nicht bewertet“ gezeigt, sodass das Briefing niemals die Antwort verrät, die Sie zu hören hoffen.
   • journeys: 3 bis 6 reale Aufgaben, jeweils von Anfang bis Ende („Ein Buch hinzufügen und in der Liste sehen“).
   • views: Die festgelegten Bildschirme, die in jeder Runde erfasst werden (Desktop, Telefon, dunkles Design). Helles Design zuerst.
   • criteria: Der Mindeststandard ist klar, schnell, vertrauenswürdig, vertraut, ruhig, funktioniert überall. stages fügen weitere Kriterien hinzu, wenn das Produkt reift (Time-to-Value, Fehlerbehebung, Text, Agentenerfahrung, gemessene Barrierefreiheit, Geschwindigkeit, Fünf-Sekunden-Test, emotionale Tonalität, Konsistenz, Datensicherheit, Begeisterung). Schalten Sie eine Stufe mit "active": true oder "from_round": <n> ein, wenn die Bewertungen zeigen, dass der Mindeststandard erfüllt ist.
   • reviewers: Mindestens zwei, von verschiedenen KI-Herstellern. Die Standardeinstellung ist Claude (von Ihnen, dem Agenten, ausgeführt) und Codex (vom Tool mit codex exec ausgeführt).
   • control: Der Rauschcheck (empfohlen). Die erste Aufnahme friert die Bildschirme dieser Runde in control/ ein; jeder Prüfer bewertet sie in jeder Runde als Journey control, und der Bericht zeigt, wie weit sich diese Bewertung bewegt hat. Eine Änderung, die kleiner ist als diese Bewegung, ist Rauschen, kein Fortschritt.
3. Zeigen Sie der Person die Journeys und Kriterien und holen Sie vor Runde 1 ein Ja ein.

2. Jede Runde

LOOP start-round --dir design-review          # erstellt rounds/r<N>/, macht einen Schnappschuss der Kriterien dieser Runde
                                               # schreibe rounds/r<N>/changes.md: was sich geändert hat, je ein Aufzählungspunkt
LOOP capture --dir design-review              # dieselben Bildschirme, auf dieselbe Weise erfasst, jede Runde
LOOP brief --dir design-review                # blinde Bewertungsbriefings in rounds/r<N>/briefs/, plus -Vergleichsbriefings ab Runde 2
LOOP review --dir design-review               # führt Kommandozeilen-Prüfer (Codex) parallel aus; im Hintergrund ausführen

Führen Sie gleichzeitig jeden Prüfer, dessen kind agent ist, selbst in frischem Kontext aus:

• Claude Code: Starten Sie einen Subagenten (das Agenten-Tool, allgemeiner Zweck), dessen Prompt der vollständige Text von rounds/r<N>/briefs/claude.md ist. Fügen Sie Ihre eigenen Meinungen, die erwartete Antwort oder frühere Bewertungen nicht hinzu.
• Jeder andere Agent: Öffnen Sie eine neue Sitzung oder einen neuen Thread mit dem Briefing als einziger Anweisung.
• Ein Prüfer von kind: "chat" (optional, Opt-in: Grok, ChatGPT oder Gemini im eigenen angemeldeten Browser der Person, kein API-Schlüssel): Nur mit dem Ja der Person, was geteilt werden darf, einen neuen privaten Chat öffnen, rounds/r<N>/briefs/<id>.md einfügen, die festgelegten Bildschirme dieser Runde hochladen, wenn das Produkt nicht öffentlich ist, die Antwort speichern, den Tab schließen, dann verdict. Es sieht Screenshots, nicht das Live-Produkt, also ist es ein Tie-Breaker: Es zählt niemals zu „bereit für Menschen“ und kann niemals der einzige Prüfer sein.

Wenn es antwortet, speichern Sie sein JSON (das Tool prüft es und lehnt eine Antwort ab, die nicht dem Format entspricht):

LOOP verdict --dir design-review --reviewer claude reply.json      # oder die Antwort mit - per Pipe einlesen

Zuerst blind, dann vergleichen. Das Bewertungsbriefing zeigt nur diese Runde: keine früheren Screenshots, keine früheren Bewertungen, keine Designrichtung, sodass die Bewertung in Runde 1 und Runde 9 dasselbe bedeutet. Ab Runde 2 gibt es auch rounds/r<N>/briefs/<reviewer>-compare.md. Geben Sie es demselben Prüfer nachdem sein Urteil gespeichert wurde (die gleiche Sitzung ist in Ordnung; sie ist nicht mehr blind), und speichern Sie die Antwort getrennt von der Bewertung:

LOOP verdict --dir design-review --reviewer claude --compare compare-reply.json
LOOP report --dir design-review                                     # schreibt design-review/report.html

Der Vergleich ändert niemals eine Bewertung; der Bericht zeigt ihn unter „Was sich geändert hat“.

Zeigen Sie der Person dann den Bericht und die Screenshots mit hellem Design (rounds/r<N>/shots/). Senden Sie ihr eine Benachrichtigung, wenn Ihr Agent dazu in der Lage ist (in Claude Code, PushNotification), wenn ein Rundenbericht fertig ist oder die Schleife eine Entscheidung benötigt; der notify-Befehl der Konfiguration kann ebenfalls eine senden (siehe references/config.md).

3. Beheben, dann wiederholen

1. Beginnen Sie mit der Liste Als nächstes tun aus dem Bericht (zuerst Korrekturen an einer Journey, die jeder Prüfer markiert hat, dann hohe Schwere, dann die größte „if fixed“-Lücke). Wenn die Journeytabelle besagt, dass die Prüfer um 2 oder mehr abweichen, sehen Sie sich diese Journey selbst an, bevor Sie auf eine der Bewertungen reagieren.
2. Nehmen Sie die Korrekturen im Produkt vor, führen Sie dessen eigene Tests aus und schreiben Sie das changes.md für die nächste Runde.
3. LOOP start-round und wiederholen, bis LOOP status bereit für Menschen sagt (die obige Stoppregel, zwei Runden gehalten). Wenn eine Runde besteht, ändern Sie nichts Großes und führen Sie eine weitere aus, damit sie Bestand hat. Nach max_rounds (Standard 6) ohne Erreichen sagt status, dass gestoppt und mit der Person gesprochen werden soll: Die Journeys oder Kriterien verlangen möglicherweise etwas, das das Produkt nicht tun sollte.
4. Dann echte Menschen: Fünf Erstanwender versuchen die Journeys ohne Hilfe. Notieren Sie ihre Zeit, Stolperer und Wörter in rounds/r<N>/people.md (je ein Aufzählungspunkt; der Bericht zeigt sie). Wo sie den KI-Prüfern widersprechen, gewinnen die Menschen: Wandeln Sie ihre Erkenntnisse in Journeys oder Kriterien für die nächste Runde um.

Regeln

• Prüfer sehen niemals die Urteile der anderen, frühere Runden, frühere Bewertungen oder den Bericht während der Bewertung; das Briefing teilt ihnen dies mit. Der Vergleich mit der letzten Runde ist ein separater Durchlauf nach dem Urteil.
• Dieselben Ansichten, auf dieselbe Weise erfasst, jede Runde, damit Vorher und Nachher gleich verglichen werden.
• Lassen Sie niemals zu, dass ein Prüfer echte Zahlungen, Nachrichten oder personenbezogene Daten übermittelt. Verwenden Sie Demodaten und eine frische Kopie.
• Sandbox-Prüfer (Codex) können Chrome nicht starten: review startet einen gemeinsam genutzten Headless-Chrome, und das Briefing teilt ihnen mit, MSTACK_CDP_PORT=<port> vor den Treiberbefehl zu setzen.
• Wenn die Antwort eines Prüfers nicht passt, lesen Sie rounds/r<N>/work/<reviewer>/raw-reply.txt und führen Sie sie erneut aus. Das Tool verweigert eine 10, die noch Korrekturen vorschlägt, und einen „if fixed“-Wert unter der Bewertung.
• Bewahren Sie den Review-Ordner im Repository des Produkts (oder daneben) auf, damit jede Runde erhalten bleibt.

Dateien

• scripts/eval_loop.py: Das Kommandozeilen-Tool (init, status, start-round, capture, brief, serve, review, verdict, validate, report, notify).
• scripts/drive.mjs: Der Journeytreiber, ein echter Headless-Chrome; Prüfer verwenden ihn direkt.
• scripts/report.py: Der Berichtsersteller. scripts/readiness.py: Die Stoppregel und der Rauschcheck.
• templates/mstack-eval.json: Die Startkonfiguration.
• references/config.md: Jedes Konfigurationsfeld. references/verdict-format.md: Das Antwortformat. references/method.md: Warum die Schleife so funktioniert und wie die Kriterien wachsen.