Befehle

Dieses Dokument beschreibt alle von Qwen Code unterstützten Befehle, die dir helfen, Sitzungen effizient zu verwalten, die Benutzeroberfläche anzupassen und das Verhalten zu steuern.

Qwen Code-Befehle werden über bestimmte Präfixe ausgelöst und fallen in drei Kategorien:

1. Slash-Befehle (/)

Slash-Befehle werden verwendet, um Qwen Code-Sitzungen, die Benutzeroberfläche und das Grundverhalten zu verwalten.

1.1 Sitzungs- und Projektverwaltung

Diese Befehle helfen dir, den Arbeitsfortschritt zu speichern, wiederherzustellen und zusammenzufassen.

1.2 Benutzeroberflächen- und Workspace-Steuerung

Befehle zum Anpassen der Benutzeroberfläche und der Arbeitsumgebung.

1.3 Spracheinstellungen

Befehle speziell zur Steuerung der Sprachen für Benutzeroberfläche und Ausgabe.

• Verfügbare integrierte UI-Sprachen: zh-CN (Vereinfachtes Chinesisch), en-US (Englisch), ru-RU (Russisch), de-DE (Deutsch), ja-JP (Japanisch), pt-BR (Portugiesisch - Brasilien), fr-FR (Französisch), ca-ES (Katalanisch)
• Beispiele für Ausgabesprachen: Chinese, English, Japanese usw.

1.4 Tool- und Modellverwaltung

Befehle zur Verwaltung von KI-Tools und -Modellen.

1.5 Integrierte Skills

Diese Befehle rufen gebündelte Skills auf, die spezialisierte Workflows bereitstellen.

Siehe Code Review für die vollständige /review-Dokumentation.

1.6 Zwischenfrage (/btw)

Der Befehl /btw ermöglicht es dir, schnelle Zwischenfragen zu stellen, ohne den Hauptkonversationsfluss zu unterbrechen oder zu beeinträchtigen.

Funktionsweise:

• Die Zwischenfrage wird als separater API-Call mit aktuellem Konversationskontext (bis zu den letzten 20 Nachrichten) gesendet
• Die Antwort wird über dem Composer angezeigt – du kannst während des Wartens weiterschreiben
• Die Hauptkonversation wird nicht blockiert – sie läuft unabhängig weiter
• Die Antwort auf die Zwischenfrage wird nicht Teil des Hauptkonversationsverlaufs
• Antworten werden mit voller Markdown-Unterstützung gerendert (Codeblöcke, Listen, Tabellen usw.)

Tastenkürzel (Interaktiver Modus):

Beispiel:

(While the main conversation is about refactoring code)

> /btw What's the difference between let and var in JavaScript?

  ╭──────────────────────────────────────────╮
  │ /btw What's the difference between let   │
  │     and var in JavaScript?               │
  │                                          │
  │ + Answering...                           │
  │ Press Escape, Ctrl+C, or Ctrl+D to cancel│
  ╰──────────────────────────────────────────╯
  > (Composer remains active — keep typing)

(After the answer arrives)

  ╭──────────────────────────────────────────╮
  │ /btw What's the difference between let   │
  │     and var in JavaScript?               │
  │                                          │
  │ `let` is block-scoped, while `var` is    │
  │ function-scoped. `let` was introduced    │
  │ in ES6 and doesn't hoist the same way.   │
  │                                          │
  │ Press Space, Enter, or Escape to dismiss │
  ╰──────────────────────────────────────────╯
  > (Composer still active)

Unterstützte Ausführungsmodi:

1.7 Second Opinion (/advisor)

Der Befehl /advisor führt eine unabhängige, schreibgeschützte Überprüfung der bisherigen Konversation durch und gibt eine strukturierte Second Opinion zurück – ohne die Aufgabe auszuführen oder die Hauptkonversation zu unterbrechen.

Funktionsweise:

• Die Überprüfung wird als separater, einstufiger API-Aufruf mit aktuellem Konversationskontext gesendet (bis zu den letzten 40 Nachrichten)
• Das Reviewer-Modell kann keine Tools ausführen – Tools werden auf Request-Ebene entfernt (derselbe Mechanismus wie bei /btw), sodass die Überprüfung niemals Code schreibt oder Befehle ausführt; jeder Anspruch muss im sichtbaren Transkript begründet sein
• Die Hauptkonversation wird nicht unterbrochen; die Überprüfung wird nur dir angezeigt
• Die Überprüfung wird als gerahmter Markdown-Block mit vier festen Abschnitten dargestellt – Verdict, Risks, Missing evidence und Recommendation – unter einem /advisor · <model>-Header, der das aufgelöste Reviewer-Modell nennt
• Im Gegensatz zu /btw, das Fire-and-Forget ist und die Sitzung benutzbar lässt, blockiert /advisor die Eingabe, bis die Überprüfung zurückkehrt; über ein volles Kontextfenster mit einem starken Reviewer kann dies zehn Sekunden dauern
• Standardmäßig wird das Hauptmodell verwendet; setze advisorModel, um die Überprüfung an ein anderes (typischerweise stärkeres) Modell weiterzuleiten – das aktuelle Transkript wird an dieses Modell gesendet, auch wenn es einen anderen Provider verwendet

Beispiel:

> /advisor is my fix for the null check actually correct?

  Consulting advisor...

  ╭──────────────────────────────────────────────────────╮
  │ /advisor · qwen3-max                                 │
  │                                                      │
  │ Verdict                                              │
  │ The approach is sound, but the edge case at line 42  │
  │ is unverified.                                       │
  │                                                      │
  │ Risks                                                │
  │  - The fix assumes the config is always loaded; a    │
  │    startup race could leave it null.                 │
  │                                                      │
  │ Missing evidence                                     │
  │  - No test exercises the null-config path in the     │
  │    visible transcript.                               │
  │                                                      │
  │ Recommendation                                       │
  │ Add a focused unit test for the null-config branch   │
  │ before merging.                                      │
  ╰──────────────────────────────────────────────────────╯

Die Überprüfung wird in einem gerahmten Block gerendert, dessen Header das aufgelöste Reviewer-Modell nennt. Ein unbekanntes advisorModel wird nicht im Voraus validiert – wenn der Provider es ablehnt, meldet /advisor den Fehler, also überprüfe den Modellnamen; nur nicht auflösbare Alias-Selektoren (z. B. fast ohne konfiguriertes Fast-Modell) fallen auf das Hauptmodell zurück. Advisor-Anfragen verwenden keine konfigurierten Modell-Fallbacks.

Unterstützte Ausführungsmodi:

1.8 Session Recap (/recap)

Der Befehl /recap erstellt eine kurze “Wo du stehengeblieben bist”-Zusammenfassung der aktuellen Session, damit du eine alte Konversation fortsetzen kannst, ohne seitenweise durch den Verlauf scrollen zu müssen.

Funktionsweise:

• Verwendet das konfigurierte Fast Model (Einstellung fastModel), falls verfügbar, und fällt andernfalls auf das Haupt-Sessionsmodell zurück. Ein kleines, günstiges Modell reicht für ein Recap völlig aus.
• Die aktuelle Konversation (bis zu 30 Nachrichten, nur Text – Tool-Calls und Tool-Antworten werden herausgefiltert) wird mit einem strikten System-Prompt an das Modell gesendet.
• Das Recap wird in gedimmter Farbe mit einem ❯-Präfix gerendert, damit es sich von echten Assistant-Antworten abhebt.
• Lehnt mit einem Inline-Fehler ab, wenn ein Model-Turn gerade läuft oder ein anderer Befehl verarbeitet wird. Wenn keine nutzbare Konversation vorhanden ist oder die zugrunde liegende Generierung fehlschlägt, zeigt /recap eine kurze Info-Nachricht anstelle eines Recaps – der manuelle Befehl antwortet immer mit irgendetwas.

Auto-Trigger bei Rückkehr aus Abwesenheit:

Wenn das Terminal für mehr als 5 Minuten den Fokus verliert und wieder fokussiert wird, wird automatisch ein Recap generiert und angezeigt (nur, wenn gerade keine Modellantwort läuft; andernfalls wartet es, bis der aktuelle Turn abgeschlossen ist, und wird dann ausgelöst). Im Gegensatz zum manuellen Befehl ist der Auto-Trigger bei Fehlern völlig still: Wenn die Generierung fehlschlägt oder es nichts zusammenzufassen gibt, wird keine Nachricht zum Verlauf hinzugefügt. Gesteuert wird dies durch die Einstellung general.showSessionRecap (Standard: false); der manuelle Befehl /recap funktioniert immer, unabhängig von dieser Einstellung.

Beispiel:

> /recap

❯ Refactoring loopDetectionService.ts to address long-session OOM caused by
  unbounded streamContentHistory and contentStats. The next step is to
  implement option B (LRU sliding window with FNV-1a) pending confirmation.

1.9 Diff Viewer (/diff)

Der Befehl /diff öffnet einen interaktiven Diff-Viewer, der uncommitted Änderungen und Diffs pro Turn anzeigt. Verwende ←/→, um zwischen dem aktuellen Git-Diff und einzelnen Konversations-Turns zu wechseln, ↑/↓, um durch Dateien zu navigieren, und Enter, um Inline-Diffs anzuzeigen.

Funktionsweise:

Im interaktiven Modus öffnet /diff einen Dialog mit einem Source Picker am oberen Rand:

• Current – Working Tree vs. HEAD (git diff HEAD). Zeigt alle uncommitted Änderungen an, einschließlich staged, unstaged und untracked Dateien.
• T1, T2, T3, … – Diffs pro Turn, ein Tab pro Model-Turn, der Dateien geändert hat. Die neuesten Turns werden zuerst angezeigt. Jeder Tab zeigt eine Vorschau des ursprünglichen Prompts als Kontext.

Die Dateiliste zeigt dateispezifische Statistiken (hinzugefügte/entfernte Zeilen) mit Tags für spezielle Zustände (new, deleted, untracked, binary, truncated, oversized). Drücke Enter auf einer Datei, um ihren Inline-Diff mit syntaxhervorgehobenen Hunks anzuzeigen.

Diffs pro Turn erfordern, dass File Checkpointing aktiviert ist (im interaktiven Modus standardmäßig eingeschaltet). Wenn File Checkpointing deaktiviert ist, ist nur die Quelle “Current” verfügbar.

Tastenkürzel:

Beispiel:

┌ /diff · Turn 3 "refactor the auth middleware" ──── 3 files +45 -12 ┐
│                                                                     │
│ ◀ Current · T3 · T2 · T1 ▶                                         │
│                                                                     │
│ › src/utils/parser.ts                              +30 -8           │
│   src/utils/parser.test.ts                         +12 -2           │
│   README.md                                        +3 -2            │
│                                                                     │
│ ←/→ source · ↑/↓ file · Enter view · Esc close                     │
└─────────────────────────────────────────────────────────────────────┘

Nicht-interaktiver Modus:

In Headless- (--prompt) oder nicht-interaktiven Kontexten gibt /diff eine Plain-Text-Zusammenfassung des Working Tree vs. HEAD aus. Die Navigation pro Turn ist nicht verfügbar.

3 files changed, +45 / -12
  +30  -8  src/utils/parser.ts
  +12  -2  src/utils/parser.test.ts
   +3  -2  README.md

Web Shell: In der Web-Shell-UI (qwen serve) öffnet /diff einen grafischen Diff-Dialog. Eine Tab-Leiste oben ermöglicht das Umschalten zwischen der Changes-Ansicht und der History-Ansicht (/log).

History Viewer (/log) — nur Web Shell

Der Befehl /log öffnet einen Commit-Verlauf-Browser für den aktuellen Workspace. Er ist nur in der Web-Shell-UI verfügbar; die CLI/TUI hat diesen Befehl nicht.

Funktionsweise:

/log öffnet einen Dialog, der Commits in umgekehrter chronologischer Reihenfolge auflistet (neueste zuerst). Jede Zeile zeigt:

• Kurze SHA (Monospace, mit Kopier-Button für die volle SHA)
• Commit-Subject (einzeilig)
• Autorname und relative Zeit (z. B. “2h ago”)
• Branch/Tag-Ref-Labels, falls vorhanden
• Ein Merge-Icon (⎇) für Merge-Commits

Klicke auf eine Commit-Zeile, um ihre Details on demand zu erweitern:

• Vollständiger Commit-Message-Body
• Dateiänderungsstatistiken (geänderte Dateien, hinzugefügte/entfernte Zeilen, Aufschlüsselung pro Datei)

Verwende Load more unten, um die nächste Seite mit Commits abzurufen (50 pro Seite).

Beispiel:

┌─ History ──────────────────────────── 50 commits ─ ✕ ┐
│                                                       │
│  a1b2c3d  feat(cli): add --json flag        2h ago   │
│           wenshao                                    │
│                                                       │
│  e4f5g6h  fix(core): handle null config     5h ago   │
│           dev · main  v1.2.0                         │
│                                                       │
│ ▼ 789abcd  refactor: simplify parser        1d ago   │
│   ┌─────────────────────────────────────────────┐    │
│   │  Broke the monolithic parse() into smaller  │    │
│   │  functions for readability.                 │    │
│   │                                             │    │
│   │  3 files · +45 −12                          │    │
│   │   +30 −8   src/parser.ts                    │    │
│   │   +10 −2   src/utils.ts                     │    │
│   │   +5  −2   test/parser.test.ts              │    │
│   └─────────────────────────────────────────────┘    │
│                                                       │
│              [ Load more ]                            │
└───────────────────────────────────────────────────────┘

1.10 Informationen, Einstellungen und Hilfe

Befehle zum Abrufen von Informationen und Vornehmen von Systemeinstellungen.

1.11 Häufige Shortcuts

1.12 Authentifizierungs-Befehle

Verwende /auth innerhalb einer Qwen Code-Sitzung, um die Authentifizierung zu konfigurieren. Verwende /doctor, um den aktuellen Authentifizierungs- und Umgebungsstatus zu überprüfen.

2. @-Befehle (Dateien einbinden)

@-Befehle werden verwendet, um lokale Datei- oder Verzeichnisinhalte schnell zur Konversation hinzuzufügen.

Hinweis: Leerzeichen in Pfaden müssen mit einem Backslash maskiert werden (z. B. @My\ Documents/file.txt)

3. Ausrufezeichen-Befehle (!) - Shell-Befehlsausführung

Ausrufezeichen-Befehle ermöglichen es dir, Systembefehle direkt in Qwen Code auszuführen.

Umgebungsvariablen: Über ! ausgeführte Befehle setzen die Umgebungsvariable QWEN_CODE=1.

4. Benutzerdefinierte Befehle

Speichere häufig verwendete Prompts als Shortcut-Befehle, um die Arbeitseffizienz zu steigern und Konsistenz sicherzustellen.

Schneller Überblick

Prioritätsregeln: Projekt-Befehle > Benutzer-Befehle (Projekt-Befehl wird verwendet, wenn die Namen identisch sind)

Regeln für die Befehlsbenennung

Zuordnungstabelle: Dateipfad zu Befehlsname

Benennungsregeln: Pfadtrennzeichen (/ oder \) wird in einen Doppelpunkt (:) umgewandelt

Markdown-Dateiformat-Spezifikation (Empfohlen)

Benutzerdefinierte Befehle verwenden Markdown-Dateien mit optionalem YAML-Frontmatter:

---
description: Optionale Beschreibung (wird in /help angezeigt)
---
 
Dein Prompt-Inhalt hier.
Verwende {{args}} für die Parameter-Injektion.

TOML-Dateiformat (Deprecated)

Parameterverarbeitungsmechanismus

1. Kontextbewusste Injektion ({{args}})

2. Standard-Parameterverarbeitung

🚀 Dynamische Content-Injektion

3. Shell-Befehlsausführung (!{...})

Beispiel: Git-Commit-Message-Generierung

---
description: Generiert eine Commit-Message basierend auf gestageten Änderungen
---
 
Bitte generiere eine Commit-Message basierend auf dem folgenden Diff:
 
```diff
!{git diff --staged}
```

4. Dateiinhalt-Injektion (@{...})

Beispiel: Code-Review-Befehl

---
description: Code-Review basierend auf Best Practices
---
 
Reviewe {{args}}, Referenzstandards:
 
@{docs/code-standards.md}

Praktisches Erstellungsbeispiel

Schrittetabelle für die Erstellung des “Pure Function Refactoring”-Befehls

---
description: Code in eine Pure Function refaktorisieren
---
 
Bitte analysiere den Code im aktuellen Kontext und refaktoriere ihn zu einer Pure Function.
Anforderungen:
 
1. Refaktorisierten Code bereitstellen
2. Wichtige Änderungen und die Implementierung der Pure-Function-Charakteristika erklären
3. Funktion unverändert lassen

Zusammenfassung der Best Practices für benutzerdefinierte Befehle

Empfehlungstabelle für das Befehlsdesign

Übersicht der Sicherheitsfunktionen

5. CLI-Subbefehle

Diese Befehle werden in der Shell als qwen <subcommand> ausgeführt, bevor eine interaktive Sitzung gestartet wird.

Sitzungsverwaltung

qwen sessions list

Zeigt deine letzten Qwen Code-Sitzungen mit Metadaten an.

Flags:

Menschenlesbare Ausgabe (Standard):

Eine Tabelle mit den Spalten: SESSION ID, STARTED (UTC-Zeitstempel), TITLE, BRANCH, PROMPT.

JSON-Ausgabe (--json):

Gibt JSON Lines auf stdout aus. Jede Zeile ist ein JSON-Objekt mit den folgenden Feldern:

sessionId, startTime, mtime, prompt, gitBranch, customTitle, titleSource, filePath, cwd

Der Hinweis “has more sessions” wird über stderr ausgegeben, sodass das Piping zu jq sicher bleibt.

Beispiele:

# Zeigt die letzten 20 Sitzungen an (Standard)
qwen sessions list
 
# Zeigt die letzten 50 Sitzungen an
qwen sessions list --limit 50
 
# Ausgabe als JSON für Skripte
qwen sessions list --json | jq .

qwen sessions ps

Zeigt die interaktiven Qwen Code-Sitzungen an, die gerade auf diesem Rechner laufen. sessions list durchsucht gespeicherte Transkripte (“woran habe ich gearbeitet”); dies durchsucht das Live-Prozess-Register (“was läuft gerade”). Zurückgelassene Records einer beendeten Sitzung werden beim Auffinden bereinigt. Headless-Sitzungen (qwen -p) registrieren sich nicht im Live-Prozess-Register und werden daher nicht angezeigt.

Flags:

Menschenlesbare Ausgabe (Standard):

Eine Tabelle mit den Spalten: NAME, PID, AGE, DIRECTORY.

JSON-Ausgabe (--json):

Gibt JSON Lines auf stdout aus, neueste Sitzung zuerst. Jede Zeile ist ein JSON-Objekt mit den folgenden Feldern:

schemaVersion, pid, procStart, pidNs, sessionId, cwd, name, startedAt,
qwenVersion

Nichts anderes wird auf stdout geschrieben – eine leere Auflistung gibt überhaupt nichts aus – daher ist qwen sessions ps --json | jq . sicher zum Skripten.

JSON-Ausgabe sind Rohdaten: Feldwerte werden genau wie aufgezeichnet ausgegeben, ohne Terminal-Sanitization. Behandle sie als Daten und sanitiere sie vor dem Rendern in einem Terminal.

Beispiele:

# Zeigt die anderen Live-Sitzungen
qwen sessions ps
 
# Welche Verzeichnisse sind gerade belegt?
# Hinweis: `jq -r` gibt den rohen aufgezeichneten Wert in deinem Terminal
# aus (siehe Rohdaten-Hinweis oben); pipe durch einen Sanitizer, wenn der
# Pfad nicht vertrauenswürdig ist.
qwen sessions ps --json | jq -r .cwd