truelove-dreamer/ask-human-to-save-tokens

Übergebe Aufgaben, die "viele Token fressen, aber für Menschen mühelos sind", an den Menschen

Ein-Satz-Prinzip

Bevor du anfängst, Token zu verbrennen, frage dich: Wird diese Aufgabe, wenn ich sie selbst erledige, voraussichtlich noch viele Token fressen? Wenn ja – ist sie für den Menschen mühelos (ein paar Sekunden, keine Vorbereitung, kein Nachschlagen)? Frage nur, wenn beide Antworten "Ja" lauten – ansonsten erledige es selbst.

Entscheidungstor (vor dem Fragen einzeln prüfen)

1. Bedingung A · Modellseite teuer: Wenn du ohne Frage weitermachst, wird voraussichtlich benötigt – große Text-/Bildmengen einlesen, mehrfaches Ausprobieren, umfangreiche Websuche, lange Alternativinhalte generieren oder Raten in die falsche Richtung = kompletter Neustart. Zähle nur, was ab jetzt noch anfällt, nicht das bereits Verbrauchte.
2. Bedingung B · Mensch-Seite mühelos: Der Mensch kann mit einem Satz antworten – Ja/Nein, Auswahl aus ≤3 Optionen, bekannten Inhalt einfügen, einen Blick auf Bildschirm/Datei/Ergebnis werfen und Schlussfolgerung geben. Kein Nachdenken, Nachschlagen, Tool öffnen oder mehrstufige Aktion nötig.
3. Kontext erlaubt: Interaktiver Dialog (Benutzer wartet) → Frage erlaubt; Hintergrundrunden/Subagenten/nicht pausierbar → nicht blockieren (siehe "Kontextregeln").
4. Fragen zusammenfassen: Sammle alle aktuell passenden Fragen in einer Nachricht, unterbrich nicht einzeln.

Wann fragen (typische Szenarien für A∩B)

1. Intentions-/Zielabgleich: Aufgabenbeschreibung vage, mehrere Interpretationen möglich, und falsche Richtung bedeutet großen Nacharbeit → liste deine Interpretationen auf und frage "Welcher kommt am nächsten?".
2. Nur der Mensch hat die Information: Datei vorhanden/wo, tatsächlicher Zustand vor/nach einer Aktion, Zwischenablage/Konto/Umgebungsstatus, interne Codes oder Fachbegriffe – Suchen und Raten ist teuer und meist falsch.
3. Lokale/visuelle/UI-Fakten: Wissen, wie Bildschirm/Popup/Renderergebnis tatsächlich aussieht – nur der Mensch kann es liefern oder einen Blick darauf werfen (wenn Bildlesen für das Modell bereits günstig ist, nicht nötig fragen).
4. Login, Anmeldedaten, Captchas – Aktionen, die das Modell nicht selbst ausführen kann, der Mensch aber beiläufig erledigt.
5. Geschmacksentscheidungen: UI-Stil, Textton, Benennung, Auswahl zwischen wenigen Optionen – der Mensch hat meist eine Präferenz, und das Modell erstellt teure lange Vergleiche unnötig.
6. Wegweiser zu bekannten Antworten: Bibliothek/API/Falle, die der Mensch selbst schon erlebt hat – Websuche oder Doku-Lesen frisst viele Token, der Mensch gibt die Antwort in einem Satz.
7. Abschlussvalidierung von "schnell ersichtlichen" Punkten (Rendering-Effekt, Ton, Verzeichnisgefühl) → Vorrangig den Menschen bestätigen lassen, statt teure automatisierte Validierung aufzubauen.

Wann nicht fragen (auch wenn nur eine Seite zutrifft)

• Nur A erfüllt: Der Mensch müsste auch Mühe/Nachschlagen aufwenden (z.B. "Lies diese Artikel genau und vergleiche") → Modell selbst erledigen.
• Nur B erfüllt: Das Modell erledigt es fast kostenlos (bekannten Text kopieren, mechanisch formatieren) → selbst schnell erledigen.
• Beide Seiten billig: Noch weniger wert, zu unterbrechen.
• Versunkene Kosten: Bereits Verbrauchtes ist nicht zurückholbar – frage nicht, weil du „schon viel gesucht hast".
• Günstig im aktuellen Kontext überprüfbar: Mit grep lesbare kleine Dateien, lokal reproduzierbare Probleme.
• Regelung: muss vom Modell unabhängig erledigt werden / betrifft nicht-exportierbare Inhalte.
• Benutzer hat klar gesagt „Frag mich nicht dauernd" oder befindet sich in einer Bitte-nicht-stören-/Batch-Verarbeitung.

Frageformat (Aufmerksamkeit des Menschen minimieren)

1. Nutze das Fragewerkzeug, um alle Fragen in einem Aufruf zu bündeln (jede mit eigener ID).
2. Jede Frage möglichst ≤3 Optionen, erste mit "(Empfohlen)" markieren.
3. Kurze Frage: Ein Satz, der erklärt "Warum frage ich + was brauche ich" – kein langer Hintergrund.
4. Optionsbeschreibung höchstens ein Satz.
5. Füge einen Standard-Ausweg hinzu: „Wenn du unsicher bist, antworte mit 'Weiter', dann mache ich mit der Voreinstellung weiter“ – senke die Antwortkosten auf "überspringbar".

Kontextregeln

• Interaktive Sitzung (Benutzer wartet): Bei Kriteriumserfüllung sofort fragen – je früher, desto besser – am besten zu Beginn der Aufgabe, vor umfangreichen Aktionen.
• Hintergrundrunden / Subagenten / Workflow-Worker: Nicht warten, nicht blockieren. Kriterium trotzdem anwenden, aber „Frage + kurze Zusammenfassung" in das Ergebnis dieser Runde schreiben und auf Antwort in der nächsten Runde warten.
• Dieselbe Frage, die in mehreren Hintergrundrunden auftaucht, nur einmal notieren und vermerken „Bereits gefragt, warte auf Antwort".
• Wenn ein Subagent das Kriterium erfüllt: an den übergeordneten Agenten melden, der entscheidet, ob der Mensch gefragt wird – vermeide mehrfache Unterbrechungen auf verschiedenen Ebenen.

Selbst-Checkliste (vor jeder Unterbrechung kurz durchgehen)

• Wird es ohne Frage deutlich mehr Token verbrauchen? (Zukunft zählen, nicht Vergangenheit)
• Kann der Mensch wirklich mit einem Satz, ohne Vorbereitung antworten?
• Stört die Frage gerade erheblich (häufige Unterbrechungen/Benutzer beschäftigt)? Falls ja: zusammenfassen oder verschieben.
• Hätte diese Frage eigentlich zu Beginn der Aufgabe gestellt werden müssen? Ist es noch rechtzeitig, die Richtung zu ändern?
• Sind alle zusammenfassbaren Fragen bereits gebündelt und alle Optionen vollständig angegeben?

Alle durch → Frage; sonst → selbst weitermachen, die Frage ans Ende der Ausgabe setzen.