In W3.1.1 haben Sie gesehen, was Copilot an Ihren Rechner und aus ihm heraus schickt und wo die Grenzen liegen. Diese Lektion handelt vom Anfang des Weges: dem Prompt und dem Kontext, den er mitbringt. Beides steuern Sie, und beides entscheidet, ob die Antwort brauchbar ist oder nur plausibel klingt. Am Ende haben Sie dieselbe Aufgabe mit drei Prompts gestellt und die Ergebnisse verglichen, und einen Umbau der Kladde in kleinen Schritten durchgeführt.

Es gilt weiter, was für den ganzen Kurs gilt: Was Copilot antwortet, ist nicht vorhersagbar. Der Kurs zeigt deshalb Prompts, nie „die" Antwort, und schreibt „eine mögliche Antwort", wenn er eine Antwort beschreibt; er sagt dann, was daran zu prüfen ist. Befehle und Oberflächen, die nur gegen die Dokumentation gelesen wurden, tragen den Vermerk „nicht gegen Copilot ausgeführt".

Die Grundlage dieser Lektion sind die Seite „Prompt engineering for GitHub Copilot" der Dokumentation von GitHub und die Lernpfade auf Microsoft Learn (Verweise unten). Wo Ihr Editor von der Dokumentation abweicht, gilt der Editor; die Dokumentation Ihres Editors nennt die genauen Schreibweisen.

Der Aufbau eines Prompts

Ein Prompt ist eine Arbeitsanweisung an jemanden, der gut Code schreibt, die Kladde aber nicht kennt und nicht nachfragt. Was Sie nicht schreiben, rät er. Fünf Bausteine helfen, nichts zu vergessen. Nicht jeder Prompt braucht alle:

Baustein Die Frage dahinter Beispiel aus der Kladde
Ziel Was soll am Ende da sein? „Tests für TimeRange.Overlaps"
Kontext Wovon geht es aus, was gibt es schon? „TimeRange ist ein Record mit Start und End; Tests liegen in Kladde.Core.Tests"
Vorgaben Welche Regeln und Grenzen gelten? „xUnit, kein Mock, Namen im Stil ARangeThatTouchesAnotherDoesNotOverlap"
Ausgabeform Wie soll das Ergebnis aussehen? „Nur die Testmethoden, kein erklärender Text"
Beispiel Wie sieht ein gutes Stück davon aus? ein vorhandener Test als Vorlage

Die Dokumentation von GitHub gibt vier Ratschläge, die zu dieser Tabelle passen:

  • Erst allgemein, dann konkret. Beschreiben Sie zuerst das Ziel, dann die Anforderungen, die wichtigste zuerst. Die Seite nennt, dass Copilot Anweisungen am Anfang und am Ende eines Prompts mehr Gewicht gibt.
  • Beispiele geben. Beispieleingaben, Beispielausgaben oder eine Beispielumsetzung; auch Tests können als Beispiel dienen.
  • Mehrdeutigkeit vermeiden. Nennen Sie die Funktion oder Datei beim Namen statt „das hier". Sagen Sie Regeln direkt, nicht als Anweisung über Anweisungen.
  • Komplexe Aufgaben in einfachere zerlegen und Schritt für Schritt erledigen lassen.

Ein schlechter und ein besserer Prompt für dieselbe Aufgabe:

Schreib Tests für die Terminprüfung.

Ziel: xUnit-Tests für TimeRange.Overlaps (Datei TimeRange.cs, im Kontext).
Regel: Zwei Zeiträume überschneiden sich, wenn jeder beginnt, bevor der andere
endet. Berühren sich Ende und Beginn, ist es keine Überschneidung.
Vorgaben: xUnit und Assert, kein Mock, feste Zeitpunkte, Methodennamen in
PascalCase ohne Unterstrich, eine Behauptung je Test.
Fälle: gleich, vollständig enthalten, teilweise überlappend (beide Richtungen),
berührend (beide Richtungen), getrennt.
Ausgabe: nur die Testmethoden, kein erklärender Text.

Der zweite Prompt ist länger, aber nicht ausschweifend: Er nennt die Regel, weil sie die Kante festlegt, die ein Modell sonst rät, und er nennt die Fälle, die Sie prüfen wollen. Je mehr in einer Anfrage von Ihrem Wissen über die Kladde steckt, desto weniger muss Copilot raten.

Wie der Kontext entsteht

Copilot kennt Ihr Repository nicht im Ganzen. Der Editor stellt für jede Anfrage einen Kontext zusammen (W3.1.1): offene Dateien, eine Auswahl, der Name des Repositorys, der Chatverlauf und eine Anweisungsdatei, falls es eine gibt. Sie beeinflussen ihn an vier Stellen.

Offene Dateien. Die Dokumentation rät, relevante Dateien zu öffnen und irrelevante zu schließen. Das ist die einfachste Maßnahme und oft die wirksamste: Für „Tests zu TimeRange" öffnen Sie TimeRange.cs und eine vorhandene Testdatei, nicht zwölf andere Dateien.

Auswahl. Markierter Code ist ein deutlicher Hinweis, worum es geht. Für „erkläre" und „baue um" markieren Sie die Methode, nicht die Datei.

Verweise mit @. Nach der Dokumentation können Sie im Chat im Editor und auf github.com mit @ Dateien, Issues, Pull Requests oder Repositorys anhängen; manche Editoren kennen außerdem Schrägstrich-Befehle wie /fix und /tests. In der Copilot CLI nennt @pfad eine Datei des Repositorys und #nummer einen Issue oder Pull Request. Welche Zeichen und Befehle Ihr Editor kennt, steht in seiner Dokumentation (nicht gegen Copilot ausgeführt).

Der Chatverlauf. Dialogformen nutzen den bisherigen Verlauf als Kontext. Das ist ein Vorteil (Sie können nachbessern: „und jetzt auch für Termine ohne Teilnehmer") und eine Falle: Ein Verlauf mit Irrwegen, Fehlern und widersprüchlichen Vorgaben ist schlechter Kontext. Die Dokumentation sagt, dass man irrelevante Beiträge entfernen oder zurückrollen kann, wo das unterstützt wird (die CLI kennt dafür Befehle; der Cloud-Agent erlaubt es nicht).

Zwei Folgerungen:

  1. Prüfen Sie, was im Kontext liegt, bevor Sie die Antwort bewerten. Hat Copilot die Datei gesehen, auf die Sie sich beziehen? Zeigt Ihr Editor an, welche Dateien einbezogen wurden, sehen Sie dort nach (die Anzeige ist je Editor verschieden; nicht gegen Copilot ausgeführt). Fehlt etwas, ist die Antwort nicht „schlecht", sie wurde ohne Kenntnis geschrieben.
  2. Was im Kontext liegt, verlässt den Rechner (W3.1.1). Schließen Sie Dateien mit Schlüsseln oder echten personenbezogenen Daten, bevor Sie fragen. Die Regeln dazu und die Ausschlüsse folgen in W3.2.3.

Zero-Shot und Few-Shot

Ein Zero-Shot-Prompt beschreibt die Aufgabe, ohne ein Beispiel zu geben. Ein Few-Shot-Prompt enthält ein oder mehrere Beispiele, wie das Ergebnis aussehen soll. Beides hat seinen Platz:

  • Zero-Shot genügt, wenn die Aufgabe eindeutig und üblich ist („erkläre diese Methode").
  • Few-Shot lohnt sich, wenn Form, Namensgebung oder Stil wichtig sind und sich schlecht beschreiben lassen. Ein Beispiel sagt oft mehr als ein Absatz Vorgaben.

Ein Few-Shot-Prompt für Testdaten (das Format ist ein Beispiel, nicht das Datenmodell der Kladde). Die Beispiele zeigen die Form, die erzeugten Daten müssen Sie trotzdem prüfen:

Erzeuge fünf weitere Testkontakte im selben Format wie die zwei Beispiele.
Nur erfundene Namen, Adressen mit der Domain example.test, keine echten Personen.

{ "name": "Mara Probe", "email": "mara@example.test", "company": "Probe GmbH" }
{ "name": "Jonas Probe", "email": "jonas@example.test", "company": null }

Auch hier gilt: Ein Beispiel lenkt stark. Ist das Beispiel fehlerhaft oder zu speziell, übernimmt Copilot den Fehler. Zeigen Sie nur Beispiele, die Sie selbst geprüft haben, und wählen Sie sie so, dass sie die Spannweite zeigen (hier: ein Kontakt mit Firma, einer ohne). Beispiele mit echten Personendaten oder Zugangsdaten sind tabu.

Kleine Schritte, eine Sitzung je Aufgabe

Die Dokumentation rät, komplexe Aufgaben in einfachere zu zerlegen und neue Aufgaben in einer neuen Unterhaltung zu beginnen. Beides hat einen praktischen Grund:

  • Kleine Schritte lassen sich prüfen. Eine Antwort, die zwei Methoden und einen Test enthält, prüfen Sie in einem Zug. Eine, die zehn Dateien ändert, prüfen Sie nicht mehr, Sie überfliegen sie. Wie groß ein Schritt ist, bestimmt Ihre Prüffähigkeit, nicht die Fähigkeit des Modells.
  • Eine Sitzung je Aufgabe hält den Kontext sauber. Wer in dieselbe Unterhaltung zuerst Testdaten, dann einen Umbau, dann eine Fehlersuche stellt, gibt Copilot widersprüchliche Vorgaben. Beginnen Sie die nächste Aufgabe mit einer neuen Sitzung und nehmen Sie nur mit, was dazugehört (die Vorgaben im Prompt, die relevante Datei).

Ein Zerlegungsmuster für einen Umbau, das sich bewährt:

  1. Verstehen: Copilot erklären lassen, was der Code tut; Ihre Prüfung ist, ob die Erklärung stimmt.
  2. Absichern: Tests für das heutige Verhalten schreiben (lassen) und grün sehen.
  3. Ändern: den kleinsten Umbau, ein Anliegen je Schritt.
  4. Prüfen: Tests, Diff lesen, committen.
  5. Wiederholen.

Der Weg bleibt derselbe, ob Sie allein arbeiten oder mit Copilot: Tests zuerst, ein Anliegen je Schritt, der Diff wird gelesen.

Fünf Arten von Aufgaben

Erzeugen

Neuer Code aus einer Beschreibung. Das Risiko ist am größten, weil nichts da ist, woran Copilot sich festhält: Erfundene Methoden und falsche Annahmen zeigen sich hier am häufigsten. Geben Sie Ziel, Vorgaben und Beispiel und prüfen Sie jede Annahme, die in der Antwort steht, gegen den echten Code.

Ein Beispiel aus der Kladde: Die Antwort der Termin-API, AppointmentResponse, hat keine Id: Sie enthält Title, Start, End und ContactIds (K2, Lektion 2.4.3). Bitten Sie Copilot ohne diese Angabe, „einen Test für den Terminendpunkt" zu schreiben, ist eine mögliche Antwort ein Test, der response.Id liest. Das Mitglied gibt es nicht; der Compiler meldet es, und Sie wissen, dass der Kontext fehlte. Schreiben Sie dann die Form der Antwort in den Prompt oder öffnen Sie die Datei AppointmentResponse.cs.

Erklären

Copilot erklärt markierten Code. Das ist die risikoärmste Aufgabe, weil Sie nichts übernehmen, und die lehrreichste, weil Sie lernen, wie Copilot Ihren Code liest. Zwei Regeln: Prüfen Sie die Erklärung gegen den Code (Copilot beschreibt manchmal, was der Code tun sollte), und fragen Sie nach Randfällen, nicht nur nach dem Normalfall. Für Overlaps zum Beispiel: „Was passiert, wenn der eine Zeitraum genau dort beginnt, wo der andere endet?" Die Antwort können Sie an der Regel in K1 messen.

Umbauen

Bestehenden Code ändern, ohne sein Verhalten zu ändern. Hier sind kleine Schritte und Tests am wichtigsten. Geben Sie genau an, was sich ändern soll („Methode extrahieren", „Name ändern") und was gleich bleiben muss („öffentliche Signatur und Verhalten"). Ein Test vor dem Umbau (Schritt 2 oben) ist Ihr Beweis, dass das Verhalten gleich blieb. Lesen Sie den Diff, bevor Sie übernehmen; ein Umbau, der „nebenbei" eine Bedingung ändert, ist die gefährlichste Fehlerform.

Dokumentieren

Kommentare, XML-Dokumentation, README-Abschnitte. Copilot formuliert gut, aber es beschreibt, was im Code steht, nicht, warum er so ist. Das Warum liefern Sie. Prüfen Sie, dass die Dokumentation das tatsächliche Verhalten beschreibt und keine Zusicherungen enthält, die der Code nicht hält. Ein Beispiel: Die Zeile Start < other.End && other.Start < End verdient einen Kommentar zur Kante („Berührung ist keine Überschneidung"); ein Kommentar „prüft, ob sich zwei Zeiträume schneiden" sagt nichts, was der Name nicht sagt.

Testdaten

Erfundene Daten für Tests und Beispiele. Copilot ist hier nützlich und schnell, aber prüfen Sie dreierlei: Die Daten sind erfunden (keine echten Personen, keine echten Adressen: example.test oder example.com), sie halten die Regeln der Kladde ein (ein Termin mit Ende vor Beginn ist kein gültiges TimeRange), und sie decken Randfälle ab statt nur den Normalfall. Beispiele mit Zugangsdaten sind Platzhalter wie <geheim>, nie ein echter Wert.

Übung 1

Drei Prompts für dieselbe Aufgabe. Vergleichen Sie einen ungenauen, einen genauen und einen Prompt mit Beispiel.

  1. Legen Sie einen Branch feature/copilot-prompts an und öffnen Sie TimeRange.cs und eine vorhandene Testdatei der Kladde.
  2. Stellen Sie in je einer neuen Chatsitzung drei Prompts für dieselbe Aufgabe „Tests für TimeRange.Overlaps":
    • A, ungenau: „Schreib Tests für die Terminprüfung."
    • B, genau: wie im zweiten Prompt oben (Ziel, Regel, Vorgaben, Fälle, Ausgabeform).
    • C, mit Beispiel: wie B, dazu ein vorhandener Test als Vorlage mit dem Hinweis, Stil und Namensgebung zu übernehmen.
  3. Kopieren Sie keine Antwort in die Kladde, bevor Sie sie bewertet haben. Legen Sie eine Tabelle an (docs/copilot-promptvergleich.md) mit je einer Spalte pro Prompt und diesen Zeilen: kompiliert, nutzt nur vorhandene Mitglieder, prüft die Kante (Berührung), Anzahl der Fälle, Namensstil, enthält erfundenes oder Überflüssiges.
  4. Führen Sie die Tests der besten Antwort aus (dotnet test, Exit-Code lesen) und notieren Sie, ob alle bestehen, und was Sie ändern mussten.

So prüfen Sie: Ihre Tabelle hat drei gefüllte Spalten, und Sie können in einem Satz sagen, welcher Baustein des Prompts den größten Unterschied gemacht hat. Eine Antwort, die ohne Ihre Änderungen alle Fälle abdeckt, ist ein Glückstreffer, kein Beleg: Wiederholen Sie Prompt B in einer neuen Sitzung und vergleichen Sie.

Lösung 1

Es gibt kein erwartbares Ergebnis; was Copilot schreibt, unterscheidet sich je Lauf. Prüfen Sie diese Punkte an jeder Antwort:

  • Kante: Gibt es einen Test, in dem Ende und Beginn zusammenfallen, in beiden Richtungen, mit Assert.False? Fehlt er, fehlt der Test, der den häufigsten Fehler fängt (W3.1.1).
  • Erfundenes: Greift ein Test auf Mitglieder zu, die TimeRange nicht hat? Der Compiler zeigt es.
  • Gleiches doppelt: Prüfen drei Tests dasselbe? Mehr Tests sind nicht mehr Prüfung.
  • Gleichgültige Tests: Ein Test, der mit jeder Implementierung besteht (etwa weil er Assert.True(true) oder nur die Konstruktion prüft), prüft nichts. Streichen Sie ihn. W3.2.2 behandelt solche Tests im Einzelnen.
  • Stil: Sind die Namen in PascalCase und ohne Unterstrich, wie in den Tests aus K2?

Was Sie typischerweise sehen werden (als Erwartung, nicht als Messwert): Der ungenaue Prompt A lässt Copilot die Datei und den Stil raten; er ist am stärksten vom Kontext abhängig. Mit B und C gewinnen Sie Kontrolle über Fälle und Stil. Ob C besser ist als B, hängt von Ihrem Beispiel ab. Das ist der Punkt der Übung: Sie sehen, welcher Baustein wirkt, und wo ein Beispiel mehr als Worte sagt.

Übung 2

Ein Umbau in Schritten. Bauen Sie eine kleine Stelle der Kladde um und halten Sie jeden Schritt fest.

Aufgabe: In IsTaken (K2, Lektion 2.5.10) prüft die Kladde zwei Listen mit demselben Ausdruck: Appointments.Any(a => a.Time.Overlaps(time)) und Bookings.Any(b => b.Time.Overlaps(time)). Extrahieren Sie die gemeinsame Prüfung in eine kleine Hilfsmethode, ohne das Verhalten zu ändern. Haben Sie den Code nicht in dieser Form, nehmen Sie eine ähnliche Stelle mit doppeltem Ausdruck.

  1. Neue Sitzung. Öffnen Sie nur die Datei mit IsTaken. Bitten Sie Copilot zu erklären, was die Methode tut. Prüfen Sie die Erklärung am Code.
  2. Absichern. Gibt es Tests für IsTaken (über BookAsync)? Laufen sie grün? Wenn nicht, bitten Sie Copilot, Tests für das heutige Verhalten zu schreiben, und prüfen Sie sie wie in Übung 1. Committen Sie sie: test(core): Verhalten von IsTaken absichern.
  3. Ändern. Neue Sitzung, Prompt mit Ziel, Vorgabe „öffentliche Signatur und Verhalten bleiben gleich, nur diese Methode, nichts anderes ändern". Lesen Sie den Diff Zeile für Zeile.
  4. Prüfen. Alle Tests, Exit-Code lesen. Committen: refactor(core): gemeinsame Überschneidungsprüfung in IsTaken.
  5. Notieren Sie in docs/copilot-promptvergleich.md zwei Sätze: Wo hat Copilot mehr geändert, als Sie verlangt haben? Was haben Sie zurückgenommen?

So prüfen Sie: Es gibt zwei Commits (Tests, Umbau), die Tests waren vor und nach dem Umbau grün, und der Diff des Umbaus enthält nur die gewollte Änderung. git diff --stat zeigt eine Datei, nicht fünf.

Lösung 2

Ein Umbau dieser Größe ist ein Beispiel für die fünf Schritte. Was Sie typischerweise prüfen müssen:

  • Schritt 1: Eine Erklärung, die „IsTaken prüft, ob die Zeit frei ist" sagt, ist zu grob: Sie ist umgekehrt. Die Methode antwortet, ob die Zeit belegt ist (true heißt belegt). Prüfen Sie, dass die Erklärung die Richtung kennt.
  • Schritt 2: Ein Test, der nur den Erfolgsfall prüft, ist keine Absicherung. Es braucht je einen Fall mit Termin, Buchung und Berührung (Ende gleich Beginn, nicht belegt).
  • Schritt 3: Achten Sie im Diff auf drei Fehlerformen: eine umgedrehte Bedingung (&& statt ||), eine geänderte Reihenfolge (die Kurzschlussauswertung ändert sich nur der Reihenfolge nach, nicht dem Ergebnis, aber prüfen Sie es), und Änderungen außerhalb der Methode („nebenbei" benannte Variablen, geänderte Typen).
  • Schritt 4: Wenn ein Test nach dem Umbau rot ist, ist das der Beweis, dass die Absicherung etwas wert war. Nehmen Sie den Umbau zurück (git restore) und beginnen Sie mit einem engeren Prompt neu, statt den Test anzupassen.

Dass Copilot mehr ändert, als Sie verlangt haben, ist die häufigste Beobachtung. Die Gegenmaßnahme steht schon im Prompt („nur diese Methode") und im Diff, den Sie lesen. Reicht beides nicht, ist der Schritt zu groß.

Was Sie jetzt können

  • Sie gliedern einen Prompt in Ziel, Kontext, Vorgaben, Ausgabeform und Beispiel und nennen die Regel hinein, die die Kante festlegt.
  • Sie steuern den Kontext: offene Dateien, Auswahl, Verweise mit @, saubere Chatverläufe, und Sie wissen, dass der Kontext den Rechner verlassen kann.
  • Sie unterscheiden Zero-Shot und Few-Shot und wählen Beispiele, die Sie selbst geprüft haben.
  • Sie zerlegen Aufgaben in kleine, prüfbare Schritte und führen je Aufgabe eine eigene Sitzung.
  • Sie setzen Copilot zum Erzeugen, Erklären, Umbauen, Dokumentieren und für Testdaten ein und prüfen jede Antwort an der Kladde.

In der nächsten Lektion verlässt Copilot den Editor-Vorschlag: Der Agent-Modus ändert Dateien und führt Befehle aus, die Kommandozeile bringt Copilot ins Terminal, und MCP verbindet Werkzeuge. Dort wird die Frage „Was geben Sie frei?" wichtiger als die nach dem Prompt.

Weiterlesen