Anmerkung des Autors: Ich habe 25 praxiserprobte Eingabeaufforderungen für das Code-Review mit Claude Code zusammengestellt. Sie decken 7 Schlüsselszenarien ab, darunter Sicherheitsüberprüfungen, Performance-Analysen, Architektur-Reviews und Bug-Erkennung, inklusive einer Formel zur Erstellung eigener Eingabeaufforderungen.
Claude Code bietet zwar den Befehl /security-review und ein Multi-Agenten-System für Code-Reviews, doch die Standardausgaben sind oft zu weitschweifig und verlieren sich in Details. Gute Eingabeaufforderungen für Reviews sollten so präzise wie Testfälle sein – sie definieren den Umfang, legen Prioritäten fest und fordern konkrete Zeilennummern sowie Verbesserungsvorschläge ein. Dieser Artikel enthält 25 Eingabeaufforderungen für 7 Szenarien, die Sie direkt kopieren und verwenden können.
Kernnutzen: 25 Eingabeaufforderungen für die häufigsten Code-Review-Szenarien, ergänzt durch eine Formel zur Erstellung eigener Prompts sowie Beispiele für gute und schlechte Formulierungen.
Review-Formel für Eingabeaufforderungen
Eine gute Review-Eingabeaufforderung ist so präzise wie ein Testfall. Eine schlechte Review-Eingabeaufforderung gleicht einer vagen Slack-Nachricht.
Die Fünf-Elemente-Formel
[Rolle] Agiere aus der Perspektive eines erfahrenen {Sprache/Bereich}-Entwicklers
[Umfang] Überprüfe die {Änderungen} in {Datei/Verzeichnis/PR}
[Fokus] Konzentriere dich auf {Sicherheit/Performance/Logik/Architektur}
[Format] Ausgabeformat: {Nummerierte Liste/Tabelle/Inline-Kommentare}
[Ebene] Markiere den Schweregrad: {Critical/High/Medium/Low}
| Element | Schlechtes Beispiel | Gutes Beispiel |
|---|---|---|
| Rolle | (nicht festgelegt) | "Aus der Perspektive eines erfahrenen Backend-Entwicklers" |
| Umfang | "Schau dir diesen Code an" | "Überprüfe den aktuellen git diff von src/auth/" |
| Fokus | "Gib mir Feedback" | "Konzentriere dich auf SQL-Injection und Authentifizierungsumgehungen" |
| Format | (beliebige Ausgabe) | "Nummerierte Liste, jedes Element enthält Datei:Zeilennummer, Problembeschreibung, Korrekturvorschlag" |
| Ebene | (keine Anforderung) | "Markiere Critical/High/Medium/Low" |
Szenario 1: Sicherheitsüberprüfung (4 Eingabeaufforderungen)
Die Sicherheitsüberprüfung hat bei Code Reviews höchste Priorität. Claude Code bietet den Befehl /security-review, aber mit benutzerdefinierten Eingabeaufforderungen erzielen Sie tiefere Einblicke.
Eingabeaufforderung #1: Umfassender OWASP Top 10 Scan
Überprüfe als Sicherheits-Audit-Ingenieur alle kürzlich geänderten Dateien im Verzeichnis src/.
Prüfe diese einzeln gemäß den OWASP Top 10:
1. Injection (SQL/NoSQL/Command Injection)
2. Authentifizierungsfehler
3. Offenlegung sensibler Daten
4. XXE
5. Fehler bei der Zugriffskontrolle
6. Sicherheitsfehlkonfigurationen
7. XSS
8. Deserialisierung
9. Verwendung von Komponenten mit bekannten Schwachstellen
10. Mangelhafte Protokollierung und Überwachung
Ausgabeformat: Nummerierte Liste, jedes Element enthält [Datei:Zeilennummer] [Schweregrad] [Problembeschreibung] [Korrekturvorschlag].
Melde nur tatsächlich existierende Probleme, keine theoretischen Risiken.
Eingabeaufforderung #2: Sicherheitsüberprüfung von API-Endpunkten
Überprüfe alle API-Routendateien (routes/, controllers/) und konzentriere dich auf:
- Endpunkte, bei denen die Authentifizierungs-Middleware fehlt
- Ob Eingabeparameter validiert und bereinigt wurden
- Risiken durch Mass Assignment
- Ob Ratenbegrenzungen konfiguriert sind
- Ob Fehlerantworten interne Informationen preisgeben
Ausgabetabelle: Endpunkt-Pfad | Problem | Schweregrad | Lösungsvorschlag
Eingabeaufforderung #3: Erkennung von Lecks sensibler Informationen
Scanne das gesamte Projekt auf hartcodierte oder versehentlich offengelegte sensible Informationen:
- API-Schlüssel, Secrets, Token
- Datenbank-Verbindungsstrings
- Private Schlüssel und Zertifikate
- Interne IP-Adressen und Domänennamen
- Passwörter oder Zugangsdaten in Kommentaren
Der Prüfumfang umfasst: Quellcode, Konfigurationsdateien, .env.example, docker-compose.yml, README
Gib für jeden Fund den Dateipfad und die Zeilennummer an.
Eingabeaufforderung #4: Überprüfung der Authentifizierungs- und Autorisierungslogik
Überprüfe als Sicherheitsexperte den Code für Authentifizierung und Autorisierung:
1. Ist die JWT-Token-Validierungslogik vollständig (Ablauf, Signatur, Manipulation)?
2. Wird für die Passwortspeicherung ein sicherer Hash (bcrypt/argon2) verwendet?
3. Besteht bei der Session-Verwaltung ein Risiko für Session-Fixation-Angriffe?
4. Ist die CORS-Konfiguration zu freizügig?
5. Validiert der OAuth-Callback den state-Parameter?
Melde nur Probleme der Stufen Critical und High und füge Code-Beispiele für die Korrektur bei.
Szenario 2: Bug-Erkennung (4 Eingabeaufforderungen)
Eingabeaufforderung #5: Null-Pointer und Randbedingungen
Überprüfe die kürzlich geänderten Dateien auf folgende potenzielle Bugs:
- Zugriff auf Eigenschaften ohne vorherige Prüfung auf null/undefined
- Array-Zugriffe außerhalb der Grenzen (Out-of-Bounds)
- Division durch Null
- Nicht behandelte leere Strings
- Nicht behandelte NaN-Werte bei parseInt/parseFloat
Gib für jeden Fund die Auslösebedingungen (welche Eingabe führt zum Absturz) und den Korrekturcode an.
Eingabeaufforderung #6: Asynchrone und Nebenläufigkeitsprobleme
Überprüfe den gesamten asynchronen Code im Projekt (async/await, Promise, Callbacks) auf:
- Promises ohne .catch-Fehlerbehandlung
- Race Conditions
- await innerhalb von Schleifen, die zu sequenzieller Ausführung führen (sollte Promise.all verwenden)
- Callback-Hölle, die refaktorisiert werden kann
- Korrekte Rollback-Behandlung bei Transaktionen
Markiere dies als [Datei:Zeilennummer] [Problem] [Auswirkung] [Lösungsvorschlag]
Eingabeaufforderung #7: Logikfehler-Jäger
Lies die Geschäftslogik der folgenden Funktionen sorgfältig durch und achte auf:
- Ob if/else-Zweige alle Fälle abdecken
- Korrekte Abbruchbedingungen in Schleifen
- Korrekte Vergleichsoperatoren (== vs ===, > vs >=)
- Korrekte Variablen-Scopes
- Ob Rückgabewerte in allen Pfaden definiert sind
Konzentriere dich nicht auf den Programmierstil, sondern ausschließlich auf die logische Korrektheit.
Eingabeaufforderung #8: Überprüfung der Fehlerbehandlung
Überprüfe den Fehlerbehandlungsmechanismus des Projekts:
1. Fangen try/catch-Blöcke spezifische Ausnahmen ab statt nur generische Fehler?
2. Werden Fehler in catch-Blöcken einfach verschluckt (leeres catch)?
3. Werden Fehler korrekt an die übergeordnete Ebene weitergegeben?
4. Sind die für den Benutzer sichtbaren Fehlermeldungen benutzerfreundlich (ohne interne Informationen preiszugeben)?
5. Gibt es Rollback-Mechanismen für kritische Vorgänge (Zahlungen, Datenänderungen) bei Fehlern?
Sortiere die Ausgabe nach Schweregrad.
Szenario 3: Leistungsanalyse (3 Eingabeaufforderungen)
Eingabeaufforderung #9: Datenbankabfrage-Performance
Überprüfe den gesamten Code für Datenbankabfragen (models/, repositories/, ORM-Aufrufe) auf:
- N+1-Abfrageprobleme (Abfragen innerhalb von Schleifen)
- Fehlende Indizes bei Abfragefeldern
- Ob SELECT * durch spezifische Felder ersetzt werden sollte
- Ob bei großen Datenmengen Paging verwendet wird
- Ob wiederholte Abfragen durch Caching optimiert werden können
Schätze für jedes Problem die Performance-Auswirkung (niedrig/mittel/hoch) ein und gib den optimierten Code an.
Eingabeaufforderung #10: Speicher- und Ressourcenlecks
Überprüfe das Projekt auf mögliche Speicher- und Ressourcenlecks:
- Werden Event-Listener beim Entfernen von Komponenten gelöscht?
- Werden Timer (setInterval/setTimeout) bereinigt?
- Werden Datenbankverbindungen korrekt geschlossen?
- Werden Datei-Handles in finally-Blöcken freigegeben?
- Werden große Arrays/Objekte nach der Verwendung dereferenziert?
Konzentriere dich besonders auf die useEffect-Bereinigung in React-Komponenten und die Stream-Verarbeitung in Node.js.
Eingabeaufforderung #11: Überprüfung der Algorithmenkomplexität
Überprüfe die kürzlich geänderten Funktionen und analysiere die Zeit- und Platzkomplexität:
- Gibt es Implementierungen mit O(n²) oder höher, die optimiert werden können?
- Gibt es Stellen, an denen eine lineare Suche durch eine Hash-Tabelle ersetzt werden kann?
- Gibt es unnötige Deep-Copies?
- Sollte bei der String-Verkettung StringBuilder/join verwendet werden?
- Wird für Sortierungen der geeignete Algorithmus verwendet?
Markiere dies als Aktuelle Komplexität → Optimierbare Komplexität → Konkreter Optimierungsvorschlag.
Szenario 4: Architektur-Review (4 Eingabeaufforderungen)
Eingabeaufforderung #12: Analyse von Abhängigkeiten und Kopplung
Analysiere die Modulabhängigkeiten in src/:
1. Erstelle ein Diagramm der Modulabhängigkeiten (welches Modul importiert welche anderen Module)
2. Identifiziere zirkuläre Abhängigkeiten
3. Identifiziere die Module mit der höchsten Kopplung (die am häufigsten von anderen Modulen importiert werden)
4. Schlage vor, welche Abhängigkeiten über Schnittstellen/Abstraktionen entkoppelt werden sollten
Ausgabe: Tabelle der Abhängigkeiten + Liste zirkulärer Abhängigkeiten + Entkopplungsvorschläge
Eingabeaufforderung #13: Compliance-Prüfung der Schichtenarchitektur
Überprüfe, ob der Code die Prinzipien der Schichtenarchitektur einhält:
- Enthält die Controller-Schicht Geschäftslogik? (Sie sollte nur Routing und Parametervalidierung übernehmen)
- Greift die Service-Schicht direkt auf die Datenbank zu? (Dies sollte über ein Repository erfolgen)
- Enthält die Model/Entity-Schicht HTTP-spezifische Logik?
- Gibt es Aufrufe über Schichtgrenzen hinweg? (z. B. Controller ruft direkt Repository auf)
Liste jede Datei und die genaue Code-Stelle auf, die gegen die Schichtenprinzipien verstößt.
Eingabeaufforderung #14: Review des API-Designs
Überprüfe alle API-Endpunkte unter dem Gesichtspunkt der Best Practices für RESTful API-Design:
- Folgt die URL-Benennung REST-Konventionen (Plural-Substantive, hierarchische Struktur)?
- Ist die Verwendung der HTTP-Methoden korrekt (GET für Lesezugriffe, POST für Erstellung, PUT für Aktualisierung, DELETE für Löschvorgänge)?
- Ist das Antwortformat konsistent (Fehlercodes, Paginierung, Zeitformate)?
- Ist eine API-Versionskontrolle vorhanden?
- Gibt es redundante Endpunkte, die zusammengelegt werden können?
Ausgabe: Tabelle mit Verbesserungsvorschlägen (Aktuell → Vorschlag → Grund)
Eingabeaufforderung #15: Bewertung technischer Schulden
Führe eine umfassende Bewertung der technischen Schulden des Projekts durch:
1. Veraltete Abhängigkeitspakete und Framework-Versionen
2. Veraltete API-Aufrufe
3. Hartcodierte Konfigurationswerte (sollten Umgebungsvariablen verwenden)
4. Kopierte und eingefügte redundante Codeblöcke
5. Kritische Module ohne Unit-Tests
6. Übermäßig komplexe Funktionen (zyklomatische Komplexität > 15)
Sortiere nach Dringlichkeit der Behebung: Blockierend (muss sofort behoben werden) > Hoch > Mittel > Niedrig
Szenario 5: PR-Review (4 Eingabeaufforderungen)
Eingabeaufforderung #16: Schnelle PR-Diff-Prüfung
Überprüfe den Diff des aktuellen Branches gegenüber main und bewerte ihn aus der Sicht eines erfahrenen Ingenieurs:
1. Was ist das Ziel dieses PRs? (abgeleitet aus dem Diff)
2. Sind die Änderungen vollständig? (gibt es fehlende Dateien oder Logik?)
3. Wurden neue Fehler oder Regressionen eingeführt?
4. Ist die Testabdeckung ausreichend?
5. Gibt es unnötige Änderungen (Debug-Code, Formatierungsrauschen)?
Berichte nur Probleme der Stufen "High" und "Critical". Bitte kein Nit-Picking beim Code-Stil.
Eingabeaufforderung #17: Prüfung der Abwärtskompatibilität
Überprüfe alle Änderungen im aktuellen PR auf nicht abwärtskompatible Anpassungen:
- Wurden Signaturen oder Rückgabewerte öffentlicher API-Schnittstellen geändert?
- Gibt es Breaking Changes im Datenbankschema?
- Hat sich das Format der Konfigurationsdateien geändert?
- Wurden Funktionen gelöscht, die von anderen Modulen verwendet werden?
- Wurden Namen oder Formate von Umgebungsvariablen geändert?
Bewerte für jeden inkompatiblen Punkt den Einflussbereich und den Migrationsplan.
Eingabeaufforderung #18: Prüfung der Testvollständigkeit
Vergleiche die Codeänderungen des aktuellen PRs mit den Teständerungen:
1. Haben alle neuen Funktionen entsprechende Unit-Tests?
2. Wurden bestehende Tests bei geänderter Logik aktualisiert?
3. Sind Randbedingungen und Ausnahmepfade durch Tests abgedeckt?
4. Decken Integrationstests die neuen API-Endpunkte ab?
5. Sind die Testdaten sinnvoll? (keine willkürlichen Werte wie 123, abc)
Liste Vorschläge für fehlende Testfälle auf: Funktionsname | Fehlendes Testszenario | Priorität
Eingabeaufforderung #19: Review der Commit-Qualität
Überprüfe die Commit-Historie des aktuellen PRs:
1. Beschreiben die Commit-Nachrichten den Inhalt der Änderungen klar?
2. Ist jeder Commit atomar (ein Commit für einen Zweck)?
3. Gibt es triviale Commits, die zusammengefasst (squashed) werden sollten?
4. Gibt es temporäre Commits wie "fix typo" oder "wip", die bereinigt werden sollten?
5. Ist die Reihenfolge der Commits logisch (erst Infrastruktur, dann Geschäftslogik)?
Schlage vor, welche Commits bereinigt werden sollten und wie die finale Commit-Struktur aussehen sollte.
Szenario 6: Lesbarkeit (3 Eingabeaufforderungen)
Eingabeaufforderung #20: Namensprüfung
Überprüfe die Benennung aller Variablen, Funktionen und Klassen in den kürzlich geänderten Dateien:
- Gibt es Namen mit unklarer Bedeutung (data, info, temp, res, obj)?
- Gibt es übermäßige Abkürzungen (usr → user, btn → button)?
- Gibt es boolesche Werte, die nicht mit is/has/should beginnen?
- Beginnen Funktionsnamen mit einem Verb, das das Verhalten präzise beschreibt?
- Beschreiben Klassennamen ihre Verantwortung präzise als Substantiv?
Schlage für jeden unpassenden Namen eine bessere Alternative vor.
Eingabeaufforderung #21: Überprüfung der Kommentarqualität
Überprüfe die Qualität der Kommentare im Code:
- Gibt es "Was"-Kommentare, die in "Warum"-Kommentare umgewandelt werden sollten?
- Gibt es veraltete Kommentare (die nicht mit dem Code übereinstimmen)?
- Gibt es Kommentare, die besser als Funktionsname extrahiert werden sollten?
- Fehlen bei komplexer Geschäftslogik erklärende Kommentare?
- Verfügen öffentliche APIs über JSDoc/Docstrings?
Schlage keine offensichtlichen Kommentare vor (wie "// Zähler erhöhen").
Eingabeaufforderung #22: Vorschläge zur Funktionsaufteilung
Überprüfe alle Funktionen mit mehr als 30 Zeilen und bewerte, ob sie aufgeteilt werden sollten:
- Hat die Funktion mehrere Verantwortlichkeiten (erledigt sie mehrere unabhängige Dinge)?
- Übersteigt die Verschachtelungstiefe 3 Ebenen?
- Übersteigt die Anzahl der Parameter 4?
- Gibt es wiederkehrende Logik, die extrahiert werden kann?
Gib einen konkreten Aufteilungsplan an: Ursprüngliche Funktion → Liste der aufgeteilten Funktionen → Verantwortung jeder Funktion.
Szenario 7: Refactoring-Vorschläge (3 Eingabeaufforderungen)
Eingabeaufforderung #23: DRY-Verletzungserkennung
Scanne das Projekt auf doppelten Code:
- Finde Codeblöcke mit mehr als 3 Zeilen Duplizierung.
- Finde Logik, die ähnlich ist, aber unterschiedlich geschrieben wurde.
- Finde allgemeine Muster, die als Hilfsfunktionen extrahiert werden können.
Gib für jede Gruppe von Duplikaten den konkreten Implementierungscode für die Extraktion in eine öffentliche Funktion an.
Eingabeaufforderung #24: Optimierung von Entwurfsmustern
Überprüfe den Code aus der Sicht eines Experten für Entwurfsmuster:
- Sollten umfangreiche if/else- oder switch-Anweisungen durch das Strategiemuster ersetzt werden?
- Sollte die Erstellung komplexer Objekte durch das Fabrik-/Erbauer-Muster ersetzt werden?
- Sollte wiederkehrender Vorlagencode durch das Schablonenmethoden-Muster ersetzt werden?
- Sollten tief verschachtelte Callbacks durch das Chain-of-Responsibility-Muster ersetzt werden?
- Sollte die globale Zustandsverwaltung durch das Beobachter-Muster ersetzt werden?
Schlage dies nur vor, wenn die Musterverbesserung die Komplexität deutlich reduziert; vermeide Over-Engineering.
Eingabeaufforderung #25: Modernisierung von Legacy-Code
Überprüfe Legacy-Code im Projekt und identifiziere Teile, die mit moderner Syntax umgeschrieben werden können:
- var → const/let
- Callback-Funktionen → async/await
- for-Schleifen → map/filter/reduce
- String-Verkettung → Template-Strings
- require → import
- Class → Funktionskomponenten + Hooks (React)
Gib einen Vergleich des Codes vor und nach dem Refactoring an und bewerte das Refactoring-Risiko (niedrig/mittel/hoch).
🎯 Nutzungsempfehlung: Speichere die am häufigsten verwendeten Review-Eingabeaufforderungen in einer
CLAUDE.mdoder unter.claude/skills/, um teamweite Standards zu etablieren. Über/loopkannst du Sicherheitsüberprüfungen und PR-Reviews automatisieren.
Wenn du ein automatisiertes Review-System über eine API aufbaust, empfehlen wir den Zugriff auf Claude Opus 4.6 über den API-Proxy-Dienst APIYI (apiyi.com) mit einem Rabatt von 20 %.
Häufig gestellte Fragen
F1: Was kann ich tun, wenn der Standardbefehl /code-review zu gesprächig ist?
Erstellen Sie eine REVIEW.md im Stammverzeichnis Ihres Projekts oder fügen Sie Review-Regeln in die CLAUDE.md ein. Definieren Sie dort klar, worauf sich Claude konzentrieren soll und was ignoriert werden kann. Beispiel: „Berichte nur kritische und hochgradige Probleme. Achte nicht auf Kleinigkeiten wie Code-Stil oder Benennungen. Schlage keine zusätzlichen Kommentare vor.“ Claude Code liest diese Datei bei jedem Review automatisch aus.
F2: Wie speichere ich eine Eingabeaufforderung als wiederverwendbaren Skill?
Speichern Sie Ihre Eingabeaufforderung für Sicherheitsüberprüfungen unter .claude/skills/security-review/SKILL.md und setzen Sie user-invocable: true. Dadurch wird sie als Slash-Befehl /security-review registriert. So können Sie den Befehl später einfach eingeben, ohne jedes Mal kopieren und einfügen zu müssen. Sie können beliebig viele Eingabeaufforderungen als eigene Skills speichern.
F3: Kann ein PR-Review automatisch als GitHub-Kommentar gepostet werden?
Ja, das ist möglich. Es gibt zwei Wege: 1) Geben Sie @claude review in einem PR-Kommentar ein; Claude analysiert dann automatisch den Diff und veröffentlicht die Ergebnisse als Inline-Kommentare. 2) Verwenden Sie den Befehl /code-review --comment, damit Claude das Review-Ergebnis direkt als PR-Kommentar postet. Anthropic hat im März 2026 ein spezialisiertes Multi-Agenten-System für Code-Reviews veröffentlicht, das eine Gruppe professioneller Agenten koordiniert, um PRs aus verschiedenen Blickwinkeln wie Sicherheit, Logik und Tests zu prüfen.
F4: Wie viele Token verbraucht eine Review-Eingabeaufforderung?
Das hängt vom Umfang der Überprüfung ab. Ein Review einzelner Dateien verbraucht etwa 2.000 bis 5.000 Token, ein vollständiger Sicherheits-Scan des Projekts kann 10.000 bis 30.000 Token beanspruchen. Es empfiehlt sich, den Bereich der Überprüfung auf bestimmte Dateien oder Verzeichnisse zu beschränken, um Token-Verschwendung durch „Scannen aller Dateien“ zu vermeiden. Über APIYI (apiyi.com) können Sie Claude Opus 4.6 mit 20 % Rabatt nutzen, was die Review-Kosten erheblich senkt.
Zusammenfassung
Die Kernpunkte für effektive Claude Code Review-Eingabeaufforderungen:
- 25 Eingabeaufforderungen für 7 Szenarien: Sicherheitsüberprüfungen (4), Bug-Erkennung (4), Leistungsanalyse (3), Architektur-Review (4), PR-Review (4), Lesbarkeit (3), Refactoring-Vorschläge (3) – einfach kopieren und anwenden.
- Die Fünf-Elemente-Formel für gute Eingabeaufforderungen: Rolle + Umfang + Fokus + Format + Schweregrad. Präzise wie ein Testfall, nicht vage wie eine Slack-Nachricht.
- Dreistufiges Review-System: Integrierte Befehle (
/security-review) → Benutzerdefinierte Eingabeaufforderungen (die 25 aus diesem Artikel) →/loopfür kontinuierliche, automatisierte Reviews.
Wir empfehlen die Anbindung über APIYI (apiyi.com), um Claude Opus 4.6 mit 20 % Rabatt für den Aufbau Ihres automatisierten Code-Review-Systems zu nutzen.
📚 Referenzmaterialien
-
Offizielle Dokumentation zu Claude Code Code Review: Vollständige Erläuterung der integrierten Review-Funktion
- Link:
code.claude.com/docs/en/code-review - Beschreibung: Enthält Informationen zu PR-Reviews, Multi-Agenten-Systemen und Anpassungsmethoden
- Link:
-
Claude Code Security Review: Offizielles Sicherheitsprüfungsverfahren von Anthropic
- Link:
github.com/anthropics/claude-code-security-review - Beschreibung: Enthält die vollständige Implementierung des Befehls
/security-review
- Link:
-
7 Claude PR-Review-Eingabeaufforderungen: Von der Community validierte Eingabeaufforderungen für Reviews
- Link:
rephrase-it.com/blog/7-claude-pr-review-prompts-for-2026 - Beschreibung: Enthält strukturierte Vorlagen für Eingabeaufforderungen zur PR-Überprüfung
- Link:
-
APIYI-Dokumentationszentrum: 20 % Rabatt auf den API-Zugang für Claude Opus 4.6
- Link:
docs.apiyi.com - Beschreibung: Die optimale API-Lösung für den Aufbau automatisierter Review-Systeme
- Link:
Autor: APIYI Technik-Team
Technischer Austausch: Diskutieren Sie gerne in den Kommentaren. Weitere Informationen finden Sie im APIYI-Dokumentationszentrum unter docs.apiyi.com
