GPT-6 Astra: 3 Anwendungsfälle, die für dich einen echten Unterschied machen

Du analysierst meine Wettbewerber, indem du ihre Websites tatsächlich durchgehst. Nicht aus dem Gedächtnis antworten – öffnen, lesen, belegen.

Mein Kontext:
- Mein Unternehmen und Angebot: [kurz]
- Meine Zielgruppe: [wer genau]
- Wettbewerber: [3 bis 6 URLs]
- Wofür ich die Analyse brauche: [z.B. Preisentscheidung, Positionierung schärfen, neue Landingpage]

So gehst du vor:

1. Pro Wettbewerber die Seiten durchgehen
Startseite, Produkt- oder Leistungsseiten, Preisseite, Über-uns, Karriere. Karriere verrät oft mehr über die tatsächliche Ausrichtung als die Startseite.

2. Positionierung auf den Punkt bringen
Für jeden: In einem Satz, wie er sich selbst positioniert – in seinen Worten, mit Zitat und Fundstelle. Danach in einem Satz, wie er tatsächlich wirkt.

3. Preise und Leistungen
Was kostet was, welches Modell steckt dahinter, was ist inklusive und was kostet extra. Wenn kein Preis öffentlich steht, schreib "kein öffentlicher Preis" statt zu schätzen.

4. Wem sie schreiben
An wen richtet sich die Sprache erkennbar? Woran machst du das fest?

5. Tabelle anlegen
Eine Zeile pro Wettbewerber, Spalten: Positionierung, Zielgruppe, Preismodell, Einstiegspreis, Stärkstes Argument, Auffällige Lücke, Quelle mit Abrufdatum.

6. Was ich daraus mache
Drei Punkte: Wo sagen alle dasselbe, sodass es kein Argument mehr ist? Wo ist eine Lücke, die zu meinem Angebot passt? Wo ist ein Wettbewerber klar besser als ich, und woran liegt das?

Bremse: Keine Aussage ohne Fundstelle. Wenn du etwas nicht auf der Seite findest, schreib "nicht auffindbar". Vermeide Wörter wie innovativ, ganzheitlich und maßgeschneidert – wenn sie auf einer Seite stehen, zitier sie als Befund, übernimm sie nicht als Beschreibung.

Du planst eine Geschäftsreise vollständig durch. Arbeite eigenständig über mehrere Schritte, recherchiere im Browser und leg die Ergebnisse in einer Tabelle ab. Buche nichts.

Rahmen:
- Von / nach: [Startort → Zielort]
- Zeitraum: [Datum Hinreise – Datum Rückreise, feste Termine vor Ort]
- Anlass und Pflichttermine: [z.B. Kundentermin Di 10 Uhr, Messe Mi ganztags]
- Budget: [Obergrenze gesamt, Obergrenze pro Nacht]
- Präferenzen: [Bahn statt Flug? Hotelkette? Umsteigezeit? Frühstück?]
- Wer reist: [Anzahl, Vielfliegerstatus, Mobilitätseinschränkungen]

So gehst du vor:

1. Rahmen prüfen
Geh die Pflichttermine durch und leite daraus ab, wann du spätestens ankommen und frühestens abreisen musst. Wenn etwas nicht zusammenpasst, sag es jetzt und plan nicht drumherum.

2. Anreise
Recherchiere mindestens drei Varianten. Für jede: Gesamtreisezeit von Tür zu Tür, Umstiege, Kosten, Puffer zum ersten Termin, Ausfallrisiko. Rechne die Wege zum und vom Bahnhof oder Flughafen mit ein, nicht nur die reine Fahrzeit.

3. Unterkunft
Drei Optionen, jeweils mit Fußweg oder Fahrzeit zum wichtigsten Termin, Preis pro Nacht, Stornofrist. Keine Bewertungsdurchschnitte ohne Zahl der Bewertungen.

4. Vor Ort
Wie kommst du zwischen den Terminen hin und her? Nenn die konkrete Verbindung, nicht "ÖPNV vorhanden".

5. Tabelle anlegen
Leg eine Tabelle mit einem Blatt pro Kategorie an: Anreise, Unterkunft, Vor Ort, Kosten. Letzte Zeile jeweils die Summe. In einer Spalte "Quelle" der Link, aus dem der Preis stammt, mit Abrufdatum.

6. Empfehlung
Eine Variante als Empfehlung, in drei Sätzen begründet. Dazu die zwei Punkte, an denen diese Planung kippen würde.

Kontrollpunkte – hier hältst du an und wartest auf mich:
- bevor du eine Seite mit Login oder Zahlungsdaten öffnest
- bevor du irgendwo persönliche Daten einträgst
- bevor du etwas reservierst oder buchst

Preise und Verfügbarkeiten ändern sich. Schreib zu jedem Preis dazu, wann du ihn abgerufen hast. Wo du dir nicht sicher bist, schreib das hin, statt eine plausible Zahl zu erfinden.

Du arbeitest dich in eine bestehende Code-Basis ein und implementierst darin eine Funktion. Verstehen kommt vor Schreiben – nicht umgekehrt.

Rahmen:
- Projekt: [Pfad oder Repository]
- Was gebaut werden soll: [die Funktion in ein bis drei Sätzen]
- Was auf keinen Fall kaputtgehen darf: [...]
- Konventionen, die gelten: [Stil, Tests, Commit-Format – oder: leite sie aus dem Bestand ab]

Phase 1 – Verstehen. Schreib in dieser Phase keine Zeile Produktivcode.

1. Verschaff dir einen Überblick über die Struktur: Welche Bereiche gibt es, wie hängen sie zusammen, wo liegt die Geschäftslogik?
2. Finde die drei bis fünf Stellen, die für meine Aufgabe relevant sind, und erklär mir, was dort passiert – mit Dateipfad und Zeilen.
3. Beschreib die Konventionen, die du im Bestand erkennst: Wie werden Fehler behandelt, wie wird getestet, wie ist benannt?
4. Nenn mir die Stelle, an der du die Funktion einbauen würdest, und eine Alternative dazu. Sag, warum du dich für die eine entscheidest.

Halt hier an und warte auf mein OK.

Phase 2 – Bauen.

5. Implementiere die Funktion im Stil des Bestands. Keine neue Bibliothek ohne Rückfrage.
6. Schreib Tests, die den neuen Weg abdecken – inklusive der Fälle, in denen er scheitern soll.
7. Lass die vorhandenen Tests laufen. Wenn welche brechen, ist das dein Problem, nicht meins.
8. Fass am Ende zusammen: was du geändert hast, warum, und welche Stellen im Projekt davon berührt sind.

Bremse: Wenn du dir bei einer Annahme über den Bestand nicht sicher bist, schreib sie als Annahme hin, statt sie als Tatsache zu formulieren. Rate nicht, was eine Funktion tut, deren Code du nicht gelesen hast.

Du gehst einem Fehler auf den Grund. In dieser Reihenfolge: reproduzieren, Ursache finden, beheben, gegenprüfen. Nicht abkürzen.

Was ich beobachte:
- Symptom: [was passiert, möglichst wörtlich, mit Fehlermeldung wenn vorhanden]
- Wann: [immer / manchmal / seit wann / unter welchen Umständen]
- Was ich schon probiert habe: [...]
- Projekt: [Pfad oder Repository]

So gehst du vor:

1. Reproduzieren
Stell den Fehler zuerst selbst her. Beschreib den kleinsten Weg dorthin. Wenn du ihn nicht reproduzieren kannst, sag das und nenn mir, was du dafür bräuchtest – arbeite nicht auf Verdacht weiter.

2. Eingrenzen
Geh vom Symptom rückwärts. Halbier den Suchraum, statt Stellen zu raten. Sag mir nach jedem Schritt, was du ausgeschlossen hast und woran du das festmachst.

3. Ursache benennen
Eine Ursache, mit Dateipfad und Zeilen, und der Erklärung, warum genau daraus dieses Symptom folgt. Wenn du mehrere Kandidaten hast, nenn sie mit deiner Einschätzung, wie sicher du bist.

4. Beheben
Die kleinste Änderung, die die Ursache beseitigt. Kein Umbau nebenbei, kein Aufräumen, das nicht zum Fehler gehört.

5. Gegenprüfen
Der Weg aus Schritt 1 darf nicht mehr zum Fehler führen. Die vorhandenen Tests müssen weiter laufen. Schreib einen Test, der genau diesen Fall abdeckt, damit er nicht zurückkommt.

6. Übergeben
Symptom, Ursache, Änderung, Nachweis – jeweils drei bis fünf Zeilen.

Bremse: Behandle nicht das Symptom. Wenn deine Behebung nur dafür sorgt, dass die Meldung verschwindet, sag es. Und wenn der Fehler an einer Stelle liegt, die ich als "darf nicht kaputtgehen" markiert habe, frag vorher.