Ein Karpathy-ähnliches Wiki in eine wiederverwendbare Fähigkeit umwandeln

Die letzten Tage waren ein echter Kampf, um diese Fähigkeit zum Laufen zu bringen.

Ich habe mit Opus 4.6 angefangen. Ich habe mehr als 20 $ verbraucht. Trotzdem konnte ich es nicht zum Laufen bringen. Ich habe mich sogar gefragt, ob das neue Modell, das am Morgen des 8. April 2026 erschienen ist, die gesamte Rechenleistung aufgesogen hat. Wie sonst könnte es einen Moment lang alles verstehen und im nächsten Moment wieder vom Kurs abkommen?

Später bin ich zu Codex gewechselt, und es gelang mir, es zu bauen.

Aber ein neues Problem tauchte auf: Es zu bauen bedeutet nicht, dass es zuverlässig funktioniert.

Besonders wenn man anfängt, es ernsthaft zu testen, ignoriert es gelegentlich Anweisungen und nimmt eigenmächtig Änderungen vor, was mich wahnsinnig gemacht hat.

In diesem Artikel möchte ich also nicht einfach sagen: „Ich habe eine Fähigkeit gebaut, ladet sie einfach herunter.“

Ich möchte etwas anderes klarstellen: wie man die LLM-Wiki-Methode, die Karpathy vorgeschlagen hat, tatsächlich in einem Obsidian-Vault umsetzt.

Das vorherige Kapitel hat die Methode behandelt. Dieses Kapitel handelt von der Praxis.

Wenn du die aktuelle bereinigte Version meiner Fähigkeit herunterladen möchtest, hier ist der Link:

https://blog.discoverlabs.ac.cn/downloads/obsidian-wiki-skill/

Ich habe bereits die API-Schlüssel, lokalen Pfade usw. entfernt. Aber ich sage es gleich vorweg: Kopiere es nicht eins zu eins.

Du kannst von dieser Methode lernen. Du kannst diese Fähigkeit auch modifizieren. Aber erwarte nicht, dass sie sofort funktioniert. Die Notiz-Vaults sind einfach zu unterschiedlich.

Was ich gebaut habe, ist nicht „KI organisiert meine Notizen“, sondern „KI macht meine Buchhaltung“

Erinnern wir uns zunächst an Karpathys Gist.

Original-Link:

https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f

Die Kernidee ist eigentlich einfach:

Die meisten Leute nutzen LLMs derzeit für die Dokumentenverarbeitung per RAG: Sie werfen einen Haufen Dateien hinein und beim Abfragen werden Antworten spontan abgerufen und generiert.

Das funktioniert natürlich.

Aber das Problem ist, dass alles Ad-hoc ist.

Einmal fragen, einmal zusammenstellen. Nochmal fragen, wieder von vorne anfangen. Keine Anhäufung.

Also schlug er eine Zwischenschicht vor: Statt für jede Abfrage spontan Antworten zusammenzustellen, pflege kontinuierlich ein Wiki.

Als ich das las, war meine erste Reaktion nicht „Das ist cool.“

Sondern: Ist das nicht genau die Art von Aufgabe, für die Obsidian am besten geeignet ist?

Denn Obsidian ist von Haus aus ein lokaler Markdown-Datei-Vault.

Das Wiki, das Karpathy beschreibt, ist im Wesentlichen eine Sammlung von Markdown-Dateien.

Das zugrundeliegende Format ist fast identisch.

Der Unterschied ist:

• Früher hast du manuell Backlinks, Themenseiten und Strukturseiten gepflegt
• Jetzt hilft dir die KI bei dieser „Buchhaltungsarbeit“

Anmerkung: Buchhaltung, nicht Denken.

Ich stimme dem immer mehr zu.

Artikel lesen, Urteile fällen, eigene Meinungen schreiben – das ist immer noch deine Aufgabe.

Aber Aufgaben wie das Vervollständigen von Backlinks, das Normalisieren von Autorennamen, das Überprüfen der Formatierung und das Aktualisieren abgeleiteter Seiten sind im Grunde Routinearbeiten. Die KI kann sie erledigen.

Wie ich Karpathys Drei-Schichten-Struktur in Obsidian umgesetzt habe

Der wichtigste Teil von Karpathys Methode sind die drei Schichten:

• Raw Sources (Rohquellen)
• The Wiki (Das Wiki)
• The Schema (Das Schema)

Meine obsidian-wiki-Fähigkeit ist ebenfalls um diese drei Schichten herum aufgebaut.

Erste Schicht: Raw Sources

In meinem Vault besteht diese Schicht aus:

• 01-Notes/
• 04-Output/

Das heißt, rohe Sammlungen, rohe Notizen und Artikel, die ich geschrieben habe.

Ich halte diese Schicht sehr zurückhaltend.

Ihre einzige Verantwortung ist es, den ursprünglichen Inhalt zu bewahren.

Ich lasse sie keine zusätzlichen Funktionen übernehmen.

Ich mische keine abgeleiteten Inhalte hinein.

Ich lasse nicht zu, dass ein roher Artikel zur Hälfte eine Themenseite und zur Hälfte eine Indexseite wird.

Denn wenn man es vermischt, wird es schwer zu pflegen.

Das ist eine der tiefsten Lektionen, die ich beim Bau dieser Fähigkeit gelernt habe: Je sauberer die rohe Schicht, desto einfacher wird alles andere.

Zweite Schicht: The Wiki

Diese Schicht ist in meinem Vault getrennt:

01-Notes/wiki/

Hier befindet sich die von der KI abgeleitete Strukturschicht, wie zum Beispiel:

• Autorenseiten
• Themenseiten
• Index
• Log
• Backlink-Verzeichnis

Mit anderen Worten: Der Originaltext bleibt der Originaltext.

Das Wiki ist das Wiki.

Die beiden Schichten sind getrennt.

Das klingt trivial, ist aber tatsächlich sehr wichtig.

Denn wenn man die Schichten nicht trennt, neigt die KI jedes Mal, wenn sie organisiert, dazu, den Originaltext unordentlicher zu machen.

Heute fügt sie einen Themenblock hinzu.

Morgen fügt sie einen Index ein.

Übermorgen fügt sie eine automatisch generierte Zusammenfassung hinzu.

Irgendwann sieht der ganze Vault aus wie ein Raum, der ständig aufgeräumt wird, aber immer unordentlicher wird.

Dritte Schicht: The Schema

Viele Leute übersehen diese Schicht.

Karpathy erwähnt das Schema in seinem ursprünglichen Beitrag. Mein Verständnis ist: Du musst der KI sagen, wie der Vault aussehen soll.

In meinem Fall umfasst das:

• SKILL.md
• Eine Reihe von scripts/
• Frontmatter-Konventionen
• Einschränkungen, wie Autoren und Themen geschrieben werden
• Prozessbeschränkungen für Lint und Ingest

Zum Beispiel setze ich jetzt durch:

• Autoren müssen im Backlink-Format sein
• Themen müssen eine Backlink-Liste sein
• Autorenseiten und Themenseiten dürfen nur in 01-Notes/wiki/ sein
• 00-Inbox/ ist nur eine Verarbeitungs-Inbox, die nicht direkt in das Wiki gemischt wird
• Rohe Artikel enthalten keine abgeleiteten Absätze mehr

Du wirst feststellen, dass das, was die Fähigkeit zum Funktionieren bringt, nicht ist, wie schön der Prompt geschrieben ist. Der eigentliche Schlüssel ist, dass diese Einschränkungen zuerst festgelegt werden.

Die drei Aktionen in ausführbare Workflows übersetzen

Karpathy hat auch drei Kernaktionen:

• Ingest
• Query
• Lint

Ich bin dem gleichen Ansatz gefolgt.

Im tatsächlichen Workflow dieser Fähigkeit sieht das so aus:

• Ingest: wiki_lint.py --preflight + ob_shuanglian.py suggest/apply + wiki_ingest.py
• Query: Zuerst wiki/index.md, authors/*.md, topics/*.md lesen, dann für Details zum Originaltext zurückgehen
• Lint: wiki_lint.py, wiki_migrate.py, wiki_build_skeleton.py

Ingest: Neue Inhalte prüfen, bevor sie in den Vault aufgenommen werden

Ich lasse die KI nicht „einen Artikel sehen und sofort improvisieren“.

Mein aktueller Workflow beginnt mit einer Preflight-Prüfung.

Zuerst prüfen, ob das Frontmatter korrekt ist.

Dann auf historische Verunreinigungen prüfen.

Dann Backlink-Vorschläge machen.

Nach Bestätigung durch den Benutzer tatsächlich anwenden.

Schließlich die abgeleitete Wiki-Schicht aktualisieren.

Warum dieser ganze Aufwand?

Weil die Modelle es mir oft genug gezeigt haben.

Wenn man diese Schutzmaßnahmen nicht einbaut, wird es eifrig „Entscheidungen für dich treffen“.

Das Problem ist, dass seine Entscheidungen vielleicht nicht das sind, was du willst.

Also habe ich starke Bestätigungstore eingebaut.

Lass es nicht willkürlich Themen schreiben.

Lass es nicht direkt Backlinks anwenden.

Lass es nicht eigenständig über Autoren-Aliasnamen entscheiden.

Vorschläge machen, ich bestätige, dann wird geschrieben.

Das mag weniger effizient erscheinen.

Aber bei einer Wissensdatenbank ist die größte Angst nicht Langsamkeit, sondern dass leise etwas Falsches geschrieben wird.

Query: Nicht im Meer des Originaltextes fischen, sondern zuerst die Wiki-Schicht lesen

Bei Abfragen ist mein Ansatz nicht „den gesamten Vault durchsuchen und der KI zur Zusammenfassung übergeben“.

Stattdessen geht es zuerst durch:

• wiki/index.md
• authors/*.md
• topics/*.md

Die KI soll sich zuerst die strukturierte Schicht ansehen.

Wenn nötig, zu bestimmten Artikeln für Details zurückgehen.

Die Vorteile sind klar:

Sie muss nicht jedes Mal aus verstreuten Originaltexten neu zusammenstellen.

Stattdessen antwortet sie aus einer bereits organisierten Schicht.

Das kommt dem näher, was Karpathy mit „Anhäufung“ meint.

Lint: Der wichtigste und am meisten unterschätzte Schritt

Viele konzentrieren sich auf Query, wenn sie LLM Wiki sehen.

Aber je mehr ich daran arbeite, desto mehr habe ich das Gefühl, dass Lint der Ort ist, an dem der wahre Wert liegt.

Denn sobald die Wissensdatenbank wächst, ist dein größtes Kopfzerbrechen nicht „keine Antworten zu bekommen“, sondern:

• Frontmatter ist chaotisch
• Autorennamen sind inkonsistent
• Themen sind verstreut
• Historische Strukturen bleiben im Originaltext erhalten
• Abgeleitete Seiten werden zunehmend verzerrt
• Dasselbe Konzept taucht unter mehreren verschiedenen Namen auf

Wenn du versuchst, das manuell zu pflegen, ist es wahnsinnig mühsam.

Und du wirst es nicht durchhalten können.

Genau das ist die Stärke der KI.

Nicht, die Welt für dich zu verstehen.

Sondern den Vault zu patrouillieren, abzugleichen, schmutzige Daten zu finden und Querverweise zu ergänzen.

Deshalb ist Karpathys Begriff so treffend: Buchhaltung.

Die wahre Falle ist nicht das Modell, sondern mein alter Notiz-Vault

Das ist auch das, was ich euch am meisten warnen möchte.

Viele Leute lesen so einen Artikel und denken instinktiv:

„Oh, ich kann einfach die Fähigkeit herunterladen, installieren, und die KI wird meine Wissensdatenbank verwalten.“

Das ist nicht der Fall.

Die größte Herausforderung bei dieser Fähigkeit ist nicht der Prompt, die Skripte oder sogar das Modell.

Es ist, dass ich zu viele alte Notizen habe und ihre Formate inkonsistent sind.

Wenn ich jetzt Lint laufen lasse, sehe ich folgenden Umfang:

• Artikelartige Rohquellen: 457
• Gesamte Rohdateien: 833
• Ausstehende Warteschlange: 249
• Das Backlink-Verzeichnis hat bereits 471 Themen

Denk mal über diese Menge nach.

Das geht nicht mehr darum, „ein paar Notizen zu organisieren“.

Es ist eher wie die Übernahme eines alten Systems mit einer langen Geschichte und ohne einheitliche Standards.

Manche Artikel haben vollständige Autorennamen.

Manche haben Aliasnamen.

Manche Themen sind sehr detailliert.

Manche sind sehr verstreut.

Manche alten Dateien enthalten noch Überreste früherer Strukturen.

Also wurde ich immer sicherer in einer Sache:

Wenn du ein LLM Wiki aufbauen willst, ist der erste Schritt nicht, die KI übernehmen zu lassen. Der erste Schritt ist, deinen Vault in einen Zustand zu versetzen, der es „wert ist, übernommen zu werden“.

Sonst, je fleißiger die KI ist, desto mehr verbreitet sie das Chaos.

Was macht diese Fähigkeit also tatsächlich zusätzlich?

Wenn du nur Karpathys ursprünglichen Beitrag liest, denkst du, es sei eine sehr elegante Methodik.

Aber beim tatsächlichen Bauen habe ich viele technische Details gefunden, die ausgefüllt werden mussten.

Zum Beispiel:

• Standardisierung des Frontmatters
• Normalisierung von Autoren-Aliasnamen
• Durchsetzung des Backlink-Formats für Themen
• Vollständige Trennung von rohen und abgeleiteten Schichten
• Verwendung von 00-Inbox/ als Verarbeitungs-Inbox
• Hinzufügen von Benutzerbestätigungstoren an wichtigen Stellen
• Aufteilung des Workflows mit Skripten wie lint, migrate, ingest

Es ist nicht so, dass Karpathy das nicht bedacht hätte.

Es ist, dass sein Gist ein Muster beschreibt, nicht die spezifische Implementierung für deinen Vault.

Bei der tatsächlichen Umsetzung musst du diese Schicht selbst ausfüllen.

Meine aktuelle obsidian-wiki-Fähigkeit macht im Wesentlichen Folgendes:

Ein abstraktes Muster in einen Workflow übersetzen, der auf meinem eigenen Obsidian-Vault läuft.

Wenn du es also herunterlädst, ist das Wichtigste, was du lernen kannst, nicht „kopiere meine Verzeichnisstruktur“.

Es ist zu verstehen, warum ich die Dinge so geschichtet habe, warum hier eine Bestätigung nötig ist, warum Lint hier gemacht wird, warum hier kein automatisches Anwenden verwendet wird.

Wenn du das auch machen willst, ändere zuerst diese Dinge

Ich habe die bereinigte Version auf die Download-Seite meines Blogs gestellt:

https://blog.discoverlabs.ac.cn/downloads/obsidian-wiki-skill/

Aber nach dem Herunterladen ist das Erste nicht, es auszuführen.

Es ist, es zu modifizieren.

Überprüfe zumindest diese Dinge:

1. Ist dein Vault-Pfad derselbe wie meiner?
2. Ist deine 01-Notes/, 04-Output/, 00-Inbox/-Struktur dieselbe?
3. Sind deine Frontmatter-Felder mit meinen konsistent?
4. Sind deine Autorennamen und Themennamen bereits einigermaßen konsistent?
5. Möchtest du meinen Workflow „vorschlagen, bestätigen, dann schreiben“ beibehalten?
6. Wenn die Skripte APIs betreffen, hast du sie durch deine eigenen Schlüssel ersetzt?

Die von mir veröffentlichte Version hat bereits API-Schlüssel und lokale Pfade bereinigt.

Nachdem du sie erhalten hast, musst du sie an deine eigene Umgebung anpassen.

Und ich empfehle immer noch: Behandle meine Methode nicht als Vorlage, sondern nur als Referenz.

Wenn dein Vault hauptsächlich aus Lesenotizen besteht, können die Regeln von meinen abweichen.

Wenn dein Vault hauptsächlich aus Projektnotizen besteht, wird die Granularität der Themen anders sein.

Wenn sich dein Vault noch in der Phase „erst sammeln, dann organisieren“ befindet, solltest du dich wahrscheinlich nicht zuerst auf Query konzentrieren, sondern dafür sorgen, dass Lint und Ingest reibungslos laufen.

Also kopiere nicht eins zu eins.

Modifiziere basierend auf dem Ansatz, das ist zuverlässiger.

Zusammenfassung

Am Ende dieses Artikels ist mein eigenes Gefühl klarer geworden.

Karpathys Vorschlag ist nicht nur eine Idee, dass „KI dir helfen kann, deine Wissensdatenbank zu organisieren“.

Sein wirklicher Wert ist, dass er die Arbeitsteilung zwischen Mensch und KI im Wissensmanagement neu definiert.

Der Mensch übernimmt das Urteilen.

Die KI übernimmt die Buchhaltung.

Je mehr ich daran arbeite, desto mehr glaube ich an diese Aussage.

Was ich heute gelernt habe:

1. Der Schlüssel zu Karpathys LLM Wiki ist die Drei-Schichten-Struktur und die drei Operationen, nicht ein einzelner Prompt
2. Der Schlüssel zu Fähigkeiten wie obsidian-wiki ist nicht „kann es zusammenfassen“, sondern ob es Raw Sources, Wiki und Schema trennen kann
3. In der Praxis ist Lint oft wichtiger als Query, weil die Bereinigung historischer Daten den Großteil der Arbeit ausmacht
4. Je mehr alte Notizen und je chaotischer das Format, desto weniger solltest du direkt die Fähigkeit eines anderen kopieren
5. Eine Fähigkeit herunterzuladen ist einfach; die eigentliche Herausforderung ist, sie an die eigene Wissensdatenbank anzupassen

Wichtige Erkenntnisse:

• KI ist am besten für Buchhaltung geeignet, nicht um für dich zu denken
• Rohe und abgeleitete Schichten müssen getrennt werden, sonst wird die Wissensdatenbank mit jedem Organisieren unordentlicher
• Benutzerbestätigungstore sind keine zusätzlichen Schritte; sie sind notwendige Schutzmaßnahmen, um zu verhindern, dass die KI eigenmächtig handelt
• Standardisiere zuerst die Formate, dann rede über Automatisierung; wenn du die Reihenfolge umkehrst, wirst du später leiden
• Diese Fähigkeit kann modifiziert werden, aber es wird nicht empfohlen, sie unverändert zu kopieren