F-Modus — Filter-First-Modus
Prinzip: Rohdaten gelangen nie in den Kontext; nur das Ergebnis tut es. Verlagere die Logik zu den Daten (eine Shell-Pipeline, ein kurzes Skript, ein Unteragent) und bringe eine kompakte Zusammenfassung zurück. Jedes Token eines Logdumps, das du liest, ist ein Token, das du nicht für das Reasoning ausgeben kannst – und langer, verrauschter Kontext verschlechtert das Reasoning, nicht nur, dass es teurer wird.
1. Vor dem Lesen filtern und aggregieren
| Stattdessen | Mach dies |
|---|---|
cat app.log | `grep -c ERROR app.log; grep -E 'ERROR |
| eine 5 MB große JSON lesen | jq '.items | length', jq -r '.items[] | [.id,.status] | @tsv' | sort | uniq -c |
SELECT * FROM orders | SELECT status, count(*) FROM orders GROUP BY 1 |
git log | git log --oneline -20, git log --format=%s origin/main..HEAD |
| in einer Datei scrollen | grep -n 'def handle' file.py, dann mit Offset/Limit lesen |
2. Filtern darf niemals Fehler verstecken
Eine abgeschnittene Ansicht, die grün aussieht, ist schlimmer als gar keine Ansicht.
- Behalte den Exit-Code:
set -o pipefail, odercmd > out.txt 2>&1; echo "exit=$?"; tail -20 out.txt. Direktes Piping intailverliert den Exit-Code des Befehls. - Greife zusätzlich zu
tailauch nach Fehlermarkern:grep -cE 'FAIL|ERROR|Traceback|panic' out.txt. - Gib Zählwerte mit Nennern aus:
bestanden 41/42, niemals nur „OK".
pytest -q --tb=short > /tmp/t.out 2>&1; echo "exit=$?"
grep -cE 'FAILED|ERROR' /tmp/t.out; tail -15 /tmp/t.out
3. Viele ähnliche Prüfungen → ein Skript, eine Tabelle
Zehn Endpunkte, zwanzig Dateien, dreißig zu validierende Zeilen: schreibe ein Skript, das schleift und eine kompakte Tabelle (name | status | detail) plus Summen ausgibt. Nicht zehn Tool-Aufrufe mit zehn vollständigen Ausgaben.
for u in / /api/health /api/items; do
printf "%-14s %s\n" "$u" "$(curl -s -o /dev/null -w '%{http_code}' "localhost:8000$u")"
done
4. Prüfe die Zusammenfassung auf Bedeutung, nicht auf Form
Gültig aussehende Ausgabe kann trotzdem falsch sein. Vergleiche mit einem erwarteten Wert oder einer Plausibilitätssumme: Die Zählwerte summieren sich zur Eingabegröße, eine bekannte Zeile ist vorhanden, die Anzahl der Dateien stimmt mit ls | wc -l überein. Wenn eine Zusammenfassung nicht gegengeprüft werden kann, sag dies.
5. Tests
Stiller Modus, kurze Tracebacks, Ende des Fehlerbereichs:
pytest -q --tb=shortvitest run --reporter=dot,jest --silentgo test ./... 2>&1 | grep -E '^(FAIL|ok|---)'cargo test -q
6. Browser-Checks
Werte ein Skript aus, das kompaktes JSON zurückgibt ({title, errors: n, buttons: n, overflowX: bool}) anstatt vollständige DOM-Snapshots. Mache nur dann einen Snapshot, wenn die DOM-Struktur selbst die Frage ist. Screenshots für visuelle Checks, nicht zum Lesen von Text.
7. Breite Untersuchung → Unteragent
Große Suchen, Log-Forensik, Datenbank-Dumps: Delegiere an einen Unteragenten, der Schlussfolgerungen mit file:line-Referenzen zurückgibt. Sein Ergebnis ist immer noch eine Behauptung – verifiziere die wichtigsten Punkte, bevor du danach handelst.
8. Geheimnisse und personenbezogene Daten
Gib niemals Geheimnisse oder echte personenbezogene Daten in Zusammenfassungen oder Diagnosen aus. Maskiere (postgres://***) oder zähle sie (E-Mails gefunden: 12). Maskiere auch Verbindungsstrings und Schlüssel in abgefangenen Ausnahmen.
9. Dateien lesen
grep -nzuerst, dann nur den relevanten Bereich mit Offset/Limit lesen.- Quellcode, den du gleich bearbeiten wirst, wird vollständig gelesen – Teilauslesen führt zu kaputten Änderungen.
- Lies eine Datei nicht direkt nach der Bearbeitung erneut, um sie zu „verifizieren"; das Edit-Tool meldet bereits Fehler bei Misserfolg.
10. Stopp-Regel
Der gleiche Fix ist zweimal fehlgeschlagen → stopp. Finde die Ursache anhand der genauen Fehlerzeile oder frage nach. Kein dritter blinder Versuch.
11. Kontext-Hygiene
- Bereinige den Kontext zwischen nicht zusammenhängenden Aufgaben; komprimiere lange Sitzungen.
- Deaktiviere Plugins, Skills und MCP-Server, die du in diesem Projekt nicht nutzt: Jeder kostet Prompt-Token in jeder Anfrage.
- Bewerte Einsparungen anhand echter Nutzungszahlen (z. B.
/cost), nicht anhand von behaupteten Prozenten.