Prompt_Engineering von NirDiamant: 22 Notebooks als Lehrbuch, nicht als Bibliothek
22 prompt engineering techniques with hands-on Jupyter Notebook tutorials, from fundamental concepts to advanced strategies for leveraging LLMs.
Auf einen Blick
- Was ist das?
- Das Repository sammelt 22 Jupyter-Notebooks zu Prompting-Techniken von einfachen Templates bis Tree-of-Thought. Es ist Lehrmaterial mit Kursangebot im Rücken, kein installierbares Paket, und genau daraus folgen seine Stärken und Grenzen.
- Für wen ist es gedacht?
- Wer Prompting-Konzepte erklären oder lernen will, findet hier 22 Notebooks, die sich einzeln öffnen lassen. Wer eine Prompt-Verwaltung mit Versionierung, Evaluierung und Deployment in seiner Anwendung braucht, ist hier falsch und sollte zu einer Bibliothek wie DSPy greifen.
- Darf ich es kommerziell nutzen?
- Erst prüfen. Die Lizenz dieses Repositorys ordnen wir nicht automatisch ein; lesen Sie vor jeder kommerziellen Nutzung die LICENSE-Datei.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 1 Tag.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Jupyter Notebook, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Wer das Repository öffnet und wer es besser schließt
Das Repository richtet sich an Leser, die Prompting verstehen wollen, nicht an Teams, die eine Abhängigkeit in eine bestehende Anwendung einbauen. Die README beschreibt es als Sammlung von Tutorials und Implementierungen, die von Grundkonzepten bis zu fortgeschrittenen Strategien reicht. Der Titel der Startseite nennt 22 Hands-on-Tutorials, von Prompt-Templates bis Chain-of-Thought, Self-Consistency und Tree-of-Thought. Wer eine dieser Techniken zum ersten Mal sieht und wissen will, wie sich zwei Varianten im Prompt-Text unterscheiden, bekommt hier für jede Technik ein eigenes Notebook. Wer dagegen eine Prompt-Registry, ein Evaluierungs-Framework oder eine CI-Anbindung sucht, wird in den Materialien nicht fündig: Es gibt keine Releases, kein Paket auf einer Registry und keine Hinweise auf eine stabile Import-Oberfläche. Die Topics des Repositories nennen unter anderem chain-of-thought, few-shot-learning, in-context-learning, langchain und openai. Das deutet darauf hin, dass mehrere Notebooks auf LangChain und die OpenAI-SDK aufsetzen. Bestätigen lässt sich das aus dem vorliegenden Material nicht im Detail, weil die Notebook-Inhalte selbst nicht mitgeliefert wurden.
Ein Notebook pro Technik: die Struktur als eigentliche Entscheidung
Die README spricht von 22 Hands-on-Tutorials, die jeweils eine Technik abdecken. Das legt eine flache Ordnerstruktur nahe, in der jede Datei für sich steht, statt eines gemeinsamen Moduls mit Hilfsfunktionen. Diese Trennung hat Konsequenzen: Man kann ein einzelnes Notebook lesen, ohne den Rest des Repositories zu verstehen. Man kann es aber auch nicht als Baustein in einen anderen Code importieren, ohne den relevanten Abschnitt herauszukopieren. Genau das ist der Unterschied zwischen einer Tutorial-Sammlung und einer Bibliothek. Wer die Technik verstanden hat, schreibt den Prompt ohnehin in seinem eigenen Code neu, weil die Notebooks auf konkrete Beispiele zugeschnitten sind. Der Preis dafür ist, dass es keine gemeinsame API gibt, an der man sich beim Wechsel zwischen Techniken festhalten kann. Bei 22 Notebooks ist ein gewisses Maß an Wiederholung unvermeidlich: Modellaufruf, Antwortausgabe und Hilfsfunktionen tauchen in ähnlicher Form mehrfach auf. Ob der Autor das über eine geteilte Utility-Datei gelöst hat, lässt sich aus dem vorliegenden Material nicht sagen.
Ausführen heißt hier: Notebook öffnen, nicht pip install
Es gibt kein Installationskommando für das Repository als Ganzes. Der Einstieg läuft über die Notebooks selbst, also über eine Umgebung, in der Jupyter läuft. Für die Ausführung sind zwei Dinge zu klären: der Zugang zu einem Modell und die Abhängigkeiten der einzelnen Notebooks. Die Topics nennen openai, langchain und claude, was auf mehrere Anbieter und damit auf mehrere Umgebungsvariablen hindeutet. Welche Variablennamen genau erwartet werden, steht in den Notebooks, nicht in der README. Praktisch bedeutet das: Vor dem ersten Ausführen sollte man ein Notebook öffnen und die erste Zelle lesen, in der ein Client initialisiert wird. Dort steht, welcher Key gesetzt sein muss. Die README selbst enthält an dieser Stelle keine Installations- oder Konfigurationsanweisung, sie verweist stattdessen auf ein Kursangebot und auf einen Newsletter. Das ist ein Hinweis darauf, wo der Autor den Schwerpunkt sieht: beim Lehren, nicht beim Ausliefern eines reproduzierbaren Setups.
Die Kursverzahnung und was sie über die Pflege aussagt
Die README bewirbt an prominenter Stelle einen kostenpflichtigen Kurs mit 20 Modulen, jeweils eine Videovorlesung plus ein Lab. Es gibt ein kostenloses Modul, und ein Satz nennt ein npm install, das einen KI-Assistenten in Claude Code ergänzt, der durch das Tutorial führt. Für ein Repository, das selbst kein npm-Paket ist, ist das ein aufschlussreicher Kontrast: Die Installation, die beworben wird, gehört zum Kursmaterial, nicht zum Prompt-Repository. Der letzte Push liegt laut Metadaten im September 2026, das Repository ist nicht archiviert. Es gibt keine abgerufenen Releases, was bei einer reinen Notebook-Sammlung erwartbar ist: Es gibt schlicht kein Artefakt zu versionieren. Für die Wartung bedeutet das, dass man nicht auf Changelogs oder Versionsnummern achten kann, sondern den Commit-Verlauf lesen muss, wenn man wissen will, ob ein bestimmtes Notebook aktualisiert wurde.
Kein Test, kein Benchmark, keine Aussage über Qualität
Aus dem Repository lassen sich keine Aussagen über Trefferquoten, Token-Kosten oder Latenz der einzelnen Techniken ableiten. Es gibt keine veröffentlichten Releases, keine Benchmark-Ergebnisse und keine Angaben zu Nutzerzahlen, die hier als Qualitätsbeleg taugen würden. Die README nennt eine Newsletter-Zahl, aber das ist Marketing für ein anderes Produkt und sagt nichts über die Notebooks. Wer wissen will, ob Self-Consistency bei seiner Aufgabe besser abschneidet als ein einfacher Prompt, muss das selbst messen. Das Repository liefert die Idee und ein Beispiel, nicht die Evidenz. Das ist keine Schwäche des Formats, aber es ist eine Erwartung, die man vor dem Öffnen korrigieren sollte. Ein Notebook, das eine Technik demonstriert, ist kein Beleg dafür, dass die Technik bei einem bestimmten Modell in einer bestimmten Domäne funktioniert.
Wann Prompting-Tutorials das falsche Werkzeug sind
Der offensichtliche Fehlfall: Aufgaben, bei denen das Modell Zugriff auf aktuelle oder interne Daten braucht. Dafür braucht man Retrieval, nicht einen besseren Prompt. Die README verweist über die Topics auf RAG-nahe Themen und der Autor betreibt ein separates Repository zu RAG-Techniken, aber innerhalb dieses Repositories löst kein Notebook das Abrufproblem. Ein zweiter Fehlfall sind Aufgaben mit harten Formatvorgaben, etwa strukturierte Ausgaben, die ein nachgelagertes System parsen muss. Ein Prompt kann das Format beschreiben, garantiert es aber nicht. Wer hier Verlässlichkeit braucht, landet bei Schema-Validierung oder bei Werkzeugen, die Ausgaben einschränken. Ein dritter Fall: Aufgaben, bei denen sich der Prompt ständig ändert und mehrere Personen daran arbeiten. Ohne Versionierung und ohne Tests wird jede Änderung zum Ratespiel. Genau diese drei Fälle deckt das Repository bewusst nicht ab, weil es sie nicht als sein Problem betrachtet.
Der Vergleich mit DSPy: Beispielsammlung gegen Optimierungsschleife
Der aufschlussreichste Kontrast ist nicht ein anderes Tutorial-Repository, sondern DSPy. Dort schreibt man keine Prompt-Texte mehr von Hand, sondern deklariert Signaturen und lässt eine Optimierungsschleife die Instruktionen und Beispiele anhand eines Bewertungssatzes suchen. Der Unterschied liegt nicht im Umfang, sondern im Ansatz: NirDiamants Repository zeigt, wie ein Mensch einen Prompt formuliert, DSPy verschiebt genau diese Formulierung in einen Suchprozess. Das hat einen Preis, den man nennen muss: Man braucht einen Bewertungssatz und Rechenzeit, und das Ergebnis ist weniger lesbar als ein handgeschriebener Prompt. Umgekehrt hat das Tutorial-Repository einen Preis, den DSPy nicht hat: Jede Verbesserung ist Handarbeit, und es gibt keinen Mechanismus, der eine Verschlechterung automatisch erkennt. Für einen einzelnen Prompt, den man einmal versteht, ist das Lesen eines Notebooks schneller. Für eine Aufgabe mit hundert Varianten und einer messbaren Zielfunktion ist die Schleife überlegen.
Lizenz, Wartung und was vor dem Einsatz zu prüfen ist
Die Metadaten geben NOASSERTION als Lizenz an. Das bedeutet, dass die Lizenz nicht automatisch erkannt wurde und man die LICENSE-Datei im Repository selbst lesen muss, bevor man Code übernimmt. Wer Ausschnitte in ein Produkt kopiert, sollte das vorher klären; eine rechtliche Bewertung kann dieser Text nicht liefern. Zur Wartung: Es gibt keine Releases, also auch keine Upgrade-Pfade. Wenn sich eine SDK-Schnittstelle ändert, etwa die Art, wie ein Client initialisiert wird, betrifft das die Notebooks, die diese Schnittstelle nutzen. Ob und wann der Autor nachzieht, lässt sich nur am Commit-Verlauf ablesen. Der letzte Push im September 2026 zeigt, dass das Repository zu diesem Zeitpunkt aktiv war. Für Leser heißt das: Man sollte ein Notebook nicht als dauerhaft lauffähige Referenz behandeln, sondern als Momentaufnahme, die man beim ersten Ausführen gegen die aktuell installierte SDK-Version prüft.
Redaktionelles Fazit
Wer Prompting-Konzepte erklären oder lernen will, findet hier 22 Notebooks, die sich einzeln öffnen lassen. Wer eine Prompt-Verwaltung mit Versionierung, Evaluierung und Deployment in seiner Anwendung braucht, ist hier falsch und sollte zu einer Bibliothek wie DSPy greifen. Vor dem Einsatz ist zu klären, welche Notebooks einen API-Key voraussetzen, ob die Abhängigkeiten noch zu den aktuellen SDK-Versionen passen und unter welcher Lizenz der Code steht, denn das Repository gibt NOASSERTION an.
Community-Notizen