Obsidian-Konstruktionstechniken, die nur Genies und Top-Verdiener nutzen

Mit KI Geld verdienen hat nichts mit der "Anzahl der Notizen" zu tun

Lassen Sie uns zunächst sachlich diskutieren.

Es gibt keine Forschungsergebnisse, die einen kausalen Zusammenhang zwischen einem Jahreseinkommen von 100 Millionen Yen und einer Obsidian-Konfiguration belegen. Es gibt keine "geheimen Plugins, die nur den Reichen bekannt sind".

Was ich mit einem "100-Millionen-Yen-Spieler" meine, ist nicht jemand, der eine riesige Menge an Wissen speichert.

Es bezieht sich auf Menschen, die die gewonnenen Informationen umwandeln können in:

• Entscheidungsfindung
• Verhandlung
• Einstellung
• Investitionsentscheidungen
• Produktdesign
• Content
• Verkaufsunterlagen
• Organisationssysteme
• Wiederverwendbare intellektuelle Vermögenswerte

...mit extrem hoher Geschwindigkeit.

Gewöhnliche Obsidian-Nutzer denken darüber nach, "was sie speichern sollen."

Starke Nutzer denken zuerst darüber nach, "in welcher Situation, mit welcher Frage, werde ich diese Informationen in Zukunft abrufen?"

Noch stärkere Nutzer verfolgen, in welche Entscheidung oder Ausgabe das abgerufene Wissen letztendlich umgewandelt wurde.

Mit anderen Worten: Was Sie wirklich entwerfen sollten, ist kein "Second Brain."

Es ist ein Personal Intelligence OS, das Entscheidungsfindung und intellektuelle Produktion verstärkt.

Obsidian speichert Notizen als lokale Markdown-Dateien. Ein Vault ist nur ein Ordner, und Änderungen, die von externen Editoren oder Skripten vorgenommen werden, werden in Obsidian übernommen. Einstellungen und Plugin-Informationen werden im .obsidian-Ordner getrennt. Das bedeutet, Obsidian ist nicht nur eine App, sondern ein "Wissensrepository", das mit Git, CLI, Claude und Codex verwaltet werden kann.

In diesem Artikel behandeln wir Elemente in Obsidian wie folgt:

Sobald Sie diese Perspektive erreicht haben, ändert sich Ihre Art, Obsidian zu nutzen, vollständig.

Kapitel 1: Recherche internationaler Fallbeispiele – Die Gewinnstrategie war "Suche", nicht "Organisation"

1. Was aus den Vaults von 7 Forschern gelernt wurde

Es gibt eine 2025 veröffentlichte Fallstudie, die die Obsidian-Nutzung von sieben Informatikforschern an einem brasilianischen Forschungsinstitut untersucht.

Die wichtigste Erkenntnis dieser Studie war nicht, wie die Teilnehmer Notizen erstellten.

Es war die Entdeckung, dass die Art und Weise, wie sie sie in Zukunft abrufen wollten, stark beeinflusste, wie sie Notizen erstellten und organisierten. Die Teilnehmer verwendeten Suchleisten, Tag-Listen, Tags im Text und interne Links für verschiedene Zwecke. Einige Benutzer legten erstellte Notizen auch in einen Posteingang und verarbeiteten sie einmal pro Woche.

Die von den Forschern abgeleiteten Designvorschläge lassen sich in diesen drei Punkten zusammenfassen:

1. Verlangen Sie nicht von Anfang an eine perfekte Klassifizierung; bereiten Sie eine minimale Ausgangsstruktur vor.
2. Erlauben Sie, die Struktur während der Nutzung zu ändern.
3. Verbinden Sie die Erstellungs-/Organisationsmethode von Anfang an mit der zukünftigen Suchmethode.

Mit anderen Worten: Es geht nicht darum, "die richtigen Ordner zu erstellen."

Es geht darum zu entscheiden, wie Ihr zukünftiges Ich suchen wird, und entsprechend diesem Suchpfad aufzuzeichnen.

Allein dieser Punkt zeigt, dass die meisten gängigen Obsidian-Kurse rückwärtsgerichtet sind.

Viele Kurse lassen Sie zuerst Ordner, Tags, Plugins und das Erscheinungsbild festlegen.

In Wirklichkeit ist die Frage, die Sie zuerst entscheiden sollten, jedoch diese:

Worüber werde ich mich in drei Monaten Sorgen machen, wenn ich diese Informationen brauche?

2. Nicole van der Hoeven – Notizen zu einem karrierefördernden Lerninstrument machen

Nicole van der Hoeven, die als Developer Advocate und Performance Engineer arbeitet, gibt an, dass das kontinuierliche Notieren während der Arbeit positive Auswirkungen nicht nur auf die Lerngeschwindigkeit, sondern auch auf ihre Karriere in der Tech-Branche hatte.

Der Schlüssel liegt nicht darin, dass sie "eine schöne Wissensdatenbank erstellt hat."

Es ist, dass sie Lerninhalte während der Arbeit aufzeichnet und für öffentliches Teilen, Erklärungen und Präsentationen wiederverwendet.

Sie leitet Lernnotizen über persönliche Aufzeichnungen hinaus in:

• Präsentationen
• Artikel
• Videos
• Dokumente
• Lehrmaterialien
• den nächsten Job

Diese "Umwandlung von Input zu Output" schafft den wirtschaftlichen Wert von Wissen.

3. Bruno Paz – Lokal, Markdown, Minimale Plugins

Der Softwareentwickler Bruno Paz aggregiert alles von Code-Snippets, Meetings und Projektspezifikationen bis hin zu Forschung und Lebenswissen in Obsidian.

Wichtiger jedoch, als alles in Obsidian zu stecken, ist seine Designphilosophie.

Er betont die Portabilität von Markdown und die Versionsverwaltung über Git und verfolgt eine Politik, die Anzahl der Plugins minimal zu halten. Plugins machen Obsidian praktisch, aber der Inhalt selbst sollte nicht zu sehr von bestimmten Plugins abhängen.

Er standardisiert auch Frontmatter wie type mit Vorlagen, setzt Wikilinks zu verwandten Notizen in topics und listet sie mit Bases oder Dataview auf.

Die Schlussfolgerung hier ist klar:

Im Falle eines Falles nur mit Markdown wiederherstellen zu können, ist wichtiger als hochfunktional zu sein.

4. Ian O’Byrne – Informationsfluss von "Konsumieren → Kuratieren → Erstellen"

Ian O’Byrne, der Obsidian in Bildung und Forschung einsetzt, strukturiert seinen Vault grob in diesem Fluss:

• Konsumieren: Inputs wie Artikel, Bücher, Papiere, Podcasts
• Kuratieren: Destillieren von Kernpunkten, Verknüpfen, Erstellen von MOCs
• Erstellen: Outputs wie Blogs, Newsletter, Lehrmaterialien
• Meta: Betriebsinformationen für den Vault selbst

Worauf es ankommt, sind nicht die Ordnernamen.

Es ist die Struktur, in der Informationen vom Input über die Sinnstiftung zum Output gelangen. Er erklärt, dass der Prozess wichtiger ist als die Plattform und dass sich der Vault nach Bedarf weiterentwickelt.

Zusammenfassend haben diese internationalen Fallbeispiele fünf Gemeinsamkeiten exzellenter Vaults:

1. Retrieval-zuerst – Von zukünftigen Suchen rückwärts arbeiten
2. Output-zentriert – Auf Ergebnisse hinarbeiten, nicht nur auf Speicherung
3. Lokal-zuerst – Markdown als Quelle der Wahrheit verwenden
4. Minimales Schema – Eingabefelder nicht überkomplizieren
5. Evolutionär – Die Struktur während der Nutzung ändern

Kapitel 2: Sechs Metriken, die einen "100-Millionen-Yen-Vault" definieren

Die Anzahl der Notizen, die Anzahl der Links und die Schönheit des Graphen sind keine wesentlichen Leistungsmetriken.

Ich würde die Vault-Leistung mit diesen sechs Metriken messen:

1. Erfassungslatenz

Die Zeit von einer Idee bis zum Speichern.

Das Ziel ist innerhalb von 30 Sekunden. Eine Struktur, die Sie zwingt, zum Zeitpunkt der Eingabe über Tags, verwandte Notizen und Speicherorte nachzudenken, ist schwach.

2. Abrufzeit

Die Zeit, um benötigte Informationen zu erreichen.

Zielen Sie auf innerhalb von 30 Sekunden für allgemeine Informationen und innerhalb von 60 Sekunden für wichtige Entscheidungsaufzeichnungen.

3. Kosten der Kontextrekonstruktion

Die Zeit, um wiederherzustellen, worum es in einer Geschichte ging, wenn man alte Notizen betrachtet.

Eine Notiz nur mit einem Meeting-Titel ist schwach. Eine Notiz, die "Hintergrund", "Entscheidung", "Grund", "Prämisse" und "Nächster Schritt" bewahrt, ist stark.

4. Entscheidungsnachvollziehbarkeit

Der Prozentsatz wichtiger Beurteilungen, bei denen Sie später nachverfolgen können:

• Warum wurde entschieden
• Was wurde abgelehnt
• Welche Prämissen existierten
• Welche Bedingungen würden eine Umkehr auslösen

5. Output-Conversion-Rate

Der Prozentsatz gespeicherter Source Notes oder Evergreen Notes, die für Artikel, Vorschläge, Produkte, Entscheidungen, Meetings oder Verkaufsaktivitäten wiederverwendet wurden.

6. Agenten-Ausführbarkeit

Der Prozentsatz der Zeit, in der Claude oder Codex suchen, vorschlagen und verifizieren können, ohne die Vault-Regeln misszuverstehen.

Zusammenfassend lässt sich der ROI eines Wissenssystems wie folgt betrachten:

Wissens-ROI = (Wiederverwendetes Wissen + Verbesserte Entscheidungen + Vermiedene Fehler) / Zeitaufwand für Aufzeichnung, Organisation und Wartung

Selbst wenn die Anzahl der Notizen steigt, wächst, wenn sie nicht wiederverwendet werden, nur der Nenner.

Kapitel 3: Eine für japanische Benutzer geeignete Vault-Struktur

Wenn ich von Grund auf neu aufbauen würde, würde ich diese Top-Level-Struktur verwenden:

MyVault/

├── 00_Inbox/

│ ├── AI/

│ └── Clippings/

├── 10_Daily/

│ └── 2026/

├── 20_Projects/

├── 30_Areas/

├── 40_Notes/

│ └── MOCs/

├── 50_Sources/

├── 60_Entities/

│ ├── People/

│ ├── Companies/

│ └── Products/

├── 70_Outputs/

│ ├── Drafts/

│ └── Published/

├── 80_Assets/

├── 90_System/

│ ├── Templates/

│ ├── Bases/

│ ├── Schemas/

│ ├── AgentSkills/

│ └── AI/

├── 99_Archive/

├── scripts/

├── .claude/

├── .agents/

├── .codex/

├── CLAUDE.md

└── AGENTS.md

00_Inbox

Unklassifizierte Eingaben. Hier nicht organisieren. Tags sind im Allgemeinen unnötig. Dies ist ein Ort "nur zum Speichern."

10_Daily

Chronologische Arbeitsprotokolle. Hinterlassen Sie Memos, Gespräche, Erkenntnisse und Fortschritte, die es nicht wert sind, als eigenständige Notizen erstellt zu werden.

20_Projects

Aktivitäten mit einer Abschlussbedingung. "Umsatz steigern" ist ein Bereich oder ein Ziel, aber "Unternehmensplan-Preise bis September 2026 überarbeiten" ist ein Projekt. Projekte müssen immer einen next_action haben.

30_Areas

Laufende Verantwortungsbereiche. Management, Vertrieb, Einstellung, Finanzen, Gesundheit, Familie, Lernen usw. Bereiche bleiben bestehen, auch nachdem ein Projekt abgeschlossen ist.

40_Notes

Wissen zur langfristigen Wiederverwendung. Platzieren Sie hier Inhalte, die Sie in eigenen Worten erklären können, nicht nur Auszüge. Es ist nicht nötig, strikt "eine Notiz, ein Konzept" zu befolgen. Im Japanischen werden Subjekte und Prämissen leicht weggelassen, daher zerbricht übermäßige Fragmentierung den Kontext. Der Standard ist:

1 Notiz = Inhalt, den Sie als eine Einheit in Zukunft wiederverwenden möchten

50_Sources

Aufzeichnungen externer Informationen. Bücher, Papiere, Artikel, Videos, Meeting-Materialien, Forschungsdaten usw. Trennen Sie "was die andere Partei gesagt hat" von "wie ich es interpretiert habe."

60_Entities

Entitäten wie Personen, Unternehmen, Produkte, Kunden, Wettbewerber und Technologien. Selbst wenn dieselbe Person oder Firma in mehreren Projekten vorkommt, führen Sie nur eine Entity Note.

70_Outputs

Artikel, Planungsdokumente, Vorschläge, Videoskripte, Präsentationen, Verkaufsmaterialien, Produktspezifikationen usw. Es ist entscheidend, Outputs in einen unabhängigen Top-Level-Ordner zu legen. Ein nur auf Speicherung ausgerichteter Vault wird zum Friedhof des Wissens.

90_System

Mechanismen, die den Vault selbst betreiben, wie Vorlagen, Schemas, Bases, KI-Regeln und Skills. Indem Sie dies aufbauen, werden Sie in der Lage, Ihre eigenen Abläufe zu erklären.

Sollte es ein Vault sein?

Im Prinzip ja. Interne Links in Obsidian werden innerhalb eines Vaults aufgelöst; das Aufteilen von Vaults trennt Beziehungen zwischen Wissen. In der erwähnten Studie berichteten Teilnehmer, die ihren Vault in drei Teile aufteilten, von Suchverwirrung.

Trennen Sie jedoch physisch Folgendes:

• Informationen, bei denen die externe KI-Eingabe vertraglich verboten ist.
• Medizinische Daten, persönliche ID-Nummern, Zugangsdaten.
• Hochsensible HR-Informationen.
• Regulierte Daten.
• Informationen, die gemäß der Organisationsrichtlinie nicht an externe Modelle weitergegeben werden dürfen.

Denken Sie daran, einen "Persönlichen Vault" und einen "Regulierten Vault" zu trennen.

Kapitel 4: Vermischen Sie nicht die Rollen von Ordnern, Properties, Links und Tags

Der Hauptgrund, warum Obsidian-Systeme zusammenbrechen, ist, dass dieselbe Klassifikation gleichzeitig mit Ordnern, Tags, Properties und Links ausgedrückt wird. Legen Sie ihre Rollen wie folgt fest:

Ordner sind für den "Lebenszyklus"

Inbox, Project, Source, Output, Archive usw. Sie repräsentieren, in welcher Phase des Prozesses sich eine Notiz gerade befindet.

Properties sind für "maschinenverarbeitete Typen und Zustände"

type, status, created, project, revisit usw. Obsidian-Properties werden als YAML gespeichert und können Typen wie Text, Liste, Zahl, Checkbox, Datum, Datum/Uhrzeit und Tags haben.

Links sind für "semantische Beziehungen"

[[Pricing Strategy]], [[ABC Corp]], [[Reversibility of Decisions]] usw. Ein Thema zu einer Notiz anstelle eines Tags zu machen, erlaubt es diesem Thema selbst, Erklärungen, Gegenbeweise, Referenzmaterialien und MOCs zu enthalten.

Tags sind für "temporäre, querschnittliche Zustände"

Beschränken Sie Tags auf Dinge wie #review, #waiting, #question, #contradiction, #publish.

Konzepte wie "Marketing" oder "KI" sollten wann immer möglich Links sein. Die Verwendung von Tags als konzeptionelles Wörterbuch führt zur Tag-Vermehrung (z. B. #KI, #KünstlicheIntelligenz, #GenerativeKI). Verwenden Sie stattdessen Aliase in Konzeptnotizen.

Kapitel 5: Minimales Property-Schema

Versuchen Sie nicht, von Anfang an 20 Elemente auszufüllen. Teilen Sie das Schema in drei Stufen auf:

Erfassungsstufe

Nur das Wesentliche:
``yaml
type: inbox
created: 2026-07-24
status: inbox
``

Hochstufungsstufe

Hinzufügen, wenn es einen Wert für die Langzeitspeicherung erhält:
``yaml
type: note
created: 2026-07-24
status: active
topics:
- "[[Pricing Strategy]]"
- "[[B2B SaaS]]"
source_notes:
- "[[SRC Competitor Pricing Research 2026-07]]"
confidence: medium
sensitivity: internal
``

Betriebsstufe

Elemente hinzufügen, die für Projekte oder Entscheidungen benötigt werden:
``yaml
type: project
created: 2026-07-24
status: active
owner: me
area: "[[Management]]"
due: 2026-09-30
next_action: Compare annual plans of 5 competitors
``

Kapitel 6: Regeln für japanische Dateinamen

Es besteht keine Notwendigkeit, japanische Fließtexte oder Titel ins Englische zu zwingen. Behalten Sie jedoch Property-Namen und Ordnernamen, die für die maschinelle Verarbeitung verwendet werden, in ASCII bei. Ich verwende diese Namenskonventionen:

• Projekt: PJT Redesign of Corporate Pricing
• Entscheidung: DEC 2026-07-24 Make Annual Plan the Standard Proposal
• Evergreen Note: Price is Determined by Implementation Failure Risk Rather Than Feature Count

Machen Sie Evergreen Note-Titel zu "Behauptungen" anstelle von "Kategorienamen." Aussagekräftige Titel helfen Ihnen, sich allein anhand der Suchergebnisse an den Inhalt zu erinnern.

Kapitel 7: Tatsächlich einzubindende Vorlagen

Tägliche Notiz

Fügen Sie ein "Friction Log" (Reibungsprotokoll) hinzu. Das Aufzeichnen von "wonach ich gesucht, aber nicht gefunden habe" ermöglicht es Ihnen, den Vault basierend auf tatsächlichen Suchfehlern zu verbessern. Entwickeln Sie die Struktur aus fehlgeschlagenen Suchen weiter, nicht aus ästhetischen Vorlieben.

Projektnotiz

Eine Projektnotiz ist kein Lager für Aufgaben. Sie ist die Projektkommandozentrale, in der jeder den aktuellen Status in 30 Sekunden verstehen kann.

Entscheidungsnotiz

Bei profitabler Arbeit ist die Qualität der Entscheidungen wichtiger als Informationen. Daher sind Entscheidungsnotizen der wertvollste Notiztyp. Das wichtigste Feld ist der Umkehr-Auslöser. Ein exzellenter Entscheider ist jemand, der zum Zeitpunkt der Entscheidung niederschreiben kann, unter welchen Bedingungen er seine Meinung ändern würde.

Kapitel 8: MOCs sind "editierte Gedankenmodelle", keine Linklisten

Ein gutes MOC (Map of Content) enthält das Urteil des Herausgebers. Es ist ein editiertes kognitives Modell, das komprimiert, wie Sie ein gesamtes Feld derzeit verstehen, und nicht nur eine Liste verwandter Notizen.

Kapitel 9: Erstellen eines "Management-Dashboards" mit Bases

Obsidian Bases ist eine Kernfunktion, die es Ihnen ermöglicht, Notizen-Properties wie eine Datenbank anzuzeigen, zu filtern und zu sortieren. Verwenden Sie es, um eine "Aktive Projekte-Base" oder eine "Entscheidungsüberprüfungs-Base" zu erstellen, um Entscheidungen, die in der Schwebe hängen, wieder aufzugreifen.

Kapitel 10: Abgestufte Plugins

• Stufe 0 (Nur Kern): Properties, Templates, Daily Notes, Bases, Search, Canvas usw.
• Stufe 1 (Wenn Reibung entsteht): QuickAdd, Templater, Tasks.
• Stufe 2 (Nur wenn Bases nicht ausreicht): Dataview.

Halten Sie aktive Community-Plugins auf 12 oder weniger. Notieren Sie Zweck, Alternative und Löschbedingungen für jedes.

Kapitel 11: Die entscheidende Veränderung im Jahr 2026 – Offizielle Obsidian CLI

Ab Juli 2026 hat Obsidian eine offizielle CLI. Sie ermöglicht es, die Desktop-Version vom Terminal aus zu bedienen: Suchen, Lesen, Erstellen, Aktualisieren von Properties und Überprüfen von Aufgaben. Dies erlaubt Claude und Codex, mit Obsidians eigener Auflösungslogik zu operieren, anstatt nur Markdown direkt zu bearbeiten.

Kapitel 12: Die richtige Struktur für einen KI-nativen Vault

KI freien Lauf zu lassen, um alle Notizen zu bearbeiten, ist keine "KI-Nutzung". Das ist, als würde man alle Firmendokumente einem ungeprüften Praktikanten übergeben. Die richtige Arbeitsteilung ist:

• Mensch: Ziele, Werturteile, endgültige Genehmigung, MOC-Bearbeitung.
• Obsidian: Quelle der Wahrheit, Beziehungen, Historie, Ansichten.
• Claude: Destillieren von Bedeutung, Vergleich, Gegenargumente, Entwürfe.
• Codex: Strukturelle Änderungen, Skripte, Validierung, Diff-Reviews.
• Git: Wiederherstellung, Prüfung, Isolierung von Experimenten.
• Validator: Erkennung von Schemaverstößen und Link-Anomalien.

Kapitel 13: Platzieren von CLAUDE.md und AGENTS.md

Claude Code liest CLAUDE.md als fortlaufende Anweisungen. Codex sucht nach AGENTS.md. Platzieren Sie einen "Vault-Betriebsvertrag" in diesen Dateien, um Sprache (Japanische Prosa, ASCII-Properties), Sicherheitsregeln (standardmäßig Trockenlauf) und Schema-Regeln zu definieren.

Kapitel 14: Obsidian-Aufgaben durch Claude in Skills verwandeln

Definieren Sie "Agent Skills" für Aufgaben, die Sie mehr als dreimal erledigen oder für standardisierte Qualität. Ein obsidian-distill-Skill kann beispielsweise rohe Meeting-Notizen in Entscheidungen, Aufgaben und Evergreen Notes umwandeln. Ein guter Skill ist ein wiederausführbarer Arbeitsstandard mit expliziten Eingaben, Verfahren, Verboten und Abschlussbedingungen.

Kapitel 17: Kollaborationsmuster für Claude, Codex und Obsidian CLI

• Muster 1: Meeting-Notiz-Destillation (Claude extrahiert Entscheidungen/Aufgaben).
• Muster 2: Wöchentliches Management-Review (Claude fasst den Wochenfortschritt und ins Stocken geratene Projekte zusammen).
• Muster 3: Schema-Drift-Audit (Codex erkennt Property-Inkonsistenzen).
• Muster 4: Entscheidungsprämissen-Audit (Claude prüft, ob die Annahmen hinter vergangenen Entscheidungen noch gültig sind).

Dies ist eine Nutzung, die über das "Zusammenfassen von Notizen mit KI" hinausgeht. Sie nutzen KI als intellektuellen Controller, der Ihre vergangenen Urteile prüft.

Kapitel 18: Einbinden eines Vault-Validators

Wenn KI Ihren Vault bearbeitet, geben Sie sich nicht mit "sieht okay aus" zufrieden. Implementieren Sie minimale statische Tests über Skripte (z. B. vault_check.py), um erlaubte Typen, Status und erforderliche Properties zu überprüfen.