--- title: "Kontext-Engineering-Regeln für das Modell Claude 5" locale: de category: ai_data category_name: "KI-Daten" translation_status: reviewed license: cc_by author: "injoys" source_url: https://injoys.com/en/articles/claude-5-context-engineering-rules published_at: 2026-07-27T05:12:07+09:00 --- # Kontext-Engineering-Regeln für das Modell Claude 5 > Für Claude-Modelle mit verbessertem Urteilsvermögen sind ein klares Ziel, gut konzipierte Tools und auf die Aufgabe abgestimmte Referenzmaterialien wichtiger als zahlreiche Detailregeln. Dieser Artikel erläutert Prinzipien und Verfahren zur Kontextgestaltung, die redundante Anweisungen reduzieren und benötigte Informationen zum richtigen Zeitpunkt bereitstellen. ## Key Points - Kontext-Engineering umfasst nicht nur Prompts, sondern auch die gemeinsame Gestaltung von Systemanweisungen, Tools, Speicher, Dateien, Gesprächsverläufen und Ausführungsergebnissen. - Regeln zu Sicherheit, Recht, Berechtigungen und Datenintegrität sollten strikt beibehalten werden, während situationsabhängige Stilvorgaben besser in kontextbasierte Prinzipien umgewandelt werden. - Statt alle Informationen von Anfang an einzubeziehen, sollten sie bei Bedarf über Suche, das Lesen von Dateien, Skills und Unteragenten zugänglich gemacht werden. - Statt Beispiele für die Tool-Nutzung wiederholt aufzulisten, sollten Schnittstellen mit klaren Namen, Eingabeschemata, Statusdefinitionen und Fehlerstrukturen gestaltet werden. - CLAUDE.md, automatischer Speicher, Code, Tests und Spezifikationen sollten unterschiedliche Aufgaben übernehmen, und dieselben Anweisungen sollten nicht an mehreren Stellen dupliziert werden. Um Claude-Modelle mit verbessertem Urteilsvermögen effektiv einzusetzen, reicht es nicht aus, lediglich einen einzelnen Satz im Prompt zu optimieren. Systemanweisungen, Projektdateien, Tools, Speicher, Gesprächsverlauf und Ausführungsergebnisse, die das Modell in einem Schlussfolgerungsvorgang sieht, müssen als einheitliche Informationsumgebung gestaltet werden. Das Grundprinzip ist einfach. > Statt jedes Verhalten im Voraus festzulegen, sollten ein klares Ziel, Sicherheitsgrenzen, ausdrucksstarke Schnittstellen und verlässliche Referenzmaterialien bereitgestellt und Detailentscheidungen dem Modell überlassen werden. In diesem Artikel bezeichnet `Claude 5` die in den bereitgestellten Materialien beschriebene Umgebung für leistungsfähige Claude-Modelle der nächsten Generation. Der Schwerpunkt liegt nicht auf konkreten Produktspezifikationen oder dem Veröffentlichungsstatus, sondern auf Prinzipien der Kontextgestaltung, die sich auf Modelle mit verbessertem Urteilsvermögen anwenden lassen. ## Prompt Engineering und Context Engineering ### Prompt Engineering Prompt Engineering ist die Gestaltung der Formulierung einer aktuellen Anfrage. Üblicherweise umfasst es folgende Punkte: - Arbeitsziel - Umfang der Aufgabe - Einschränkungen - Ausgabeformat - Erfolgskriterien - erforderliche Beispiele Ein Beispiel: ```text Implementiere in einer Next.js API Route eine Funktion zum Stornieren von Zahlungen. Verwende die bestehende Service-Schicht wieder und füge Tests hinzu. Ändere den öffentlichen API-Vertrag nicht und erläutere die Gründe für die Änderungen. ``` ### Context Engineering Context Engineering ist die Auswahl und Pflege der gesamten Informationsmenge, die in die Schlussfolgerungen des Modells einfließt. Bei Coding-Agenten wie Claude Code setzt sich der Kontext ungefähr aus folgenden Elementen zusammen: ```text aktuelle Anfrage des Benutzers + Systemanweisungen + CLAUDE.md und Projektanweisungen + Skills + automatischer Speicher + Code, Spezifikationen, Tests und Dokumentation + Tooldefinitionen und MCP-Ressourcen + Gesprächsverlauf + Ergebnisse der Toolausführung und Fehlerprotokolle ``` Daher kann selbst ein guter Prompt an Wirkung verlieren, wenn er zusammen mit veraltetem Speicher, redundanten Projektregeln oder umfangreichen Protokollen bereitgestellt wird. Umgekehrt kann auch eine kurze Anfrage hinreichend präzise ausgeführt werden, wenn der relevante Code, Tests und klar definierte Tools verfügbar sind. | Kategorie | Prompt Engineering | Context Engineering | |---|---|---| | Gestaltungsgegenstand | Formulierung der aktuellen Anfrage | Gesamte Informationsumgebung für die Schlussfolgerung | | Zentrale Frage | Was soll wie angefordert werden? | Was soll das Modell wann sehen? | | Typische Elemente | Ziel, Format, Einschränkungen, Beispiele | Systemanweisungen, Dateien, Tools, Speicher, Verlauf | | Typische Fehler | Mehrdeutige Anfrage, unklare Erfolgskriterien | Konflikte, Redundanzen, veraltete Informationen, übermäßige Protokolle | | Verbesserungsmethode | Anfrage konkretisieren und Prüfkriterien angeben | Informationen mit hohem Signalwert auswählen, bedarfsgerecht abrufen, Lebenszyklus verwalten | ## Warum mehr Kontext nicht immer besser ist Auch wenn das Kontextfenster eines LLM größer wird, ist die für eine Aufgabe verfügbare Aufmerksamkeit nicht unbegrenzt. Wenn die Zahl wenig relevanter Tokens steigt, können folgende Probleme entstehen: 1. Wichtige Anforderungen gehen in weitschweifigen Erläuterungen unter. 2. Ähnliche Anweisungen an verschiedenen Stellen widersprechen sich auf subtile Weise. 3. Veraltete Entscheidungen oder gescheiterte Versuche beeinflussen die aktuelle Aufgabe. 4. Beispiele wirken wie vorgegebene Lösungen und schränken andere Lösungswege ein. 5. Protokolle und Toolausgaben belegen den Platz, der für Code, Spezifikationen und Tests benötigt wird. 6. Das Modell verbraucht Schlussfolgerungskapazität darauf, die Priorität der Anweisungen zu interpretieren, statt die eigentliche Aufgabe zu bearbeiten. Anthropic beschreibt, dass die Effizienz der Informationsnutzung bei langem Kontext abnimmt, und empfiehlt, Agenten so zu gestalten, dass sie benötigte Informationen zum richtigen Zeitpunkt abrufen und veraltete Aufzeichnungen komprimieren. Entscheidend ist nicht, die maximale Tokenzahl auszuschöpfen, sondern den Anteil der Tokens mit hohem Signalwert zu erhöhen, die das Ergebnis beeinflussen. ## Was der Fall einer Verkleinerung des System-Prompts bedeutet Im bereitgestellten Fall von Anthropic wird erläutert, dass der System-Prompt nach einer Überprüfung der internen Anweisungen von Claude Code um mindestens 80 % verkleinert wurde. Diese Zahl ist keine Regel, nach der die Prompts aller Anwendungen im gleichen Verhältnis gekürzt werden müssen. Sie ist als Beispiel dafür zu verstehen, dass redundante und übermäßig detaillierte Verhaltensanweisungen in einem bestimmten System bereinigt wurden. Beispielsweise können folgende Anweisungen gleichzeitig in einer Anfrage enthalten sein: ```text Systemanweisung: Hinterlasse der Situation angemessene Dokumentation. Skill-Anweisung: Füge keine Kommentare hinzu. Benutzeranfrage: Sorge dafür, dass es wie die bisherige Version funktioniert. ``` Jeder Satz kann für sich genommen sinnvoll sein, doch zusammen führen sie zu mehreren Interpretationsproblemen. - Gehören Dokumentation und Codekommentare zur gleichen Kategorie? - Ist das Verbot von Kommentaren eine ausnahmslose Regel? - Umfasst das Verhalten der bisherigen Version auch deren Kommentar- oder Dokumentationsstruktur? - Was hat Vorrang: die aktuelle Anfrage oder der wiederverwendbare Skill? In diesem Fall liegt die Fehlerursache nicht nur in den Programmierfähigkeiten des Modells. Ein weiterer Grund ist, dass die von Menschen zusammengestellte Informationsumgebung unnötige Widersprüche enthält. ## Sechs neue Regeln für die Kontextgestaltung | Bisheriger Ansatz | Empfohlener Ansatz | |---|---| | Detailliertes Verhalten durch Verbotslisten festlegen | Ziel und Beurteilungskriterien angeben und den Kontext nutzen | | Zahlreiche Beispiele für Toolaufrufe bereitstellen | Das Schema selbst so gestalten, dass es die Verwendung erklärt | | Alle Informationen zu Beginn der Aufgabe einspeisen | Informationen bei Bedarf schrittweise offenlegen | | Dieselbe Anweisung an mehreren Stellen wiederholen | Für jede Anweisung einen maßgeblichen Speicherort festlegen | | Selbst temporäre Erinnerungen in CLAUDE.md speichern | Rollen dauerhafter Richtlinien und automatischen Speichers trennen | | Sich auf lange Markdown-Erklärungen verlassen | Ausführbare Materialien wie Code, Tests, HTML und Bewertungsraster bereitstellen | ### 1. Detaillierte Verbotslisten durch kontextbasierte Prinzipien ersetzen Um wiederkehrende Fehler früherer Modelle zu verhindern, wurden bisweilen lange Listen mit Regeln wie den folgenden erstellt: - Keine Kommentare schreiben. - Keine mehrteiligen Docstrings erstellen. - Keine nicht angeforderten Planungsdokumente erzeugen. - Keine Dateien mit Zwischenanalysen speichern. Solche Regeln verhindern bestimmte Fehler, sind aber keine absoluten Prinzipien, die für jede Situation gelten. Komplexe Sicherheitsprüfungen oder nebenläufiger Code können Erläuterungen erfordern, während Kommentare bei selbsterklärendem CRUD-Code eher Störungen verursachen können. Besser ist es, Beurteilungskriterien wie die folgenden anzugeben: ```text Schreibe Code, der sich auf dieselbe Weise wie der umgebende Code lesen lässt. Halte dich an die Namenskonventionen, Idiome und Kommentardichte der bestehenden Dateien. Füge nur dort erforderliche Dokumentation hinzu, wo Sicherheit oder Absicht ohne Erklärung unklar wären. ``` Allerdings dürfen nicht alle Regeln abgeschwächt werden. Folgende Punkte sollten als explizite Einschränkungen oder Kontrollen auf Tool-Ebene beibehalten werden: - Genehmigung von Bereitstellungen in Produktionsumgebungen und Datenlöschungen - Beschränkungen bei der Verarbeitung personenbezogener und vertraulicher Daten - Prüfung von Authentifizierung und Autorisierung - Idempotenz und Auditprotokolle bei finanziellen Transaktionen - Richtlinien für Datenbankmigrationen - Einhaltung von Gesetzen, Lizenzen und Vorschriften - unveränderliche öffentliche API-Verträge | Regeltyp | Angemessene Behandlung | |---|---| | Sicherheit, Recht, Berechtigungen | Explizite und strikte Einschränkungen beibehalten | | Vorgänge mit möglichem Datenverlust | Durch Genehmigungsverfahren und Toolberechtigungen kontrollieren | | Öffentliche Verträge und Kompatibilität | Durch Tests und Schemata prüfen | | Codestil und Kommentare | Beurteilungsprinzipien anhand des umgebenden Codes verwenden | | Temporäre Arbeitsreihenfolge | Im aktuellen Plan oder in der Aufgabenliste verwalten | ### 2. Ausdrucksstarke Tools statt vieler Beispiele gestalten Wenn in Toolbeschreibungen immer weitere Beispiele für gültige und ungültige Aufrufe ergänzt werden, wächst der Kontext, und das Modell kann die äußere Form der Beispiele nachahmen. Besser ist es, Toolnamen, Eingabefelder und Zustandsübergänge so zu gestalten, dass sie die Verwendung erkennen lassen. ```text TodoWrite Zweck: Aufgabenliste der aktuellen Sitzung erstellen und aktualisieren status: - pending - in_progress - completed Einschränkung: - Es kann jeweils nur eine Aufgabe den Status in_progress haben. ``` Gute Agenten-Tools weisen folgende Merkmale auf: - Name, Aktion und Ziel sind bereits am Namen erkennbar. - Pflichtfelder und optionale Felder sind klar getrennt. - Zulässige Werte werden durch Aufzählungstypen begrenzt. - Lesen und Schreiben sowie Vorschau und Ausführung sind getrennt. - Fehler geben Ursache und Wiederherstellungsmethode strukturiert zurück. - Gefährliche Vorgänge erfordern ein Bestätigungs-Token oder einen Genehmigungsschritt. - Bei übermäßig langen Ergebnissen werden eine Zusammenfassung und Seitennavigation angeboten. Beispiele sollten nur hinzugefügt werden, um Ausnahmen oder mehrdeutige Eingaben zu erläutern, die sich über die Schnittstelle nur schwer ausdrücken lassen. ### 3. Nicht alle Informationen von Anfang an einfügen, sondern schrittweise offenlegen Nur weil ein Agent Informationen möglicherweise für eine Aufgabe benötigen könnte, sollten nicht von Anfang an das gesamte Repository, sämtliche Richtlinien und lange Protokolle eingespeist werden. Zunächst sollten nur die für die Erkundung erforderlichen Mindestinformationen bereitgestellt werden. Sobald die Aufgabe konkreter wird, kann der Agent die relevanten Materialien lesen. Der empfohlene Ablauf lautet: 1. Ziel, Erfolgskriterien und Sicherheitsgrenzen bereitstellen. 2. Über die Repository-Struktur oder Such-Tools relevante Stellen finden. 3. Nur die erforderlichen Dateien und Spezifikationen lesen. 4. Nach der Implementierung relevante Tests und statische Analysen ausführen. 5. Bei einem Fehler nur den betreffenden Fehler und den umgebenden Code zusätzlich abrufen. 6. Nach Abschluss veraltete Protokolle und Zwischenschlussfolgerungen komprimieren oder entfernen. Schrittweise Offenlegung bedeutet nicht, Informationen zu verbergen. Sie besteht darin, Suchpfade und eine klare Dateistruktur bereitzustellen, damit das Modell die benötigten Informationen finden kann. ### 4. Redundante Anweisungen entfernen und maßgebliche Speicherorte festlegen Wenn dieselbe Regel im System-Prompt, in CLAUDE.md, in Skills und Toolbeschreibungen dupliziert wird, können die Formulierungen im Laufe der Zeit voneinander abweichen. Für jede Art von Anweisung sollte ein maßgeblicher Speicherort festgelegt werden. | Information | Empfohlener Speicherort | |---|---| | Organisationsweite Sicherheitsrichtlinien | Systemanweisungen oder Berechtigungshierarchie | | Build- und Testbefehle des Repositorys | CLAUDE.md des Projekts | | Vorgehensweise für eine bestimmte Aufgabe | Entsprechender Skill | | Tool-Eingaben und Einschränkungen | Tool-Schema und Beschreibung | | Verhalten der öffentlichen API | Codeschema, Spezifikation und Vertragstests | | Fortschritt der aktuellen Sitzung | Aufgabenliste oder Sitzungsstatus | Wenn Redundanzen unvermeidlich sind, ist es sicherer, auf den maßgeblichen Speicherort zu verweisen oder Inhalte automatisch zu generieren, statt sie zu kopieren. ### 5. Die Rollen von CLAUDE.md und automatischem Speicher trennen CLAUDE.md eignet sich für dauerhafte Anweisungen, die von Projektmitgliedern überprüft und versioniert werden können. - Standardbefehle für Build und Tests - Zentrale Erläuterung der Repository-Struktur - Vom Team vereinbarte Bereiche, die nicht geändert werden dürfen - Projektspezifische Prüfverfahren - Regeln, die sich mit allgemeinen Tools nur schwer erschließen lassen Folgende Informationen eignen sich dagegen besser für den automatischen Speicher oder den Sitzungsstatus: - Bei wiederkehrenden Aufgaben erkannte persönliche Präferenzen - Suchpfade, die sich bei kürzlich ausgeführten Aufgaben als nützlich erwiesen haben - Temporäre Eigenschaften der Entwicklungsumgebung - Fortschritt der aktuellen Sitzung Es darf nicht davon ausgegangen werden, dass der automatische Speicher immer korrekt oder dauerhaft ist. Veraltete Einträge müssen bearbeitet oder entfernt werden können. Außerdem darf er nicht als alleiniger Speicherort für Sicherheitsrichtlinien und öffentliche Verträge dienen. ### 6. Ausführbare Referenzmaterialien gegenüber erklärenden Dokumenten bevorzugen Spezifikationen in natürlicher Sprache sind nützlich, um Absichten zu erläutern, können aber das tatsächliche Verhalten möglicherweise nicht vollständig ausdrücken. Wenn möglich, sollten folgende Materialien gemeinsam bereitgestellt werden: - bestehende Implementierungen, die dem aktuellen Code ähneln - Unit- und Integrationstests - API-Schemata und Typdefinitionen - tatsächliches HTML oder Designartefakte - Dateien für Datenbankmigrationen - Beispieldaten für Ein- und Ausgaben - Bewertungsraster und automatische Bewertungskriterien Auch zwischen Referenzmaterialien können Konflikte entstehen, weshalb ihre Priorität angegeben werden muss. Beispielsweise kann festgelegt werden, dass Vertragstests den maßgeblichen Standard für die öffentliche API bilden und die README lediglich als Erklärung dient. ## Praktische Vorlage für die Kontextzusammenstellung Die folgende Struktur ist ein Beispiel dafür, wie sich die für eine Coding-Aufgabe benötigten Informationen kompakt ordnen lassen. ```text Ziel - Eine API zum Stornieren von Zahlungen hinzufügen. Erfolgskriterien - Die bestehende Service-Schicht für Zahlungen wiederverwenden. - Auch bei doppelten Anfragen nur einmal stornieren. - Die zugehörigen Vertragstests bestehen. Strikte Einschränkungen - Das öffentliche Antwortschema nicht ändern. - Nicht auf Produktionsdaten zugreifen. Referenzmaterialien - src/payments/capture.ts - tests/contracts/payment-cancel.test.ts - openapi/payments.yaml Beurteilungsprinzipien - Fehlerbehandlung und Namenskonventionen des umgebenden Zahlungscodes einhalten. - Bei unsicheren Annahmen vor der Implementierung nachfragen. Prüfung - Betroffene Unit-Tests - Vertragstests - Typprüfung ``` Dieses Format versucht nicht, jede denkbare Situation im Voraus aufzulisten. Stattdessen trennt es Ziel, Erfolgskriterien, unveränderliche Grenzen, maßgebliche Materialien und Prüfmethoden. ## Vorgehensweise zur Bereinigung vorhandener Kontexte ### Schritt 1: Quellen aller Anweisungen auflisten System-Prompt, CLAUDE.md, Skills, automatischen Speicher, Toolbeschreibungen und CI-Konfiguration gemeinsam prüfen. Wenn nur ein einzelnes Dokument betrachtet wird, lassen sich tatsächliche Konflikte nur schwer erkennen. ### Schritt 2: Jede Anweisung kategorisieren - aus Sicherheits- oder Rechtsgründen erforderlich - aufgrund des Produktvertrags erforderlich - dauerhafte Konvention des Teams - nur für ein bestimmtes Tool erforderliche Erläuterung - temporäre Regel zur Vermeidung von Fehlern früherer Modelle - Regel, deren Grundlage derzeit unklar ist ### Schritt 3: Redundanzen und Konflikte finden Sätze zusammenfassen, die dasselbe Verhalten unterschiedlich ausdrücken. Insbesondere Formulierungen wie `immer`, `niemals`, `unbedingt` und `nicht tun` sollten zuerst geprüft werden. ### Schritt 4: Regeln in Tests oder Berechtigungen überführen Punkte, die durch automatische Prüfungen zuverlässiger als durch Warnungen in natürlicher Sprache kontrolliert werden können, sollten in folgende Ebenen verschoben werden: - Tests und Linter - Typsysteme und Schemata - Tools mit minimalen Berechtigungen - Genehmigungsverfahren - Sandbox - CI-Richtlinien ### Schritt 5: Anhand tatsächlicher Aufgaben bewerten Es reicht nicht, nur die Länge des Prompts zu messen. Für eine repräsentative Aufgabenmenge sollten folgende Kennzahlen verglichen werden: - Erfolgsquote und Testbestehensquote - Anzahl unnötiger Dateiänderungen - Anzahl der Benutzerkorrekturen - Fehlerquote bei Toolaufrufen - Zeit und Tokens bis zum Abschluss - Verstöße gegen Sicherheitsrichtlinien ### Schritt 6: Nur die Fehlerursache minimal ergänzen Wenn ein Fehler auftritt, sollte nicht sofort eine neue Verbotsregel hinzugefügt werden. Zunächst muss unterschieden werden, ob die Ursache ein mehrdeutiges Ziel, unzureichende Referenzmaterialien oder ein fehlerhaftes Tool-Schema ist. ## Anweisungen, die nicht entfernt werden dürfen Vereinfachung bedeutet nicht bedingungsloses Löschen. Wenn mindestens eine der folgenden Fragen mit `Ja` beantwortet wird, sollte die Anweisung beibehalten oder in eine stärkere Kontrolle überführt werden. - Entstehen bei einem Verstoß Datenverlust oder finanzielle Schäden? - Bezieht sich die Anweisung auf gesetzliche, datenschutzrechtliche oder lizenzrechtliche Pflichten? - Handelt es sich um eine Organisationsrichtlinie, die das Modell nicht allein anhand des Codes erkennen kann? - Bestimmt sie die Kompatibilität einer öffentlichen API oder eines Datenformats? - Ist vor der Ausführung der Aufgabe die Genehmigung eines Menschen erforderlich? - Lässt sich ein Verstoß durch automatisierte Tests allein nur schwer vollständig erkennen? ## Häufige Fehlermuster ### Nach jedem Fehler eine neue Regel hinzufügen Wird ein einzelner Fehler verallgemeinert und in eine dauerhafte Regel umgewandelt, sammeln sich Ausnahmen und Konflikte an. Zunächst sollte ein Bewertungsfall hinzugefügt und geprüft werden, ob der Fehler wiederholt auftritt. ### Lange Beispiele faktisch als Vorlage verwenden Wenn ein Beispiel zu konkret ist, kann das Modell ihm Vorrang vor der aktuellen Codebasis geben. Beispiele sollten auf die minimale Größe beschränkt werden, die zur Erläuterung des Prinzips erforderlich ist. ### Vollständige Protokolle unverändert aufbewahren Toolausgaben und Build-Protokolle belegen schnell den Kontext. Besser ist es, nur die Fehlerursache, den relevanten Stack und den geänderten Zustand strukturiert festzuhalten. ### Automatischen Speicher als Richtlinienspeicher verwenden Automatischer Speicher ist praktisch, kann aber nur schwach in Prüf-, Bereitstellungs- und Auditprozesse eingebunden sein. Verbindliche Organisationsrichtlinien müssen in versionierten Anweisungen oder einer Berechtigungshierarchie gespeichert werden. ### Kontextverkleinerung nur als Tokenersparnis bewerten Ein kurzer Kontext ist nicht immer besser. Werden erforderliche Tests, Sicherheitsregeln oder Spezifikationen entfernt, verschlechtert sich das Ergebnis. Das Ziel sind nicht minimale Tokens, sondern ein Minimum an Tokens mit hohem Signalwert. ## Abschließende Checkliste - Sind Ziel und Erfolgskriterien der aktuellen Anfrage voneinander getrennt? - Sind Sicherheitsregeln und Stilpräferenzen voneinander unterschieden? - Ist dieselbe Anweisung nicht an mehreren Stellen dupliziert? - Erklärt das Tool-Schema die Verwendung auch ohne lange Beispiele? - Können relevante Dateien bei Bedarf gesucht werden? - Gibt es eine Möglichkeit, veralteten Speicher und Ausführungsprotokolle zu entfernen? - Lassen sich Regeln in natürlicher Sprache durch Tests oder Berechtigungen durchsetzen? - Ist die Priorität zwischen den Referenzmaterialien klar? - Gibt es Bewertungsaufgaben, mit denen sich der Zustand vor und nach einer Änderung der Anweisungen vergleichen lässt? ## Fazit Context Engineering für leistungsfähige Claude-Modelle ist keine Technik, bei der Anweisungen bedingungslos gekürzt werden. Es ist die Gestaltung von Informationen, bei der Ziele, Sicherheitsgrenzen und Belege, die das Modell zur Beurteilung der aktuellen Aufgabe benötigt, klar herausgearbeitet und irrelevante Informationen sowie widersprüchliche Regeln entfernt werden. Das praktischste Prinzip lässt sich wie folgt zusammenfassen: > Sicherheit und Verträge strikt durchsetzen, Stil dem Kontext überlassen, Informationen zum erforderlichen Zeitpunkt bereitstellen und Ergebnisse durch ausführbare Tests prüfen. ## FAQ ### Wie unterscheiden sich Prompt Engineering und Context Engineering? Prompt Engineering befasst sich damit, wie Ziel, Format und Einschränkungen der aktuellen Anfrage formuliert werden. Context Engineering gestaltet, was dem Modell wann gezeigt wird – darunter dieser Prompt sowie Systemanweisungen, Dateien, Tools, Speicher, Gesprächsverlauf und Ausführungsergebnisse. ### Wird die Leistung des Modells bei einem langen Kontext immer besser? Nein. Ein langer Kontext kann irrelevante Informationen und Anweisungen enthalten, die mit älteren Aufzeichnungen in Konflikt stehen. Entscheidend ist nicht die Gesamtzahl der Token, sondern der Anteil hochinformativer Informationen, die direkt zur aktuellen Aufgabe beitragen. ### Müssen für Claude 5 alle bestehenden Regeln gelöscht werden? Nein. Feinregeln, die je nach Situation variieren, etwa zum Codestil oder zu Kommentaren, können zwar durch Entscheidungsprinzipien ersetzt werden, doch Einschränkungen in Bezug auf Sicherheit, personenbezogene Daten, Berechtigungen, Finanztransaktionen, Datenlöschung und öffentliche API-Verträge müssen beibehalten oder durch Tools und Tests noch strenger kontrolliert werden. ### Welche Inhalte sollten sinnvollerweise in CLAUDE.md aufgenommen werden? Geeignet sind dauerhafte und überprüfbare Anweisungen, etwa die Build- und Testbefehle des Projekts, die Repository-Struktur, Bereiche, die nicht geändert werden dürfen, sowie die vom Team vereinbarten Prüfverfahren. Wenn alle vorübergehenden Fortschritte oder persönlichen Erkenntnisse darin festgehalten werden, kann das Dokument schnell veralten. ### Kann der automatische Speicher CLAUDE.md ersetzen? Er kann es nicht vollständig ersetzen. Der automatische Speicher ist nützlich, um bei wiederkehrenden Aufgaben erkannte Präferenzen oder Rechercheinformationen beizubehalten. Richtlinien, die wie Sicherheitsrichtlinien und öffentliche Verträge geprüft und versioniert werden müssen, sollten jedoch in CLAUDE.md oder einer separaten Richtlinienebene hinterlegt werden. ### Welche Merkmale hat eine gute Schnittstelle für Agentenwerkzeuge? Der Zweck sollte allein anhand des Namens des Werkzeugs und des Eingabeschemas erkennbar sein, und Pflichtwerte sowie zulässige Zustände müssen klar definiert sein. Für riskante Schreibvorgänge sollte eine Vorschau oder eine Genehmigung erforderlich sein, und bei Fehlern sollten Ursache und Wiederherstellungsmethode möglichst strukturiert zurückgegeben werden. ### Bedeutet eine schrittweise Offenlegung, dass dem Modell Informationen vorenthalten werden? Nein. Zunächst werden das Ziel und der Suchpfad vorgegeben, und während das Modell die Aufgabe konkretisiert, sucht es nach den erforderlichen Dateien, Spezifikationen und Protokollen. Ziel ist es, unnötige Vorabzuführung zu reduzieren und gleichzeitig den Zugang zu Informationen aufrechtzuerhalten. ### Wie bewertet man die Wirkung nach der Reduzierung des Kontexts? Bei einer repräsentativen Aufgabenmenge sollten vor und nach der Änderung die Testbestehensrate, die Anzahl der Benutzerkorrekturen, unnötige Änderungen, Toolfehler, der Tokenverbrauch und etwaige Verstöße gegen Sicherheitsrichtlinien verglichen werden. Der Erfolg sollte nicht allein anhand der Verkürzung der Prompt-Länge beurteilt werden. ### Müssen überhaupt keine Beispiele für die Verwendung des Tools bereitgestellt werden? Beispiele sind nicht immer unnötig. Bei Grenzfällen oder mehrdeutigen Eingaben, die sich allein mit dem Schema nur schwer darstellen lassen, sind minimale Beispiele hilfreich. Vorrangig sollte jedoch die Schnittstelle selbst klar gestaltet werden, statt wiederholt reguläre Aufrufe aufzulisten. ## Sources - [Effektives Context Engineering für KI-Agenten](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) - [Effektive Agenten entwickeln](https://www.anthropic.com/engineering/building-effective-agents) - [Überblick über Prompt Engineering](https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview) - [Dokumentation zum Speicher von Claude Code](https://docs.anthropic.com/en/docs/claude-code/memory) ## Images ![문서와 데이터 아이콘이 깔때기를 거쳐 중앙 AI 네트워크로 모이는 일러스트](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzMzMywicHVyIjoiYmxvYl9pZCJ9fQ==--b6a9225f1d5837dd6ca93532a1e1a3388a1cc4fc/ai-e5c0c894.webp) ![로봇이 검색, 파일, 도구, 코드, 검증, 보고서 단계를 거쳐 목표로 향하는 AI 워크플로](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzMzOSwicHVyIjoiYmxvYl9pZCJ9fQ==--c5e1421a425951ca760407e2d7b6c78654f545e5/ai-8b2296c2.webp)