KI-Lernreihe · Lektion 3 von 4
Jede neue KI-Sitzung beginnt ohne Erinnerung an Ihr Repository. Leben die Konventionen nur im Kopf einer Person — oder in einem Dokument, das niemand mehr liest —, bricht das Modell sie still, und der Bruch sieht aus wie funktionierender Code, bis er es nicht mehr tut.
Status: Gliederung. Die Vorführung am Bildschirm ist noch nicht aufgezeichnet — dieser Beitrag ist der Plan, dem sie folgen wird, und er erhält die echte Vorführung, sobald die Lektion ausgestrahlt ist.
| Lektion | Schwerpunkt | Beantwortete Frage |
|---|---|---|
| 1 — Modellnutzung | Modellstufe, Kontext, Tokens | Welches Modell braucht diese Aufgabe? |
| 2 — Prompting, Projekt und Kontext | Prompt-Struktur, dauerhafter Kontext | Was legt man dem Modell vor? |
| 3 — Dokumentation, Regeln und Skills | Repository-Struktur | Wie bleibt ein Repository über Sitzungen hinweg konsistent? |
| 4 — Kosten senken | Messung, Hebel, Leitplanken | Wie gibt man weniger aus, ohne Qualität zu verlieren? |
Was Sie danach können
- Einem Repository drei verschiedene Dinge geben: Dokumentation, in der es sich zurechtfindet, Regeln, die es befolgen muss, und Skills, die es wiederverwenden kann
- Jede Vorgabe der richtigen der drei Schichten zuordnen
- Eine geschriebene Regel in eine Prüfung verwandeln, die fehlschlägt, wenn die Regel gebrochen wird
Baut auf Lektion 1 und 2 auf: Der dauerhafte Kontext aus Lektion 2 war ein einziger Block Anweisungen. Diese Lektion teilt ihn in Schichten mit unterschiedlichen Aufgaben, damit jede Sitzung nur lädt, was sie braucht — die Kontextkosten-Idee aus Lektion 1, angewandt auf Repository-Ebene.
Nicht Teil dieser Lektion: Ausgaben messen oder senken (Lektion 4) und eine vollständige Anwendung bauen. Was am Bildschirm entsteht, ist bewusst klein — das Thema ist die Struktur drumherum.
Die drei Schichten
| Schicht | Enthält | Geladen | Folge, wenn sie fehlt |
|---|---|---|---|
| Dokumentation | Fakten — was existiert und wie es funktioniert | Wenn relevant | Der Assistent entdeckt das System neu, langsam und uneinheitlich |
| Regeln | Immer gültige Einschränkungen und Verbote, mit dem Warum | In jeder Sitzung | Konventionen driften, eine neue Sitzung nach der anderen |
| Skills | Wiederholbare Abläufe für bestimmte Aufgaben | Bei Bedarf (je nach Tool) | Derselbe Ablauf wird in jeden Prompt neu eingefügt |
Dokumentation — auffindbar, ein Verantwortlicher pro Fakt
- Ein Index, ein klar zugeordneter Fakt pro Thema und eine Änderungsauswirkungstabelle
- Die Dokumentation bleibt auffindbar und veraltet nicht still, wenn sich das Beschriebene ändert
Regeln — kurz, immer geladen, mit Begründung
- Die immer geladene Datei nennt die Verbote — und begründet sie, statt sie nur zu behaupten
- Alles Längere gehört in ein verlinktes Dokument, nicht in die Datei, deren Laden jede Sitzung bezahlt
Skills — Abläufe, die nur bei Bedarf geladen werden
- Ein Skill ist ein wiederverwendbarer Ablauf, den der Assistent lädt, wenn eine bestimmte, wiederkehrende Aufgabe ansteht
- Das Repository des Praxisbeispiels hat heute kein Skills-Verzeichnis auf Projektebene, daher wird der Skill live gebaut — nicht für die Demo vorbereitet
Das Praxisbeispiel
Die Lektion läuft an einem echten, täglich genutzten Repository, nicht an einem Spielzeug für die Lektion. Fünf Muster, jedes mit eigener Aufgabe:
Einstiegsdatei — wird zuerst gelesen
- Eine Datei sagt, was das Projekt ist, was zu tun ist und was nicht — vor allem anderen
- Arbeiten mehrere KI-Agenten im Repository, wird sie an den erwarteten Einstiegspunkt jedes Agenten gespiegelt, damit keiner eine veraltete oder unvollständige Kopie liest
Per Test erzwungene Regel — stärker als Prosa
- Eine Regel, die ein Test prüft, schlägt eine Regel, die in einem Absatz steht, den man überspringen kann
- Dieser Blog macht das bei Übersetzungen: Kategorie und Datum müssen über alle Sprachen byte-identisch bleiben, und
npm run check:translationsschlägt fehl, wenn sie es nicht sind
Entscheidungswarteschlange — freigegeben, bevor es losgeht
- Arbeit wird aufgeschrieben und genehmigt, bevor sie beginnt
- Kein Agent leitet den Umfang aus einer vagen Chatnachricht ab
Änderungsauswirkungs-Index — „Wenn Sie X ändern …“
- Eine Tabelle, die sagt, welche Dokumente veralten, wenn sich eine bestimmte Datei ändert
- Der Zusammenhang wird nachgeschlagen, nicht erst nach einem Fehler neu entdeckt
Definition of Done — je nach Änderung verschieden
- Was als geprüft gilt, hängt von der Art der Änderung ab
- Eine Dokumentationsänderung braucht einen anderen Nachweis als eine Schemamigration
▶ show code▼ hide code
# Rules File — Skeleton
## What this project is
One paragraph. Link to README for everything else.
## Never
- Edit generated or vendored directories (why: overwritten on update)
- Commit secrets or expose them via public env vars (why: shipped to the browser)
- Mark work done without the check for its change type (why: see Definition of Done)
## Where things live
- Architecture → docs/ARCHITECTURE.md
- Change impact → docs/CHANGE_IMPACT.md
- Definition of done → docs/DONE.md
Am Bildschirm
- Zuerst der Fehlerfall — eine neue Sitzung macht eine Änderung, die gegen eine Konvention verstößt, die niemand dort aufgeschrieben hat, wo das Modell sie finden konnte
- Dokumentationsstruktur — Index, ein Verantwortlicher pro Fakt, Änderungsauswirkungstabelle
- Regeln — was in die immer geladene Datei gehört und was in ein verlinktes Dokument
- Durchsetzung — eine geschriebene Regel wird zum Test, absichtlich gebrochen, dann behoben
- Ein Skill, live gebaut — für eine Aufgabe, die sich wirklich wiederholt, dann verglichen mit der Arbeit ohne ihn
- Sortierübung — echte Vorgaben werden Dokumentation, Regeln oder Skills zugeordnet, darunter eine absichtlich falsch einsortierte, die dann korrigiert wird
In welche Schicht gehört es?
▶ show code▼ hide code
# Sorting Guidance
Is it a fact about how the system works? → Documentation
Is it always true, and does breaking it hurt? → Rules (with the why)
Is it a procedure you repeat for a specific task? → Skill
Can a test check it? → Also write the test
Prüfen, bevor Sie sich darauf verlassen
- Dass jede Datei und jeder Pfad im Praxisbeispiel noch existiert und noch aussagt, was behauptet wird — Repositorys driften, und diese Lektion stützt sich auf echte Pfade
- Wie das gezeigte Tool eine Regeldatei und einen Skill nennt, wo beide liegen und wie beide geladen werden
- Ob Skills in diesem Tool bei Bedarf oder immer geladen werden — das Live-Skill-Segment hängt davon ab
- Ob die Größenempfehlung für Regeldateien noch dem aktuellen Rat des Anbieters entspricht
- Dass der live gebaute Skill danach tatsächlich wiederverwendet wird und kein Demo-Requisit ist
Häufige Fragen
„Kann ich nicht einfach alles in die Regeldatei schreiben?“ Können Sie, und jede Sitzung bezahlt dafür. Lange Regeldateien werden von Menschen überflogen und für Modelle verwässert. Halten Sie Regeln kurz; verlinken Sie den Rest.
„Woher weiß ich, dass eine Regel wirklich befolgt wird?“ Schreiben Sie eine Prüfung, die fehlschlägt, wenn sie es nicht wird. Eine Regel ohne Prüfung ist ein Vorschlag.
„Wann wird aus einem Prompt ein Skill?“ Beim dritten Mal, wenn Sie denselben Ablauf einfügen. Speichern Sie ihn einmal und laden Sie ihn, wenn die Aufgabe ansteht.
Weiter: Lektion 4
Lektion 4 kommt absichtlich zuletzt. Sie nutzt alles, was die ersten drei Lektionen vermitteln — Modellwahl, Qualität von Prompt und Kontext sowie Repository-Struktur — als Hebel, um die Kosten eines KI-Workflows zu senken.