Hauptgedanke

Ein Product Manager, der einem Assistenten eine Produktchance erklärt, hat ein Gegenüber, das nichts davon weiß und aus Höflichkeit keine Lücke füllt. Man muss das Ziel nennen, die Einschränkungen, was bereits entschieden ist, was offen bleibt — und von vorn anfangen, wenn das Ergebnis nicht das erwartete ist, umformulieren, präzisieren.

Hier kehrt sich der Aufbau um. Erneut zu erklären stellt auf die Probe, was man verstanden zu haben glaubte: Was implizit blieb, muss aufgeschrieben werden, und ein Teil dessen, was man für gesichert hielt, übersteht das Aufschreiben nicht. Wo ein Kollege eine Ungenauigkeit mit seinem eigenen Kontext aufgefangen hätte, nimmt die Maschine sie beim Wort und liefert ein ungenaues Ergebnis — ohne sichtbaren Fehler, einfach daneben.

Der Assistent gleicht Unschärfe also nicht aus, er verstärkt sie: Ist der Kontext im Kopf dessen, der ihn beschreibt, verschwommen, wird das Ergebnis verschwommen sein, und die Qualität der Ausgabe wird zum Gradmesser für die Klarheit der Eingabe.

Warum das wichtig ist

Das macht aus einer Arbeit, die man als lästige Vorarbeit empfindet, eine Übung im Überprüfen. Die Zeit, die man ins Rahmen steckt, ist nicht nur der Preis, um etwas zu bekommen: Es ist der einzige Moment, in dem man feststellt, was man noch nicht formulieren kann.

Das erlaubt auch, ein schlechtes Ergebnis anders zu lesen. Bevor man das Modell beschuldigt, ist zu prüfen, was man ihm gegeben hat — und diese Prüfung ist oft aufschlussreicher als die Korrektur des Prompts.

Nuancen und Grenzen

Der Spiegel zeigt nicht alles. Ein vollkommen klarer und vollkommen falscher Kontext ergibt ein sauberes Ergebnis, und die Übung sagt nichts über seine Richtigkeit.

Und ein gefälliger Assistent verwischt das Signal: Erzeugt er aus einer vagen Anweisung etwas Plausibles, ist die anfängliche Unklarheit nicht mehr zu sehen.

Offene Fragen

• Wie unterscheidet man ein mittelmäßiges Ergebnis, das an einem verschwommenen Kontext liegt, von einem, das an den Grenzen des Modells liegt?