Thema: Anhang B. Qwen Code-Kompatibilität
Schwierigkeitsgrad: Mittelstufe
Geschätzte Lernzeit: 6-8 Stunden (Theorie + Praxis)
Voraussetzungen: Grundlegende Vertrautheit mit Qwen Code und dessen CLI-Schnittstelle
Verständnis der Git-Grundlagen und der Repository-Struktur
Erfahrung mit Markdown-Dateien und Konfigurationen
Grundkenntnisse in Python oder einer anderen Skriptsprache
Verständnis der CI/CD-Konzepte (wünschenswert)
Lernziele: Die drei Reifegrade (Standard, Empfehlung, Frontier) unterscheiden und Production-Prozesse korrekt nach Implementierungsschichten klassifizieren
Benutzerdefinierte Befehle in der Struktur .qwen/commands/ mit korrekter Benennung und Stoppverträgen erstellen
Reproduzierbare Prüfungen als Projektskripte entwerfen, unabhängig von der Überzeugungskraft der Modellantwort
Qwen Code-Hooks (PreToolUse, PostToolUse, UserPromptSubmit usw.) für Guardrails konfigurieren
Externe Production-APIs über MCP-Server mit Tools-Zulassungsliste und Geheimnisschutz integrieren
Übersicht: Anhang B definiert eine kritisch wichtige Grenze zwischen den integrierten Funktionen von Qwen Code und den Prozessen, die im Projekt selbst implementiert werden müssen. Der zweite Band des Kurses beschreibt Production-Prozesse rund um Qwen Code: Ein Teil ist in das Tool integriert, ein Teil erfordert benutzerdefinierte Befehle, Skills, Hooks, MCP-Server oder reguläre Skripte. Das Lehrmaterial basiert auf einer kanonischen Skala mit drei Reifegraden — Standard, Empfehlung und Frontier — die die Erwartungen an den Leser und die Implementierungsschicht definiert. Das Verständnis dieser Grenze verhindert den Fehler, bei dem ein zu entwerfender Prozess für einen integrierten CLI-Befehl gehalten wird, und ermöglicht eine korrekte architektonische Verteilung der Verantwortung zwischen dem integrierten Tool, der Projektkonfiguration und der externen Orchestrierung.
Schlüsselkonzepte: Kanonische Skala der drei Reifegrade: Ein Klassifizierungssystem, das nicht die Qualität einer Idee bewertet, sondern die Grenze der Lesererwartungen definiert. Standard — funktioniert in gewöhnlichem Qwen Code ohne zusätzliche Plattform, Basismaterial des Kurses, integrierte Funktionen. Empfehlung — lohnt sich, im Projekt bei wiederholenden Prozessen umzusetzen, erfordert Repository-Dateien: benutzerdefinierte Befehle, Skills, Hooks oder Skripte. Frontier — Production-Orchestrierung rund um Qwen Code, benötigt für Teams mit externen APIs, SRE-Prozessen und Modellbudgetierung, implementiert über externen Orchestrator, MCP, externe Dienste.
Integrierte Qwen Code-Schicht: Grundlegende Funktionen, die wie vorhanden ohne zusätzliche Konfiguration verwendet werden: /plan (Planungsmodus ohne Bearbeitungen und Shell-Ausführung), /review (integriertes Code-Review mit deterministischen Prüfungen und parallelen Review-Agenten), /skills (Anzeige und expliziter Start von Skills), /memory, /remember, /forget (Speicherverwaltung und QWEN.md), /mcp und qwen mcp add (MCP-Server verbinden), @path (Datei/Verzeichnis zum Kontext hinzufügen), !command (Shell-Befehle in der interaktiven Sitzung), qwen -p "..." (headless-Ausführung für CI und Skripte).
Benutzerdefinierte Befehle: Erweiterungsmechanismus von Qwen Code durch Erstellung von Markdown-Dateien in der Struktur .qwen/commands/<namespace>/<command>.md. Befehle werden als /<namespace>:<<command> aufgerufen, enthalten Vorlagen mit {{args}}, Verweise auf @specs/... und Stoppregeln. Ermöglichen die Reproduktion des Verhaltens von Befehlen aus dem ersten Band (z.B. /clarify) ohne implizite Annahmen über deren Integration.
Projektskripte: Reproduzierbare Prüfungen, unabhängig vom Modell, als reguläre Skripte im Projektverzeichnis formatiert. Der grüne CI-Status sollte vom Prüfcode abhängen, nicht von der Überzeugungskraft der Modellantwort. Beispiele: check_coverage.py, validate_schema.py, mutate_specs.py, run_duel.py, compile.py für Budget.
Hooks: Offizielle Qwen Code-Ereignisse zur Implementierung von Guardrails: PreToolUse, PostToolUse, UserPromptSubmit, SessionStart, Stop, SubagentStop, Notification, PreCompact und andere. Erfordern die Verwendung genauer Ereignisnamen aus der aktuellen Dokumentation, keine freien Varianten.
MCP-Server und externe APIs: Methode zur Integration von Production-APIs (Grafana, PagerDuty, Kubernetes, Jira) ohne deren Verwandlung in uneingeschränkte Shell-Befehle. Erfordern eine Tools-Zulassungsliste (Allowlist): nur-lesend für Triage, separate schreibende Tools für sichere Aktionen, explizite Bestätigungs- und Rollback-Bedingungen, Verbot der Weitergabe von Geheimnissen in Vorlagen, Traces und QWEN.md.
Rollen des Production-Prozesses: Verifizierer (Verifier) — stimmt über /review, separate Sitzung, Sub-Agent oder Skript ab. Implementierer (Implementor) — stimmt über Qwen Code im Modus default/auto-edit nach genehmigtem Plan ab. Safety — stimmt mit Veto bei critical_risk über separate Sitzung oder Blast-Radius-Prüfungsskript ab. Koordinator (Coordinator) — Non-Voting-Protokollist, implementiert durch Mensch, CI oder externen Orchestrator.
Datei-Arbitrage (Tribunal): Kein integrierter Befehl; Kombination aus /review, Skripten, Berichten und Regeln in validation.md zur Beilegung von Konflikten bei gleichzeitiger Bearbeitung.
Spezifikations-Gateway (Spec CI): GitHub Actions oder lokale Skripte, die qwen -p nur als Hilfsschicht verwenden können, aber die Hauptprüfung ist deterministischer Code.
Budget-Hüter (Budget Keeper): Externer Dienst oder Skript; Qwen Code verwaltet nicht selbst die tägliche Modell-Tier-Quoten.
Praktische Übungen: Titel: Klassifizierung von Prozessen nach Reifegraden
Aufgabe: Fünf Production-Prozesse sind gegeben: (1) Start von /plan zur Aufgabenzerlegung, (2) automatische Abdeckungsprüfung durch Tests über das Skript check_coverage.py, (3) Integration mit Kubernetes für Rolling Deployment, (4) Verwendung von /review für Code Review, (5) benutzerdefinierter Befehl /sdd:validate zur Spezifikationsprüfung. Klassifizieren Sie jeden Prozess nach der kanonischen Skala (Standard, Empfehlung, Frontier). Begründen Sie die Entscheidung für jeden Fall.
Lösung: 1) Standard — /plan ist ein integrierter Qwen Code-Befehl, erfordert keine zusätzlichen Dateien. 2) Empfehlung — das Skript check_coverage.py erfordert die Erstellung einer Datei im Repository, reproduzierbar ohne Modell, nützlich bei Wiederholung. 3) Frontier — Kubernetes ist ein externer Orchestrator, erfordert Production-Infrastruktur, SRE-Prozesse. 4) Standard — /review ist in Qwen Code mit deterministischen Prüfungen integriert. 5) Empfehlung — der benutzerdefinierte Befehl erfordert die Erstellung von .qwen/commands/sdd/validate.md, gehört zur Projektschicht. Entscheidendes Kriterium: Sind Dateien im Repository (Empfehlung) oder externe Dienste (Frontier) erforderlich.
Schwierigkeit: Anfänger
Titel: Erstellung eines benutzerdefinierten clarify-Befehls
Aufgabe: Im ersten Band wurde der Befehl /clarify zur Klärung von Anforderungen vor der Planung verwendet. Er ist nicht in Qwen Code integriert. Erstellen Sie die Dateistruktur und den Inhalt der Markdown-Datei für den benutzerdefinierten Befehl /sdd:clarify, der das Verhalten aus dem ersten Band reproduziert. Definieren Sie den Stoppvertrag und Regeln für die Verwendung von {{args}} und @specs/.
Lösung: Struktur: .qwen/commands/sdd/clarify.md. Der Dateiinhalt sollte enthalten: (1) Beschreibung des Zwecks — Klärung mehrdeutiger Anforderungen vor der Planung; (2) Vorlage mit {{args}} zur Kontextweitergabe; (3) Verweise auf @specs/ zum Laden von Spezifikationen; (4) Stoppregeln — der Befehl stoppt, wenn alle Mehrdeutigkeiten geklärt sind und eine Liste der geklärten Anforderungen erstellt wurde; (5) Anweisung, nicht mit der Planung oder Codebearbeitung zu beginnen. Aufrufbeispiel: /sdd:clarify 'Anforderungen an die Authentifizierungs-API'. Stoppvertrag: Beenden beim Erreichen des Zustands 'alle Fragen geklärt, Antworten im Listenformat dokumentiert'.
Schwierigkeit: Mittelstufe
Titel: Entwurf eines MCP-Servers für sichere Integration
Aufgabe: Das Team nutzt Grafana für Monitoring und PagerDuty für Alerting. Qwen Code muss Zugriff auf diese Dienste erhalten, ohne sie in uneingeschränkte Shell-Befehle zu verwandeln. Entwerfen Sie die Architektur eines MCP-Servers mit Tools-Zulassungsliste, definieren Sie Bestätigungsbedingungen für schreibende Operationen und den Geheimnisschutzmechanismus.
Lösung: MCP-Server-Architektur: (1) Nur-Lesen-Tools: grafana_query_metrics (PromQL-Abfragen), grafana_list_dashboards, pagerduty_list_incidents, pagerduty_get_incident_details — für Triage und Prüfung, ohne Bestätigung. (2) Schreibende Tools mit expliziter Bestätigung: pagerduty_acknowledge_incident (erfordert Bestätigung mit Angabe des Grundes), pagerduty_escalate_incident (erfordert doppelte Bestätigung). (3) Rollback-Bedingungen: für pagerduty_create_incident — Prüfung auf Pflichtfelder, Limit von 5 Incidents pro Stunde, automatische Stornierung bei 5xx-Fehler. (4) Geheimnisschutz: API-Schlüssel werden in Umgebungsvariablen des Servers gespeichert, nicht in Vorlagen weitergegeben; QWEN.md enthält keine Endpoint-Adressen mit Credentials;Logging von Anfragen maskiert Autorisierungsheader. (5) Konfiguration: qwen mcp add pagerduty-ops --url http://localhost:3001/sse --tools allowlist:grafana_query_metrics,grafana_list_dashboards,pagerduty_list_incidents,pagerduty_acknowledge_incident.
Schwierigkeit: Fortgeschritten
Titel: Konfiguration von Hooks für Guardrails
Aufgabe: Es müssen Guardrails für folgendes Szenario implementiert werden: (1) Ausführung von Shell-Befehlen verbieten, die rm -rf / oder DROP TABLE enthalten, (2) alle Zugriffe auf externe APIs vor der/Ausführung protokollieren, (3) Sitzungskontext vor Speicherkompaktierung archivieren. Wählen Sie geeignete offizielle Qwen Code-Ereignisse und beschreiben Sie die Hook-Konfiguration.
Lösung: (1) PreToolUse — Prüfung der tool-Argumente von shell_execute auf verbotene Muster: rm -rf /, DROP TABLE, TRUNCATE. Bei Übereinstimmung — Ausführung abbrechen mit Benachrichtigung des Nutzers. (2) PreToolUse oder PostToolUse — Protokollierung von Zugriffen auf externe APIs: Erfassung von Endpoint, Methode, Zeitstempel im strukturierten Log. (3) PreCompact — Archivierung des aktuellen Sitzungskontexts in Datei .qwen/archive/sessions/<timestamp>.md vor Speicherkompaktierung. Wichtig: Verwenden Sie genaue Ereignisnamen aus der Dokumentation — PreToolUse, PostToolUse, PreCompact — nicht Varianten wie pretooluse. Die Hook-Konfiguration erfordert Abgleich mit der aktuellen Qwen Code-Dokumentation zu Format und Parametern.
Schwierigkeit: Mittelstufe
Titel: Verantwortungstrennung in Spec CI
Aufgabe: Das Team möchte Spezifikationen bei jedem PR automatisch prüfen. Zwei Ansätze werden diskutiert: (A) qwen -p 'prüfe die Spezifikation' als Hauptmechanismus verwenden, (B) ein Skript validate_schema.py mit deterministischen Prüfungen erstellen und qwen -p nur zur Berichterstellung verwenden. Wenden Sie die Prinzipien von Anhang B an, um den richtigen Ansatz zu wählen, und beschreiben Sie die Architektur.
Lösung: Der richtige Ansatz ist — (B), entspricht der Schicht Empfehlung/Frontier. Architektur: (1) Hauptprüfung — Skript validate_schema.py, das JSON Schema, Referenzintegrität, Duplikat-Identifikatoren prüft. Der grüne CI-Status hängt nur vom Prüfcode ab. (2) Hilfsschicht — qwen -p 'generiere lesbaren Bericht zu den Ergebnissen von validate_schema.py', wird nur zur Ausgabeformatierung verwendet, beeinflusst nicht pass/fail. (3) Integration in GitHub Actions: Schritt 'Validate Schema' startet python scripts/spec_ci/validate_schema.py --strict; Schritt 'Generate Report' verwendet optional qwen -p zur Verbesserung der Lesbarkeit. (4) Prinzip: Der grüne Status sollte nicht von der Überzeugungskraft der Modellantwort abhängen — dies ist eine zentrale Anforderung von Anhang B für Projektskripte.
Schwierigkeit: Mittelstufe
Fallstudien: Titel: Migration eines Entwicklungsteams von impliziten Annahmen zu expliziter Qwen Code-Architektur
Szenario: Ein Team von 12 Entwicklern nutzte Qwen Code sechs Monate lang für die Entwicklung einer Microservice-Plattform. Die Teammitglieder verwendeten informell Befehle wie '/clarify', '/specify', '/tasks' in der Annahme, sie seien in Qwen Code integriert. Beim Onboarding neuer Entwickler entstanden ständige Konflikte: Befehle funktionierten in neuen Projekten nicht, das Verhalten unterschied sich zwischen Sitzungen, Prozesse konnten nicht in CI reproduziert werden.
Herausforderung: Implizite Annahmen über die Integration von Befehlen führten zu: (1) Prozessfragmentierung — jeder Entwickler hatte seine eigene Vorstellung von den Schritten; (2) Unmöglichkeit der Reproduktion in CI — Befehle, die im interaktiven Modus funktionierten, fehlten im Headless-Modus; (3) fehlende Dokumentation — Stoppverträge waren mündlich; (4) Risiken bei der Skalierung — neue Teammitglieder verbrachten Wochen damit, herauszufinden 'wie es bei uns funktioniert'.
Lösung: Das Team führte einen Audit nach der Methodik von Anhang B durch. Schritt 1: Klassifizierung aller verwendeten Prozesse nach der kanonischen Skala. Es stellte sich heraus, dass /plan und /review Standard sind, und /clarify, /specify, /tasks, /validate die Erstellung benutzerdefinierter Befehle erfordern. Schritt 2: Erstellung der Struktur .qwen/commands/sdd/ mit Namespace 'sdd' (Software Design Document), einschließlich clarify.md, specify.md, tasks.md, validate.md, constitution.md. Jede Datei enthielt einen expliziten Stoppvertrag, Vorlagen mit {{args}}, Verweise auf @specs/. Schritt 3: Verlagerung deterministischer Prüfungen in Projektskripte: validate_schema.py, check_coverage.py, mutate_specs.py. Schritt 4: Konfiguration von Spec CI in GitHub Actions mit qwen -p nur für Berichte. Schritt 5: Dokumentation der Grenzen: in der README explizit angegeben, welche Befehle integriert, welche projektbezogen sind.
Ergebnis: Nach 3 Wochen: Onboarding-Zeit von 2 Wochen auf 2 Tage reduziert; 100% Reproduzierbarkeit von CI-Prüfungen; einheitliche Prozesssprache zwischen Teams; Möglichkeit der Versionierung von Befehlen über Git. Das Team konnte auf 20 Entwickler skalieren, ohne dass Prozesse degradierten. Die wichtigste Denkänderung: Der Übergang von 'Qwen Code kann alles' zu 'wir entwerfen explizit, was Qwen Code tut und was unser Projekt tut'.
Gewonnene Erkenntnisse: Implizite Annahmen über die Integration — Hauptquelle der Prozessfragmentierung in Teams
Die kanonische Skala ist ein Kommunikationsinstrument, nicht nur ein architektonisches; sie synchronisiert die Erwartungen zwischen Entwicklern
Benutzerdefinierte Befehle mit expliziten Stoppverträgen sind teurer in der Erstellung, aber kostenlos bei der Skalierung
Der grüne CI-Status sollte vom Code abhängen, nicht vom Modell — das ist schwer zu akzeptieren, aber kritisch für Production
Verwandte Konzepte: Kanonische Skala der drei Reifegrade
Benutzerdefinierte Befehle
Projektskripte
Spezifikations-Gateway (Spec CI)
Titel: Integration von SRE-Prozessen über MCP-Server für ein FinTech-Unternehmen
Szenario: Ein FinTech-Unternehmen mit regulatorischen Anforderungen nutzte Qwen Code für die Entwicklung eines Payment-Gateways. Eine Integration mit PagerDuty für Incident-Eskalation, Grafana zur Prüfung von Metriken vor dem Deployment und einer internen API für Audit war erforderlich. Direkte Shell-Befehle mit API-Schlüsseln in Vorlagen schufen kritische Sicherheitsrisiken.
Herausforderung: Regulatorische Anforderungen: (1) alle Aktionen mit Production-Systemen müssen auditierbar sein; (-2) API-Schlüssel dürfen nicht in Logs und Vorlagen gelangen; (3) Incident-Eskalation erfordert doppelte Bestätigung; (4) Rollback von Änderungen muss innerhalb von 5 Minuten möglich sein. Gleichzeitig wollten Entwickler Qwen Code für operative Aufgaben nutzen, ohne den Kontext zu wechseln.
Lösung: Architektur nach den Prinzipien von Anhang B (Frontier-Schicht): (1) MCP-Server 'ops-bridge' in Go, innerhalb VPC deployed, mit Zulassungsliste von 8 Tools. Nur-Lesen: grafana_query_metrics, pagerduty_list_incidents, pagerduty_get_incident_details, audit_log_query. Schreibend mit Bestätigung: pagerduty_acknowledge_incident (erfordert reason ≥ 20 Zeichen), pagerduty_escalate_incident (erfordert approval_code aus SMS), audit_log_append (nur strukturierte Einträge). (2) Verbot von Shell-Zugriff auf Production über Hook PreToolUse — Blockierung beliebiger !command, die kubectl, ssh, curl zu Production-Domains enthalten. (3) Geheimnisse: API-Schlüssel in HashiCorp Vault, MCP-Server authentifiziert sich über mTLS; QWEN.md enthält nur die Beschreibung der Tools, niemals Endpoint-URLs mit Credentials. (4) Hook PostToolUse protokolliert alle Aufrufe in strukturierten Audit-Trail. (5) Budgetierung über externen Budget Keeper — separater Dienst, der die Kosten von Modellaufrufen verfolgt und bei Überschreitung des täglichen Kontingents blockiert.
Ergebnis: Bestanden den Audit der Aufsichtsbehörde ohne Beanstandungen bezüglich KI-Tools. Reaktionszeit auf Incidents um 40% verkürzt durch Metrik-Zugriff aus Qwen Code. Null Incidents mit Credential-Leakage. Modellbudget kontrollierbar und vorhersehbar. Das Team erhielt ein 'Einzelnes Fenster' für Entwicklung und Betrieb ohne Verletzung der Security Boundary.
Gewonnene Erkenntnisse: Production-API über MCP mit Allowlist — der einzige akzeptable Weg für regulierte Branchen
Hooks PreToolUse/PostToolUse — kritisch wichtig für Defense in Depth, erfordern aber genaue Ereignisnamen aus der Dokumentation
Externer Budget Keeper ist notwendig, da Qwen Code keine täglichen Kontingente verwaltet — das ist per Definition Frontier-Schicht
QWEN.md darf niemals sensible Daten enthalten, auch nicht verschlüsselt
Verwandte Konzepte: MCP-Server und externe APIs
Hooks
Budget-Hüter (Budget Keeper)
Frontier — Reifegrad
Lerntipps: Erstellen Sie eine physische oder digitale 'Entscheidungskarte': Stellen Sie für jeden Production-Prozess die Frage 'Kann dies mit einem integrierten Qwen Code-Befehl erreicht werden?' → wenn ja, ist es Standard; wenn Dateien im Projekt erforderlich sind, aber keine externen Dienste — Empfehlung; wenn Kubernetes, Grafana, externe APIs benötigt werden — Frontier
Üben Sie in einem echten Repository: Erstellen Sie .qwen/commands/demo/ mit 2-3 benutzerdefinierten Befehlen, rufen Sie sie auf, prüfen Sie die Reproduzierbarkeit nach git clone in ein anderes Verzeichnis
Zum Verständnis von Hooks: Richten Sie ein Testprojekt ein, konfigurieren Sie Logging von PreToolUse und PostToolUse, analysieren Sie, welche Ereignisse bei verschiedenen Aktionen generiert werden — das gibt Intuition über Abfangpunkte
MCP durch die Sicherheitsbrille betrachten: Dokumentieren Sie für jedes Tool, das Sie hinzufügen, explizit 'was das Schlimmste passieren kann' und wie Allowlist/Bestätigung dies verhindert
Peer-Learning: Eine Person entwirft den Prozess als 'alles in Qwen Code integriert', die andere als 'alles externe Skripte'; wenden Sie dann die kanonische Skala zur Synthese an — das trainiert architektonisches Denken
Führen Sie ein 'Grenz-Tagebuch': Notieren Sie Fälle, in denen Sie oder Kollegen eine Integration des Befehls annahmen, aber er projektbezogen war — das ist ein typischer Fehler, dessen Muster sich wiederholen
Für Headless-Modus (qwen -p): Richten Sie eine minimale CI-Pipeline in GitHub Actions oder GitLab CI ein, um den Unterschied zwischen interaktiver Sitzung und automatisierter Ausführung zu spüren
Studieren Sie die Verbindung zwischen den Rollen des zweiten Bandes (Verifizierer, Implementierer, Safety, Koordinator) und den konkreten Qwen Code-Mechanismen — erstellen Sie eine Korrespondenztabelle für Ihr Projekt
Zusätzliche Ressourcen: Qwen Code-Dokumentation — Befehle: https://qwenlm.github.io/qwen-code-docs/en/users/features/commands/
Qwen Code-Dokumentation — Headless-Modus: https://qwenlm.github.io/qwen-code-docs/en/users/features/headless/ Qwen Code-Dokumentation — Hooks: https://qwenlm.github.io/qwen-code-docs/en/users/features/hooks/ Qwen Code-Dokumentation — Skills: https://qwenlm.github.io/qwen-code-docs/en/users/features/skills/ Qwen Code-Dokumentation — Speicher: https://qwenlm.github.io/qwen-code-docs/en/users/features/memory/ Qwen Code-Dokumentation — MCP: https://qwenlm.github.io/qwen-code-docs/en/users/features/mcp/ Qwen Code-Dokumentation — Genehmigungsmodus: https://qwenlm.github.io/qwen-code-docs/en/users/features/approval-mode/ Qwen Code-Dokumentation — Code-Review: https://qwenlm.github.io/qwen-code-docs/en/users/features/code-review/ GitHub Spec Kit: https://github.com/github/spec-kit AWS Kiro-Dokumentationsübersicht: https://aws.amazon.com/documentation-overview/kiro/ OWASP Top 10 für LLM-Anwendungen: https://owasp.org/www-project-top-10-for-large-language-model-applications/ Google SRE-Buch: https://sre.google/sre-book/ Goodharts Gesetz (Wikipedia): https://en.wikipedia.org/wiki/Goodhart%27s_law MCP-Protokollspezifikation (Model Context Protocol): Es wird empfohlen, die offizielle Anthropic-Spezifikation für ein tiefes Verständnis der MCP-Server-Architektur zu studieren
Zusammenfassung: Anhang B etabliert eine architektonische Grenze zwischen den integrierten Funktionen von Qwen Code und den Prozessen, die Teams selbst implementieren müssen. Das zentrale Instrument ist die kanonische Skala mit drei Reifegraden (Standard, Empfehlung, Frontier), die Erwartungen und Implementierungsschicht definiert. Integrierte Befehle (/plan, /review, /skills, /memory, /mcp, @path, !command, qwen -p) werden wie vorhanden verwendet. Benutzerdefinierte Befehle erfordern die Erstellung von .qwen/commands/<namespace>/<command>.md mit expliziten Stoppverträgen. Projektskripte gewährleisten Reproduzierbarkeit unabhängig vom Modell. Hooks implementieren Guardrails über offizielle Qwen Code-Ereignisse. MCP-Server mit Tools-Zulassungsliste integrieren externe APIs sicher. Das Verständnis dieser Grenze verhindert den Fehler impliziter Annahmen über die Integration, gewährleistet die Skalierbarkeit von Prozessen und macht die Production-Nutzung von Qwen Code vorhersehbar und auditierbar.