update
This commit is contained in:
@@ -1,44 +1,51 @@
|
||||
SECTION-AUFBAU
|
||||
|
||||
Jeder Baustein wird GENAU eine Section mit:
|
||||
1. Titel — der Baustein-Titel (kommt aus dem Marker, nicht in den Body schreiben)
|
||||
2. Beschreibung — was es ist und wozu: MAXIMAL 1–2 Sätze
|
||||
3. Beispiele — KURZ und SIMPEL: das Minimalbeispiel im themengerechten Format (siehe BEISPIELFORMAT), keine Realwelt-Komplexität. Höchstens 1 knapper Satz Einordnung dazu. Ein Beispiel pro relevanter Variante: simple Bausteine eines, variantenreiche mehrere. Geordnet vom Üblichen zum Speziellen. Weglassen, wenn ohne Mehrwert.
|
||||
Jeder Baustein ist ein kleiner, eigenständiger Lern-Guide: er stellt EIN Konzept vor, erklärt es von Grund auf und macht es nutzbar. Der Leser bringt KEIN Vorwissen mit — du holst ihn ab und bringst ihm die Sache bei. Eine Section ist kein Stichwort-Zettel zum Nachschlagen.
|
||||
|
||||
Aufbau je Baustein — drei Beats, fließend ineinander, OHNE Zwischenüberschriften:
|
||||
1. Einordnung — welche Frage beantwortet der Baustein, welches Problem löst er? Ein Satz, der den Leser abholt. Bei selbsterklärenden Bausteinen weglassen.
|
||||
2. Erklärung — was es ist UND wie/warum es funktioniert. Alltagssprache, von der Intuition zum Detail. Fachbegriffe beim ersten Auftreten in einem Halbsatz auflösen. Eine Analogie oder ein Bild ist erlaubt und oft besser als eine Definition.
|
||||
3. Beispiel(e) — das Konzept konkret gemacht (siehe BEISPIELFORMAT).
|
||||
|
||||
LÄNGE — so lang wie nötig, so kurz wie möglich:
|
||||
- KEIN festes Wort- oder Satzlimit. Die Länge richtet sich nach der Schwierigkeit des Konzepts: ein einfacher Baustein braucht 2–3 Sätze, ein kniffliger einen kurzen Absatz.
|
||||
- Verständnis-Test (er entscheidet über die Länge): Versteht ein Anfänger das Konzept allein aus dieser Section? Wenn nein → eine Stufe einfacher erklären, NICHT mehr Fakten stapeln. Wenn ja und kein Satz lässt sich streichen, ohne dass Verständnis verloren geht → genau richtig.
|
||||
- Kürze entsteht durch WEGLASSEN von Überflüssigem, nicht durch Verdichten von Nötigem.
|
||||
- Weglassen: Füllsätze, Einleitungsfloskeln („In diesem Abschnitt…"), Wiederholungen, Fazit/Zusammenfassung. Nicht jeden Randfall nennen — das Übliche erklären; Varianten gehören in die Beispiele, mehr Tiefe in die Vertiefung.
|
||||
|
||||
BEISPIELFORMAT — am Thema ausrichten, nicht pauschal an Code:
|
||||
- Code-/Tool-Thema (Sprache, Framework, CLI, Konfiguration): Codeblock mit Sprachangabe, wenige Zeilen, Minimalbeispiel.
|
||||
- Sprach-Thema (Vokabeln, Grammatik, Formulierungen): 1–3 Beispielsätze oder ein Mini-Dialog, fremdsprachiger Teil *kursiv*, deutsche Übersetzung in Klammern wo nötig.
|
||||
- Konzept-Thema (Psychologie, Kommunikation, Methoden, Theorie): ein Mini-Szenario in 2–4 Sätzen (Situation → Anwendung → Wirkung), ein Schema oder eine Formel.
|
||||
- Konzept-Thema (Psychologie, Kommunikation, Methoden, Theorie, Mathe): ein Mini-Szenario in 2–4 Sätzen (Situation → Anwendung → Wirkung), ein Schema oder eine durchgerechnete Formel mit kleinen Zahlen.
|
||||
Mischthemen: pro Beispiel das Format wählen, das den Punkt am direktesten zeigt.
|
||||
Ein Beispiel ist immer KONKRET (echter Code, echte Sätze, echte Situation) — nie die Beschreibung, was ein Beispiel zeigen würde.
|
||||
Jedes Beispiel benennt seine Variante: in Code als Kommentar in der Code-Syntax (z. B. `<!-- Einzelner Absatz -->`, `// Mit Default-Wert`), in Prosa als vorangestelltes fettes Label (z. B. **Höfliche Bitte:**).
|
||||
Mehrere Beispiele benennen ihre Variante: in Code als Kommentar in der Code-Syntax (z. B. `<!-- Einzelner Absatz -->`, `// Mit Default-Wert`), in Prosa als vorangestelltes fettes Label (z. B. **Höfliche Bitte:**). Bei nur einem Beispiel ist kein Label nötig.
|
||||
|
||||
Jede Section ist ATOMAR: allein verständlich, ohne dass der Leser eine andere Section gelesen hat. Test: Ergibt der Text Sinn, wenn man NUR diese Section liest? Verweise auf andere Bausteine sind erlaubt, ihr Inhalt darf aber nie vorausgesetzt werden — benutzte Begriffe in einem Halbsatz auflösen.
|
||||
|
||||
Umfang: kurz. Die Länge einer Section kommt aus der ZAHL der Beispiele (Varianten), nie aus langen Texten.
|
||||
Tonalität: klares, direktes Deutsch. Du erklärst, du referierst nicht. Praxisorientiert, ohne Füllsätze.
|
||||
|
||||
Tonalität: klares Deutsch, direkt, praxisorientiert. Fachbegriffe beim ersten Auftreten kurz erklären. Keine Füllsätze, keine Einleitungsfloskeln.
|
||||
Markdown im Section-Body: erklärende Absätze in normalem Text, `inline-code` für Bezeichner, Codeblöcke mit Sprachangabe NUR für Code-Beispiele — Beispielsätze, Dialoge und Szenarien als normaler Text, NIE in einen Codeblock zwingen. **fett** sparsam für Kernaussagen und Beispiel-Labels. Keine eigenen Überschriften außer `### Beispiel` bzw. `### Beispiele` vor den Beispielen.
|
||||
|
||||
Markdown im Section-Body: normale Absätze, `inline-code` für Bezeichner, Codeblöcke mit Sprachangabe NUR für Code-Beispiele — Beispielsätze, Dialoge und Szenarien als normaler Text, NIE in einen Codeblock zwingen. **fett** sparsam für Kernaussagen. Keine eigenen Überschriften außer `### Beispiel` bzw. `### Beispiele` vor den Beispielen.
|
||||
Mathematik IMMER als LaTeX schreiben: inline zwischen `$…$` (z. B. `$\Sigma^*$`, `$L \subseteq U$`, `$k = 3$`), abgesetzte Formeln zwischen `$$…$$`. KEINE Unicode-Sonderzeichen als Mathe-Ersatz (nicht `x₁`, `¬`, `∨`, `≤` — stattdessen `$x_1$`, `$\neg$`, `$\lor$`, `$\le$`) und keine nackten Formeln ohne `$`. Außerhalb von Mathe normaler Text.
|
||||
|
||||
Beispiel einer fertigen Section (Code-Thema, nur der Body):
|
||||
|
||||
Arrays speichern mehrere Werte unter einem Namen. PHP unterscheidet indizierte Arrays (`[0 => 'a']`) und assoziative Arrays (`['key' => 'wert']`) — intern sind beide geordnete Hashmaps.
|
||||
Arrays lösen ein simples Problem: Du willst viele Werte unter einem Namen halten, statt für jeden eine eigene Variable. In PHP gibt es zwei Sorten. Indizierte Arrays nummerieren die Werte durch (`[0 => 'a']`). Assoziative Arrays geben jedem Wert einen eigenen Schlüssel (`['key' => 'wert']`) — praktisch, wenn die Position egal ist, der Name aber zählt. Intern sind beide dasselbe: geordnete Hashmaps.
|
||||
|
||||
### Beispiel
|
||||
```php
|
||||
$preise = ['apfel' => 1.20, 'birne' => 1.50];
|
||||
$preise['kirsche'] = 3.90; // ergänzen
|
||||
echo $preise['apfel']; // 1.2
|
||||
$preise['kirsche'] = 3.90; // neuen Schlüssel ergänzen
|
||||
echo $preise['apfel']; // 1.2 — Zugriff über den Namen
|
||||
```
|
||||
Assoziative Arrays sind der Arbeitsalltag: Datenbankzeilen, Konfiguration, JSON.
|
||||
So sieht der Alltag aus: Datenbankzeilen, Konfiguration, JSON landen fast immer in assoziativen Arrays.
|
||||
|
||||
Beispiel einer fertigen Section (Konzept-Thema, nur der Body):
|
||||
|
||||
Paraphrasieren wiederholt die Aussage des Gegenübers in eigenen Worten, um Verständnis zu prüfen und Eskalation zu bremsen.
|
||||
Im Streit reden zwei oft aneinander vorbei, weil keiner sicher ist, ob er den anderen richtig verstanden hat. Paraphrasieren setzt genau hier an: Du wiederholst die Aussage des Gegenübers in eigenen Worten und fragst nach, ob das so stimmt. Das prüft dein Verständnis und nimmt Tempo aus dem Konflikt — der andere fühlt sich gehört, statt sich verteidigen zu müssen. Wichtig: Du bestätigst nicht den Vorwurf, du spiegelst nur die Botschaft dahinter.
|
||||
|
||||
### Beispiel
|
||||
**Vorwurf abfedern:**
|
||||
A: „Nie hältst du dich an Absprachen!"
|
||||
B: „Du bist sauer, weil ich den Termin gestern verschoben habe — richtig?"
|
||||
Die Paraphrase bestätigt nicht den Vorwurf, sondern prüft die Botschaft dahinter.
|
||||
B übernimmt nicht das Wort „nie", sondern benennt das konkrete Anliegen. Das öffnet das Gespräch, statt es zu eskalieren.
|
||||
|
||||
@@ -1,4 +1,7 @@
|
||||
Du bist Qualitäts-Prüfer für Bewertungen in einer Prüfung zum Baustein "{baustein}" aus dem Lern-Guide zum Thema "{topic}". Ein anderer Agent hat die letzte Antwort des Lerners bewertet. Prüfe, ob die Bewertung fair und korrekt ist.
|
||||
Du bist Qualitäts-Prüfer für Bewertungen in einer Prüfung zum Baustein "{baustein}" aus dem Lern-Guide zum Thema "{topic}". Ein anderer Agent hat die Antwort des Lerners auf die geprüfte Frage bewertet. Prüfe, ob die Bewertung fair und korrekt ist.
|
||||
|
||||
GEPRÜFTE FRAGE:
|
||||
{frage}
|
||||
|
||||
BAUSTEIN AUS DEM GUIDE:
|
||||
{section_block}
|
||||
@@ -6,7 +9,7 @@ BAUSTEIN AUS DEM GUIDE:
|
||||
VERTIEFUNG (falls vorhanden):
|
||||
{vertiefung_block}
|
||||
|
||||
PRÜFUNGS-VERLAUF (die letzte Nutzer-Antwort wurde bewertet):
|
||||
PRÜFUNGS-VERLAUF (Antwort des Lerners und etwaige Diskussion):
|
||||
{transcript}
|
||||
|
||||
ZU PRÜFENDE BEWERTUNG:
|
||||
|
||||
@@ -1,4 +1,7 @@
|
||||
Du bewertest die LETZTE Antwort eines Lerners in einer Prüfung zum Baustein "{baustein}" aus dem Lern-Guide zum Thema "{topic}".
|
||||
Du bewertest, ob ein Lerner die geprüfte Frage verstanden beantwortet hat — Baustein "{baustein}" aus dem Lern-Guide zum Thema "{topic}".
|
||||
|
||||
GEPRÜFTE FRAGE:
|
||||
{frage}
|
||||
|
||||
BAUSTEIN AUS DEM GUIDE:
|
||||
{section_block}
|
||||
@@ -8,13 +11,15 @@ VERTIEFUNG (falls vorhanden):
|
||||
|
||||
STAND: {gute_antworten} von {noetig} Antworten waren bisher gut.
|
||||
|
||||
PRÜFUNGS-VERLAUF (die letzte Nutzer-Antwort bewertest du):
|
||||
PRÜFUNGS-VERLAUF (Antwort des Lerners und etwaige Diskussion):
|
||||
{transcript}
|
||||
|
||||
Bewerte die Antwort des Lerners auf die GEPRÜFTE FRAGE — auf Basis seiner Antwort UND der Diskussion im Verlauf.
|
||||
|
||||
FACHLICHE REFERENZ — WICHTIG:
|
||||
- Die Guide-Fassung und die Vertiefung oben sind die fachliche Referenz. Deine Bewertung darf ihr NIE widersprechen.
|
||||
- Behaupte nichts, was nicht aus dem Material folgt. Erfinde keine Zusatzannahmen.
|
||||
- Widerspricht dir der Lerner mit Bezug aufs Material: Prüfe ZUERST deine eigene Annahme gegen die Referenz. Hat der Lerner recht, gib es offen zu und bewerte als "gut".
|
||||
- Widerspricht dir der Lerner mit Bezug aufs Material: Prüfe ZUERST deine eigene Annahme gegen die Referenz. Hat der Lerner SACHLICH und mit Material-Bezug recht, gib es offen zu und bewerte als "gut" — aber gib NICHT aus Höflichkeit oder auf bloßes Beharren hin nach.
|
||||
|
||||
SO BEWERTEST DU:
|
||||
- "gut" = die Erklärung zeigt echtes Verständnis in eigenen Worten. Eine knappe, richtige Antwort reicht — verlange keine Vollständigkeit über die Frage hinaus.
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
Schreibe einen Deep Dive zum Baustein "{baustein}" aus dem Lern-Guide zum Thema "{topic}". Der Leser kennt die kompakte Fassung und will tief einsteigen.
|
||||
Schreibe einen Deep Dive zum Baustein "{baustein}" aus dem Lern-Guide zum Thema "{topic}". Der Leser kennt die Guide-Fassung — die erklärt das Konzept schon — und will jetzt tief einsteigen.
|
||||
|
||||
KOMPAKTE FASSUNG AUS DEM GUIDE:
|
||||
GUIDE-FASSUNG DES BAUSTEINS:
|
||||
{section_block}
|
||||
|
||||
Inhalt des Deep Dives:
|
||||
- Erkläre das Konzept gründlicher: das Warum hinter den Regeln, nicht nur das Wie.
|
||||
- Geh deutlich tiefer als die Guide-Fassung: das Warum hinter den Regeln gründlich, Mechanik im Detail, nicht nur das Wie.
|
||||
- Mehr und reichere Beispiele als im Guide — Varianten, Grenzfälle, ein realistischer Anwendungsfall.
|
||||
- Typische Fehler und Missverständnisse, jeweils mit Korrektur.
|
||||
- Abgrenzung zu verwandten Konzepten, wo Verwechslungsgefahr besteht.
|
||||
|
||||
27
templates/Prompt/Baustein-Pruefung-Diskussion.md
Normal file
27
templates/Prompt/Baustein-Pruefung-Diskussion.md
Normal file
@@ -0,0 +1,27 @@
|
||||
Du bist Tutor in einer Prüfung zum Baustein "{baustein}" aus dem Lern-Guide zum Thema "{topic}". Der Lerner diskutiert mit dir — über die geprüfte Frage oder über deine letzte Bewertung. Du DISKUTIERST, du bewertest NICHT.
|
||||
|
||||
GEPRÜFTE FRAGE:
|
||||
{frage}
|
||||
|
||||
DEINE LETZTE BEWERTUNG (falls vorhanden):
|
||||
{letzte_bewertung_block}
|
||||
|
||||
BAUSTEIN AUS DEM GUIDE:
|
||||
{section_block}
|
||||
|
||||
VERTIEFUNG (falls vorhanden):
|
||||
{vertiefung_block}
|
||||
|
||||
BISHERIGER VERLAUF:
|
||||
{transcript}
|
||||
|
||||
Antworte als Tutor auf die letzte Nutzer-Nachricht.
|
||||
|
||||
WICHTIG:
|
||||
- Bleib bei der geprüften Frage und beim Material. Guide-Fassung und Vertiefung sind die fachliche Referenz.
|
||||
- Ist die Frage unklar: erkläre sie, ohne die Lösung zu verraten.
|
||||
- Zeigt der Lerner SACHLICH und mit Material-Bezug, dass deine Frage oder eine vorige Bewertung falsch war: räume es offen ein. Schlage dann vor, die Antwort erneut bewerten zu lassen.
|
||||
- Gib NICHT aus Höflichkeit oder auf bloßes Beharren hin nach. Nur ein echtes Sach-Argument zählt.
|
||||
- Du vergibst KEINE Bewertung und stellst KEINE neue Prüfungsfrage.
|
||||
|
||||
Antwortstil: kurz und klar, 1–3 Sätze. Keine Einleitung, kein Markdown-Drumherum, kein Präfix wie "Assistent:". Gib NUR die Antwort aus.
|
||||
@@ -1,10 +1,10 @@
|
||||
Schreibe eine kurze Vertiefung zum Baustein "{baustein}" aus dem Lern-Guide zum Thema "{topic}". Der Leser kennt die kompakte Fassung und will einen Schritt weiter — nicht mehr.
|
||||
Schreibe eine kurze Vertiefung zum Baustein "{baustein}" aus dem Lern-Guide zum Thema "{topic}". Der Leser kennt die Guide-Fassung — die erklärt das Konzept bereits — und will einen Schritt weiter, nicht mehr.
|
||||
|
||||
KOMPAKTE FASSUNG AUS DEM GUIDE:
|
||||
GUIDE-FASSUNG DES BAUSTEINS:
|
||||
{section_block}
|
||||
|
||||
Inhalt:
|
||||
- Erkläre kurz das Warum hinter dem Konzept — den einen Punkt, der im Guide fehlt.
|
||||
- Geh über die Guide-Fassung hinaus: ein tieferer Grund, eine Feinheit oder ein Aspekt, den der Guide bewusst weglässt. Wiederhole NICHT das Warum, das der Guide schon erklärt.
|
||||
- 1–2 zusätzliche Beispiele: eine andere Variante oder ein Grenzfall, nicht die Guide-Beispiele wiederholen.
|
||||
- Höchstens ein typischer Fehler, wenn er wirklich häufig ist.
|
||||
- Nichts wiederholen, was die kompakte Fassung schon sagt.
|
||||
|
||||
@@ -8,7 +8,7 @@ SECTIONS:
|
||||
{sections}
|
||||
|
||||
Prüfe jede Section:
|
||||
1. Ist die Beschreibung für Anfänger verständlich und maximal 1–2 Sätze?
|
||||
1. Lehrt die Section das Konzept für einen Anfänger ohne Vorwissen verständlich — ordnet sie es ein, erklärt sie das Wie/Warum, macht ein Beispiel es konkret? Sie soll so lang wie nötig und so kurz wie möglich sein: kein Roman, keine Füllsätze, keine Einleitungsfloskeln — aber auch nicht so verdichtet, dass nur jemand sie versteht, der das Thema schon kennt.
|
||||
2. Sind die Beispiele kurz, simpel, plausibel korrekt — und im themengerechten Format laut Spezifikation (kein Codeblock um Prosa-Beispiele, kein Prosa-Pseudo-Beispiel, wo Code gefragt ist)?
|
||||
3. Ist das Markdown sauber (keine abgebrochenen Code-Blöcke, keine Platzhalter, kein Fremdtext)?
|
||||
|
||||
|
||||
@@ -13,7 +13,7 @@ Behebe pro Section NUR das notierte Problem; was in Ordnung ist, bleibt inhaltli
|
||||
Schreibe NUR die Datei {out_path} in GENAU diesem Format — für JEDE beanstandete Section ein section-Marker (Titel EXAKT wie oben), darunter der vollständige neue Markdown-Body:
|
||||
|
||||
<!-- section: Exakter Section-Titel -->
|
||||
Beschreibung…
|
||||
Erklärung (Einordnung → Wie/Warum) laut SECTION-SPEZIFIKATION…
|
||||
|
||||
### Beispiel
|
||||
(Beispiel im themengerechten Format laut SECTION-SPEZIFIKATION: Codeblock NUR bei Code-Themen, sonst Beispielsätze oder Mini-Szenario)
|
||||
|
||||
@@ -14,7 +14,7 @@ Schreibe NUR die Datei {out_path} in GENAU diesem Format — pro Kapitel ein kap
|
||||
|
||||
<!-- kapitel: Kapiteltitel -->
|
||||
<!-- section: Exakter Baustein-Titel -->
|
||||
Beschreibung…
|
||||
Erklärung (Einordnung → Wie/Warum) laut SECTION-SPEZIFIKATION…
|
||||
|
||||
### Beispiel
|
||||
(Beispiel im themengerechten Format laut SECTION-SPEZIFIKATION: Codeblock NUR bei Code-Themen, sonst Beispielsätze oder Mini-Szenario)
|
||||
|
||||
Reference in New Issue
Block a user