Tecniche di costruzione su Obsidian utilizzate solo da geni e persone ad alto reddito

Ecco la traduzione del testo in italiano, seguendo fedelmente tutte le linee guida fornite.

Guadagnare con l'AI non è una questione di "numero di note"

Prima di tutto, facciamo una discussione tranquilla.

Non esistono ricerche che suggeriscano una relazione causale tra un reddito annuo di 100 milioni di yen e una configurazione di Obsidian. Non esistono "plugin segreti conosciuti solo dai ricchi."

Quello che intendo per "giocatore da 100 milioni di yen" non è qualcuno che accumula una quantità enorme di conoscenza.

Si riferisce a persone che riescono a convertire le informazioni che ottengono in:

• Processo decisionale
• Negoziazione
• Assunzioni
• Giudizio di investimento
• Progettazione di prodotto
• Contenuti
• Materiali di vendita
• Sistemi organizzativi
• Asset intellettuali riutilizzabili

...a una velocità estremamente elevata.

Gli utenti comuni di Obsidian pensano a "cosa salvare."

Gli utenti esperti pensano prima a "in quale situazione, usando quale domanda, recupererò queste informazioni in futuro?"

Gli utenti ancora più esperti tengono traccia di quale decisione o output quella conoscenza recuperata ha poi generato.

In altre parole, ciò che dovresti realmente progettare non è un "Secondo Cervello."

È un Sistema Operativo di Intelligenza Personale che capitalizza il processo decisionale e la produzione intellettuale.

Obsidian salva le note come file Markdown locali. Un Vault è solo una cartella, e le modifiche apportate da editor esterni o script si riflettono in Obsidian. Le impostazioni e le informazioni sui plugin sono separate nella cartella .obsidian. Questo significa che Obsidian non è solo un'app, ma un "repository di conoscenza" gestibile con Git, CLI, Claude e Codex.

In questo articolo, trattiamo gli elementi di Obsidian come segue:

Una volta raggiunta questa prospettiva, il tuo modo di usare Obsidian cambia completamente.

Capitolo 1: Ricercare Casi Internazionali—La Strategia Vincente era la "Ricerca," non l'"Organizzazione"

1. Cosa è stato appreso dai Vault di 7 Ricercatori

Esiste un caso di studio pubblicato nel 2025 che indaga l'uso di Obsidian da parte di sette ricercatori di informatica presso un istituto di ricerca brasiliano.

L'insegnamento più importante di questo studio non è stato come i partecipanti creavano le note.

È stata la scoperta che il modo in cui intendevano recuperarle in futuro influenzava fortemente il modo in cui le creavano e organizzavano. I partecipanti usavano barre di ricerca, elenchi di tag, tag all'interno del testo e link interni per scopi diversi. Alcuni utenti mettevano anche le note create in una Casella di Posta e le processavano una volta a settimana.

Le proposte di design derivate dai ricercatori possono essere riassunte in questi tre punti:

1. Non richiedere una classificazione perfetta dall'inizio; prepara una struttura iniziale minima.
2. Permetti che la struttura venga modificata durante l'uso.
3. Collega il metodo di creazione/organizzazione con il metodo di ricerca futuro fin dall'inizio.

In altre parole, non si tratta di "creare le cartelle corrette."

Si tratta di decidere come il tuo io futuro cercherà e di registrare in base a quel percorso di ricerca.

Questo solo punto mostra che la maggior parte dei corsi comuni su Obsidian sono sbagliati.

Molti corsi ti fanno decidere prima cartelle, tag, plugin e aspetto.

Tuttavia, in realtà, la domanda che dovresti decidere per prima è questa:

Tra tre mesi, cosa mi preoccuperà quando avrò bisogno di queste informazioni?

2. Nicole van der Hoeven—Trasformare le Note in un Dispositivo di Apprendimento per la Carriera

Nicole van der Hoeven, che lavora come Developer Advocate e Performance Engineer, afferma che prendere appunti continui sul lavoro ha avuto un impatto positivo non solo sulla velocità di apprendimento, ma anche sulla sua carriera nel settore tecnologico.

Il punto chiave non è che lei "ha creato un bellissimo database di conoscenza."

È che lei registra l'apprendimento durante il lavoro e lo riutilizza per condivisione pubblica, spiegazioni e presentazioni.

Lei fa fluire le note di apprendimento oltre i semplici registri personali in:

• Presentazioni
• Articoli
• Video
• Documenti
• Materiali didattici
• Il lavoro successivo

Questa "conversione da input a output" crea il valore economico della conoscenza.

3. Bruno Paz—Locale, Markdown, Plugin Minimi

L'ingegnere informatico Bruno Paz aggrega tutto, da snippet di codice, riunioni e specifiche di progetto a ricerche e conoscenza sulla vita, in Obsidian.

Tuttavia, più importante che mettere tutto in Obsidian è la sua filosofia di design.

Enfatizza la portabilità del Markdown e la gestione della cronologia tramite Git, adottando la politica di mantenere il numero di plugin al minimo. I plugin rendono Obsidian comodo, ma il contenuto stesso non dovrebbe dipendere troppo da plugin specifici.

Standardizza anche Frontmatter come type con i template, mette Wikilink alle note correlate in topics e li elenca con Bases o Dataview.

La conclusione qui è chiara:

Essere in grado di recuperare con solo Markdown quando le cose si rompono è più importante che essere iper-funzionale.

4. Ian O'Byrne—Far Fluire le Informazioni da "Consuma → Cura → Crea"

Ian O'Byrne, che usa Obsidian nell'istruzione e nella ricerca, struttura il suo Vault più o meno in questo flusso:

• Consuma: Input come articoli, libri, paper, podcast
• Cura: Distillare i punti chiave, metterli in relazione, creare MOC
• Crea: Output come blog, newsletter, materiali didattici
• Meta: Info operative per il Vault stesso

Ciò che conta non sono i nomi delle cartelle.

È la struttura in cui le informazioni si muovono dall'input, attraverso la creazione di significato, fino all'output. Lui spiega che il processo è più importante della piattaforma e che il Vault si evolve secondo necessità.

Riassumendo questi casi internazionali, i Vault eccellenti hanno cinque caratteristiche comuni:

1. Ricerca al primo posto—Lavora a ritroso dalle ricerche future
2. Centrato sull'output—Fluisci verso i risultati finali, non solo l'archiviazione
3. Locale al primo posto—Usa Markdown come fonte di verità
4. Schema minimo—Non complicare eccessivamente i campi di input
5. Evolutivo—Cambia la struttura mentre la usi

Capitolo 2: Sei Metriche che Definiscono un "Vault da 100 Milioni di Yen"

Il numero di note, il numero di link e la bellezza del Grafico non sono metriche di performance essenziali.

Misurerei la performance del Vault con queste sei metriche:

1. Latenza di Acquisizione

Il tempo che intercorre tra l'avere un'idea e il salvarla.

L'obiettivo è entro 30 secondi. Una struttura che ti obbliga a pensare a tag, note correlate e posizioni di salvataggio al momento dell'input è debole.

2. Tempo di Recupero

Il tempo necessario per raggiungere le informazioni necessarie.

Punta a entro 30 secondi per informazioni generali ed entro 60 secondi per registrazioni di decisioni importanti.

3. Costo di Ricostruzione del Contesto

Il tempo necessario per ripristinare di cosa parlava una storia quando si guardano note vecchie.

Una nota con solo un titolo di riunione è debole. Una nota che preserva "Contesto," "Decisione," "Motivo," "Premessa" e "Azione Successiva" è forte.

4. Tracciabilità delle Decisioni

La percentuale di giudizi importanti per cui puoi successivamente tracciare:

• Perché è stato deciso
• Cosa è stato rifiutato
• Quali premesse esistevano
• Quali condizioni attiverebbero un'inversione di rotta

5. Tasso di Conversione in Output

La percentuale di Note Sorgente o Note Evergreen memorizzate che sono state riutilizzate per articoli, proposte, prodotti, decisioni, riunioni o attività di vendita.

6. Eseguibilità da Parte degli Agenti

La percentuale di tempo in cui Claude o Codex possono cercare, proporre e verificare senza fraintendere le regole del Vault.

Riassumendo, il ROI di un sistema di conoscenza può essere pensato come segue:

ROI della Conoscenza = (Conoscenza Riutilizzata + Decisioni Migliorate + Fallimenti Evitati) / Tempo speso per registrare, organizzare e manutenere

Anche se il numero di note aumenta, se non vengono riutilizzate, solo il denominatore sta crescendo.

Capitolo 3: Una Struttura di Vault Facile per gli Utenti Italiani

Se stessi costruendo da zero, userei questa struttura di primo livello:

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

Input non classificati. Non organizzare qui. I tag sono generalmente inutili. Questo è un posto "solo per salvare."

10_Daily

Registri di lavoro cronologici. Lascia appunti, conversazioni, realizzazioni e progressi che non meritano di creare note indipendenti.

20_Projects

Attività con una condizione di completamento. "Aumentare le vendite" è un'Area o un Obiettivo, ma "Revisionare i prezzi del piano aziendale entro settembre 2026" è un Progetto. I progetti devono sempre avere una next_action.

30_Areas

Aree di responsabilità continue. Gestione, vendite, assunzioni, finanza, salute, famiglia, apprendimento, ecc. Le Aree rimangono anche dopo che un Progetto è completato.

40_Notes

Conoscenza per il riutilizzo a lungo termine. Metti qui contenuti che puoi spiegare con parole tue, non solo estratti. Non c'è bisogno di seguire rigorosamente "una nota, un concetto." In italiano, soggetti e premesse vengono facilmente omessi, quindi un'eccessiva frammentazione rompe il contesto. Lo standard è:

1 Nota = Contenuto che vuoi riutilizzare come unità singola in futuro

50_Sources

Registrazioni di informazioni esterne. Libri, paper, articoli, video, materiali di riunioni, dati di ricerca, ecc. Separa "cosa ha detto l'altra parte" da "come l'ho interpretato."

60_Entities

Entità come persone, aziende, prodotti, clienti, concorrenti e tecnologie. Anche se la stessa persona o azienda appare in più progetti, mantieni una sola Nota Entità.

70_Outputs

Articoli, documenti di pianificazione, proposte, script video, presentazioni, materiali di vendita, specifiche di prodotto, ecc. È fondamentale posizionare gli Output in una cartella di primo livello indipendente. Un Vault mirato solo all'archiviazione diventa un cimitero della conoscenza.

90_System

Meccanismi che gestiscono il Vault stesso, come template, Schemas, Bases, regole AI e Skills. Costruendo questo, diventi in grado di spiegare le tue stesse operazioni.

Dovrebbe essere un Vault unico?

In linea di principio, sì. I link interni in Obsidian vengono risolti all'interno di un Vault; la suddivisione in Vault disconnette le relazioni tra le conoscenze. Nello studio menzionato, i partecipanti che avevano suddiviso il loro Vault in tre hanno riportato confusione nella ricerca.

Tuttavia, separa fisicamente quanto segue:

• Informazioni per cui l'input AI esterno è vietato da contratto.
• Dati medici, numeri di identificazione personale, credenziali.
• Informazioni HR altamente sensibili.
• Dati regolamentati.
• Info che non possono essere passate a modelli esterni secondo la politica organizzativa.

Pensala come separare un "Vault Personale" e un "Vault Regolamentato."

Capitolo 4: Non Mescolare i Ruoli di Cartelle, Properties, Link e Tag

Il motivo principale per cui i sistemi Obsidian crollano è esprimere la stessa classificazione usando contemporaneamente cartelle, tag, properties e link. Assegna i loro ruoli come segue:

Le Cartelle sono per il "Ciclo di Vita"

Inbox, Project, Source, Output, Archive, ecc. Rappresentano in quale fase del processo si trova attualmente una nota.

Le Properties sono per "Tipi e Stati Gestiti dalla Macchina"

type, status, created, project, revisit, ecc. Le Properties di Obsidian vengono salvate come YAML e possono avere tipi come text, list, number, checkbox, date, datetime e tags.

I Link sono per "Relazioni Semantiche"

[[Strategia di Prezzo]], [[Società ABC]], [[Reversibilità delle Decisioni]], ecc. Rendere un argomento una nota invece di un tag permette a quell'argomento stesso di contenere spiegazioni, controprove, materiali di riferimento e MOC.

I Tag sono per "Stati Trasversali Temporanei"

Limita i tag a cose come #review, #waiting, #question, #contradiction, #publish.

Concetti come "Marketing" o "AI" dovrebbero essere link quando possibile. Usare i tag come dizionario concettuale porta alla proliferazione dei tag (es., #AI, #IntelligenzaArtificiale, #AIgenerativa). Invece, usa gli Alias nelle note concettuali.

Capitolo 5: Schema di Properties Minimo

Non cercare di riempire 20 voci dall'inizio. Suddividi lo Schema in tre fasi:

Fase di Acquisizione

Solo l'essenziale:
``yaml
type: inbox
created: 2026-07-24
status: inbox
``

Fase di Promozione

Aggiungi quando acquisisce valore per la conservazione a lungo termine:
``yaml
type: note
created: 2026-07-24
status: active
topics:
- "[[Strategia di Prezzo]]"
- "[[B2B SaaS]]"
source_notes:
- "[[SRC Ricerca Prezzi Concorrenti 2026-07]]"
confidence: medium
sensitivity: internal
``

Fase Operativa

Aggiungi voci necessarie per Progetti o Decisioni:
``yaml
type: project
created: 2026-07-24
status: active
owner: me
area: "[[Gestione]]"
due: 2026-09-30
next_action: Confrontare i piani annuali di 5 concorrenti
``

Capitolo 6: Regole per i Nomi File in Italiano

Non c'è bisogno di forzare il testo del corpo o i titoli in italiano in inglese. Tuttavia, mantieni i nomi delle Properties e i nomi delle cartelle usati per l'elaborazione automatica in ASCII. Io uso queste convenzioni di denominazione:

• Progetto: PJT Ridisegno Prezzi Aziendali
• Decisione: DEC 2026-07-24 Rendere il Piano Annuale la Proposta Standard
• Nota Evergreen: Il Prezzo è Determinato dal Rischio di Fallimento dell'Implementazione Piuttosto che dal Numero di Funzionalità

Rendi i titoli delle Note Evergreen "Affermazioni" piuttosto che "Nomi di Categorie." I titoli assertivi ti aiutano a ricordare il contenuto solo dai risultati di ricerca.

Capitolo 7: Template da Includere Effettivamente

Nota Quotidiana

Includi un "Registro degli Attriti." Registrare "cosa ho cercato ma non sono riuscito a trovare" ti permette di migliorare il Vault basandoti sui fallimenti di ricerca reali. Evolvi la struttura dai fallimenti di ricerca, non dalle preferenze estetiche.

Nota di Progetto

Una Nota di Progetto non è un magazzino per le attività. È il Centro di Comando del Progetto dove chiunque può capire lo stato attuale in 30 secondi.

Nota di Decisione

Nel lavoro ad alto profitto, la qualità delle decisioni è più importante delle informazioni. Quindi, le Note di Decisione sono il tipo di nota più prezioso. Il campo più importante è il Trigger di Inversione. Un eccellente decisore è qualcuno che sa scrivere al momento della decisione in quali condizioni cambierebbe idea.

Capitolo 8: Le MOC sono "Modelli di Pensiero Modificati," Non Elenchi di Link

Una buona MOC (Mappa dei Contenuti) contiene il giudizio del curatore. È un modello cognitivo modificato che comprime la tua attuale comprensione di un intero campo, piuttosto che solo un elenco di note correlate.

Capitolo 9: Creare una "Dashboard di Gestione" con le Bases

Obsidian Bases è una funzionalità principale che ti permette di visualizzare, filtrare e ordinare le Properties delle note come un database. Usala per creare una "Base Progetti Attivi" o una "Base Revisione Decisioni" per recuperare giudizi rimasti in sospeso.

Capitolo 10: Plugin a Livelli

• Livello 0 (Solo Core): Properties, Templates, Daily Notes, Bases, Search, Canvas, ecc.
• Livello 1 (Quando sorge attrito): QuickAdd, Templater, Tasks.
• Livello 2 (Solo se Bases non basta): Dataview.

Mantieni i Community Plugin attivi a 12 o meno. Registra lo scopo, l'alternativa e le condizioni di eliminazione per ciascuno.

Capitolo 11: Il Cambiamento Decisivo del 2026—CLI Ufficiale di Obsidian

Da luglio 2026, Obsidian ha una CLI ufficiale. Permette di operare sulla versione desktop dal terminale: cercare, leggere, creare, aggiornare properties e controllare le attività. Questo permette a Claude e Codex di operare usando la logica di risoluzione propria di Obsidian, piuttosto che modificare direttamente il Markdown.

Capitolo 12: La Struttura Corretta per un Vault AI-Nativo

Permettere all'AI di modificare liberamente tutte le note non è "utilizzo dell'AI." È come consegnare tutti i documenti aziendali a uno stagista non verificato. La corretta divisione del lavoro è:

• Umano: Obiettivi, giudizi di valore, approvazione finale, modifica delle MOC.
• Obsidian: Fonte di verità, relazioni, cronologia, viste.
• Claude: Distillazione del significato, confronto, controargomentazioni, bozze.
• Codex: Modifiche strutturali, script, validazione, revisioni diff.
• Git: Ripristino, auditing, isolamento degli esperimenti.
• Validatore: Rilevamento di violazioni dello schema e anomalie nei link.

Capitolo 13: Posizionare CLAUDE.md e AGENTS.md

Claude Code legge CLAUDE.md come istruzioni continue. Codex cerca AGENTS.md. Posiziona un "Contratto Operativo del Vault" in questi file per definire la lingua (italiano per il testo, ASCII per le properties), le regole di sicurezza (dry-run di default) e le regole dello schema.

Capitolo 14: Trasformare le Attività di Obsidian in Skills tramite Claude

Definisci "Agent Skills" per le attività che svolgi più di tre volte o per una qualità standardizzata. Ad esempio, una skill obsidian-distill può convertire note grezze di riunioni in Decisioni, Attività e Note Evergreen. Una buona Skill è uno standard di lavoro rieseguibile con input, procedure, divieti e condizioni di completamento espliciti.

Capitolo 17: Modelli di Collaborazione per Claude, Codex e CLI di Obsidian

• Modello 1: Distillazione di Note di Riunione (Claude estrae decisioni/attività).
• Modello 2: Revisione di Gestione Settimanale (Claude riassume i progressi della settimana e i progetti in stallo).
• Modello 3: Audit di Deriva dello Schema (Codex rileva incoerenze nelle properties).
• Modello 4: Audit delle Premesse Decisionali (Claude verifica se le ipotesi alla base di decisioni passate sono ancora valide).

Questo è un uso che va oltre il "riassumere note con l'AI." Usi l'AI come un controllore intellettuale che verifica i tuoi giudizi passati.

Capitolo 18: Includere un Validatore del Vault

Se l'AI sta modificando il tuo Vault, non accontentarti di "sembra a posto." Implementa test statici minimi tramite script (es., vault_check.py) per verificare i tipi consentiti, gli stati e le properties richieste.