Eigne dir die drei Reflexe der Praxis an - mit der offiziellen Dokumentation abgleichen, selbst testen, nach Halluzinationssignalen suchen -, bevor du irgendetwas übernimmst.
Diese Lektion in Kodokon öffnenEine Halluzination ist keine absurde Antwort: Sie ist eine plausible und falsche Antwort - eine Methode, die es geben müsste, aber nicht gibt, eine vor zwei Versionen umbenannte Option, ein umgedrehtes Standardverhalten. Genau das macht kompetente Entwicklerinnen und Entwickler angreifbar: Halluzinierter Code ist idiomatisch, gut benannt, stimmig mit dem Ökosystem. Er sieht richtig aus. Drei nicht verhandelbare Reflexe, bevor du irgendetwas übernimmst: mit der offiziellen Dokumentation deiner Version abgleichen, den Code selbst testen in einem minimalen Kontext und die Antwort prüfen lassen - auch vom Modell selbst.
Take your previous answer and audit it as if it came from someone else.
1. List every verifiable technical claim: API or function name, described behavior, default value, version number.
2. For each, give your confidence level: certain / likely / to verify.
3. For each "to verify," state exactly what to look up in the official documentation: the name of the page, function, or module concerned.
4. Flag anything that might depend on the version or platform, specifying from which version it holds if you know.
Be harder on yourself than I would be: a claim over-rated as "certain" costs me more than one under-rated.Dieses Selbst-Audit beweist nichts - ein Modell kann überzeugt sein und trotzdem falsch liegen -, aber es verwandelt flüssige Prosa in eine Liste überprüfbarer Fakten, jeder mit seinem Einstiegspunkt in die Doku. Überprüfen musst du selbst; die KI hat nur den Boden bereitet. Lerne außerdem, die Warnsignale zu erkennen: eine API, die exakt auf deinen Bedarf zugeschnitten ist (zu schön, um wahr zu sein), eine Mischung von Konventionen verschiedener Versionen im selben Snippet, eine vollkommen gleichmäßige Zuversicht - echte Expertise sagt „es kommt darauf an“, eine Halluzination nie - und das Fehlen jeder Erwähnung einer Grenze oder eines Grenzfalls. Kein einzelnes Signal ist ein Beweis, aber jedes sollte eine Überprüfung auslösen.
You just claimed that [precise claim to verify].
1. Help me design the shortest possible test to verify it myself: the minimal file to create, the exact command to run, the precise result I should observe if you're right - and what I'll observe instead if you're wrong.
2. Then play devil's advocate: in which cases would your claim be false? Version, platform, configuration, strict mode or not - go through it all.
I'll run the test myself: don't ask me to take your word for it, give me the means to contradict you.Dieser Prompt überträgt ein wissenschaftliches Prinzip auf die tägliche Arbeit: Eine Behauptung ist etwas wert, wenn sie widerlegbar ist - wenn du weißt, was du beobachten würdest, falls sie sich als falsch herausstellt. Zehn Zeilen in einer Wegwerfdatei und ein Durchlauf schlagen jedes erklärte Zuversichtsniveau. Für den Abgleich mit der Doku drei Gewohnheiten: in der Doku deiner Version nachsehen (Modelle mischen munter verschiedene Epochen einer API), das Changelog prüfen, wenn sich ein Verhalten geändert zu haben scheint, und jederzeit eine REPL oder eine Kritzeldatei offen halten - die Kosten des Überprüfens sollen so niedrig sein, dass du nie eine Ausrede hast, den Schritt zu überspringen.