LLM-Wiki: wie du eins aufbaust und aktuell hältst

Ein LLM-Wiki ist eine persönliche Wissensdatenbank, die ein KI-Agent für dich schreibt. Du sammelst Rohquellen (Artikel, Papers, Transkripte, Notizen) in einem Ordner. Der Agent liest sie und pflegt darüber eine Reihe verlinkter Markdown-Seiten: eine Seite pro Konzept, Person oder Quelle, dazu einen Index. Wenn du eine Quelle hinzufügst, aktualisiert der Agent jede Seite, die sie betrifft. Wenn du eine Frage stellst, antwortet er aus dem Wiki und kann die Antwort als neue Seite ablegen.

Die Idee stammt von Andrej Karpathy. Am 2. April 2026 schrieb er auf X über „LLM Knowledge Bases“, und zwei Tage später veröffentlichte er eine längere Fassung als „Ideen-Datei“ auf GitHub, gedacht zum direkten Einfügen in einen Agenten wie Claude Code oder Codex. Sein Gegenbild ist RAG: Dort holt sich ein Modell bei jeder Frage Abschnitte deiner Dateien, und nichts baut sich auf. In einem LLM-Wiki wird das Wissen „einmal kompiliert und dann aktuell gehalten“, also sind Querverweise und Widersprüche schon geklärt, bevor du fragst.

Obsidian ist die IDE, das LLM ist der Programmierer, das Wiki ist die Codebasis.

Dieser Satz aus dem Gist fasst das Setup zusammen, das die meisten nachbauen: auf der einen Seite der Agent in einem Terminal, auf der anderen ein Markdown-Editor, dazwischen ein Ordner mit Dateien. Das Muster braucht aber keinen bestimmten Editor. Jeder Ordner und jeder Agent, der Dateien lesen und schreiben kann, tut es.

Was dir ein Editor nicht sagt: welche Seiten der Agent geändert hat und ob die jemand geprüft hat. Knowtarium ist eine Ende-zu-Ende-verschlüsselte Wissensdatenbank, gebaut für genau dieses Setup. Dein Wiki liegt als einfache Markdown-Seiten in einem Workspace, dein Agent liest und schreibt es über MCP, und jede Seite, die er ändert, ist signiert, zeigt, wer die Änderung gemacht hat, und lässt sich rückgängig machen. Der Einstieg ist kostenlos. Der Rest dieser Anleitung zeigt das Setup mit einfachen Dateien, mit Hinweisen unterwegs, wie Knowtarium es handhabt.

Karpathy beschreibt das LLM-Wiki-Muster in drei Schichten:

• Rohquellen. Deine ausgewählten Dokumente. Sie sind unveränderlich: Der Agent liest sie und ändert sie nie. Sie sind deine verlässliche Grundlage.
• Das Wiki. Ein Verzeichnis mit Markdown-Seiten, die der Agent schreibt: Zusammenfassungen, Seiten zu Entitäten und Konzepten, Vergleiche, ein Überblick. „Du liest es, das LLM schreibt es.“
• Das Schema. Eine Datei wie CLAUDE.md für Claude Code oder AGENTS.md für Codex, die dem Agenten sagt, wie das Wiki aufgebaut ist und welchen Abläufen er folgt. Du und der Agent verfeinert sie mit der Zeit.

Und drei Dinge, um die du den Agenten bittest:

Zwei Dateien halten es übersichtlich. index.md listet jede Seite mit Link und einer Zusammenfassung in einer Zeile, und der Agent liest sie bei jeder Frage zuerst. Laut Karpathy funktioniert das in mittlerer Größe (rund 100 Quellen und Hunderte Seiten) „überraschend gut“, ganz ohne Embedding-Suche. Darüber hinaus schlägt der Gist vor, dem Agenten ein lokales Suchtool über die Markdown-Dateien zu geben. log.md ist eine Zeitleiste der Ingests, Abfragen und Lint-Durchläufe.

Der Gist ist bewusst abstrakt und überlässt die Details dir und deinem Agenten. Hier eine konkrete Fassung, die mit Claude Code, Codex oder Cursor funktioniert. Sie dauert etwa eine halbe Stunde, das meiste davon geht für das Schema drauf.

1. Leg die Ordner an

Halte Quellen und Wiki getrennt, damit immer klar ist, welcher Text aus der Welt kommt und welcher vom Agenten.

customer-wiki/
  CLAUDE.md            # das Schema (oder AGENTS.md für Codex)
  raw/                 # deine Quellen: der Agent liest sie, ändert sie nie
    2026-09-12-interview-northwind.md
    2026-09-14-support-tickets.md
    assets/            # Bilder, die neben geclippten Artikeln gespeichert werden
  wiki/                # die Seiten des Agenten
    index.md           # eine Zeile pro Seite, bei jeder Frage zuerst gelesen
    log.md             # was wann passiert ist
    overview.md
    concepts/
    entities/
    sources/           # eine Zusammenfassung pro Rohquelle
    answers/           # gute Antworten, zurück ins Wiki gelegt

In Knowtarium

Importier customer-wiki/ in einen Knowtarium-Workspace, und seine Ordner kommen mit. Der Graph zeigt, was veraltet ist (mit Review kann er Seiten nach Vertrauensstufe einfärben), und Links auf Seiten, die der Agent noch nicht geschrieben hat, erscheinen als Geister: eine To-do-Liste für den nächsten Ingest.

(öffnet in voller Größe in einem neuen Tab) (öffnet in voller Größe in einem neuen Tab)

2. Stell es unter Git

Führ vor dem ersten Ingest git init aus. Karpathy weist darauf hin, dass das Wiki „einfach ein Git-Repo aus Markdown-Dateien“ ist, und Git ist auch der günstigste Weg zu sehen, was der Agent geändert hat. Mehr dazu weiter unten.

3. Schreib die Schema-Datei

Das ist die wichtigste Datei im ganzen Setup. Fang kurz an und ergänze eine Regel, jedes Mal wenn der Agent etwas tut, das du nicht wolltest. Die Hinweise von Anthropic zu CLAUDE.md gelten auch hier: unter etwa 200 Zeilen bleiben und jede Anweisung so konkret machen, dass man sie überprüfen kann. Wenn du mehrere Agenten nutzt, schreib sie einmal als AGENTS.md und leg eine CLAUDE.md an, die @AGENTS.md enthält, damit Claude Code dieselben Regeln lädt.

# Wiki-Schema
 
Du pflegst das Wiki in wiki/. Die Quellen in raw/ sind schreibgeschützt.
 
## Seiten
- Ein Konzept, eine Entität oder eine Quelle pro Datei. Dateinamen in kebab-case.
- Jede Seite beginnt mit Frontmatter: type, title, description, sources.
- Verlinke verwandte Seiten mit normalen Markdown-Links.
- Jede Aussage nennt ihre Quelle als Fußnote mit der ID der Quelle.
- Was du nicht belegen kannst, schreibst du nicht. Markiere offene Fragen als solche.
 
## Ingest (wenn ich eine Datei in raw/ lege)
1. Lies die Quelle. Nenn mir vor dem Schreiben die 3 bis 5 Kernpunkte.
2. Schreib wiki/sources/<name>.md mit einer Zusammenfassung und der ID der Quelle.
3. Aktualisiere die Konzept- und Entitätsseiten, die sie betrifft. Markiere Widersprüche
   zu bestehenden Seiten, statt sie stillschweigend zu überschreiben.
4. Aktualisiere wiki/index.md und füge einen Eintrag in wiki/log.md hinzu.
5. Liste jede Datei auf, die du geändert hast.
 
## Query
- Lies zuerst wiki/index.md und öffne dann nur die Seiten, die du brauchst.
- Antworte mit Belegen. Biete an, gute Antworten in wiki/answers/ abzulegen.
 
## Lint (wenn ich darum bitte)
- Melde Widersprüche, veraltete Aussagen, verwaiste Seiten, fehlende Seiten
  und Aussagen ohne Quelle. Schlag Korrekturen vor; setz sie noch nicht um.

Zwei Regeln darin sind wichtiger, als sie aussehen: „Jede Aussage nennt ihre Quelle“ und „Liste jede Datei auf, die du geändert hast“. Sie kosten jetzt nichts und machen später die Prüfung erst möglich.

4. Füg eine Quelle hinzu und lies sie ein

Speicher einen Artikel als Markdown in raw/ und bitte den Agenten, ihn einzulesen. Karpathy liest lieber eine Quelle nach der anderen ein und bleibt dabei: die Zusammenfassung lesen, die Updates prüfen, dem Agenten sagen, was er betonen soll. Mach das mindestens bei den ersten zehn Quellen. So findest du heraus, was deinem Schema fehlt.

In Knowtarium

Jede Seite, die der Ingest schreibt oder ändert, ist in der Seitenleiste markiert, bis du sie öffnest. Unter ihrem Titel steht eine Zeile, welcher Agent sie wann bearbeitet hat, mit einem Link zu den Änderungen und einem Undo. Lies dort die Zusammenfassung und die Updates und mach rückgängig, was du nicht willst. Wenn du lieber vorher freigibst, schalte Review („Ask me first“) für den Ordner wiki/ ein, dann wartet jede Änderung als Diff auf dich.

(öffnet in voller Größe in einem neuen Tab) (öffnet in voller Größe in einem neuen Tab)

5. Stell Fragen und behalte die guten Antworten

Frag quer über mehrere Quellen, nicht nur zu einer. Wenn eine Antwort es wert ist, behalten zu werden, lass den Agenten sie in wiki/answers/ ablegen und von den Seiten aus verlinken, auf die sie sich stützt.

# eine Quelle einlesen
> Lies raw/2026-09-14-support-tickets.md ein. Zeig mir zuerst die Kernpunkte.
 
# fragen und die Antwort behalten
> Wo bleiben neue Kunden hängen? Nutz nur das Wiki und nenn die Seiten.
> Leg das als wiki/answers/onboarding-blockers.md ab und verlinke es.
 
# Gesundheitscheck
> Mach einen Lint des Wikis. Ändere noch nichts, gib mir eine Liste.

6. Lint nach festem Rhythmus

Bitte einmal pro Woche oder nach jeweils zehn Ingests um einen Lint-Durchlauf. Lass dir zuerst einen Bericht geben und gib Korrekturen getrennt frei, damit ein Gesundheitscheck nicht unbemerkt das halbe Wiki umschreibt. Ein einheitliches Präfix im Log macht leicht sichtbar, was zuletzt passiert ist:

## [2026-09-14] ingest | Support-Tickets, August
## [2026-09-15] query | Wo bleiben neue Kunden hängen?
## [2026-09-20] lint | 2 Widersprüche, 4 verwaiste Seiten

$ grep "^## \[" wiki/log.md | tail -5

Das LLM-Wiki-Muster macht die Pflege fast kostenlos. Das ist der Sinn der Sache und zugleich das Risiko. Der Agent kann in einem Durchgang 15 Seiten anfassen, und in den meisten Setups liest niemand diese 15 Änderungen. Karpathy selbst bleibt beim Einlesen dabei, und für Team-Wikis erwähnt er „womöglich mit Menschen in der Schleife, die Updates prüfen“. Die meisten Tutorials lassen diesen Teil weg. Das sammelt sich an, wenn du ihn weglässt:

• Abdriften von der Quelle. Eine Zusammenfassung einer Zusammenfassung verliert eine Einschränkung. Aus „in manchen Benchmarks“ wird „durchweg“, und drei Seiten später ist es ein Fakt.
• Synthese ohne Quelle. Der Agent verbindet zwei Ideen in einem Satz, der sich gut liest und nichts belegt. Du kannst ihn nicht von einer belegten Aussage unterscheiden.
• Widersprüche, still aufgelöst. Eine neue Quelle widerspricht einer alten Seite, und der Agent kürt einen Gewinner, statt es zu melden.
• Veraltete Seiten, die frisch aussehen. Eine Seite aus dem Mai liest sich im Dezember genauso. Nichts sagt, dass sie wieder geprüft werden müsste.
• Deine eigenen Änderungen laufen auseinander. Du korrigierst eine Zahl auf einer Seite. Die fünf Seiten, die sie wiederholen, haben noch die alte.
• Der Linter benotet seine eigenen Hausaufgaben. Lint ist dieselbe Art Modell, die dieselben Seiten liest. Es findet Widersprüche zwischen Seiten, aber keine Fehler, in denen sich alle Seiten einig sind.

Nichts davon macht das Muster zu einer schlechten Idee. Es heißt nur, dass ein LLM-Wiki dasselbe braucht wie jede Codebasis, die eine einzige Person geschrieben hat: ein zweites Paar Augen und eine Aufzeichnung, wer was geschrieben hat.

Vier Gewohnheiten schließen den größten Teil der Lücke. Du kannst sie eine nach der anderen einführen, mit einfachen Dateien und ohne neue Tools.

1. Halte die Herkunft im Frontmatter fest

Jede Seite sollte sagen, wer sie wann und aus welchen Quellen geschrieben hat, und jede Aussage sollte auf eine dieser Quellen zeigen. Fußnoten mit der ID einer Quelle ([^northwind-call]) überstehen es, wenn der Agent die Liste umsortiert, nummerierte Fußnoten nicht. Hier eine Seite mit den Feldnamen des Open Knowledge Format, damit auch andere Tools sie lesen können:

---
type: Concept
title: Absprung beim Import
description: Warum neue Kunden beim Import ihrer Daten hängen bleiben.
generated: { by: claude-code/2.1, at: 2026-09-20T09:12:00Z }
verified:
  - { by: human:sam, at: 2026-09-20T18:40:00Z }
stale_after: 2027-03-20T00:00:00Z
sources:
  - id: northwind-call
    resource: /raw/2026-09-12-interview-northwind.md
    title: Kundeninterview, Northwind Traders
---
 
Northwind hing eine Woche lang am CSV-Import fest.[^northwind-call]

generated sagt, wer den aktuellen Text geschrieben hat. verified sagt, wer ihn geprüft hat, und das Präfix human: kennzeichnet einen Menschen. Ergänze dein Schema um eine Zeile: „Signiere jede Seite, die du änderst, in generated, und trag dich nie in verified ein“. Unsere Anleitung dazu, wie Agenten ihre Quellen nennen, geht weiter ins Detail.

2. Prüf jede Änderung des Agenten, bevor du dich darauf verlässt

Behandle einen Ingest wie einen Pull Request. Committe, bevor du anfängst, lass den Agenten arbeiten, lies dann den Diff und übernimm oder verwirf ihn. Git kann das gut:

$ git status --short          # welche Seiten sich geändert haben$ git diff --stat             # wie viel$ git diff wiki/concepts/     # die tatsächlichen Änderungen lesen$ git add -p                  # Stück für Stück übernehmen$ git commit -m "ingest: support tickets"$ git restore wiki/entities/  # verwerfen, was du nicht übernommen hast

Lies nicht jede Seite. Lies die Zeilen, die sich geändert haben, und prüf jede neue Aussage gegen die Fußnote, die sie nennt. Wenn du eine Seite freigibst, trag dich mit Datum in verified ein. Die ganze Routine steht in So prüfst du Agenten-Änderungen.

3. Lass den Agenten deine Änderungen prüfen

Die Prüfung sollte in beide Richtungen laufen. Wenn du eine Seite von Hand änderst, bitte den Agenten, jede Seite zu finden, die auf sie verlinkt, dieselbe Quelle nennt oder den alten Wert wiederholt, und für diese Seiten Korrekturen vorzuschlagen. Die Korrekturen prüfst du dann wie jede andere Änderung eines Agenten. So erreicht deine Korrektur auch die anderen fünf Seiten.

4. Gib Seiten ein Ablaufdatum

Ergänze stale_after mit einem festen Datum: kurz bei Preisen, Versionen und Rollen von Personen, lang bei Definitionen. Ein Lint-Durchlauf kann dann die Seiten nach ihrem Datum auflisten, statt zu raten. Ob etwas veraltet ist, wird zum Datumsvergleich statt zur Ermessensfrage.

Das Open Knowledge Format ist eine offene Spezifikation von Google Cloud für Wissen, das Agenten schreiben. Version 0.2 hat Vertrauenssignale ergänzt, genau für den Fall oben: Bestände, die laufend von Agenten geschrieben und von anderen Agenten gelesen werden. Ein OKF-Bundle hat dieselbe Form wie ein LLM-Wiki (ein Ordner mit Markdown-Dateien mit YAML-Frontmatter) und reserviert dieselben zwei Dateinamen, index.md und log.md.

Wer eine Seite liest, leitet die Vertrauensstufe aus verified ab: keine Einträge heißt unverified, nur Agenten oder Prozesse heißt machine-confirmed, und mindestens ein Mensch heißt human-reviewed. Eine Seite kann sich nie selbst für vertrauenswürdig erklären. Zwei kleine Unterschiede zum Gist: Der Gist legt keine Link-Syntax fest, OKF nutzt normale Markdown-Links; und die log.md von OKF listet die neuesten Einträge zuerst, unter einfachen Datumsüberschriften im Format YYYY-MM-DD. Jedes Feld ist optional, du kannst also ein LLM-Wiki in OKF beginnen und die Vertrauensfelder nach und nach ergänzen.

Git ist die Grundlage: Es zeigt dir, was sich geändert hat, wenn du vor jeder Sitzung committest und danach den Diff liest. Knowtarium ist das Setup, das wir empfehlen, sobald das Wiki wächst, weil es Verlauf, Undo und Vertrauensstatus neben den Seiten hält statt in deinem Terminal. So schneiden die beiden im Vergleich ab.

Wenn du ein paar Quellen pro Woche einliest und jeden Diff liest, kann Git allein reichen. Knowtarium ist eine Web-App: Deine Seiten werden auf deinem Gerät verschlüsselt, bevor sie bei uns ankommen, wir können sie also nicht lesen, und die App ruft selbst keine KI auf. Der Agent, den du verbindest, sieht, was er liest. Liegt dein Wiki schon in einem Obsidian-Vault, importier ihn in einen Workspace, und er wird in OKF umgewandelt, ohne dass sich an deinem Text etwas ändert. Die Anleitung zum Umzug führt dich Schritt für Schritt hindurch, und die Vergleichsseite zeigt, wie sich die beiden Apps unterscheiden.