Fehlerbehebung
Reproduziere mit einer Testnotiz und exaktem Anbieter, Modell und Aufgabeneinstellungen. Prüfe Fortschritt und Zielpfad. Trenne Authentifizierung, Generierung, Parsing und Dateischreiben; ein Verbindungstest prüft nicht den gesamten Workflow.
Überblick
Erfasse Notemd-/Obsidian-Version, Betriebssystem, Aktion, Protokoll, Modell und minimale Schritte. Starte während laufender Abbruchverarbeitung keine neue Aufgabe. Behalte Ausgaben und Wiederherstellung, bis ihre Herkunft geklärt ist.
Diagnose
Verbindungstest
Je nach Profil prüft Verbindung testen zunächst nur Modelle oder ein kleines Gespräch. Danach eine echte kleine Aufgabe für Modell und Ausgabeformat durchführen.
Fortschritt und Entwicklerdiagnosen
Fortschritt zeigt Zustand, Fehler und Ziele. API-Aktivität trennt ausstehende und abgeschlossene Versuche. API-Debugging nur bei Bedarf nutzen. Lange Anbieterdiagnosen können Kontingent verbrauchen und sollten gezielt eingesetzt werden.
Diagnosen enthalten möglicherweise Notiztext, Teilantworten, Endpunkte oder Zugangsdaten. Lokal prüfen und bereinigen; auch ein bereinigtes Anbieterprofil erfordert Metadatenprüfung.
Häufige Fehler
Fehlender oder ungültiger Schlüssel
401: passender Schlüssel ohne versehentliche Leerzeichen. 403: Konto-/Projektregeln, Modellberechtigung und Abrechnung. Wiederholungen reparieren keine Zugangsdaten.
Netzwerkfehler
Host, Port, Protokoll und Route vom Obsidian-Gerät prüfen. Ollama/LM Studio brauchen Server und verfügbares Modell. localhost bezeichnet dieses Gerät. Passendes Profil wählen; Transport-Fallbacks sind automatisch, kein UI-Schalter.
Quotenfehler 429
Parallelität reduzieren, Anfrage-/Tokenquoten und andere Clients desselben Schlüssels berücksichtigen. Wiederholungen können vorübergehende Fehler beheben, garantieren aber keine Quotenumgehung.
Modell nicht gefunden
Modellliste nutzen oder bekannten Modell-/Deploymentnamen eingeben. API-Version und Region prüfen; alte Voreinstellungen können upstream entfallen sein. Azure braucht Deploymentnamen, Ark möglicherweise endpoint ID.
Keine Links oder Konzepte
Tatsächliche Ausgabedatei, Quellmaterial, Antwortformat und aktivierten nichtleeren Konzeptordner prüfen. Eigenständige Extraktion ist standardmäßig titelbasiert ohne Rücklinks. Bei verlorenem Ausgabemarker mit Standardprompt vergleichen.
Ausgabe fehlt oder liegt anderswo
Gemeldeten Pfad lesen: _processed.md für Links, _<language>.md für Übersetzung, complete für Titelstapel. Gescheiterte Übersetzungsordner können auf Quelle zurückfallen. Vor Wiederholung Kollisionen und Rechte prüfen.
Abbruch hinterlässt Dateien
Fertige Schreibvorgänge bleiben; bereits akzeptierte Anfragen oder Schreibvorgänge können enden. Prüfe Ergebnisse je Datei und Konflikte vor Löschen oder vollständiger Wiederholung.
Diagramm oder nativer Export scheitert
Typen werden nacheinander erzeugt. Ein Fehler blockiert die anderen nicht. Abbrechen stoppt ausstehende Typen und erhält fertige Dateien. Exporte lassen sich in Vorschau oder Verlauf ohne neue Modellanfrage wiederholen. Bei einem Generierungsfehler muss dieser Typ neu erzeugt werden. v1/v2-Protokolle bleiben lesbar.
Diagramm-HTML enthält eine zoombare Grafik; strukturiertes Zusammenfassungs-HTML enthält Text, Struktur und Belege. Editierbares HTML/SVG bezeichnet einen Renderer, keinen Webeditor. Zum Bearbeiten dient die native Quelldatei. Präsentationsexporte einschließlich PPTX und MP4 behalten eigene Einstellungen und Abhängigkeiten. Diagrammhandbuch.
Fehler melden
- Kleine synthetische Notiz in eigenem Ordner verwenden.
- Exakte Versionen, Aktion, Modell, relevante Einstellungen sowie Soll/Ist erfassen.
- Bereinigte Fehler, Fortschritt und kleinstes reproduzierendes Artefakt beifügen; Geheimnisse und private Inhalte entfernen.
- Angeben, ob Einzeldatei und Standardprompt reproduzieren.
- GitHub Issues öffnen.
Ein Screenshot allein beweist selten Format- oder Abbruchfehler. Wenn möglich Quell-/Ausgabepaar oder genaue Sequenz angeben.