MSO Foundations

Screen 1: What you will be able to do by the end

MODULE 1 ORIENTATION · 2 MIN Was du am Ende können wirst

Bevor du eine Zeile Code gegen Claude schreibst, hilft es zu wissen, was die Wörter bedeuten.

Dieses Modul führt die Modell-Grundlagen und die technischen Fundamente ein, die der Rest des Developer-Kurses bereits voraussetzt.

Am Ende dieses Moduls wirst du in der Lage sein: 1 Zu erklären, was ein token ist, wie das context window als festes Budget funktioniert, warum Sampling die Ausgaben variabel macht, und was Non-Determinismus für Tests und Evals bedeutet. 2 Die Claude-Modellfamilie und ihre Capability-Tiers zu beschreiben und zwischen der Wahl eines Modells und der Aktivierung eines Reasoning-Modus wie Extended Thinking zu unterscheiden. 3 Zwischen Zero-Shot-, One-Shot- und Multi-Shot-Prompting zu wählen und den Kosten- und Qualitäts-Trade-off beim Hinzufügen von Beispielen abzuwägen. 4 Zu beschreiben, wie ein Developer auf Claude zugreift: SDK versus Raw REST, synchrone versus Streaming-Responses und asynchrone Muster für Hochvolumen-Arbeiten. DISCLAIMER / NOTICE FOR EDUCATIONAL CONTENT

Wir haben diesen Developer-Kurs Modul 1: MSO Foundations gebaut, um dir echte Arbeit mit Claude zu ermöglichen. Behandle ihn als Bildungsinhalte. Er stellt keine rechtliche, finanzielle oder andere professionelle Beratung dar, daher solltest du das Gelernte auf deine eigene Situation anpassen. Unsere Produkte und Services entwickeln sich schnell, daher können bestimmte Inhalte Fehler enthalten oder veraltet sein; denke daran, auf der Website oder in der Dokumentation von Anthropic zu überprüfen. Beispiele und Szenarien im Kurs sind illustrativ und oft fiktiv. Wenn das Kursmaterial ein Unternehmen oder Produkt erwähnt, bedeutet das nicht, dass Anthropic es unterstützt, sie Anthropic unterstützen oder dass wir verbunden sind. Beachte auch, dass deine Nutzung von Anthropic-Produkten und Services durch unsere Bedingungen, Richtlinien und Dokumentation abgedeckt ist; falls etwas in diesem Kurs damit in Konflikt steht, haben diese Vorrang.

Screen 2: How LLMs behave: tokens, context, sampling, non-determinism

TeachingHow LLMs Behave·12 min Wie LLMs sich verhalten: tokens, context, sampling, non-determinism

Tokens Context Window Sampling Non-Determinismus

Tokens: die Einheit von Input, Output und Kosten Claude liest nicht direkt Zeichen oder Wörter. Er liest tokens, und der Durchschnitt der Zeichen pro token hängt vom Tokenizer des betreffenden Modells ab und unterscheidet sich zwischen Modellgenerationen. Behandle jede Faustregel für Zeichen pro token als modellabhängig und bestätige das aktuelle Tokenizer-Verhalten zur Build-Zeit. Alles, das das Modell verarbeitet, wird in tokens gezählt: dein Prompt, die Gesprächshistorie, Tool-Definitionen, Tool-Ergebnisse und die vom Modell generierte Response. Tokens sind sowohl die Einheit der Preisgestaltung als auch des Budgets, daher zählst du beim Schätzen, was ein Feature kostet oder ob ein Input passt, tokens, nicht Wörter. Eine nützliche Gewohnheit ist, in tokens zu denken, da dies die Einheit ist, in der die API abrechnet und das context window misst.

Das context window: ein festes Budget Das context window ist die Gesamtzahl der tokens, die das Modell für eine einzelne Anfrage verarbeiten kann. Es hält alles auf einmal: den System-Prompt, das gesamte bisherige Gespräch, alle eingefügten Dokumente, jedes Tool-Ergebnis und die Modell-Ausgabe. Es ist ein festes Budget mit zwei unterschiedlichen Grenzverhalten. Eine Anfrage, deren Input bereits größer als das Window ist, wird mit einem Validierungsfehler abgelehnt, bevor die Generierung beginnt. Eine Anfrage, die beim Input passt, kann während der Generierung trotzdem die Grenze erreichen. Aktuelle Modelle stoppen dann und geben die bisher generierte Ausgabe mit einem model_context_window_exceeded Stop-Grund zurück, anstatt einen Fehler zu werfen. In jedem Fall erfordert das Ausführen einer langen Session, dass die Anwendung die History vor jedem Aufruf trimmt oder zusammenfasst. In der Entwicklung füllt sich das Window selten, da Test-Inputs kurz sind. In der Produktion hingegen füllen längere Inputs und mehr Turns das Window schneller. Dies ist der Fehler, den Modul 2 im Detail erforscht.

Sampling: warum derselbe Prompt unterschiedliche Antworten geben kann Ein Sprachmodell wählt nicht einen festen nächsten token. Bei jedem Schritt erzeugt es eine Wahrscheinlichkeitsverteilung über mögliche nächste tokens und sampelt dann daraus. Einstellungen wie temperature formen diese Verteilung: eine niedrigere Temperatur konzentriert die Wahrscheinlichkeit auf die wahrscheinlichsten tokens und macht die Ausgabe wiederholbarer, während eine höhere Temperatur sie ausbreitet und die Ausgabe variabler macht. Da die Wahl gesampelt statt fest ist, kann derselbe Prompt zweimal ausgeführt unterschiedliche Formulierungen zurückgeben, auch wenn beide Antworten korrekt sind. Dies ist eine Eigenschaft, wie das Modell generiert. Beachte, dass Sampling-Kontrollen modellabhängig sind: die neuesten Claude-Modelle akzeptieren keine nicht-standardmäßigen Sampling-Parameter. Das Setzen von temperature, top_p oder top_k gibt einen 400-Fehler zurück, und das Verhalten bei diesen Modellen wird stattdessen durch Prompting gesteuert. Auch wenn temperature akzeptiert wird, macht temperature 0 die Ausgaben wiederholbarer, garantiert aber keine identischen Ausgaben über Aufrufe hinweg. Bestätige die aktuelle Parameter-Unterstützung in der API-Referenz zur Build-Zeit.

Non-Determinismus: was er für Tests und Evals bedeutet Non-Determinismus ist die primäre Folge des Sampling: identische Inputs garantieren keine identischen Outputs. Das ändert, wie du ein Claude-Feature testest. Ein Test, der den genauen Text einer Response behauptet, wird inkonsistent sein, da das Modell dieselbe korrekte Antwort auf viele Weisen ausdrücken kann. Stattdessen behaupte die Eigenschaft, die gelten muss: ein erforderliches Feld ist vorhanden, ein Wert liegt im Bereich, die Struktur wird geparst. Wenn du Bedeutung statt Struktur beurteilen musst, verwende ein Eval mit einem modellgestützten Judge. Dies ist der Grund, warum der Kurs Evals als Standard für das Wissen behandelt, dass ein Feature korrekt ist, und warum Modul 3 diese Fähigkeit aufbaut.

Screen 3: Model options and reasoning modes

TeachingModels & Reasoning·10 min Modelloptionen und Reasoning-Modi

Die Modellfamilie Reasoning-Modi Wie sie zusammenarbeiten

Die Claude-Modellfamilie Claude ist eine Familie von Modellen, die derzeit vier Tiers umfasst: Fable, Opus, Sonnet und Haiku. Jedes Modell stellt einen anderen Trade-off zwischen Kosten, Latenz und Capability dar. Sonnet ist der ausgewogene Standard für die meisten Production-Workloads. Haiku ist für Geschwindigkeit und Kosteneffizienz bei Aufgaben gebaut, die in sein Capability-Spektrum passen. Opus bewältigt anspruchsvolle Arbeiten über dem Sonnet-Spektrum, und Fable ist der fähigste Tier, gebaut für die anspruchsvollste Reasoning-, Coding- und Agentic-Arbeit, wo maximale Intelligenz die Priorität ist. Der praktische Standard ist, mit Sonnet zu beginnen, nur dann eine Stufe höher zu gehen, wenn ein Eval zeigt, dass der aktuelle Tier deine Qualitätsanforderung nicht erfüllt, und nur dann zu Haiku zu gehen, wenn ein Eval zeigt, dass der Qualitätsverlust für die Aufgabe akzeptabel ist. Bestätige die aktuelle Modell-Aufstellung und Identifikatoren gegen platform. claude. com/docs zur Build-Zeit, da die Claude-Familie sich entwickelt.

Reasoning-Modi sind eine separate Einstellung von der Modellwahl Die Wahl, welches Modell ausgeführt wird, ist eine Entscheidung. Ob das Modell vor der Antwort nachdenkt, ist eine separate Entscheidung, die du pro Aufruf triffst. Bei aktuellen Modellen ist der Reasoning-Modus Adaptive Thinking: das Modell entscheidet, wann und wie viel es denkt, und du stimmst die Tiefe mit einer Effort-Einstellung ab, anstatt ein festes token-Budget (die ältere budget_tokens-Kontrolle ist veraltet und gibt bei den neuesten Modellgenerationen einen 400-Fehler zurück). Thinking-Inhalte werden bei den neuesten Modellen standardmäßig aus Responses ausgelassen. Fordere zusammengefasste Anzeige an, wenn du sie anzeigen musst. Reasoning verdient seinen Preis bei schwierigen, mehrstufigen Problemen und wird bei Lookups und Klassifikation verschwendet. Der Schlüsselpunkt für dieses Modul ist, dass die beiden Hebel zusammengesetzt sind: die Modellwahl wählt das Familienmitglied, während der Reasoning-Modus pro Anfrage konfiguriert wird. Pro-Modell-Standards unterscheiden sich (einige der neuesten Modelle denken standardmäßig adaptiv oder immer), daher bestätige die aktuellen Thinking-Standards für dein Modell zur Build-Zeit.

Wie die beiden zusammenarbeiten Da Modellwahl und Reasoning-Modus unabhängig sind, kann jeder separat gesetzt werden. Ein fähiges Modell mit ausgeschaltetem Reasoning ist schnell und direkt, während ein kleineres Modell mit eingeschaltetem Reasoning mehr tokens zum Denken ausgibt. Die anspruchsvollsten Aufgaben kombinieren ein fähiges Modell mit einer höheren Effort-Einstellung. Modul 2 lehrt die Mechanik des Aktivierens von Reasoning und des Umgangs mit den Thinking-Blöcken, die es zurückgibt. Die Entscheidung, welches Modell ausgeführt wird, abgewogen gegen Kosten, Latenz und Qualität, wird in Modul 4 behandelt.

Screen 4: Prompting modes: zero-shot, one-shot, multi-shot

TeachingPrompting Modes·8 min Prompting-Modi: zero-shot, one-shot, multi-shot

Die drei Modi Kosten- und Qualitäts-Trade-off Modus und Modellwahl

Die drei Modi Getrennt davon, wie du einen Prompt formulierst, ist, wie viele durchgearbeitete Beispiele du dem Modell darin gibst. Zero-Shot gibt die Anweisung und keine Beispiele: du beschreibst die Aufgabe und fragst nach dem Ergebnis. One-Shot fügt ein Beispiel des Inputs gepaart mit der gewünschten Ausgabe hinzu. Multi-Shot, auch Few-Shot genannt, enthält mehrere solche Beispiele. Die Beispiele sind keine Trainingsdaten; sie sitzen im Prompt und zeigen dem Modell die genaue Form der Antwort, die du willst, was eine Beschreibung allein oft nicht schafft.

Der Kosten- und Qualitäts-Trade-off Jedes Beispiel, das du hinzufügst, kostet tokens bei jedem Aufruf und verbraucht Context-Budget, daher handelt die Wahl Qualität gegen Kosten ab. Greifen zu Zero-Shot, wenn die Aufgabe einfach ist und die Ausgabeform offensichtlich ist. Gehe zu One-Shot oder Multi-Shot, wenn die Ausgabe eine spezifische Struktur, Groß-/Kleinschreibung oder Edge-Case hat, die eine Beschreibung immer wieder verfehlt. Oft beheben ein oder zwei korrekte Beispiele das Problem schneller als ein weiterer Absatz Anweisungen. Die allgemeine Disziplin, die Modul 2 verstärkt, ist, die kleinste Menge an Prompt hinzuzufügen, die ein zuverlässiges Ergebnis erzeugt.

Modellwahl interagiert mit Modellwahl Prompting-Modus und Modellwahl sind verwandte Hebel. Ein fähigeres Modell gelingt oft Zero-Shot bei einer Aufgabe, bei der ein kleineres Modell ein paar Beispiele braucht, um die Struktur zu treffen, daher kann das Hinzufügen von Beispielen einem billigeren Modell ermöglichen, die Arbeit zu erledigen. Die beiden Entscheidungen lohnen sich, zusammen zu treffen: versuche das einfachste Modell und die wenigsten Beispiele, die dein Eval erfüllen, und füge Capability oder Beispiele nur dort hinzu, wo das Eval sagt, dass du sie brauchst.

Screen 5: The technical substrate: SDKs, REST, streaming, async

TeachingTechnical Substrate·12 min Das technische Substrat: SDKs, REST, Streaming, Async

SDK vs. REST Sync, Streaming & Echtzeit Async für Hochvolumen-Arbeiten

Wie ein Developer Claude erreicht: SDK versus Raw REST Im Kern wird Claude über eine HTTP REST API erreicht: dein Code sendet eine Anfrage an einen Endpoint mit deinem API-Schlüssel und einem JSON-Body und liest eine JSON-Response zurück. Du kannst diesen Endpoint direkt mit jedem HTTP-Client aufrufen. Häufiger verwendest du ein offizielles SDK, verfügbar für Python und TypeScript unter anderem, das eine dünne Convenience-Schicht über derselben REST API ist. Es verwaltet Authentifizierung, Request-Konstruktion, Wiederholungen und Response-Parsing, damit du weniger Boilerplate schreibst. Das SDK und Raw REST erreichen dieselbe API und dasselbe Modell. Das SDK spart dir davor, Requests von Hand zusammenzusetzen. Modul 2 baut gegen das SDK und die Messages API auf, die auf demselben Fundament sitzt.

Synchrone, Streaming- und Echtzeit-Responses Eine synchrone Anfrage ist das einfachste Muster: du sendest die Anfrage und wartest, bis die komplette Response in einem Stück zurückkommt, dann handelst du danach. Das ist in Ordnung für kurze Responses und Backend-Jobs, bei denen niemand wartet. Wenn eine Response lang ist oder ein Benutzer zuschaut, sendet Streaming die Response in Stücken, während das Modell sie generiert. Die Ausgabe erscheint sofort statt nach einem leeren Bildschirm-Warten, und dein Code setzt die Stücke zur finalen Nachricht zusammen. Claude stellt Streaming über dieselbe HTTP-Verbindung mit Server-Sent Events zur Verfügung. Modul 2 lehrt, wie man einen Stream sicher konsumiert und sich erholt, wenn er unterbrochen wird.

Asynchrone Muster für Hochvolumen-Arbeiten Zwei Muster adressieren Hochvolumen-Arbeiten, und sie lösen unterschiedliche Probleme. Das Python SDK stellt einen Async-Client (AsyncAnthropic) zur Verfügung, der nicht-blockierendes Async/Await verwendet, um API-Aufrufe zu machen, ohne deinen Anwendungs-Thread zu blockieren. Im TypeScript SDK ist der Standard-Anthropic-Client Promise-basiert, daher wartest du Aufrufe direkt ab. Es gibt keine separate Async-Client-Klasse. In jedem Fall kehrt die Anfrage immer noch in Echtzeit zurück, aber deine Anwendung kann andere Arbeiten erledigen, während sie wartet. Dies ist das richtige Muster, wenn du Concurrency ohne Blockierung brauchst. Die Message Batches API ist ein separates Muster für Bulk-Offline-Workloads. Du reichst einen großen Satz von Anfragen in einem Aufruf ein, erhältst einen Identifikator und fragst nach Fertigstellung ab. Batch-Jobs können bis zu 24 Stunden dauern und laufen mit niedrigeren Pro-Token-Kosten im Austausch für diese Latenz. Dies passt zu Offline-Pipelines, Evaluation-Läufen und Bulk-Jobs, bei denen niemand auf jedes Ergebnis wartet und Kosten wichtiger sind als Turnaround-Zeit.

Screen 6: Module quiz

QuizModule 1·5 min Modul-Quiz Versuche es jetzt. Hier sind einige Multiple-Choice-Fragen, um dein Verständnis des Kurses bisher zu testen. Frage 1Ein Teamkollege sagt, zwei identische Prompts müssen identischen Text zurückgeben. Was ist die genaueste Antwort? ADas ist wahr, das Modell ist deterministisch. BNicht unbedingt, das Modell sampelt jeden nächsten token aus einer Wahrscheinlichkeitsverteilung, daher kann die Formulierung variieren, auch wenn beide Antworten korrekt sind. CDas ist nur wahr, wenn Streaming aus ist. DDas ist nur wahr beim größten Modell. Frage 2Welche Aussage trennt Modellwahl am besten von Reasoning-Modus? ASie sind dieselbe Einstellung. BExtended Thinking ist ein anderes Modell. CModellwahl wählt, welches Familienmitglied läuft; Extended Thinking ist eine Pro-Aufruf-Einstellung, die jedes unterstützende Modell mit an oder aus laufen kann. DReasoning-Modus ist pro Konto fest. Frage 3Eine kurze, gut spezifizierte Klassifikationsaufgabe gibt die richtige Antwort Zero-Shot zurück. Was macht das Hinzufügen von drei Beispielen höchstwahrscheinlich? AVerbesserung der Genauigkeit erheblich. BFügt Token-Kosten bei jedem Aufruf für wenig oder keinen Gewinn hinzu. CÄndert das verwendete Modell. DDeaktiviert Sampling. Frage 4Du musst Tausende von Inputs offline mit den niedrigsten Kosten verarbeiten. Welche Form passt? ASynchrone Aufrufe in einer Schleife. BStreaming. CCharge-Einreichung mit Abfrage. DEin größeres Context Window.

Quiz einreichen Jetzt überspringen

Screen 7: Exercise: predict the behavior

ExercisePredict the Behavior·6 min Übung: Verhalten vorhersagen Versuche es jetzt. Jedes Szenario unten präsentiert eine Konfiguration aus einem der vier Fundamente dieses Moduls: Sampling, Prompting-Modus, Request-Form und das Context-Budget. Wähle für jedes die Antwort, die das korrekte Verhalten vorhersagt und den Grund identifiziert. Teilpunkte sind verfügbar, wenn du drei von vier richtig beantwortest. Szenario 1Betrachte eine Klassifikationsaufgabe, die bei temperature 0 versus dieselbe Aufgabe bei hoher Temperatur läuft. Vorhersage, wie sich die Outputs über wiederholte Läufe unterscheiden. ABeI niedriger Temperatur konzentriert das Modell die Wahrscheinlichkeit auf die wahrscheinlichsten tokens, daher geben wiederholte Läufe das gleiche Label weit konsistenter zurück, obwohl nie mit garantiertem Determinismus, auch bei temperature 0. Bei hoher Temperatur breitet sich die Verteilung aus, daher können Formulierung und sogar das gewählte Label variieren. Für einen Klassifizierer willst du das Verhalten mit niedriger Temperatur und Wiederholbarkeit. BBei beiden Konfigurationen wird identische Ausgabe bei jedem Lauf zurückgegeben, da temperature nur die Response-Länge beeinflusst, nicht welche tokens gewählt werden. CDer Lauf mit hoher Temperatur ist genauer, da das Ausbreiten der Verteilung dem Modell ermöglicht, mehr der korrekten Antworten zu berücksichtigen. DTemperature hat keine Auswirkung auf eine Klassifikationsaufgabe, da Klassifikation immer ein festes Label unabhängig vom Sampling zurückgibt. Szenario 2Betrachte eine Aufgabe, die unter einem Zero-Shot-Prompt immer wieder Ausgabe in der falschen Struktur zurückgibt. Vorhersage, was sich ändert, wenn du zu Multi-Shot wechselst. ADas Wechseln zu Multi-Shot trainiert das Modell auf der neuen Struktur um, daher ist die Änderung permanent über jeden zukünftigen Aufruf, sobald die Beispiele gesendet werden. BDas Hinzufügen von zwei oder drei korrekten Input-Output-Beispielen zeigt dem Modell die genaue Struktur zum Treffen, was normalerweise ein Strukturproblem behebt, das mehr Anweisungstext nicht tat. Die Kosten sind extra tokens bei jedem Aufruf, daher füge die wenigsten Beispiele hinzu, die die Ausgabe zuverlässig machen. CMulti-Shot wird ein Strukturproblem nicht helfen; nur das Erhöhen der Temperatur ändert die Form der Ausgabe. DMulti-Shot senkt die Token-Kosten pro Aufruf, da Beispiele dem Modell ermöglichen, kürzere Responses zu erzeugen. Szenario 3Betrachte eine Pipeline, die 50. 000 Dokumente über Nacht mit niemandem, der wartet, verarbeiten muss. Vorhersage, welche Request-Form passt und warum. AEine synchrone Schleife passt am besten, da das Aufrufen der API einmal pro Dokument das einfachste Muster ist und den Overhead der Einreichung eines Batch vermeidet. BStreaming passt am besten, da das Senden der Response in Stücken der Pipeline ermöglicht, jedes Dokument sooner zu verarbeiten. CDas Batch-Muster passt: reiche die Anfragen in einem Batch ein und frage nach Fertigstellung ab, akzeptiere längere Latenz für niedrigere Pro-Token-Kosten. Eine synchrone Schleife würde Rate Limits treffen und die Anwendung blockieren, und Streaming bringt nichts, da niemand zuschaut. DEin größeres Context Window passt am besten, da das Passen aller 50. 000 Dokumente in eine Anfrage wiederholte Aufrufe vermeidet. Szenario 4Betrachte eine lange Multi-Turn-Agent-Session, deren Context Window immer wieder füllt. Vorhersage der Symptome und benenne das Budget, das schuld ist. ADas Modell lässt die ältesten Turns stillschweigend fallen, um Platz zu machen, daher läuft die Session weiter, aber verliert stillschweigend frühen Context ohne Fehler. BDas Context Window ist ein festes Token-Budget; während sich History und Tool-Ergebnisse ansammeln, füllt es sich. Ein Input, der bereits zu groß ist, wird mit einem Fehler abgelehnt, bevor die Generierung beginnt, während eine Anfrage, die beim Input passt, aber die Grenze während der Generierung erreicht, mit gekürzter Ausgabe und einem model_context_window_exceeded Stop-Grund zurückkommt. Das Symptom ist eine Session, die in Tests gut lief, aber fehlschlägt, sobald Inputs wachsen, weshalb die Anwendung History trimmen oder zusammenfassen muss. CDas Symptom ist langsameres Sampling, und das Budget, das schuld ist, ist die Temperature-Einstellung, die gesenkt werden muss, während die Session wächst. DEs gibt kein festes Budget; das Window expandiert automatisch, um welche History sich auch ansammelt, daher schlägt eine lange Session nie aus diesem Grund fehl.

Einreichen Jetzt überspringen

Screen 8: Recap: five takeaways

RecapFive Takeaways·2 min Zusammenfassung: fünf Erkenntnisse

1 Tokens sind die Einheit von Input, Output und Kosten. Denke und budgetiere in tokens statt Wörtern, da dies das ist, was die API misst und das Context Window misst.

2 Das Context Window ist ein festes Token-Budget, das die ganze Anfrage auf einmal hält. Ein zu großer Input gibt einen Fehler vor der Generierung, während das Erreichen der Grenze während der Generierung gekürzte Ausgabe mit einem model_context_window_exceeded Stop-Grund zurückgibt, daher ist das Verwalten der History die Aufgabe der Anwendung.

3 Sampling macht die Generierung nicht-deterministisch. Derselbe Prompt kann bei jedem Lauf unterschiedliche Formulierung zurückgeben, daher ist das Testen auf genauen Text unzuverlässig. Dies ist das, wofür Evals gebaut sind.

4 Modellwahl und Reasoning-Modus sind separate, zusammensetzbare Hebel. Wähle das kleinste Modell und das einfachste Reasoning und Prompting, das dein Eval erfüllt, und füge Capability nur dort hinzu, wo das Eval sagt, dass du sie brauchst.

5 Ein Developer erreicht Claude über eine REST API, normalerweise durch ein SDK. Wähle zwischen synchron, Streaming, Async/Await oder Batch basierend darauf, ob ein Benutzer wartet und ob die Workload Echtzeit oder Bulk-Offline ist.

Was kommt als nächstes: Modul 2 setzt diese Fundamente über Prompting-Handwerk, Tool-Schemas, Streaming, Context-Engineering und Agent-Konstruktion um.

Quellen Claude 101 (Skilljar), Building with the Claude API (Skilljar), AI Fluency: Framework & Foundations (Skilljar), platform. claude. com/docs. Überprüfe Produktspezifika zur Veröffentlichungszeit.

Du kannst jetzt das gemeinsame Vokabular des Developer-Kurses sprechen. Tokens, Context, Sampling, Modell-Tiers, Prompting-Modi und die Transport-Mechanik der API haben jetzt Namen, daher kann der Rest des Kurses direkt darauf aufbauen.

Screen 9: Congrats! You've successfully completed this module.

Module CompleteDeveloper Path·2 min Glückwunsch! Du hast dieses Modul erfolgreich abgeschlossen. Du kannst jetzt tokens, das Context Window, Sampling und Non-Determinismus erklären, Modellwahl von Reasoning-Modus unterscheiden, den richtigen Prompting-Modus für die Aufgabe wählen und beschreiben, wie ein Developer Claude über SDKs, REST, Streaming und Async-Muster erreicht. Diese Fundamente sind das gemeinsame Vokabular, auf dem der Rest des Developer-Kurses aufbaut.

0 of ? checkpoints passed

M1

MSO Foundations Tokens, Context, Sampling, Modell-Tiers, Prompting-Modi und das technische Substrat.

Du bist hier

M2

Production-Grade Prompting, Agents & Tool-use Prompting-Handwerk, Extended Thinking, Tool-Schemas, Streaming, Context-Engineering und Agent-Konstruktion.

Nächstes

M3

Claude Code, MCP & Integration Permission-Modi, dauerhafter Project-Context, Plugin-Packaging und MCP-Integration ohne Credential-Lecks.

M4

Production Engineering, Evals, and Security Evals, Tracing, Failure-Handling, Kosten- und Orchestration-Budgets und Security-Grenzen, die in Production halten.

M5

Accelerators and IP Contribution Package Accelerators, bereite verifiable Contributions vor, wähle Deployment-Plattformen und markiere Trust-Grenzen.

Modul überprüfen Von vorne beginnen Starte Modul 2 → Zurück zur Kurs-Startseite

Modul 1 abgeschlossen.