Verwenden von /probe, um KI-Halluzinationen zu erkennen, bevor Code geschrieben wird

Was /probe macht

Die /probe-Technik zwingt KI-generierte Pläne dazu, jede aufgestellte Behauptung als nummerierte CLAIM mit einem EXPECTED-Wert auszugeben. Anschließend führt sie einen Befehl aus, um das reale System abzufragen, und erfasst die Differenz zwischen erwarteten und tatsächlichen Ergebnissen.

Praktisches Beispiel aus der Quelle

Ein Entwickler versuchte, Claudes JSONL-Sitzungsdateien unter ~/.claude/projects/... zu parsen. Claude beschrieb das Format selbstbewusst, aber die Ausführung von /probe deckte vier Halluzinationen auf:

• Behauptung 1: Die KI sagte, es gäbe 2 Top-Level-Typen (user, assistant). Realität: 7 Typen, darunter queue-operation, file-history-snapshot, attachment, system, permission-mode und summary.
• Behauptung 2: Die KI sagte, Assistant-Inhalt = text + tool_use. Realität: Thinking-Blöcke wurden übersehen, die etwa ein Drittel der Assistant-Ausgabe im erweiterten Denkmodus ausmachen.
• Behauptung 3: Die KI sagte, User-Inhalt sei immer ein Array. Realität: Polymorph: string ODER array.
• Behauptung 4: Die KI sagte, Ordnernamen ersetzen / durch -. Realität: Tatsächlich wird ein Bindestrich vorangestellt, dann ersetzt.

Ohne /probe hätte der jq-Filter bei String-User-Inhalten einen Fehler ausgegeben, Thinking-Blöcke als Müll ausgegeben und 5 von 7 Nachrichtentypen vollständig übersehen.

Wie die Probe funktioniert

Die KI schreibt Behauptungen wie "EXPECTED: 2 types", bevor sie Befehle wie jq -r '.type' file.jsonl | sort -u ausführt. Eine Probe-Ausgabe sah so aus:

CLAIM 1: JSONL hat 2 Top-Level-Typen (user, assistant)
EXPECTED: 2
COMMAND: jq -r '.type' *.jsonl | sort -u | wc -l
ACTUAL: 7
DELTA: +5 unbekannte Typen (queue-operation, file-history-snapshot, attachment, system, permission-mode, summary)

Wesentliche Erkenntnisse aus der Quelle

Die Behauptungen, die es wert sind, abgefragt zu werden, sind oft die, bei denen die KI am selbstbewusstesten ist. Wenn die KI zögert, weiß man bereits, dass man nachprüfen muss. Wenn sie X einfach behauptet, tut man das nicht. Hochvertrauensbehauptungen sind, wo Halluzinationen versteckt sind.

Ein weiterer Vorteil ist, dass eine Probe zu N permanenten Tests wird. Die 7-Typen-Erkenntnis wird zu einem Schema-Test, der im CI fehlschlägt, wenn ein neuer Typ auftaucht. Die String-oder-Array-Erkenntnis wird zu einem Eigenschaftstest, der beide Formen fuzzes. Wenn sich das Upstream-Format ändert, schlägt der Test fehl, man führt die Probe erneut aus und das Orakel aktualisiert sich.

Einschränkungen und Verbesserungen

Die Probe erfasst nur Behauptungen, die die KI zu machen denkt. Unbekannte Unbekannte bleiben unsichtbar. Dinge, die helfen:

• Zuerst jq 'keys' ausführen, um die Realität aufzuzählen, bevor Behauptungen generiert werden
• Dex Horthys CRISPY-Muster drängt die KI dazu, ihre eigene Lückenliste aufzuzeigen
• GitHubs Spec Kit verwendet [NEEDS CLARIFICATION]-Markierungen in Spezifikationen, um die KI zu zwingen, blinde Flecken zu markieren
• Eine menschliche Überprüfung der Behauptungsliste wird ebenfalls empfohlen

Kontrast zu traditionellem TDD

Traditionelles TDD schreibt Tests basierend auf dem, was man DENKT, passieren sollte. Probe-gesteuertes TDD schreibt Tests basierend auf dem, was man gespiked oder VERIFIZIERT hat, dass es passiert. Mocks testen Ihr Modell des Systems. Die Probe testet das System selbst.

Quelldateien

Der Entwickler teilte die vollständige /probe-Skill-Datei in einem Gist mit zwei Dateien:

• README.md: Längere Ausarbeitung mit dem REPL-als-Orakel-Ansatz und TDD-Kontrast
• probe-skill.md: Das 7-Schritte-Protokoll, geladen als Claude Code Skill

Das Muster ist einfach "Behauptungstabelle + Real-System-Probe + Differenz erfassen" und funktioniert mit jedem REPL oder CLI-Tool, das das System abfragen kann, gegen das Sie programmieren wollen.