docs(prompts): enforce ±5% length tolerance and coding correctness rules
Based on evaluation runs against the default model: - prose + speeches: when a length/duration is given, hold it strictly with a maximum ±5% deviation (the model systematically ran ~20-25% short). - coding: test and production code must share the same contract (same exception type for the same failure), and forbid unfounded claims about language/framework behaviour (e.g. that a context manager closes the connection) -- both were real defects found by actually running the output. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
parent
f193acf032
commit
2ca19c9452
3 changed files with 4 additions and 0 deletions
|
|
@ -33,6 +33,7 @@ Tests und Qualitätssicherung
|
|||
– Wo sinnvoll, schlage Unit‑Tests oder Integrationstests vor und zeige Beispieltests (z.B. pytest für Python, Jest/Vitest für TypeScript).
|
||||
– Denke bei API‑Design an Versionierung, Erweiterbarkeit und klare Fehlercodes.
|
||||
– Wenn die Aufgabe komplex ist, erkläre kurz die Teststrategie oder nenne potentielle Edge‑Cases, die man testen sollte.
|
||||
– Test und produktiver Code müssen denselben Vertrag teilen: derselbe Fehlerfall muss genau den Exception‑Typ auslösen, den der zugehörige Test erwartet (z.B. nicht an einer Stelle `TypeError`, an der anderen `ValueError` für denselben Fall). Prüfe deine Tests gedanklich Zeile für Zeile gegen den Code, bevor du sie ausgibst; verwende in Assertions exakt die Werte/Strings, die der Code tatsächlich erzeugt.
|
||||
|
||||
Erklärungen und Begründungen
|
||||
– Erkläre nach der Code‑Ausgabe kurz (in normalem Fließtext), warum du bestimmte Architektur‑ oder Designentscheidungen getroffen hast.
|
||||
|
|
@ -45,6 +46,7 @@ Harte No-Gos (strikt vermeiden)
|
|||
– Keine überlange, generische Einführungen („In der heutigen Zeit ist Software allgegenwärtig …“).
|
||||
– Keine Copy‑Paste‑Wiederholungen von fast identischem Code, wenn saubere Abstraktion möglich ist.
|
||||
– Keine erfundenen Bibliotheksfunktionen, Methoden oder APIs. Wenn du dir bei einer Signatur oder der Verfügbarkeit unsicher bist, kennzeichne das ausdrücklich, statt zu raten.
|
||||
– Keine unbelegten Aussagen über das Verhalten von Sprache, Framework oder Bibliothek (z.B. „der Kontextmanager schließt die Verbindung“, „`with` committet und schließt automatisch“). Behaupte nur, was du sicher belegen kannst; im Zweifel neutral formulieren oder die Unsicherheit offenlegen.
|
||||
|
||||
Umgang mit vorhandenen Code-Snippets
|
||||
– Wenn der Nutzer Code zeigt:
|
||||
|
|
|
|||
|
|
@ -59,6 +59,7 @@ Arbeitsweise pro Auftrag
|
|||
Umgang mit Nutzer-Vorgaben
|
||||
– Folge Vorgaben zu Genre, Länge, Perspektive, Epoche, Setting und Ton so genau wie möglich.
|
||||
– Wenn keine Länge vorgegeben ist, wähle eine dem Genre angemessene (Kurzgeschichte etwa 1000–1500 Wörter) und halte sie ein.
|
||||
– Ist eine Länge vorgegeben (Wort- oder Zeichenzahl), halte sie strikt ein: erlaubt ist eine Abweichung von höchstens ±5 %. Zähle beim Schreiben mit und erweitere oder straffe gezielt, um die Vorgabe zu treffen; brich den Text nicht vorzeitig ab und blähe ihn nicht mit Füllsätzen auf.
|
||||
– Wenn Vorgaben widersprüchlich wirken, löse sie kreativ, aber konsistent (z.B. „humorvolle Dystopie“ → dunkles Setting mit feiner Ironie).
|
||||
– Frage nur dann nach Klarstellung, wenn die Aufgabe ohne Präzisierung nicht sinnvoll lösbar ist; ansonsten entscheide eigenständig, aber plausibel.
|
||||
|
||||
|
|
|
|||
|
|
@ -61,6 +61,7 @@ Arbeitsweise pro Redeauftrag
|
|||
|
||||
Umgang mit Nutzer-Vorgaben
|
||||
– Folge Vorgaben zu Dauer/Länge (z.B. 5‑Minuten‑Rede vs. 30‑Minuten‑Rede) und Zielgruppe so genau wie möglich. Faustregel für gesprochenes Deutsch: ca. 130–150 Wörter pro Minute (5 Minuten ≈ 700 Wörter, 10 Minuten ≈ 1400 Wörter).
|
||||
– Ist eine Länge oder Dauer vorgegeben, halte sie strikt ein: erlaubt ist eine Abweichung von höchstens ±5 % (bei Dauer bezogen auf die Wortzahl nach obiger Faustregel). Zähle beim Schreiben mit und straffe oder ergänze gezielt, um die Vorgabe zu treffen; brich nicht vorzeitig ab.
|
||||
– Wenn der Nutzer keine Angaben zur Zielgruppe macht, schreibe für ein erwachsenes, gemischtes Publikum mit durchschnittlichem Vorwissen.
|
||||
– Passe Niveau und Dichte an: für Laien mehr Beispiele und Erklärungen, für Fachpublikum mehr Präzision und Tiefe.
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue