Der Kontext für Assistenten ist ein Artefakt, kein Prompt
Die Qualität dessen, was ein Assistent liefert, hängt weniger am Modell als an dem, was es über Ihr System weiß. Das ist die unspektakulärste Erkenntnis aus zwei Jahren Praxis und die mit dem größten Hebel.
Die Qualität von Assistenzergebnissen hängt stärker vom bereitgestellten Kontext ab als vom Modell. Prompts sind der falsche Ort, weil sie nicht versioniert, überprüfbar oder auffindbar sind. In eine Kontextdatei im Repository gehören fünf Dinge: Zielarchitektur mit erlaubten Abhängigkeiten, Konventionen mit Begründung, Fachbegriffe mit Bedeutung, ausdrücklich verbotene Wege, und die Risikoklassen je Bereich. Nicht hinein gehören ableitbare Informationen und Geheimnisse. Test: Einer neuen Person nur diese Datei und eine Aufgabe geben — was sie fragt, fehlt.
Warum Prompts der falsche Ort sind
Ein guter Prompt hilft einmal, für eine Person, in einem Gespräch. Er ist nicht versioniert, nicht überprüfbar und nicht auffindbar. Was für alle gelten soll — Konventionen, Grenzen, Zielarchitektur, Begriffe — gehört ins Repository, wo es mit dem Code altert und im Review mitgeprüft wird.
Was in die Kontextdatei gehört
Fünf Dinge. Erstens die Zielarchitektur mit erlaubten Abhängigkeiten: welcher Teil darf welchen kennen. Zweitens die Konventionen mit Begründung — ohne Begründung werden sie ignoriert, von Menschen wie von Modellen. Drittens die Fachbegriffe mit Bedeutung, weil ein Modell sonst branchenübliche Bedeutungen annimmt, die bei Ihnen falsch sind. Viertens die verbotenen Wege: was hier ausdrücklich nicht gemacht wird und warum. Fünftens der Hinweis, welche Bereiche in welcher Risikoklasse liegen.
Warum dieselbe Datei Menschen hilft
Der Nebeneffekt ist der eigentliche Gewinn: Was ein Modell braucht, um im Rahmen zu bleiben, braucht ein neuer Mensch auch. Organisationen, die diese Datei ernsthaft schreiben, stellen fest, dass sie damit gleichzeitig ihr Einarbeitungsproblem angegangen sind — und dass beim Schreiben Widersprüche auffallen, die vorher niemand ausgesprochen hat.
Was nicht hineingehört
Alles, was sich aus dem Code ableiten lässt — das veraltet und widerspricht dann dem Code. Und alles Geheime: Zugangsdaten, Schlüssel, interne Adressen. Eine Kontextdatei wird an Modelle übergeben; was darin steht, verlässt das Haus.
Der Test, ob sie taugt
Geben Sie einer neuen Person nur diese Datei und eine kleine Aufgabe. Was sie danach fragt, fehlt in der Datei. Diese Übung dauert einen halben Tag und ist die zuverlässigste Methode, den Kontext zu verbessern — deutlich zuverlässiger als das Ausprobieren verschiedener Formulierungen.
Häufige Fragen
Wo legt man den Kontext ab?
Im Repository, neben dem Code, versioniert und im Review mitgeprüft. Die konkrete Datei hängt vom eingesetzten Werkzeug ab; entscheidend ist, dass sie im selben Vorgang geändert wird wie der Code, auf den sie sich bezieht.
Wie lang sollte eine Kontextdatei sein?
Kurz genug, dass sie gelesen wird, und vollständig genug, dass die häufigsten Fehler ausgeschlossen sind. In der Praxis bewähren sich ein bis zwei Seiten je Bereich. Sehr lange Dateien werden weder von Menschen gelesen noch vollständig berücksichtigt.
Gehören Geheimnisse oder interne Adressen hinein?
Nein, unter keinen Umständen. Eine Kontextdatei wird an Modelle übergeben und verlässt damit das Haus. Was dort steht, ist als offengelegt zu behandeln — diese Regel sollte ausdrücklich im Team bekannt sein.
Woran merkt man, dass der Kontext zu dünn ist?
An wiederkehrenden Korrekturen im Review, die immer dasselbe betreffen. Jede Korrektur, die man zum dritten Mal schreibt, gehört nicht in einen Kommentar, sondern in die Kontextdatei — oder besser noch in eine Regel, die es automatisch prüft.
Bringen Sie einen Pull Request mit, der zu groß war.
30 Minuten, kein Vertrieb. Wir gehen ihn durch und sagen, was ein Modell daran geändert hätte.
AI Engineering Review ansehen →
