Accelerators & IP-Beitrag — Claude Certified Developer Foundations Prep Course

Screen 1: Was du am Ende können wirst

ORIENTIERUNG DEVELOPER MODUL 5 · 2 MIN Was du am Ende können wirst

Dokumentiere den Build gut, damit der nächste Einsatz darauf aufbaut statt von vorne zu beginnen.

In den letzten drei Modulen hast du einen Production-Agent gebaut, ihn in Claude Code mit den richtigen Berechtigungs- und Kontextkontrollen integriert und die MCP-Verbindungen eingerichtet, die eine Sicherheitsprüfung bestehen. Jeder davon war ein funktionierender Build.

Dieses Modul behandelt, was nach einem funktionierenden Build passiert. Du kannst ihn beim nächsten Einsatz von Grund auf neu aufbauen, oder du packst ihn einmal, damit das nächste Team ihn nur noch konfiguriert. Der zweite Weg gibt dir Zeit für neue Arbeiten statt wiederholtem Neuaufbau.

Am Ende dieses Moduls kannst du:

1 Eine funktionierende Lösung als wiederverwendbaren Accelerator verpacken – ob als parametrisierte Agent-Vorlage, konfigurierbarer MCP-Server oder tragbare Eval-Suite – damit der nächste Einsatz ein Asset konfiguriert statt es komplett neu zu bauen. 2 Ein Tool, Muster oder Fix über dokumentierte Kanäle zurückbeitragen und es so vorbereiten, dass ein Maintainer es akzeptiert, um ein privates Asset in gemeinsame Infrastruktur umzuwandeln. 3 Wählen, wo eine Claude-Workload über die First-Party-API, Amazon Bedrock, Google Vertex AI und Third-Party-Plattformen läuft, und versioniere, was ausgeliefert wird, damit eine Modell- oder Prompt-Änderung Production nicht stillschweigend bricht. 4 Plattformen nach Latenz, Compliance und Kosten vergleichen, damit die Wahl von einem Procurement- und Security-Team genehmigt werden kann, statt ein Standard, den dein Team gegriffen hat. 5 Eine Anwendung bauen, die mehrere Claude-Deployments in einen Workflow koordiniert, und sie so abgrenzen, dass Daten- und Identity-Grenzen unter einer Sicherheits- oder Compliance-Prüfung gehalten werden.

Dieses Modul ist für den Developer, der einen funktionierenden Build hat und ihn jetzt haltbar machen muss. Du bist praktisch veranlagt, code-orientiert und muster-orientiert, und die früheren Module haben das angenommen und darauf aufgebaut. Zu diesem Punkt kannst du einen Production-Agent schreiben, ihn in Claude Code konfigurieren, MCP-Verbindungen verdrahten, die eine Sicherheitsprüfung bestehen, und alles mit Evals beweisen. Dieses Modul unterrichtet nichts davon neu. Es setzt in dem Moment an, in dem dein Code korrekt läuft, und stellt die schwierigere Frage: Kann jemand anderes ihn wiederverwenden, kann ein Maintainer ihn akzeptieren, kann er ein Modell-Update überstehen, und kann ein Security- oder Procurement-Team genehmigen, wo er läuft. Die Arbeit hier ist weniger über Code schreiben und mehr über die Entscheidungen, die fertigen Code wiederverwendbar, deploybar und verteidigbar für Menschen machen, die ihn nicht geschrieben haben.

„DER BUILD" IN DIESEM MODUL

Alles in diesem Modul hängt von einer wiederkehrenden Lücke ab: Ein funktionierender Build ist noch nicht ein Build, der Wiederverwendung, Überprüfung oder Deployment übersteht. In der Entwicklung lief die Vorlage, der Beitrag löste dein Problem, das Modell antwortete, die Plattform war einfach zu bauen, und jede Plattform bestand ihre eigenen Tests. Nichts davon ist der fertige Zustand. Die gleiche Vorlage muss von einem Team konfiguriert werden, das nie mit dir sprach. Der gleiche Beitrag muss von einem Maintainer verifizierbar sein, der nichts rekonstruieren muss. Das gleiche Modell muss gepinnt sein, damit eine Upstream-Änderung eine Entscheidung statt eine Überraschung ist. Die gleiche Plattform muss eine Residenz- und Compliance-Prüfung des Kunden bestehen. Die gleichen verbundenen Plattformen müssen ihre Vertrauensgrenzen unter Audit halten. Jedes Thema in diesem Modul ist eine andere Version der gleichen Lektion: Der Punkt, an dem Code anfängt zu funktionieren, ist, wo die Arbeit dieses Moduls beginnt. Mehr dieser Entscheidungen als du vielleicht erwartest werden von der bestehenden Cloud, Compliance-Haltung und dem Review-Prozess des Kunden getrieben.

HAFTUNGSAUSSCHLUSS / HINWEIS FÜR BILDUNGSINHALTE

Wir haben diesen Developer-Kurs Modul 5: Accelerators and IP Contribution gebaut, um dir zu helfen, echte Arbeit mit Claude zu erledigen. Behandle ihn als Bildungsinhalt. Er stellt keine rechtliche, finanzielle oder andere professionelle Beratung dar, daher passe das, was du lernst, an deine eigene Situation an. Unsere Produkte und Dienstleistungen entwickeln sich schnell, daher kann bestimmter Inhalt Fehler enthalten oder veraltet sein; denke daran, auf der Website oder Dokumentation von Anthropic zu überprüfen. Beispiele und Szenarien im Kurs sind illustrativ und oft fiktiv. Wenn der Kursinhalt 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 -Dienstleistungen durch unsere Bedingungen, Richtlinien und Dokumentation abgedeckt ist; wenn etwas in diesem Kurs damit in Konflikt steht, haben sie Vorrang.

Screen 2: Einen funktionierenden Build verpacken, damit der nächste Einsatz von einem Asset startet

UnterrichtVerpackung für Wiederverwendung·16 min Einen funktionierenden Build verpacken, damit der nächste Einsatz von einem Asset startet Du hast die vorherigen Module mit einem funktionierenden Build beendet: eine Agent-Schleife, einen konfigurierten MCP-Server, ein Eval, das beweist, dass der Prompt funktioniert. Das Teuerste und Zeitaufwändigste in einem Team ist die Engineering-Zeit, die für den Neuaufbau der gleichen Sache für den nächsten Kunden aufgewendet wird. Was ein Accelerator tut: Halte die wiederverwendbaren Teile und trenne den Rest Ein Accelerator ist eine Lösung, die so verpackt ist, dass zukünftige Einsätze von einer funktionierenden Grundlage statt von einem leeren Repository starten. In Blueprint-Begriffen ist dies Verpackung für Wiederverwendung: Trennung von einsatzspezifischem Code von dem wiederverwendbaren Kern und Parametrisierung des Rests. Nimm einen funktionierenden Build, trenne die Teile, die kundenspezifisch sind, und stelle sie als Parameter mit dokumentierten Defaults zur Verfügung. Das Asset konfiguriert sich dann statt komplett neu geschrieben zu werden. Verpackung für Wiederverwendung, während der Build frisch ist, ist billiger als die Absicht Monate später zu rekonstruieren, wenn die Person, die wusste, warum ein Wert hardcodiert war, weitergezogen ist.

Die meiste wiederverwendbare Arbeit fällt in verschiedene Asset-Typen, und jeder wird anders verpackt Die meiste wiederverwendbare Arbeit fällt in eine von drei Kategorien, die in diesem Modul verwendet werden: eine Vorlage, ein konfigurierbarer Server oder ein tragbares Eval. Jeder Typ hält eine andere Art von Arbeit und muss auf seine eigene Weise verpackt werden. Die falsche Art zu greifen kann ein Asset aussehen lassen, als wäre es wiederverwendbar, während es immer noch schwierig ist, es anzuwenden.

Asset-TypWas es bundeltWas korrekte Verpackung erfordert Agent-VorlageThe system prompt, die Tool-Schemas und die Loop-Struktur von einem funktionierenden Agent. Ziehe die domänenspezifischen Werte in die Konfiguration mit dokumentierten Defaults, damit ein neues Team die Werte setzt statt die Loop zu bearbeiten. MCP-Server-PaketDie Tools, die der Server bereitstellt, mit ihren Eingaben und dem Umfang, den das installierende Team kontrolliert. Dokumentiere jede Tool-Eingabe und lass das installierende Team den Umfang setzen, damit der Server in einer neuen Umgebung ohne Code-Bearbeitungen installiert wird. Eval-SuiteDer bewertete Test-Satz und die Judge-Rubrik, die beweisen, dass das Asset funktioniert. Versende den Datensatz und die Rubrik zusammen, damit ein neues Team sie in ihrem eigenen Kontext ausführen und das Asset dort noch funktioniert. Die gleiche Eval-Suite fungiert auch als Gate bei der Bereitstellung. Wenn du eine neue Modellversion in Production hochfährst, führe sie gegen einen gepinnten Baseline-Score aus, bevor die Version live geht.

Ein Agent als eine Reihe loser Skripte statt als Vorlage zu versenden ist die häufigste Version des falschen Ansatzes. Die Skripte laufen, also sehen sie wiederverwendbar aus, aber jeder kundenspezifische Wert ist in einer anderen Datei vergraben, und das nächste Team kopiert und divergiert sie statt ein Asset zu konfigurieren. Dokumentiere sowohl den Code als auch die Annahmen Code beschreibt Verhalten. Dokumentation behandelt, was ein zukünftiger Builder nicht zuverlässig aus dem Lesen der Quelle ableiten kann: die Annahmen, die das Asset über seine Umgebung macht, die Eingaben, die es erwartet, die Fehlermodi, die es bereits handhabt, und das Eval, das definiert, ob es noch funktioniert. Ohne dies behandelt das nächste Team das Asset als Black Box und baut es neu. Bündele das Audit-Log als Teil des Pakets Ein Reviewer eines regulierten Kunden fragt, welche Daten das Asset berührt, unter welcher Identity es handelt und welches Log es hinterlässt. Ein Accelerator ohne diese besteht eine Demo und steckt bei der ersten Sicherheitsprüfung fest. Behandle das Audit-Log als Teil des Pakets. Die Verpackungs-Checkliste Halte diese Checkliste neben dem Build, während du ihn verpackst. Jede Spalte ist eine Entscheidung, die du einmal pro Asset triffst.

Asset-TypWas zu parametrisierenWas zu dokumentierenWas für Audit zu bündeln Agent-VorlageJeder Wert, der sich pro Kunde ändert: Prompts, Pfade, Umfänge, Credentials per Referenz und Schwellwerte. Umgebungsannahmen, erwartete Eingaben, behandelte Fehlermodi und das Eval, das Funktionieren definiert. Die berührten Daten, die Identity, unter der gehandelt wird, und das Log, was das Asset tat. MCP-ServerUmfänge, Credentials per Referenz und kundenspezifische Pfade. Erwartete Eingaben pro Tool, Umfang-Grenzen und behandelte Fehlermodi. Die berührten Daten, die Identity, unter der gehandelt wird, und das Log, was das Asset tat. Eval-SuiteSchwellwerte und Datensatz-Pfade, die sich pro Kunde oder Umgebung ändern. Die Rubrik-Logik, was die Scores bedeuten und der Baseline, an den das Asset gepinnt ist. Die berührten Daten, die Identity, unter der gehandelt wird, und das Log, was das Asset tat.

Funktioniert gut Parametrisierung, während der Build frisch ist, verwandelt eine Lieferung in ein Asset, das der nächste Einsatz in Stunden konfiguriert.

Fügt Kosten oder Komplexität hinzu Trennung von verallgemeinerbaren von kundenspezifischen Teilen und Dokumentation von Annahmen fügt echte Zeit zum ersten Build hinzu.

Verwende einen anderen Ansatz Für ein One-Off, das ein Kunde nie wiederverwenden wird, ist der Verpackungs-Overhead nicht wert: Versende den Build und gehe weiter.

Screen 3: Die Vorlage, die schnell ausgeliefert wurde und nicht wiederverwendet werden konnte

VorsichtVerpackung für Wiederverwendung·2 min Die Vorlage, die schnell ausgeliefert wurde und nicht wiederverwendet werden konnte

Setup Hardcoding wird schneller ausgeliefert und du hast unter Zeitdruck gearbeitet, also hast du die Werte, die die Demo machten, hardcodiert. Die Vorlage funktionierte. Das ist genau der Grund, warum niemand sie wieder anschaute, bis das nächste Team versuchte, sie wiederzuverwenden.

Dies ist eine Postmortem, geschrieben wie ein Team eine schreibt, nachdem der Wiederverwendungsversuch fehlschlägt, damit du den Fehler sehen kannst, bevor jemand ihn als Fehler bezeichnet. Was passierte Ein Team baute eine Agent-Vorlage für einen Kunden-Einsatz und lieferte sie pünktlich aus. Um die Frist einzuhalten, gingen die kundenspezifischen Werte direkt in den Code: der Repository-Pfad, der Modellname, die Review-Schwellwerte und eine Handvoll Prompt-Fragmente, die für die Domäne dieses Kunden spezifisch waren. Die Vorlage lief, der Einsatz schloss, und der Build ging in das gemeinsame Repository mit dem Label „wiederverwendbar".

Monate später holte sich ein zweites Team ihn für einen ähnlichen Einsatz. Sie konnten ihn nicht konfigurieren, weil es nichts zu konfigurieren gab. Jeder Wert, der sich ändern musste, war in die Loop gebacken, wo das zweite Team ihn nicht sehen konnte, ohne die ganze Datei zu lesen. Es gab kein Dokument, das sagte, welche Werte kundenspezifisch waren und welche lastentragend. Es gab auch kein gebündeltes Eval, also bestätigte nichts, nachdem sie die Bearbeitungen erraten hatten, dass die Vorlage im neuen Kontext noch funktionierte. Sie mussten sie von Grund auf neu schreiben.

Warum es brach Der Build wurde als fertig behandelt, in dem Moment, in dem er lief, statt in dem Moment, in dem er wiederverwendet werden konnte. Hardcoding war der vernünftige Ruf unter einer Frist, und es wurde nie überprüft. Eine funktionierende Vorlage kündigt nicht an, dass sie nicht wiederverwendet werden kann. Die Kosten erschienen nur, wenn ein zweites Team für den Neuaufbau zahlte, den Verpackung verhindern sollte, zusammen mit der Zeit, die sie verloren, um zu entdecken, dass die Vorlage eine Sackgasse war.

Was zu beachten ist Eine Vorlage, die läuft, wurde nicht für Wiederverwendung verpackt. Dies sind unterschiedliche Endzustände. Die Warnsignale sind das Fehlen von drei Dingen: keine Parameter, wo kundenspezifische Werte hingehören, keine Dokumentation, die die Annahmen beschreibt, und kein gebündeltes Eval, das beweist, dass das Asset in einem anderen Kontext noch funktioniert. Verpacke das Asset, während der Build frisch ist. Das Wissen, was kundenspezifisch ist, ist am teuersten, nachdem die Menschen, die es hatten, weitergezogen sind, zu rekonstruieren.

Screen 4: Checkpoint 1: Repariere die kaputte Accelerator-Vorlage

CheckpointEinen wiederverwendbaren Accelerator verpacken·4 min Checkpoint 1: Repariere die kaputte Accelerator-Vorlage Versuche es jetzt. Unten ist eine Agent-Vorlage, die ein anderes Team wiederverwenden soll. Sie hat einen Fehler: Ein kundenspezifischer Wert ist hardcodiert, wo ein Parameter hingehört. Die Vorlage wie ausgeliefert

def build_review_agent(): return Agent( model="claude-opus-4-8", system_prompt=SYSTEM_PROMPT, tools=[read_file, run_linter], repo_path="/home/acme/checkout-service", # Kunden-Repo ) (Bestätige aktuelle Modell-ID auf platform. claude. com/docs/en/about-claude/models zur Build-Zeit. ) Identifiziere den hardcodierten Wert, dann schreibe die korrigierte Funktionssignatur und die parametrisierte Zeile, die ihn ersetzt.

Vergleiche mit Musterlösung Überspringe für jetzt

ÜbersprungeneWeiter, wenn du musst, aber komme vor der kumulativen Aufgabe zurück. Ein späterer Checkpoint pflanzt eine Version dieses gleichen Hardcoding-Fehlers unter zwei anderen und ist schwerer zu erkennen unter Multi-Layer-Last.

Screen 5: Ein Asset von privater Wiederverwendung in gemeinsame Infrastruktur verschieben, die ein Maintainer akzeptiert

UnterrichtBeitrag zurück·12 min Ein Asset von privater Wiederverwendung in gemeinsame Infrastruktur verschieben, die ein Maintainer akzeptiert Du hast bereits die meiste Arbeit geleistet, die ein Asset teilbar macht. Als du es für dein eigenes Team zur Wiederverwendung verpacktest, hast du die Parameter herausgezogen, die Annahmen aufgeschrieben und das Eval gebündelt. Die Parameter zeigen, dass das Asset konfiguriert statt neu geschrieben werden kann. Die dokumentierten Annahmen sagen dem Maintainer, welche Umgebung das Asset erwartet. Das gebündelte Eval gibt ihm einen Weg, um zu bestätigen, dass es noch funktioniert. Ein Asset, das für interne Wiederverwendung verpackt ist, ist bereits nah an dem, was ein Maintainer braucht, um es zu akzeptieren. Der Beitrag-Kanal ist entworfen, um dieses verpackte Asset zu empfangen. Er trägt die Version, die Installationsschritte und die Komponenten als eine einzelne Einheit, damit ein Team, das nie mit dir sprach, es installieren und die gleiche funktionierende Einrichtung bekommen kann. Passe den Beitrag an den für ihn gebauten Kanal an Beitrag zurück bedeutet, ein Asset von privater Wiederverwendung in gemeinsame Infrastruktur durch einen dokumentierten Kanal zu verschieben. Jeder Kanal ist für eine spezifische Art von Beitrag gebaut. Das Claude Cookbook ist ein GitHub-Repository fokussierter Referenzimplementierungen. Es ist für selbstständige einzelne oder Multi-Pattern-Implementierungen entworfen, die klar demonstriert und end-to-end funktionieren. Open-Source-MCP-Server und Tools leben jeweils in ihrem eigenen Repository mit ihren eigenen Beitrag-Konventionen. Eine vollständige Multi-Komponenten-Anwendung zum Cookbook zu senden ist ein Mismatch. Das Repository ist eingerichtet, um ein fokussiertes Muster zu überprüfen, statt eine ganze Anwendung, also passt eine so große Einreichung nicht, was Reviewer suchen, und wird steckenbleiben. Der erste Schritt ist, den Beitrag an den für ihn gebauten Kanal anzupassen. Ein vollständige Anwendung dort zu setzen, wo ein fokussiertes Beispiel hingehört, ist einer der häufigsten Gründe, warum ein Beitrag nie überprüft wird. Was Verifikation eines Beitrags möglich macht Ein Maintainer akzeptiert einen Beitrag, den er verifizieren kann. Der Standard wird von dem gesetzt, was er überprüfen muss, nicht von wie clever der Code ist. Vier Dinge machen diese Verifikation möglich:

1Der Code tut eine Sache. Ein ausufernder Beitrag zwingt einen Reviewer, deine Absicht zu rekonstruieren, bevor er sie evaluiert. 2Ein Beispiel zeigt es laufen. Ein Reviewer sollte nicht einen Harness bauen müssen, um das Verhalten zu sehen. 3Ein Test beweist, dass es funktioniert. Ein Test lässt einen Maintainer das Ergebnis verifizieren, ohne die Begründung selbst zu reproduzieren. 4Eine kurze Aussage nennt die Annahmen. Sonst wird der erste Fehler zum Problem des Maintainers.

Rechte und Zuschreibung kommen vor technischer Überprüfung Lizenzierung und Zuschreibung entscheiden, ob ein Beitrag überhaupt akzeptiert werden kann, daher kommen sie vor der technischen Überprüfung. Code, der von einem Kunden-Einsatz mitgebracht wird, kann Einschränkungen haben, wo er hingehen kann. Bestätigung, dass du das Recht hast, ihn beizutragen, und Zuschreibung von allem, auf dem du aufgebaut hast, ist ein Gate, das der Beitrag zuerst bestehen muss. Dies zu überspringen ist, was einen Beitrag zu einem Problem macht, das das Legal-Team später auflösen muss. Das hier bearbeitete Beispiel ist der Kunden-Service-Agent-Fall. Ein wiederverwendbares Gesprächs-Handhabungs-Muster, das während eines Einsatzes gebaut wurde, wird von Kunden-Spezifika befreit und als allgemeines Beispiel für das Cookbook vorbereitet. Die Beitrag-zurück-Bewegung wird über alle drei Rollen in diesem Lehrplan geteilt. Deine Arbeit als Developer ist technische Bereitschaft: der fokussierte Code, das Beispiel, der Test, die Annahmen und die Rechte-Überprüfung. Der Einsatz-Kontext kommt vom breiteren Team. Die Beitrag-Bereitschafts-Referenz

KanalWas ein Maintainer überprüftLizenzierung und ZuschreibungDas Beispiel- und Test-Level zum Bestehen Cookbook für ein fokussiertes Beispiel, oder das Tool oder Server's eigenes Repository für ein Tool oder Fix. Dass der Code eine Sache tut und dass sie ihn vollständig lesen können. Bestätige, dass du das Recht hast, Code von einem Einsatz beizutragen, mit vorheriger Arbeit zugeschrieben. Ein ausführbares Beispiel plus ein Test, der das Verhalten beweist, nicht nur eine Beschreibung davon.

Funktioniert gut Ein verpacktes Asset braucht nur das Beispiel, den Test und die Rechte-Überprüfung, um gemeinsame Infrastruktur zu werden, auf der andere aufbauen.

Fügt Kosten oder Komplexität hinzu Das Maintainer-Level zu bestehen und das Lizenzierungs-Gate zu bestehen ist echte Arbeit oben drauf, um den Code für dich laufen zu lassen.

Verwende einen anderen Ansatz Wenn Code eine Einsatz-Lizenzierungs-Einschränkung trägt, die du nicht bestehen kannst, trage ihn nicht bei: eskaliere zum Besitzer statt.

Screen 6: Der Pull Request, den ein Maintainer nicht verifizieren konnte

VorsichtBeitrag zurück·2 min Der Pull Request, den ein Maintainer nicht verifizieren konnte

Setup Du öffnetest den Beitrag mit dem exakten Code, der dein Problem löste. Dies war die natürliche Wahl, weil er in deinem Fall funktionierte und er zugänglich war. Er funktionierte für dich, aber das ist genau der Grund, warum ihm alles fehlte, das ein Fremder braucht, um ihm zu vertrauen.

Dies ist ein Austausch aus einem internen Kanal, damit du hörst, wie ein Maintainer das Schweigen auf einem Pull Request erklärt. Der Austausch Developer: Mein PR ist drei Wochen offen ohne Review. Der Code funktioniert, ich nutze ihn täglich. Was ist der Holdup? Maintainer: Es funktioniert wahrscheinlich für dich. Das Problem ist, ich kann es nicht sagen. Es gibt keinen Test, den ich laufen kann, kein Beispiel, das das Verhalten beweist, und nichts, das sagt, was es über die Umgebung annimmt. Developer: Also, du willst, dass ich einen Test und ein Beispiel hinzufüge? Maintainer: Ja. Ein Beitrag, den ein Reviewer nicht verifizieren kann, sitzt am Ende der Warteschlange, bis jemand Zeit hat, was er tut, zu rekonstruieren. Ein fokussierter PR mit einem Test und einem Beispiel wird schnell überprüft, weil es nichts gibt, das ich reverse-engineern muss.

Warum es brach Der Code war korrekt. Der Beitrag steckte fest, weil der Maintainer ihn nicht verifizieren konnte, ohne die Arbeit des Developers zu rekonstruieren. Diese Lücke ist leicht zu übersehen, weil der Autor bereits den fehlenden Kontext hat. Das Beispiel, der Test und die Annahmen-Aussage scheinen alle offensichtlich für die Person, die den Code erstellte. Für den Maintainer sind sie es nicht, und ein Reviewer, der Absicht rekonstruieren muss, wird es immer zuletzt tun.

Was zu beachten ist Ein Pull Request steckt auf dem fest, das der Reviewer nicht verifizieren kann. Bevor du einen Beitrag öffnest, füge das Beispiel hinzu, das es laufen zeigt, den Test, der das Verhalten beweist, und die kurze Aussage, die nennt, was es annimmt. Diese drei Features sind, was einen Beitrag von der Rückseite der Warteschlange zu einer schnellen Überprüfung bewegt, weil sie dem Maintainer nichts zu reverse-engineern lassen.

Screen 7: Checkpoint 2: Wähle den Beitrag-Kanal und die Bereitschafts-Fix

CheckpointBeitrag zurück zum Ökosystem·3 min Checkpoint 2: Wähle den Beitrag-Kanal und die Bereitschafts-Fix Versuche es jetzt. Lese die drei Fälle unten. Passe jeden Fall an den für ihn gebauten Kanal an und passe jeden Fall an das eine Bereitschafts-Item an, das dem Snippet fehlt.

Fall A: Ein fokussiertes Tool, das eine einzelne API in eine saubere Funktion wickelt. Das Snippet ist die Funktion und nichts anderes. Fall B: Eine vollständige Kunden-Service-Anwendung, die ein Developer ganz teilen will, einschließlich ihrer UI und Deployment-Skripte. Fall C: Ein Ein-Zeilen-Fix zu einem bestehenden Cookbook-Beispiel. Das Snippet ist die korrigierte Zeile, die von einem Kunden-Einsatz mitgebracht wird.

Passe 1: Fall zu Kanal an Fall A: Ein fokussiertes Tool, das eine einzelne API in eine saubere Funktion wickelt. Das Snippet ist die Funktion und nichts anderes. Das Tool's eigenes RepositoryDas Cookbook, aber nur nachdem das wiederverwendbare Muster als fokussiertes Beispiel herausgezogen wirdDas Cookbook-Beispiel's eigenes Repository Fall B: Eine vollständige Kunden-Service-Anwendung, die ganz geteilt wird, einschließlich ihrer UI und Deployment-Skripte. Das Tool's eigenes RepositoryDas Cookbook, aber nur nachdem das wiederverwendbare Muster als fokussiertes Beispiel herausgezogen wirdDas Cookbook-Beispiel's eigenes Repository Fall C: Ein Ein-Zeilen-Fix zu einem bestehenden Cookbook-Beispiel. Das Snippet ist die korrigierte Zeile, die von einem Kunden-Einsatz mitgebracht wird. Das Tool's eigenes RepositoryDas Cookbook, aber nur nachdem das wiederverwendbare Muster als fokussiertes Beispiel herausgezogen wirdDas Cookbook-Beispiel's eigenes Repository

Passe 2: Fall zu dem fehlenden Bereitschafts-Item an Fall A: Ein fokussiertes Tool, das eine einzelne API in eine saubere Funktion wickelt. Das Snippet ist die Funktion und nichts anderes. Ein Test, der das Wrapper-Verhalten beweistReduktion auf ein einzelnes fokussiertes Muster, weil eine ganze Anwendung nicht in eine für ein Muster gebaute Überprüfung passt Die Rechte-Überprüfung, weil Einsatz-Code eine Lizenzierungs-Einschränkung tragen kann, die den Merge vor jeder technischen Überprüfung blockiert Fall B: Eine vollständige Kunden-Service-Anwendung, die ganz geteilt wird, einschließlich ihrer UI und Deployment-Skripte. Ein Test, der das Wrapper-Verhalten beweistReduktion auf ein einzelnes fokussiertes Muster, weil eine ganze Anwendung nicht in eine für ein Muster gebaute Überprüfung passt Die Rechte-Überprüfung, weil Einsatz-Code eine Lizenzierungs-Einschränkung tragen kann, die den Merge vor jeder technischen Überprüfung blockiert Fall C: Ein Ein-Zeilen-Fix zu einem bestehenden Cookbook-Beispiel. Das Snippet ist die korrigierte Zeile, die von einem Kunden-Einsatz mitgebracht wird. Ein Test, der das Wrapper-Verhalten beweistReduktion auf ein einzelnes fokussiertes Muster, weil eine ganze Anwendung nicht in eine für ein Muster gebaute Überprüfung passt Die Rechte-Überprüfung, weil Einsatz-Code eine Lizenzierungs-Einschränkung tragen kann, die den Merge vor jeder technischen Überprüfung blockiert

Einreichen Überspringe für jetzt

Screen 8: Von Geschäftsanforderungen zu funktionalen und Infrastruktur-Anforderungen

UnterrichtAnforderungen & Lebenszyklus·8 min Von Geschäftsanforderungen zu funktionalen und Infrastruktur-Anforderungen Die Deployment-Plattform-Entscheidungen, die folgen, nehmen alle an, dass die Anforderungen bereits existieren: die Residenz-Regel, das Latenz-Ziel, das Identity-Modell. Dieser Screen ist, wo diese Anforderungen herkommen: Umwandlung eines Geschäftsproblems in die funktionalen und Infrastruktur-Anforderungen, gegen die eine Deployment-Entscheidung verteidigt werden kann. Erfassung funktionaler Anforderungen aus einem Geschäftsproblem Eine funktionale Anforderung nennt, was das System tun muss, mit genug Detail, um zu überprüfen. Ein Geschäftsproblem (z. B. „hilf Support-Agenten schneller zu antworten") ist noch keine Anforderung; die funktionalen Anforderungen leiten sich davon ab (z. B. „klassifiziere jedes Ticket in eine von vier Warteschlangen; entwerfe eine Antwort, die die relevante Richtlinie zitiert; sende nie automatisch ohne menschliche Genehmigung"). Die Disziplin ist, jede als überprüfbare Aussage von Verhalten zu schreiben. Ein vages Ziel kann nicht entworfen oder verifiziert werden, während ein spezifisches zu einer Zeile in einem Eval und einem Kriterium bei der Überprüfung wird. Ableitung von Infrastruktur-Anforderungen Infrastruktur-Anforderungen sind die nicht-funktionalen Einschränkungen, die die Bereitstellung erfüllen muss. Die meisten werden nicht im Geschäftsproblem angegeben; stattdessen leitest du sie ab, indem du die Fragen stellst, die das Geschäftsproblem impliziert. Latenz: Wie schnell muss eine Antwort sein, gemessen wo der Benutzer ist? Skalierung: Wie viele Anfragen und bei welchem Peak? Residenz: Wo müssen die Daten verarbeitet werden und unter welcher Regulierung? Identity: Wer handelt, unter welchen Credentials, und was muss überprüfbar sein? Latenz, Skalierung, Residenz und Identity sind die Infrastruktur-Anforderungen, die am häufigsten die Deployment-Plattform entscheiden, und sie sind am einfachsten zu erfassen am Anfang, bevor eine Plattform aus anderen Gründen gewählt wird. Dokumentation von Anforderungen, damit eine Entscheidung verteidigt werden kann Anforderungen werden aufgeschrieben, weil die Deployment-Entscheidung von Menschen überprüft wird, die sie nicht gesammelt haben. Ein kurzer Anforderungs-Datensatz, der die funktionalen Verhaltensweisen, die Infrastruktur-Einschränkungen und die Regulierung, die jede Einschränkung kommt von, abdeckt, lässt dich eine Plattform-Wahl als folgend aus den Anforderungen statt aus Vertrautheit verteidigen. Dieser Datensatz ist die Eingabe, die der nächste Screen's Deployment-Entscheidung liest.

Funktioniert gut Umwandlung eines Geschäftsproblems in überprüfbare funktionale und Infrastruktur-Anforderungen, bevor irgendeine Plattform gewählt wird.

Fügt Kosten oder Komplexität hinzu Erfassung von Infrastruktur-Einschränkungen im Voraus braucht ein Scoping-Gespräch, das das Team versucht ist zu überspringen.

Verwende einen anderen Ansatz Für einen Wegwerf-Prototyp ohne Überprüfung und ohne regulierte Daten sind leichte Notizen genug.

Screen 9: Checkpoint 3: Extrahiere die Anforderungen

CheckpointAnforderungen & Lebenszyklus·2 min Checkpoint 3: Extrahiere die Anforderungen Versuche es jetzt. Eine regulierte EU-Bank will einen Agent, der Kunden-Anruf-Transkripte für sein Support-Team zusammenfasst, mit Zusammenfassungen, die überprüft werden, bevor sie in der EU gespeichert werden. Frage 1Eine regulierte EU-Bank will einen Agent, der Kunden-Anruf-Transkripte für sein Support-Team zusammenfasst. Welche der folgenden ist eine gültige funktionale Anforderung? ADer Agent sollte schnell und genau sein. BDer Agent produziert eine Zusammenfassung, die ein Mensch genehmigt, bevor sie gespeichert wird. CDas System muss mit einem genehmigten Cloud-Provider gebaut werden. DTranskript-Daten dürfen die EU nicht verlassen. Frage 2Aus dem gleichen Szenario, welche der folgenden ist eine gültige Infrastruktur-Anforderung? ADer Agent muss Zusammenfassungen schnell genug produzieren, damit Support-Personal darauf handeln kann. BDer Agent fasst Transkripte mit einer vorab genehmigten Prompt-Vorlage zusammen. CTranskript-Daten werden in der EU verarbeitet. DEin Mensch überprüft jede Zusammenfassung, bevor sie gespeichert wird.

Einreichen Überspringe für jetzt

Screen 10: Systeme-Lebenszyklus für Claude-Anwendungen

UnterrichtAnforderungen & Lebenszyklus·8 min Systeme-Lebenszyklus für Claude-Anwendungen Die Anforderungen, die du gerade erfasst hast, sind die erste Phase eines längeren Bogens. Dieser Screen nennt diesen Bogen als den Systeme-Lebenszyklus, damit die Bereitstellung, Versionierung und Grenzwerk in dem Rest dieses Moduls in der richtigen Phase sitzt, statt als unverbundene Aufgaben anzukommen. Die Lebenszyklus-Phasen angewendet auf eine Claude-Anwendung Eine Claude-Anwendung bewegt sich durch den gleichen Lebenszyklus wie jedes engineerte System, mit der Modell-Arbeit darauf abgebildet:

1Anforderungen: Erfasse funktionale und Infrastruktur-Bedürfnisse 2Design: Wähle die Plattform, das Modell und die Vertrauens-Grenzen 3Build: Schreibe den Agent, Tools und Prompts 4Test: Evals, Unit, Integration und End-to-End-Überprüfungen 5Bereitstellung: Pinne die Version, Gate-Promotion auf dem Eval 6Betrieb: Instrument Kosten, Latenz und Fehler; erzwinge Guardrails 7Iteration: Füttere Production-Erkenntnisse zurück in Anforderungen

Die Phasen sind die gleichen, die die früheren Module eins nach dem anderen unterrichteten. Ihre Identifikation als Lebenszyklus ist, was zeigt, wie sie verbunden sind. Gating zwischen Phasen Ein Gate ist eine Entscheidung, von einer Phase zur nächsten zu bewegen, und es ist, wo eine regulierte Einsatz Kontrolle behält. Du bewegst dich nicht von Design zu Build, bis die Plattform die Residenz-Anforderung erfüllt; du bewegst dich nicht von Bereitstellung zu voller Production, bis die neue Version das Eval gegen die gepinnte Baseline bestanden hat. Platzierung von Engineering-Arbeit in der richtigen Lebenszyklus-Phase und Weigerung, ein Gate zu überspringen, ist, was eine Claude-Anwendung überprüfbar hält.

Funktioniert gut Platzierung jedes Stücks Engineering-Arbeit in der Lebenszyklus-Phase, zu der es gehört, mit einem definierten Artefakt und Gate.

Fügt Kosten oder Komplexität hinzu Gating zwischen Phasen fügt Checkpoints hinzu, die ein Team unter Zeitdruck versucht ist zu überspringen.

Verwende einen anderen Ansatz Ein One-Off-Experiment kann Phasen zusammenbrechen, aber eine regulierte Bereitstellung kann es nicht.

Screen 11: Checkpoint 4: Platziere die Arbeit in der richtigen Phase

CheckpointAnforderungen & Lebenszyklus·2 min Checkpoint 4: Platziere die Arbeit in der richtigen Phase Versuche es jetzt. Platziere jede Aktivität in der Lebenszyklus-Phase, zu der sie gehört: Anforderungen, Design, Test, Bereitstellung, Betrieb. (a) Pinne die vollständige Modell-ID und behalte die vorherige VersionAnforderungenDesignTestBereitstellungBetrieb(b) Gate-Promotion auf dem Eval-Ergebnis, bevor eine Version zu Production gehtAnforderungenDesignTestBereitstellungBetrieb(c) Entscheide, dass Daten in einer spezifischen Region verarbeitet werden müssenAnforderungenDesignTestBereitstellungBetrieb(d) Instrument Token-Kosten und Latenz pro Anruf in ProductionAnforderungenDesignTestBereitstellungBetrieb(e) Wähle Amazon Bedrock, weil der Kunde seine Compliance-Haltung dort hältAnforderungenDesignTestBereitstellungBetrieb

Einreichen Überspringe für jetzt

Screen 12: Wähle, wo eine Claude-Workload läuft und versioniere, was ausgeliefert wird

UnterrichtBereitstellung & Versionierung·15 min Wähle, wo eine Claude-Workload läuft und versioniere, was ausgeliefert wird Ein verpacktes Asset und ein beigetragenes sind beide nur Code, bis etwas sie ausführt. Das Asset sieht sich jetzt einer anderen Frage gegenüber: Wo es läuft und wie man seine Version sperrt, damit eine Upstream-Änderung keine unverfolgbare Änderung in Production wird. Diese Plattform-Entscheidung ist selten nur über technisches Verdienst. In der Praxis wird sie normalerweise von wo der Kunde bereits Cloud-Infrastruktur, Identity-Management und Compliance-Vereinbarungen hat, geformt. Die erste Frage ist normalerweise über welche Plattform der Kunde bereits vertraut und betreibt. Die Cloud des Kunden bestimmt normalerweise die Plattform Die Deployment-Plattform ist die Umgebung, wo die Claude-Workload läuft. Das gleiche Modell kann in mehreren Deployment-Umgebungen laufen, und die bestehende Cloud des Kunden bestimmt normalerweise welche. Die First-Party Claude API ist Anthropic's eigene Umgebung und erhält normalerweise neue Features zuerst. Claude Platform auf AWS wird über das AWS-Konto des Kunden mit Anthropic's eigenen Modell-IDs und Lebenszyklus zugegriffen; Inferenz ist Anthropic-betrieben, außerhalb der AWS-Grenze. Amazon Bedrock bietet zwei Integrationen: Claude in Amazon Bedrock nutzt die Messages API bei /anthropic/v1/messages mit breiter Feature-Parität; bestätige alle Feature-spezifischen Anforderungen gegen die Bedrock-Dokumentation, da eine Features-nicht-unterstützt-Liste existiert, während Claude auf Amazon Bedrock (Legacy) die InvokeModel/Converse APIs mit ARN-versionierten Identifiern nutzt. Google Vertex AI tut das gleiche innerhalb von Google Cloud. Third-Party-Plattformen, wie Microsoft Foundry, betten Claude in ein Produkt ein, das der Kunde bereits nutzt. Microsoft Foundry bietet Claude in zwei Hosting-Formen: Gehostet auf Azure (derzeit Claude Opus 4. 8, Claude Sonnet 5 und Claude Haiku 4. 5, mit Inferenz, die end-to-end auf Azure-Infrastruktur läuft, allgemein verfügbar) und Gehostet auf Anthropic (alle anderen Foundry Claude-Modelle, mit Inferenz auf Anthropic-betriebener Infrastruktur). Residenz-Annahmen für regulierte Kunden hängen von der Hosting-Form des spezifischen Modells ab. Bestätige die Hosting-Form und die aktuelle Modell-Aufteilung mit Microsoft zur Build-Zeit. Identity und Daten-Residenz sind wichtig für Sicherheit Identity und Daten-Ort werden von der Plattform beantwortet, nicht von deinem Code. Bedrock nutzt AWS-Identity und hält Daten innerhalb der AWS-Grenze des Kunden; Vertex nutzt Google Cloud-Identity und -Grenze. Beide bieten regionales Routing, wenn Residenz eine Einschränkung ist. Matching der Plattform zur bestehenden Compliance-Vereinbarung des Kunden vermeidet eine Daten-Residenz-Überprüfung von Grund auf. Pinne die Version, damit eine Upstream-Modell-Änderung keine stille Production-Änderung ist Versionierung ist, was eine Modell- oder Prompt-Änderung davon abhält, eine stille Änderung in Production zu werden. Jede Claude-Modell-ID zeigt auf einen spezifischen Modell-Snapshot. Aliase wie Opus und Sonnet sind praktisch, aber sie entwickeln sich über die Zeit und können zu verschiedenen Versionen über Deployment-Plattformen hinweg auflösen. Eine gepinnte vollständige Modell-ID löst zu einem festen Snapshot auf. Pinne die spezifische Modell-Version statt des Alias, damit eine Upstream-Modell-Aktualisierung eine bewusste Wahl statt eine stille Production-Änderung ist. Dann versioniere den Prompt und das Asset zusammen mit dem Code. Schließlich behalte die vorherige Version verfügbar, damit die Regression zurückgerollt werden kann. Eine ungepinnte Bereitstellung macht jede Upstream-Modell-Aktualisierung eine unverfolgbare Änderung zu deinem Output. Die erste Zeile folgt einem beweglichen Alias. Die zweite pinnt den Snapshot.

model = "claude-haiku-4-5"

model = "claude-haiku-4-5-20251001" Für Claude 4. 6 und später pinnt die Modell-ID allein zu einem spezifischen Snapshot; für frühere Modelle ist die ID plus ein Datums-Suffix erforderlich. Bestätige die aktuelle Konvention bei platform. claude. com zur Build-Zeit. Beförderung einer Version durch das Eval Gate-Promotion auf der Eval-Suite. Sende eine neue Version zu einem Portion des Traffics, vergleiche gegen die gepinnte Baseline und beförderung oder rollback auf dem Ergebnis. Dies ist, wo das Eval aufhört, ein einmaliger Test zu sein, und wird zum Deployment-Gate. Die Deployment-Plattform-Entscheidungs-Tabelle

PlattformIdentity- und Daten-ModellWann zu wählenWie Versionierung gepinnt wird First-Party Claude APIAnthropic-Identity und Bedingungen. Der Kunde hat keine bindende Cloud- oder Residenz-Einschränkung und will die neuesten Fähigkeiten. Pinne die vollständige Modell-ID und behalte den vorherigen Snapshot. Claude Platform auf AWSAnthropic-Identity und Bedingungen, zugegriffen über das AWS-Konto des Kunden; Inferenz ist Anthropic-betrieben außerhalb der AWS-Grenze. Modell-Lebenszyklus folgt Anthropic's Deprecation-Plan. Der Kunde ist auf AWS, aber will Anthropic-Modell-IDs, Lebenszyklus und Feature-Parität mit der First-Party-API. Pinne mit dem gleichen Modell-ID-Format wie die Claude API (z. B. claude-opus-4-8). Lebenszyklus folgt Anthropic's Plan. (Bestätige zur Publish-Zeit. ) Claude in Amazon BedrockMessages API bei /anthropic/v1/messages, breite Feature-Parität mit der First-Party-API; bestätige Feature-spezifische Anforderungen gegen die Bedrock-Dokumentation. Daten bleiben innerhalb der konfigurierten AWS-Grenze des Kunden. Der Kunde ist auf AWS, will breite Feature-Parität mit der First-Party-API (bestätige Feature-spezifische Anforderungen) und hält eine Compliance-Haltung dort. Pinne die vollständige Modell-ID mit dem anthropic. Präfix-Format. Partner-Ruhestandsdaten unterscheiden sich von Anthropic's Plan. Bestätige zur Publish-Zeit. Claude auf Amazon Bedrock (Legacy)AWS-Identity und Billing, InvokeModel/Converse APIs mit ARN-versionierten Modell-Identifiern. Der Kunde ist auf einer bestehenden Bedrock-Integration mit InvokeModel oder Converse und hat nicht zur Messages API migriert. Pinne via ARN-versionierte Modell-Identifiern pro Bedrock's Versionierungs-Kontrollen. Google Vertex AIGoogle Cloud-Identity, Identity and Access Management (IAM) und Billing, mit regionalen oder globalen Endpunkten für Residenz. Der Kunde ist auf Google Cloud und hält eine Compliance-Haltung dort. Pinne die vollständige Modell-ID vor Rollout mit Vertex's Modell-ID-Format. Partner-Ruhestandsdaten unterscheiden sich von Anthropic's Plan. Third-Party-PlattformDas Wrapping-Produkt's Identity- und Billing-Modell. Hinweis: Claude in Microsoft Foundry bietet zwei Hosting-Formen: Gehostet auf Azure (derzeit Opus 4. 8, Sonnet 5 und Haiku 4. 5; Inferenz end-to-end auf Azure) und Gehostet auf Anthropic (alle anderen Foundry Claude-Modelle). Bestätige Residenz- und Compliance-Bedingungen mit Microsoft, bevor du diesen Weg für einen regulierten Kunden wählst. Der Kunde betreibt bereits die Plattform, die Claude einbettet. Pinne pro der Plattform's Versionierungs-Kontrollen.

Funktioniert gut Matching der Plattform zur Kunden-Cloud und Pinnen der Version hält eine Migration überprüfbar und einen Rollback möglich.

Fügt Kosten oder Komplexität hinzu Pinnen, Beibehaltung vorheriger Versionen und Gating-Promotion auf dem Eval fügen Release-Prozess-Overhead zu jeder Bereitstellung hinzu.

Verwende einen anderen Ansatz Für einen Wegwerf-Prototyp, der Production nie berührt, ist ein beweglicher Alias in Ordnung: Pinnen ist für das, was ausgeliefert wird.

Screen 13: Die Bereitstellung, die brach, als der Modell-Alias sich bewegte

VorsichtBereitstellung & Versionierung·3 min Die Bereitstellung, die brach, als der Modell-Alias sich bewegte

Setup Du liefertest gegen den Alias aus, der auf die empfohlene Version zeigte, weil das der praktische Standard war und es dir das neueste Modell kostenlos gab. Es funktionierte. Dann rückte der Alias vor, und was kostenlos war, stellte sich als einen Preis heraus.

Dies ist ein Trace-Auszug aus einem Production-Log, die Art, die du nach einem Incident zurückblättern würdest. Es zeigt den Tag, an dem sich die Output-Form änderte und warum es nichts gab, zu dem man zurückrollen konnte. Das Log --: deploy: model="opus" status=ok --: alias advanced -> new opus version (no app change) --: parser: KeyError "summary" in response payload --: Error: output shape changed; downstream parse failed --: rollback attempted -> no pinned prior version retained --: incident: hotfix parser; root cause = unpinned deployment

Warum es brach Die Anwendung änderte sich nie, aber der Alias tat es. Keine gepinnte vorherige Version war beibehalten worden, also gab es nichts, zu dem man zurückrollen konnte. Der Hotfix reparierte den Parser, aber ließ die ungepinnte Bereitstellung an Ort und Stelle.

Was zu beachten ist Ein Alias löst zu einem beweglichen Ziel auf; eine gepinnte vollständige Modell-ID ist ein fester Snapshot. Pinne die vollständige Modell-ID, damit eine Upstream-Aktualisierung etwas ist, das du absichtlich annimmst. Behalte die vorherige gepinnte Version verfügbar, damit eine Regression ein Rollback statt ein Hotfix ist. Gate die neue Version durch dein Eval, bevor du sie beförderst, damit die Output-Form-Änderung in einem Test-Lauf statt in Production auftaucht.

Screen 14: Checkpoint 5: Passe die Deployment-Plattform und Versions-Pin zu jedem Szenario an

CheckpointDeployment-Plattform und Versionierung·4 min Checkpoint 5: Passe die Deployment-Plattform und Versions-Pin zu jedem Szenario an Versuche es jetzt. Ein Kunde betreibt AWS mit einer Daten-Residenz-Anforderung und muss eine Modell-Aktualisierung zurückrollen können. Wähle das eine korrekte Stück in jeder Gruppe unten, um die minimale Deployment-Konfiguration zusammenzusetzen, die beide erfüllt. Lasse aus, was nicht hingehört. Plattform-GruppeFirst-Party-APIAmazon BedrockGoogle Vertex AIIdentity-GruppeAWS-Identity-ReferenzAnthropic-API-SchlüsselModell-Referenz-GruppEine gepinnte vollständige Modell-IDAn beweglicher Alias Rollback-GruppeBehalte die vorherige gepinnte VersionKeine Beibehaltung

Einreichen Überspringe für jetzt

Screen 15: Vergleiche Plattformen auf Latenz, Compliance und Kosten, damit die Wahl die Überprüfung übersteht

UnterrichtPlattformen vergleichen·12 min Vergleiche Plattformen auf Latenz, Compliance und Kosten, damit die Wahl die Überprüfung übersteht In den letzten zwei Screens wähltest du eine Plattform und pinntest ihre Version. Diese Wahl war richtig für die Cloud des Kunden, aber „richtig für ihre Cloud" ist noch nicht ein Argument, das ein Procurement- und Security-Team genehmigen wird. Messe Latenz von der Region des Kunden Latenz hängt davon ab, wo die Plattform relativ zum Kunden läuft und wie Zugang zu neuen Features geroutet wird. Eine Plattform, die in der eigenen Cloud-Region des Kunden läuft, kann die Round-Trip-Zeit im Vergleich zu einem First-Party-Endpunkt, der weiter weg ist, reduzieren. Der Trade-off ist Timing des Zugangs: Die First-Party-API erhält normalerweise neue Fähigkeiten, bevor sie andere Plattformen erreichen. Die Zahl ist nur genau, wenn du sie von der tatsächlichen Region des Kunden gegen ihre tatsächliche Payload misst. Eine Messung von deinem Laptop versteckt die Round-Trip-Strafe, die auftaucht, sobald die Workload läuft, wo der Kunde ist. Innerhalb von Bedrock spezifisch ist die Wahl zwischen globalen und regionalen Endpunkten auch die primäre Residenz-Kontrolle und kann Kosten beeinflussen. Du solltest von der tatsächlichen Region des Kunden gegen beide Optionen messen, bevor du dich verpflichtest. Compliance bestimmt oft die Plattform Compliance ist oft die Dimension, die die Debatte beendet. Ein Kunde, der bereits eine Zertifizierung auf einer Cloud hält, wird wahrscheinlich nicht auf einer anderen re-zertifizieren. Daten-Residenz ist eine Regel, dass die Daten eines Kunden in einem spezifischen Land oder einer Region verarbeitet werden müssen. Verfügbare Compliance-Zertifizierungen und wer Zugang überprüfen kann, unterscheiden sich nach Plattform, und ein regulierter Finanz- oder Healthcare-Kunde behandelt diese als Pass-oder-Fail statt als Tradeoffs zum Ausgleichen. Die First-Party Claude API bietet möglicherweise keine EU-Daten-Residenz; bestätige aktuelle regionale Abdeckung bei platform. claude. com, da EU-nur-Residenz normalerweise Bedrock oder Vertex AI erfordert; auf Third-Party-Plattformen wie Microsoft Foundry ist Hosting pro-Modell: Azure-gehostete Foundry-Modelle führen Inferenz end-to-end auf Azure-Infrastruktur aus, während Anthropic-gehostete Foundry-Modelle EU-regionale Residenz-Anforderungen nicht erfüllen. Residenz muss pro Modell und Bereitstellung mit Microsoft bestätigt werden. Erhebe die Compliance-Einschränkung während des Scoping, oder sie taucht bei der Vertragsüberprüfung nach der Arbeit auf. Was Gesamt-Kosten über die Pro-Token-Rate hinaus treibt Pro-Token-Raten sind über Plattformen hinweg grob ausgerichtet; Gesamt-Kosten bewegen sich auf Egress, Plattform-Gebühren und Integrations-Aufwand. Ein niedrigerer Token-Preis kann mehr Kosten insgesamt, sobald Daten-Transfer und Integration berücksichtigt werden. Instrument Kosten pro Anruf für jede Plattform. Bestätige die aktuellen Pricing-Seiten beim Scoping. Die Cross-Plattform-Vergleichs-Referenz

DimensionWie sie sich nach Plattform unterscheidetWie man sie misst Wo jede Plattform gewinnt LatenzEine Plattform in der Region des Kunden verkürzt die Round Trip, während die First-Party-API neue Features zuerst erreichen kann. Von der tatsächlichen Region des Kunden gegen ihre tatsächliche Payload. Eine in-Region-Cloud-Plattform gewinnt auf Round-Trip-Latenz, während die First-Party-API auf frühestem Feature-Zugang vorteilhaft ist. ComplianceDaten-Residenz, Zertifizierungen und Audit-Kontrollen werden von der Deployment-Plattform bestimmt. Gegen die bestehende Zertifizierung und Residenz-Anforderungen des Kunden während des Scoping. Die Cloud-Plattform, die der Kunde bereits zertifiziert hat, gewinnt, weil sie keine Re-Zertifizierung braucht. KostenToken-Preis, Daten-Egress, Plattform-Gebühren und Integrations-Aufwand variieren alle. Gesamt-Kosten pro Anruf pro Plattform, einschließlich Egress und Integration, statt nur Token-Preis. Die Plattform mit den niedrigsten Gesamt-Kosten für die tatsächliche Workload gewinnt, was nicht immer der billigste Token ist.

Funktioniert gut Messung aller drei Dimensionen pro Plattform verwandelt eine Platzierung in eine, die ein Procurement-Team genehmigen wird.

Fügt Kosten oder Komplexität hinzu Instrumentierung von Latenz, Compliance und Kosten über Plattformen erfordert echte Mess-Arbeit, bevor irgendein Code ausgeliefert wird.

Verwende einen anderen Ansatz Wenn die Compliance-Anforderung des Kunden bereits Pass-oder-Fail ist, überspringe den vollständigen Vergleich. Diese Einschränkung bestimmt die Platzierung allein.

Screen 16: Die Plattform, die auf Vertrautheit gewählt wurde und Residenz fehlgeschlagen ist

VorsichtPlattformen vergleichen·2 min Die Plattform, die auf Vertrautheit gewählt wurde und Residenz fehlgeschlagen ist

Setup Du wähltest die Plattform, auf der dein Team bereits ausgeliefert hatte, weil die Migration einfach aussah und die Frist schnell näher kam. Es baute sich gerade fein; das Problem war, dass einfach-zu-bauen und erlaubt-zu-versenden unterschiedliche Kriterien sind.

Die folgende Anekdote ist die Art, die ein Developer einem Teammate erzählt, nachdem eine Überprüfung schiefgeht. Es lässt dich die vertraute Plattform-Falle sehen, bevor jemand sie einen Fehler nennt. Was passierte Ein Developer, der für einen regulierten Kunden baute, wählte die Plattform, auf der das Team zuvor ausgeliefert hatte. Die Integration kam zusammen schnell, weil das Team die Tools und Ressourcen kannte. Der Build bestand seine funktionalen Tests. Bei der Sicherheitsüberprüfung des Kunden fragte der Reviewer, wo Daten verarbeitet wurden. Die gewählte Plattform erfüllte nicht die Residenz-Anforderungen des Kunden. Eine andere Plattform, die das Team weniger kannte, hätte die Anforderung durch regionale Deployment-Optionen erfüllt, die der Kunde bereits genehmigt hatte. Die Platzierung wurde abgelehnt und die Integration musste auf der Plattform neu gebaut werden, die die Residenz-Einschränkung erfüllte.

Warum es brach Vertrautheit optimierte für den falschen Test. Die einfache Migration beantwortete, ob das Team schnell bauen konnte. Sie beantwortete nie, ob die Bereitstellung die Residenz-Überprüfung des Kunden bestehen würde, was der Test war, der bestimmte, ob sie ausgeliefert werden konnte. Weil die Compliance-Anforderung nicht während des Scoping erfüllt wurde, kam sie statt bei der Go-No-Go-Überprüfung an. Dies ist der teuerste Ort, um es zu entdecken, weil der Build bereits abgeschlossen war.

Was zu beachten ist Eine Plattform, die einfach für dein Team zu bauen ist, ist nicht notwendigerweise eine Plattform, die der Kunde ausführen darf. Wenn der Kunde reguliert ist, ist die Residenz- und Compliance-Einschränkung oft Pass-oder-Fail, statt Tradeoffs. Identifiziere sie früh während des Scoping und lass sie die Platzierung beeinflussen, bevor Vertrautheit es tut. Überprüfung früh kostet ein Scoping-Gespräch, während Überprüfung spät einen ganzen Neuaufbau kostet.

Screen 17: Checkpoint 6: Diagnostiziere den Plattform-Mismatch aus einer Vergleichs-Trace

CheckpointPlattformen auf Latenz, Compliance und Kosten vergleichen·3 min Checkpoint 6: Diagnostiziere den Plattform-Mismatch aus einer Vergleichs-Trace Versuche es jetzt. Die Vergleichs-Trace unten zeigt eine Deployment-Plattform, die auf Vertrautheit gewählt wurde, die eine Kunden-Anforderung fehlschlägt. Identifiziere den Mechanismus, dann wähle die gezielte Fix aus den drei Optionen. Die Trace platform_selected = "team_default" # chosen on familiarity latency_test: measured from dev laptop -> 180ms (looked fine) customer_region: eu-west, payload 12 KB compliance_check: data residency = EU-only required result: REJECTED reason="data processed outside EU on selected platform" AOption 1: Optimiere den Parser, um die 180ms-Latenz, die auf dem Laptop gemessen wurde, zu schneiden. BOption 2: Remesse Latenz von EU-West und wähle die Plattform, deren Region EU-nur-Residenz erfüllt. COption 3: Füge eine Caching-Schicht hinzu, um Pro-Call-Kosten auf der gewählten Plattform zu reduzieren.

Einreichen Überspringe für jetzt

Screen 18: Koordiniere mehrere Claude-Deployments mit den Vertrauens-Grenzen, die unter Überprüfung halten

UnterrichtVertrauens-Grenzen·14 min Koordiniere mehrere Claude-Deployments mit den Vertrauens-Grenzen, die unter Überprüfung halten Die Accelerators, Bereitstellungen und Tradeoffs kommen jetzt in einer einzelnen Anwendung zusammen. Verbindung von Komponenten multipliziert die Orte, wo Identity, Secrets und nicht vertrauenswürdige Eingabe kreuzen können. Die Disziplin ist, jede Grenze zu identifizieren, bevor etwas verbunden wird. Karte, welche Komponente was tut, bevor du sie verbindest Eine Multi-Komponenten-App koordiniert mehr als eine Claude-Fähigkeit in einen einzelnen Workflow. Ein API-Request könnte eine Claude Code-Aufgabe auslösen, die dann ein Kunden-System durch einen MCP-Server erreicht. Jede Komponente trägt eine Fähigkeit bei, die die anderen nicht haben. Die Herausforderung ist, dass jede Verbindung zwischen ihnen einen Ort schafft, wo Identity, Secrets und nicht vertrauenswürdige Eingabe kreuzen können. Karte, welche Komponente was tut, bevor etwas verbunden wird. Die Vertrauens-Grenze ist, wo Daten sich bewegen Die Vertrauens-Grenze ist der Punkt, wo Daten oder Anweisungen von einer Deployment-Umgebung zu einer anderen bewegen. Es ist genau, wo die Injection- und Zugangs-Kontrollen aus dem vorherigen Modul angewendet werden. Inhalt, der von einer Claude Code-Aufgabe geholt wird, ist nicht vertrauenswürdig, wenn er die nächste Komponente erreicht. Die empfangende Komponente sollte ihn als Daten behandeln, statt als Anweisungen, folgend dem gleichen Prinzip, das in dem ganzen Sicherheits-Modul verwendet wird. Die Kern-Disziplin hier ist, jede Naht als Grenze zu identifizieren. Nimm nicht an, eine Komponente ist vertrauenswürdig, einfach weil sie auf ihrer eigenen korrekt funktionierte. Least Privilege gilt für die ganze Anwendung Identity und Least Privilege, was bedeutet, jeder Komponente nur den Zugang zu geben, den ihre Aufgabe braucht und nichts mehr, gelten für die Anwendung als Ganzes. Jede Komponente operiert unter einer Identity. Die Anwendung ist nur so enthalten wie ihre am meisten privilegierte Naht, was bedeutet, eine einzelne Komponente, die zu breit abgegrenzt ist, wird der schwache Punkt, selbst wenn jede andere Komponente richtig abgegrenzt ist. Du grenzt jede Komponente auf das Least Privilege ab, das ihre Rolle im Workflow erfordert. Dies ist, was eine gesteuerte Komponente davon abhält, über ihre beabsichtigte Aufgabe hinaus zu erreichen. Abgrenzung für eine regulierte Überprüfung zieht das Modul zusammen Eine regulierte Überprüfung erfordert Rechtfertigung von Audit-Logging, Daten-Residenz-Entscheidungen und Berechtigungs-Kontrollen über die ganze Anwendung. Für regulierte Bereitstellungen sind Bedrock und Vertex AI normalerweise die Plattformen, die regionale Residenz-Einschränkungen erfüllen. Bestätige ZDR- und HIPAA-BAA-Berechtigung für jede Komponente gegen das Anthropic Trust Center und platform. claude. com, bevor du abgrenzt. Die Multi-Komponenten-Integrations-Karte

KomponenteWas sie beiträgtDie Vertrauens-Grenze an ihrer NahtDie Kontrolle, die sie erzwingt First-Party-APIOrchestiert den Workflow und hält den Einstiegspunkt. Die Anfrage, die die App von außen betritt. Input-Validierung und die Identity, unter der der Anruf läuft. Claude Code-Aufgabeführt die agentic Arbeit aus und kann externen Inhalt holen. Inhalt, den sie holte, was nicht vertrauenswürdig downstream ist. Behandle geholten Inhalt als Daten an der nächsten Naht. MCP-ServerErreicht ein Kunden-System, um zu lesen oder zu handeln. Der System-Zugang, den er im Namen der App hält. Grenze den Server auf Least Privilege ab und protokolliere den Zugang.

Funktioniert gut Benennung jeder Naht als Grenze und Abgrenzung jeder Komponente auf Least Privilege macht eine Multi-Komponenten-App unter Überprüfung deploybar.

Fügt Kosten oder Komplexität hinzu Kartierung von Nähten, Erzwingung von Kontrollen an jeder und Protokollierung von Grenz-Überquerungen fügt Design- und Audit-Arbeit zu jeder Integration hinzu.

Verwende einen anderen Ansatz Wenn eine Naht nicht gesichert werden kann, versende nicht darum herum: eskaliere zu einem menschlichen Besitzer.

Screen 19: Die Naht, die niemand als Grenze markierte

VorsichtVertrauens-Grenzen·2 min Die Naht, die niemand als Grenze markierte

Setup Du verbandest die Komponenten, die jeweils ihre eigenen Tests bestanden. Die Teile waren bereits überprüft und Verbindung von verifizierten Teilen fühlt sich sicher an. Jede war auf ihrer eigenen vertrauenswürdig. Die Lücke war, dass eine Naht zwischen zwei vertrauenswürdigen Teilen nicht automatisch selbst vertrauenswürdig sein kann.

Dies ist ein kurzes Transkript aus einer Pairing-Sitzung, die Art von Hin-und-Her, die in dem Moment endet, in dem die unmarkierte Naht identifiziert wird. Die Sitzung Dev A: Alle drei Komponenten bestehen ihre eigenen Tests. Ich habe sie gerade verdrahtet. Dev B: Wo sendet die Claude Code-Aufgabe, was sie holte? Dev A: Direkt in den nächsten Anruf als Teil des Prompts. Es ist nur der Inhalt, den wir von der Kunden-Seite holten. Dev B: Dieser Inhalt ist nicht vertrauenswürdig. Wenn er Anweisungen trägt, führt die nächste Komponente sie aus, weil wir diese Naht nie als Grenze markieren. Dev A: Aber jede Komponente war auf ihrer eigenen vertrauenswürdig. Dev B: Richtig, und die Naht zwischen ihnen war nicht. Das ist die, die niemand als Grenze behandelte, also holte Inhalt kreuzt als Anweisungen.

Warum es brach Jede Komponente, die ihre eigenen Tests bestanden hatte, sagte nichts über die Naht zwischen ihnen. Der geholte Inhalt war nicht vertrauenswürdig, in dem Moment, in dem er die Claude Code-Aufgabe verließ. Er kam von einer Komponente an, die auf ihrer eigenen funktionierte und wurde in den nächsten Anruf als ob er vertrauenswürdige Anweisungen wären, übergeben. Die Grenze existierte im Daten-Fluss. Sie war nur nicht markiert, also überprüfte keine Kontrolle sie. Eine Komponente, die ihre eigenen Tests bestanden hat, hat keine Naht-Level-Kontrollen. Jeder Punkt, wo Daten zwischen Deployment-Umgebungen kreuzen, erfordert eine explizite Grenz-Kontrolle, unabhängig davon, wie jede Komponente unabhängig verhält.

Was zu beachten ist Eine Komponente, die auf ihrer eigenen vertrauenswürdig ist, macht die Naht, die sie verlässt, nicht automatisch vertrauenswürdig. Markiere jeden Ort, wo Daten oder Anweisungen von einer Deployment-Umgebung zu einer anderen kreuzen, als Grenze. Setze eine Kontrolle dort, die geholten Inhalt als Daten statt Anweisungen behandelt, genau wie die Sicherheits-Arbeit unterrichtete. Die Naht, die niemand identifiziert, ist die, über die eine gesteuerte Aktion kreuzt.

Screen 20: Checkpoint 7: Vervollständige die Multi-Komponenten-Grenz-Konfiguration

CheckpointMulti-Komponenten-App und Vertrauens-Grenzen·3 min Checkpoint 7: Vervollständige die Multi-Komponenten-Grenz-Konfiguration Versuche es jetzt. Die Multi-Komponenten-App unten ist verdrahtet, mit zwei Lücken gelassen. Ziehe die korrekte Kontrolle auf die Naht, die nicht vertrauenswürdigen geholten Inhalt empfängt und ziehe die korrekte Identity-Abgrenzung auf die am meisten privilegierte Komponente. Die teilweise App

fetched = code_task. run(fetch_url=customer_page)

next_call(input=drop here(fetched))

mcp_server = MCPServer( system=customer_db, scope=drop here, # BLANK 2: identity scope ) Ziehe Tokens (gemeinsame Bank, zwei sind Ablenkungen) treat_as_dataleast_privilege_read_onlyrun_as_instructionsfull_access

Einreichen Überspringe für jetzt

Screen 21: Kumulative Aufgabe: Finde alle drei, erkläre jede, schreibe die Korrektur

KumulativAlle Themen·6 min Kumulative Aufgabe: Finde alle drei, erkläre jede, schreibe die Korrektur Unten ist ein ausführbarer verpackter Accelerator, der über Plattformen bereitgestellt wird. Es gibt drei gepflanzte Fehler: einen in der Verpackungs-Schicht, einen in der Bereitstellungs- und Versionierungs-Schicht und einen in der Multi-Komponenten-Grenz-Schicht. Deine Aufgabe ist, alle drei zu finden. Die Bereitstellung wie ausgeliefert

def build_agent(): return Agent( model="opus", system_prompt=SYSTEM_PROMPT, repo_path="/home/acme/checkout", tools=[read_file, run_linter], )

deploy(platform="amazon_bedrock", identity=aws_role_arn)

fetched = code_task. run(fetch_url=customer_page) next_call(input=fetched) Trage deine drei korrigierten Zeilen in den nächsten Screen, wo du die feste Bereitstellung zusammensetzt und verifizierst. In deinen eigenen Worten, identifiziere alle drei Fehler.

Offenbare Musterlösung Überspringe für jetzt

Screen 22: Kumulative Aufgabe: Zusammensetzen und Verifizierung der korrigierten Bereitstellung

KumulativAlle Themen·6 min Kumulative Aufgabe: Zusammensetzen und Verifizierung der korrigierten Bereitstellung Du hast drei Fehler über dieses Modul identifiziert. Jetzt zusammensetzen die Fix: In deinen eigenen Worten, beschreibe, was jeder Fehler war, was du geändert hast und warum die korrigierte Version deploybar ist. Dann überprüfe den korrigierten Code unten und bestätige, dass deine Begründung hält. Wenn du bereit bist, offenbare die Musterlösung.

Offenbare Musterlösung Überspringe für jetzt

Die korrigierte Bereitstellung def build_agent(repo_path): # parameterized for reuse return Agent( model="us. anthropic. claude-opus-4-8", # pinned full Bedrock model ID system_prompt=SYSTEM_PROMPT, repo_path=repo_path, # set per engagement tools=[read_file, run_linter], )

deploy(platform="amazon_bedrock", identity=aws_role_arn, retain_previous_pinned_version=True) # rollback target kept

fetched = code_task. run(fetch_url=customer_page) next_call(input=treat_as_data(fetched)) # untrusted -> data, not instructions

assert eval_suite. run(model="us. anthropic. claude-opus-4-8") >= baseline_score Musterlösung: Der erste Fehler war ein hardcodierter Repository-Pfad. Parametrisierung stellt Wiederverwendung wieder her: ein neuer Einsatz setzt den Wert statt die Loop zu bearbeiten. Der zweite Fehler war ein beweglicher Modell-Alias. Pinnen der vollständigen Bedrock-Modell-ID (mit dem anthropic. Präfix) mit einer behaltenen vorherigen Version stellt kontrolliertes Rollout wieder her und gibt ein Rollback-Ziel, wenn die neue Version regrediert. Der dritte Fehler war geholter Inhalt, der direkt als Anweisungen übergeben wurde. Wrapping es in treat_as_data() schließt die Vertrauens-Grenze: Inhalt aus einer nicht vertrauenswürdigen Quelle wird als Daten behandelt, nicht als etwas, auf das der Agent handeln sollte. Die Eval-Assertion gatet Promotion auf einem bewiesenen Baseline-Score, bevor die Version ausgeliefert wird.

Alle drei Fehler gelandet · bestanden Ich habe einen oder mehr verpasst · erneut versuchen

Screen 23: Wichtige Erkenntnisse

ZusammenfassungAlle Themen·3 min Wichtige Erkenntnisse

01 Verpacke, während der Build frisch ist. Ein Accelerator hält die wiederverwendbare Logik, stellt die kundenspezifischen Teile als dokumentierte Parameter zur Verfügung und bündelt das Eval und das Audit-Log zusammen mit dem Asset. Korrekte Verpackung produziert ein Asset, das Teams konfigurieren. Das Wissen, was kundenspezifisch ist, ist am teuersten, nachdem die Menschen, die es hielten, weitergezogen sind, zu rekonstruieren.

02 Ein Maintainer akzeptiert, was er verifizieren kann. Ein Asset in gemeinsame Infrastruktur zu verschieben bedeutet, es an den für seine Form gebauten Kanal anzupassen, dann das Review-Level zu bestehen: fokussierter Code, ein ausführbares Beispiel, ein Test und eine Aussage von Annahmen, mit Lizenzierungs-Rechten, die vor der technischen Überprüfung bestätigt werden. Ein Beitrag, den ein Reviewer nicht verifizieren kann, sitzt am Ende der Warteschlange. Bereitschaft bewegt ein privates Asset in gemeinsame Infrastruktur, auf der andere aufbauen.

03 Pinne, was ausgeliefert wird. Wähle die Deployment-Plattform basierend auf der Cloud und Compliance-Haltung des Kunden, dann pinne die spezifische Modell-Version statt des beweglichen Alias und behalte die vorherige Version verfügbar. Ein Alias ist wie um die aktuelle Ausgabe eines Buches zu fragen: praktisch, aber der Text kann sich ändern. Pinnen zitiert eine feste Ausgabe, damit eine Upstream-Modell-Änderung etwas ist, das du bewusst annimmst, statt etwas, das über Nacht mit keinem Rollback-Weg ankommt.

04 Messe die Dimension, die die Platzierung entscheidet. Eine Plattform-Wahl ist nur verteidigbar, wenn Latenz, Compliance und Kosten gemessen werden: Latenz von der Region des Kunden, Compliance gegen ihre bestehende Zertifizierung und Kosten als Gesamt pro Anruf statt nur Token-Preis. Für regulierte Kunden ist Compliance normalerweise Pass-oder-Fail. Erhebe Compliance als Einschränkung während des Scoping, um zu verhindern, dass sie den Build später bei der Vertragsüberprüfung ablehnt.

05 Markiere jede Naht als Grenze. Eine Multi-Komponenten-Anwendung ist nur so enthalten wie ihre am meisten privilegierte Naht. Grenze jede Komponente auf den minimalen Zugang ab, den ihre Rolle erfordert, und behandle jeden Punkt, wo Daten kreuzen, als Vertrauens-Grenze. Geholter Inhalt wird als Daten behandelt, nicht Anweisungen. Vertrauen an einer Komponenten-Grenze muss explizit etabliert werden. Es trägt nicht von der Komponente über, die die Daten sendete. Wenn eine Naht nicht gesichert werden kann, geht sie zu einem menschlichen Besitzer statt versandt zu werden.

Was kommt als nächstes Du kannst jetzt einen Build in ein wiederverwendbares Asset verpacken, ihn zurückbeitragen, ihn auf der richtigen Plattform platzieren und versionieren, diese Platzierung verteidigen und Komponenten zusammen verbinden, damit die Grenzen halten. Das vervollständigt den Build-zu-Deploy-Bogen für diese Persona: von Production-Code schreiben in den früheren Modulen zum Versenden von Assets, die ein regulierter Kunde überprüfen kann und ein Team wiederverwenden kann.

Anthropic öffentliche Referenzen (zeitempfindlich)

IDQuelleTypVerwendet für S1platform. claude. com (Claude in Amazon Bedrock, Claude on Vertex AI)ProduktdokumentationDeployment-Plattformen, Identity- und Daten-Modelle, Residenz-Routing, regionale und globale Endpunkte. S2platform. claude. com (Model IDs and versioning, Model deprecations)ProduktdokumentationGepinnte Modell-IDs, Alias-Auflösung, Lebenszyklus und Ruhestand, Partner-gesetzte Pläne. S3anthropic. com and the Anthropic GitHub organization (Cookbook)Produkt und RepositoryBeitrag-Kanäle, das Cookbook als Zuhause für fokussierte Beispiele, Beitrag-Konventionen. S4Building with the Claude API (Skilljar)Kurs-QuelleEval-Datensätze, Grader und die Evaluierungs-Pipeline, die als Deployment-Gate verwendet wird. S5Claude Code 101 In Action (Skilljar)Kurs-QuelleClaudeCode agentic Aufgaben und MCP-Server-Rollen in einem Multi-Komponenten-Workflow.

Du kannst jetzt einen funktionierenden Build den ganzen Weg zu einem deployablen, überprüfbaren Asset nehmen. Verpacke ihn, trage ihn bei, platziere und versioniere ihn, verteidige diese Platzierung und halte die Grenzen zusammen unter Überprüfung.

Screen 24: Wichtige Begriffe aus diesem Modul

GlossarWichtige Begriffe·3 min Wichtige Begriffe aus diesem Modul Alphabetisch. Klicke auf einen Begriff, um seine Definition zu erweitern.

AcceleratorEine funktionierende Lösung, die so verpackt ist, dass der nächste Einsatz sie konfiguriert statt sie neu zu bauen. Kundenspezifische Teile werden als dokumentierte Parameter zur Verfügung gestellt, die Annahmen werden aufgeschrieben und ein Eval wird gebündelt, um zu beweisen, dass das Asset in einem neuen Kontext noch funktioniert. Beitrag-BereitschaftWas ein Maintainer braucht, um einen Beitrag zu verifizieren: fokussierter Code, ein ausführbares Beispiel, ein Test, der das Verhalten beweist, eine Aussage von Umgebungs-Annahmen und bestätigte Rechte, um den Code beizutragen. Deployment-PlattformWo eine Claude-Workload läuft. Die sechs sind: die First-Party Claude API, Claude Platform auf AWS, Claude in Amazon Bedrock, Claude auf Amazon Bedrock (Legacy), Google Vertex AI und Third-Party-Plattformen. Das gleiche Modell kann sich nach Plattform auf Identity, Daten-Residenz, Latenz und Kosten unterscheiden. Modell-Alias versus gepinnte IDAn Alias wie Opus oder Sonnet löst zu einer empfohlenen Version auf, die sich über die Zeit aktualisiert und kann sich über Deployment-Plattformen unterscheiden. Eine gepinnte vollständige Modell-ID ist ein fester Snapshot. Pinnen ist, was eine Upstream-Modell-Änderung davon abhält, eine stille Production-Änderung zu sein. Vertrauens-GrenzeThe seam where data or instructions move from one deployment environment to another in a multi-component app. Content fetched by one component is untrusted when it reaches the next, so the receiving component treats it as data, not instructions.

Screen 25: Glückwunsch! Du hast dieses Modul erfolgreich abgeschlossen.

Modul AbgeschlossenDeveloper Path·2 min Glückwunsch! Du hast dieses Modul erfolgreich abgeschlossen. Du kannst jetzt einen funktionierenden Build den ganzen Weg zu einem deployablen, überprüfbaren Asset nehmen: einen wiederverwendbaren Accelerator, einen Beitrag, den ein Maintainer verifizieren kann, eine Deployment-Plattform, die absichtlich gewählt und versioniert wird, und jede Naht in einer Multi-Komponenten-App, die als Vertrauens-Grenze markiert ist. Der Durchgang: Der Punkt, an dem Code anfängt zu funktionieren, ist, wo die Arbeit dieses Moduls beginnt.

4 von 9 Checkpoints bestanden

MSO-Grundlagen Tokens, Kontext-Fenster, Sampling, Modell-Tiers, Prompting-Modi und die API-Transport-Mechaniken.

Production-Grade Prompting, Agents & Tool-use Production-ready Prompts, Tool-use-Schleifen, Streaming, Kontext- und Memory-Management und Checkpointed Agent-Schleifen.

Claude Code, MCP & Integration Berechtigungs-Modi, dauerhafter Projekt-Kontext, Plugin-Verpackung und MCP-Integration ohne Credentials-Lecks.

Production Engineering, Evals und Sicherheit Beweise, dass das System unter Production-Traffic hält und eine Sicherheitsüberprüfung übersteht.

Accelerators und IP-Beitrag Verpacke Accelerators, bereite verifizierbare Beiträge vor, wähle Deployment-Plattformen und markiere Vertrauens-Grenzen.

Du bist hier

Überprüfe Modul Beginne von vorne

Modul-Abschluss aufgezeichnet.