Optional · KI-Crashanalyse · Apple und Android · Schritt für Schritt
Im Bericht gibt es einen eigenen Reiter „KI-Crashreports“. Du fügst dort Absturzberichte aus Xcode, App Store Connect oder der Play Console ein, einzeln oder mehrere, und lässt sie von einer KI analysieren. Heraus kommt ein Ticket mit Ursache, Stelle im Code, technischer Lösung und Prüfschritten. Das Programm liest die Fakten selbst, ersetzt persönliche Daten vor dem Senden und erkennt Abstürze, die schon einmal analysiert wurden. Die KI darf nicht raten: Jede Aussage muss wörtlich im Material stehen, ein zweiter Durchgang prüft sie.
[Apple] Absturz beim Öffnen der Kassenübersicht Fehlernummer 3f9a1c2b4d5e · 27.10.2026 · Kasse Nord Umgebung EXC_BAD_ACCESS · SIGSEGV · 4.2.1 (812) · iOS 17.1 Ursache (Sicherheit mittel) Die Liste wird entpackt, bevor sie geladen ist. Stelle KassenView.swift:42 Beleg „0 KasseNord KassenView.body.getter“ Lösung Optional sicher entpacken, Ladezustand abwarten, Leerzustand anzeigen. Prüfer (KI) eingeschränkt · Zeile 12 nicht belegt KI · anthropic/claude-opus-5-5 · Fakten aus dem Parser
Warum?
Xcode, Crashlytics und die Play Console zeigen dir, dass und wie oft eine App abstürzt. Dann beginnt die eigentliche Arbeit: Report lesen, den richtigen Thread finden, die Datei suchen, den Kontext verstehen. Genau diesen Schritt nimmt dir die KI-Crashanalyse ab, so weit das Material es zulässt, und sagt offen, wenn es das nicht tut.
Fehlertyp, Signal, App- und OS-Version, oberste Frames, welche davon dein Code sind, ob der Report symbolisiert oder verschleiert ist. Das rechnet das Programm, nie die KI.
Jede Aussage zur Ursache braucht ein wörtliches Zitat aus Report, Anmerkung, Quelltext oder Rezensionen. Erfundene Zitate prüft das Programm heraus.
Ein zweiter KI-Durchgang prüft die Analyse gegen dasselbe Material. Er darf streichen und die Sicherheit senken, nie erhöhen.
Jeder Absturz bekommt eine Fehlernummer. Kommt derselbe Absturz von einem anderen Gerät, ist er ein Duplikat und kostet nichts.
Rezensionen der App mit Absturz-Stichworten gehen als Kontext mit. Das hat kein anderes Werkzeug, weil es die Rezensionen nicht hat.
Das Ergebnis als Ticket in die Zwischenablage für Jira oder Mail, zum Drucken oder als PDF, auch mehrere auf einmal.
Vor- und Nachteile
Die Qualität der Analyse hängt von zwei Dingen ab: vom Report und vom Modell. Mit einem symbolisierten Report, dem passenden Quelltext und einem starken Modell ist die Ursache bei den häufigen Absturzarten meist schnell gefunden. Ohne Symbole kann niemand die Ursache seriös bestimmen, auch keine KI.
Kein Ersatz für Crashlytics oder den Xcode Organizer. Die zeigen Häufigkeit und Verteilung. Die KI-Crashanalyse setzt danach an: Sie hilft beim Verstehen eines einzelnen Absturzes. Den Fix baut und testet weiter ein Mensch.
Schritt 1 · Einschalten
Die Crash-Analyse braucht eine eingeschaltete KI (ein Anbieter mit Schlüssel oder ein lokales Modell, siehe KI einrichten). Der Schalter ai.features.crashReports steht dann von selbst auf an. Ist die KI aus, erscheint der Reiter nie, egal wie der Schalter steht.
./ratings.sh admin oder Kurzmenü 7. Die Seite läuft nur auf deinem Rechner (mehr zur Einrichtung).
Unter „Was die KI tun soll“ den Haken „KI-Crashreports im Bericht“ prüfen. Darunter erscheint der Kasten „KI-Crashreports“.
Die Seite prüft alles mit den Regeln der Skripte, sichert die alte Fassung und sagt dir, welche laufenden Skripte neu starten müssen.
Schritt 2 · Das Modell wählen
Je Anbieter gibt es drei Modelle, eines je KI-Werkzeug. Gewählt wird nur in der Einrichtung im Browser, im Bericht kann niemand das Modell ändern. Der Reiter zeigt oben, welches gerade gilt.
Viele Rezensionen in Stapeln, jeden Tag. Ein günstiges, schnelles Modell reicht meist.
Einzelne Fragen an die Rezensionen. Leer heißt: wie die Analyse.
Stacktraces und Code richtig lesen ist die schwerste Aufgabe. Hier das stärkste verfügbare Modell. Leer heißt: wie die Analyse.
Lokal geht auch. Mit dem Anbieter local (Ollama, LM Studio) bleibt alles auf deinem Rechner, auch der Quelltext. Kleine lokale Modelle lesen Stacktraces aber deutlich schwächer; der Prüfdurchgang fängt das zum Teil ab, ersetzt es nicht.
Schritt 3 · Sicherheit festlegen
Im Kasten „KI-Crashreports“ der Einrichtung stehen drei Schalter. Sie gelten für alle, die den Bericht benutzen; im Bericht selbst lassen sie sich nicht ändern.
Aus: Es verlässt nie Quelltext den Rechner, das Feld „Projektordner“ fehlt im Formular. An: nur aus dem Projektordner, den du in der Anfrage angibst, und nur die Dateien, die der Stacktrace nennt.
Aus: Nur Report und Anmerkung gehen mit. An: bis zu zehn Rezensionen der zugeordneten App mit Absturz-Stichworten.
Aus: Tabelle, Anfrage und Ticket zeigen den Ordner nur mit Namen („…/kassen-app“). Ein voller Pfad enthält oft den Benutzernamen. Beim Bearbeiten bleibt der Ordner, solange das Feld leer bleibt.
Nicht in der Einrichtung: Du gibst den Ordner in jeder Anfrage an, passend zu App und Plattform, etwa das iOS-Projekt für einen Apple-Absturz: eintippen oder über „Ordner wählen …“ durch die Ordner klicken (der Dienst zeigt nur Ordnernamen, keine Dateien, und markiert erkannte Xcode- und Gradle-Projekte). Der Dienst prüft ihn vor dem Lesen: vorhanden, ein Ordner, nicht die Festplatte, nicht der Benutzerordner, kein versteckter Ordner.
An: Die KI darf in bis zu vier Runden weitere Dateien oder Klassen anfordern. Aus: Es gehen nur die Dateien mit, die der Stacktrace nennt.
Aus (empfohlen): Du gibst jede angeforderte Datei im Bericht einzeln frei. An: Der Dienst liefert innerhalb der Grenzen selbst nach; was gesendet wurde, steht im Ticket.
An: Jede Analyse wird von einem zweiten KI-Aufruf geprüft. Kostet etwa doppelt so viele Tokens. Vorgabe an.
Höchstens 8 Quelldateien, 60 000 Zeichen Quelltext und 120 000 Zeichen Report je Anfrage. Selten zu ändern.
Schritt 4 · Starten
Die Crash-Analyse läuft über denselben kleinen Dienst wie die KI-Anfragen. Er läuft nur auf deinem Rechner (127.0.0.1) und nur, solange du ihn startest. Der Bericht auf dem Server hat den Reiter nie.
./ratings.sh ai-report, im Menü „Bericht mit KI-Fragen“. Der Bericht öffnet sich im Browser.
Reiter „KI-Crashreports“. Oben steht, welches Modell gilt; der Filter ist hier ausgeblendet, er hat mit Abstürzen nichts zu tun.
Strg+C im Fenster. Nach einer Änderung in der Einrichtung einmal beenden und neu starten, sonst gilt die alte Einstellung.
Der Ablauf
So läuft eine Anfrage, vom Einfügen bis zum Ticket.
„+ Neue Anfrage“. Pflicht: Plattform (Apple oder Google), Titel, der vollständige Report. Optional: eine Anmerkung (iOS-Version, Funktion, Architektur, was schon geprüft wurde), die App und der Projektordner dieser App und Plattform (leer heißt: kein Quelltext; das Feld schlägt Ordner früherer Anfragen vor). „Speichern“ legt die Anfrage in data/crash-reports.json ab, auf deinem Rechner. Bis hier verlässt nichts den Rechner.
Der Parser liest Fehlertyp, Signal, App- und OS-Version, die obersten Frames des abgestürzten Threads und welche davon dein Code sind. Er erkennt fehlende Symbolisierung und Verschleierung und warnt. Aus Fehlertyp, Signal und den App-Frames ohne Adressen entsteht die Fehlernummer: Derselbe Absturz von einem anderen Gerät hat dieselbe Nummer.
Steht die Fehlernummer in data/crash-history.json, wird die Anfrage sofort zum Duplikat: Sie zeigt die alte Analyse mit Hinweis, woher sie stammt, und wird nie an die KI gesendet. Die Historie bleibt auch, wenn du die erste Anfrage löschst.
Eine oder mehrere ankreuzen, „Analysieren“ (ohne Häkchen alle offenen). Zuerst baut der Dienst für jede Anfrage genau den Text, der rausgehen würde, und zeigt ihn dir: den bereinigten Report, was ersetzt wurde, welche Quelldateien mitgehen, wie viele Rezensionen, die geschätzten Tokens und deinen Monatsverbrauch. Erst „Absenden“ in dieser Vorschau sendet.
Die Anfragen laufen nacheinander, ein Fenster zeigt „2 von 5“ und lässt sich abbrechen. Die KI bekommt den klaren Auftrag, nicht zu raten. Das Programm prüft jedes Zitat wörtlich gegen das Material; was nicht drinsteht, fällt weg. Ohne Beleg wird die Sicherheit „niedrig“, bei nicht symbolisiertem Report höchstens „mittel“.
Reicht der Stacktrace nicht, darf die KI statt einer Antwort nennen, welche Datei oder Klasse sie noch braucht und warum, höchstens fünf je Runde. Der Dienst sucht sie im Projektordner der Anfrage, nach Dateiname oder nach der Stelle, an der die Klasse definiert ist. Im Bericht erscheint ein Fenster: jede Datei mit Pfad und Begründung der KI, einzeln freizugeben oder abzulehnen. Erst dann geht es weiter, bis zu vier Runden; danach muss die KI antworten. Abgelehnte Dateien werden nie gesendet, die KI erfährt nur, dass sie abgelehnt wurden.
Ein zweiter KI-Aufruf bekommt dasselbe Material und die Analyse. Er prüft, ob die Belege stimmen, ob die Stelle existiert und ob der Mechanismus aus den Frames folgt. Er darf streichen und die Sicherheit senken, nie erhöhen. Sagt er „verworfen“, steht im Ergebnis „nicht bestimmbar“.
Die Analyse wird in die Anfrage geschrieben, die Fehlernummer in die Historie. Fehlt der Anbieter oder bricht etwas ab, wird nur diese Anfrage „Fehler“, die anderen laufen weiter. Danach: Zeile anklicken, Ticket kopieren, drucken oder als PDF sichern.
Datenschutz und persönliche Daten
Crash-Reports enthalten selten Daten von Nutzern, aber oft Kennungen von Geräten und den Benutzernamen des Entwicklers in Dateipfaden. Das alles braucht die KI nicht, um einen Fehler zu finden. Deshalb ersetzt das Programm es vor dem Senden durch Platzhalter, und du siehst in der Vorschau genau, was rausgeht.
/Users/…, /home/…, C:\Users\…)data/crash-reports.json und data/crash-history.json, Rechte 0600Hat das Programm etwas ersetzt, endet die Anfrage mit dem Status „Analysiert/PD“ und nennt Art und Zahl der Ersetzungen. In einem Crash-Report sollte das eigentlich nicht vorkommen; der Status macht es sichtbar.
Die Bereinigung erkennt Muster. Einen Namen, den jemand frei in die Anmerkung tippt, oder einen Kundennamen in einer Fehlermeldung erkennt sie nicht. Darum die Vorschau: lesen, dann senden.
Wer keinen Code in die Cloud geben will, schaltet „Quelltext übertragen“ aus oder nimmt für die Crash-Analyse ein lokales Modell.
Für die Übermittlung gelten die API-Bedingungen des Anbieters. Wähle einen, dessen Bedingungen die Verwendung der Eingaben zum Training ausschließen. Details in der Datenschutzerklärung.
Die Prompts, wörtlich
Jede Anfrage besteht aus einer Systemanweisung (die Regeln) und einem Nutzertext (das Material). Die Systemanweisung ist fest und steht hier unverändert, so wie das Programm sie sendet. Die Sprache folgt ai.language; die englische Fassung steht auf der englischen Seite und in KI-PROMPTS.md, Abschnitt 7a. Ein Test prüft, dass diese Seite und der Code übereinstimmen.
Du bist ein erfahrener Mobile-Entwickler und analysierst einen Crash-Report für das Entwicklungsteam. Arbeite nur mit dem übergebenen Material: Report, Anmerkung des Entwicklers, Quelltext-Ausschnitte und Nutzerrezensionen. Rate nie, erfinde keine Frames, Dateien, Zeilennummern oder APIs. Jede Aussage zur Ursache braucht einen wörtlichen Beleg aus dem Material. Erlaubt das Material keinen Schluss, sage das und nenne genau, was fehlt (Symbolisierung, Mapping-Datei, mehr Kontext, eine bestimmte Quelldatei). Antworte ausschließlich mit gültigem JSON: {"summary": "ein Satz", "cause": "wahrscheinlichste Ursache oder 'nicht bestimmbar'", "confidence": "hoch|mittel|niedrig|unbestimmbar", "evidence": [{"source": "report|code|note|review", "text": "wörtlicher Ausschnitt"}], "location": "Datei:Zeile oder Frame, sonst null", "fix": "technische Lösung, konkret", "steps": ["wie reproduzieren oder prüfen"], "openQuestions": ["was unklar bleibt"], "notChecked": ["was du nicht prüfen konntest"], "missing": ["was nötig wäre"]}. "hoch" nur, wenn Report und Code zusammenpassen und der Mechanismus erklärt ist; "mittel" bei plausiblem Mechanismus mit Teilbelegen; "niedrig" bei einer Hypothese; "unbestimmbar", wenn der Report nicht symbolisiert, verschleiert oder unvollständig ist. Insgesamt unter 250 Wörtern, auf Deutsch. Gib keine personenbezogenen Daten aus, auch wenn sie im Material stehen.Aufgabe: Finde die Ursache dieses Absturzes, soweit das Material es erlaubt, und schlage eine technische Lösung vor. Nenne, was du nicht prüfen konntest. Plattform: Apple (iOS/macOS) Titel: <Titel> Fakten aus dem Parser (nicht von dir): Typ=<Typ>, Signal=<Signal>, Version=<Version>, OS=<OS> Anmerkung des Entwicklers: <Anmerkung> Crash-Report: <bereinigter Report> Quelltext-Ausschnitte: --- Kasse/KassenView.swift (Zeilen 1–122) --- <Ausschnitt> Nutzerrezensionen mit Absturz-Stichworten (Kontext, keine Beweise): [n=1, app=<App>, store=apple, sterne=1, datum=2026-10-20, version=4.2.1] | titel: <Titel der Rezension> | text: <Text>
Die Zeile „Fakten aus dem Parser“ enthält nur, was der Parser gefunden hat. „Anmerkung“, „Quelltext-Ausschnitte“ und „Nutzerrezensionen“ fehlen, wenn es sie nicht gibt oder die Einrichtung sie ausschaltet. Der Report ist an dieser Stelle schon bereinigt. Der Nutzertext ist immer deutsch beschriftet; die Antwortsprache legt die Systemanweisung fest.
Agentenmodus: Reicht dir das Material nicht, darfst du stattdessen weitere Quelldateien oder Klassen dieses Projekts anfordern, höchstens 5 je Runde. Antworte dann ausschließlich mit gültigem JSON: {"need": [{"name": "Dateiname oder Klassenname", "why": "wozu du es brauchst"}]}. Fordere nur an, was du für die Ursache wirklich brauchst; der Entwickler gibt jede Anforderung einzeln frei. Reicht das Material, antworte mit der Analyse.Agentenmodus: Runde 2 von 4. Bisherige Anforderungen: - ListCache: übertragen Letzte Runde: Antworte jetzt mit der Analyse, fordere nichts mehr an.
Die Zeile „Letzte Runde“ kommt nur in der letzten Runde; dann fehlt auch der Zusatz zur Systemanweisung, die KI muss antworten.
Du bist ein zweiter, unabhängiger Entwickler und prüfst die Crash-Analyse eines Kollegen. Du siehst dasselbe Material und die Analyse. Deine Aufgabe ist, Raten zu erkennen: Prüfe, ob jeder zitierte Beleg wirklich im Material vorkommt, ob die genannte Stelle im Report oder in den Quelltext-Ausschnitten existiert und ob der Mechanismus tatsächlich aus den Frames folgt. Du darfst die Sicherheit senken oder Aussagen streichen, nie erhöhen oder neue Behauptungen hinzufügen. Antworte ausschließlich mit gültigem JSON: {"verdict": "bestaetigt|eingeschraenkt|verworfen", "confidence": "hoch|mittel|niedrig|unbestimmbar", "removed": ["gestrichene Aussage und warum"], "cause": "die Ursache, wie sie nach deiner Prüfung stehen darf", "fix": "die Lösung, wie sie stehen darf", "notes": "ein bis zwei Sätze für das Team"}. Unter 150 Wörtern, auf Deutsch. Keine personenbezogenen Daten.Aufgabe: Prüfe die folgende Analyse gegen das Material. Streiche, was nicht belegt ist, und setze die Sicherheit entsprechend.
Analyse des Kollegen:
{…}
Analyse des Kollegen:
{"summary": …, "cause": …, "confidence": …, "evidence": […], "location": …, "fix": …, "steps": […]}
<danach dasselbe Material wie in Durchgang 1>Jedes Zitat muss ohne Satzzeichen und Groß-/Kleinschreibung wörtlich im Material stehen, sonst fällt es weg. Ohne Beleg wird „hoch“ oder „mittel“ zu „niedrig“; bei nicht symbolisiertem oder verschleiertem Report höchstens „mittel“. Die genannte Stelle wird im Material gesucht.
Die Sicherheit ist die niedrigere der beiden Stufen. „verworfen“ ergibt „nicht bestimmbar“. Bei „eingeschränkt“ oder „verworfen“ ersetzen Ursache und Lösung des Prüfers die der Analyse.
Zusammenfassung 400, Ursache 1 200, Lösung 2 000 Zeichen, Listen je acht Einträge. Unbekannte Felder der Antwort werden verworfen.
Das Ergebnis
Der Reiter zeigt alle Anfragen: System, Titel, Datum, Status, Ergebnis und Fehlernummer. Links an jeder Zeile zeigt ein breiter Farbstreifen den Status. Ein Klick öffnet die Anfrage mit Eingaben, Fakten, Analyse und Ticket; dort lässt sie sich ändern, erneut analysieren oder löschen (mit Rückfrage).
Gespeichert, noch nicht gesendet.
Die KI hat weitere Dateien angefordert. Zeile öffnen, „Freigabe fortsetzen“.
Analyse fertig, keine persönlichen Daten ersetzt.
Analyse fertig, vorher mussten persönliche Daten ersetzt werden.
Fehlernummer schon bekannt, alte Analyse übernommen, nichts gesendet.
Anbieter nicht erreichbar, Budget erschöpft oder abgebrochen. Erneut absenden geht.
Fehlernummer, Umgebung, Ursache mit Sicherheit, Belege, Stelle, Lösung, Prüfschritte, offene Fragen, was nicht geprüft werden konnte, Urteil des Prüfers, Stacktrace.
Jede KI-Aussage trägt die Marke „KI“ mit Anbieter, Modell und Datum. Fehlernummer, Fakten und Status rechnet das Programm, nie die KI.
Einstellungen
ai.crashReports.Die Tabelle steht auch in README.md (Abschnitt Konfiguration). Alle Prompts wörtlich stehen in KI-PROMPTS.md, Abschnitt 7a.
| Schlüssel | Bedeutung | Vorgabe |
|---|---|---|
ai.features.crashReports | Reiter „KI-Crashreports“ an oder aus; wirkt nur mit eingeschalteter KI | true |
providers[].crashModel | Modell für die Crash-Analyse; leer = wie model | leer |
crashReports.review | zweiter Prüfdurchgang, etwa doppelte Tokens | true |
crashReports.sendSource | Quelltext an die KI übertragen | true |
crashReports.sendReviews | Rezensionen der App als Kontext übertragen | true |
crashReports.showSourcePath | volle Ordnerpfade im Bericht zeigen; aus = nur Namen, nur Auswahl | true |
crashReports.agent | KI darf weitere Dateien oder Klassen anfordern (nur mit Quelltext und Projektordner) | true |
crashReports.agentRounds | höchstens so viele Anforderungsrunden, 1 bis 10 | 4 |
crashReports.agentAutoApprove | angeforderte Dateien ohne Rückfrage übertragen | false |
crashReports.maxSourceFiles | Quelldateien je Anfrage | 8 |
crashReports.maxSourceChars | Zeichen Quelltext je Anfrage | 60 000 |
crashReports.maxReportChars | Zeichen je Report, längere werden abgelehnt | 120 000 |
Wenn etwas nicht klappt
Das Log liegt in data/logs/ki.log, ohne Schlüssel. Ein Fehler bei einer Anfrage hält die anderen nicht auf.
Der Dienst läuft nicht, die KI ist aus oder ai.features.crashReports steht auf aus. ./ratings.sh ai-report starten.
Nur Adressen, keine Funktionsnamen. Den Report in Xcode mit dem passenden dSYM symbolisieren und neu einfügen.
ProGuard/R8. Den Stacktrace mit der mapping.txt der Version zurückübersetzen (Play Console oder retrace).
Den Ordner des App-Projekts angeben, nicht die Festplatte, den Benutzerordner oder einen Ordner, dessen Name mit einem Punkt beginnt.
Der Stacktrace nennt eine Datei, die es dort nicht gibt: falscher Ordner, oder die Datei liegt in einem Framework. Die Analyse läuft ohne sie.
Anbieter nicht erreichbar, Schlüssel falsch oder Monatslimit erreicht. Die Meldung steht in der Anfrage; danach einfach erneut absenden.