Técnicas de Construção no Obsidian Usadas Apenas por Gênios e Pessoas de Alta Renda

Ganhar Dinheiro com IA Não é Sobre a "Quantidade de Notas"

Primeiro, vamos ter uma conversa calma.

Não existe nenhuma pesquisa sugerindo uma relação causal entre uma renda anual de 100 milhões de ienes e uma configuração do Obsidian. Não existem "plugins secretos conhecidos apenas pelos ricos."

O que quero dizer com "jogador de 100 milhões de ienes" não é alguém que armazena uma quantidade massiva de conhecimento.

Refere-se a pessoas que conseguem converter as informações que obtêm em:

• Tomada de decisão
• Negociação
• Contratação
• Julgamento de investimento
• Design de produto
• Conteúdo
• Materiais de vendas
• Sistemas organizacionais
• Ativos intelectuais reutilizáveis

...com uma velocidade extremamente alta.

Usuários comuns do Obsidian pensam sobre "o que salvar."

Usuários fortes pensam primeiro sobre "em que situação, usando qual pergunta, irei recuperar esta informação no futuro?"

Usuários ainda mais fortes rastreiam em que decisão ou resultado aquele conhecimento recuperado eventualmente se converteu.

Em outras palavras, o que você realmente deveria projetar não é um "Segundo Cérebro."

É um SO de Inteligência Pessoal que capitaliza a tomada de decisão e a produção intelectual.

O Obsidian salva notas como arquivos Markdown locais. Um Vault é apenas uma pasta, e alterações feitas em editores externos ou scripts são refletidas no Obsidian. As configurações e informações dos plugins são separadas na pasta .obsidian. Isso significa que o Obsidian não é apenas um aplicativo, mas um "repositório de conhecimento" que pode ser manipulado por Git, CLI, Claude e Codex.

Neste artigo, tratamos os elementos do Obsidian da seguinte forma:

Quando você atinge essa perspectiva, sua forma de usar o Obsidian muda completamente.

Capítulo 1: Pesquisando Casos Internacionais—A Estratégia Vencedora era "Busca," Não "Organização"

1. O que foi Aprendido com os Vaults de 7 Pesquisadores

Existe um estudo de caso publicado em 2025 investigando o uso do Obsidian por sete pesquisadores de ciência da computação em um instituto de pesquisa brasileiro.

A conclusão mais importante deste estudo não foi como os participantes criavam notas.

Foi a descoberta de que a forma como pretendiam recuperá-las no futuro influenciava fortemente como criavam e organizavam as notas. Os participantes usavam barras de pesquisa, listas de tags, tags dentro do texto e links internos para diferentes propósitos. Alguns usuários também colocavam as notas criadas em uma Caixa de Entrada e as processavam uma vez por semana.

As propostas de design derivadas pelos pesquisadores podem ser resumidas nestes três pontos:

1. Não exija classificação perfeita desde o início; prepare uma estrutura inicial mínima.
2. Permita que a estrutura seja alterada durante o uso.
3. Conecte o método de criação/organização com o método de busca futuro desde o início.

Em outras palavras, não se trata de "criar as pastas corretas."

Trata-se de decidir como seu eu futuro irá pesquisar e registrar de acordo com esse caminho de busca.

Só este ponto já mostra que a maioria dos cursos comuns de Obsidian estão ao contrário.

Muitos cursos fazem você decidir sobre pastas, tags, plugins e aparência primeiro.

No entanto, na realidade, a pergunta que você deve decidir primeiro é esta:

Daqui a três meses, com o que estarei me preocupando quando precisar desta informação?

2. Nicole van der Hoeven—Transformando Notas em um Dispositivo de Aprendizagem de Carreira

Nicole van der Hoeven, que trabalha como Developer Advocate e Performance Engineer, afirma que fazer anotações contínuas sobre o trabalho teve um impacto positivo não apenas na velocidade de aprendizado, mas também em sua carreira na indústria de tecnologia.

O ponto chave não é que ela "criou um belo banco de dados de conhecimento."

É que ela registra o aprendizado durante o trabalho e o reutiliza para compartilhamento público, explicações e apresentações.

Ela faz fluir as notas de aprendizado, além de meros registros pessoais, para:

• Apresentações
• Artigos
• Vídeos
• Documentos
• Materiais educacionais
• O próximo trabalho

Essa "conversão de entrada em saída" cria o valor econômico do conhecimento.

3. Bruno Paz—Local, Markdown, Plugins Mínimos

O engenheiro de software Bruno Paz agrega tudo, desde snippets de código, reuniões e especificações de projetos até pesquisa e conhecimento de vida, no Obsidian.

No entanto, mais importante do que colocar tudo no Obsidian é sua filosofia de design.

Ele enfatiza a portabilidade do Markdown e o gerenciamento de histórico via Git, adotando uma política de manter o número de plugins ao mínimo. Os plugins tornam o Obsidian conveniente, mas o conteúdo em si não deve depender muito de plugins específicos.

Ele também padroniza o Frontmatter como type com templates, coloca Wikilinks para notas relacionadas em topics e os lista com Bases ou Dataview.

A conclusão aqui é clara:

Ser capaz de recuperar apenas com Markdown quando algo quebra é mais importante do que ser cheio de funcionalidades.

4. Ian O'Byrne—Fazendo Fluir a Informação de "Consumir → Curar → Criar"

Ian O'Byrne, que usa o Obsidian na educação e pesquisa, estrutura seu Vault aproximadamente neste fluxo:

• Consumir: Entradas como artigos, livros, artigos acadêmicos, podcasts
• Curar: Destilando pontos-chave, relacionando-os, criando MOCs
• Criar: Saídas como blogs, newsletters, materiais de ensino
• Meta: Informações operacionais para o próprio Vault

O que importa não são os nomes das pastas.

É a estrutura onde a informação se move da entrada, através da criação de significado, para a saída. Ele explica que o processo é mais importante que a plataforma e que o Vault evolui conforme necessário.

Resumindo esses casos internacionais, Vaults excelentes têm cinco características em comum:

1. Prioridade na recuperação—Trabalhe de trás para frente a partir de buscas futuras
2. Foco na saída—Flua em direção a entregáveis, não apenas armazenamento
3. Primeiro local—Use Markdown como a fonte da verdade
4. Esquema mínimo—Não complique demais os campos de entrada
5. Evolutivo—Mude a estrutura enquanto a usa

Capítulo 2: Seis Métricas que Definem um "Vault de 100 Milhões de Ienes"

O número de notas, o número de links e a beleza do Grafo não são métricas de desempenho essenciais.

Eu mediria o desempenho do Vault com estas seis métricas:

1. Latência de Captura

O tempo desde ter uma ideia até salvá-la.

O objetivo é dentro de 30 segundos. Uma estrutura que força você a pensar sobre tags, notas relacionadas e locais de salvamento no momento da entrada é fraca.

2. Tempo de Recuperação

O tempo necessário para alcançar a informação necessária.

Mire em dentro de 30 segundos para informações gerais e dentro de 60 segundos para registros importantes de decisão.

3. Custo de Reconstrução de Contexto

O tempo para restaurar sobre o que era uma história ao olhar para notas antigas.

Uma nota com apenas um título de reunião é fraca. Uma nota que preserva "Contexto," "Decisão," "Motivo," "Premissa" e "Próxima Ação" é forte.

4. Rastreabilidade de Decisão

A porcentagem de julgamentos importantes onde você pode posteriormente rastrear:

• Por que foi decidido
• O que foi rejeitado
• Que premissas existiam
• Que condições acionariam uma reversão

5. Taxa de Conversão em Saída

A porcentagem de Notas Fonte ou Notas Perenes armazenadas que foram reutilizadas para artigos, propostas, produtos, decisões, reuniões ou atividades de vendas.

6. Executabilidade por Agente

A porcentagem de vezes que o Claude ou Codex podem pesquisar, propor e verificar sem entender mal as regras do Vault.

Resumindo, o ROI de um sistema de conhecimento pode ser pensado da seguinte forma:

ROI do Conhecimento = (Conhecimento Reutilizado + Decisões Melhoradas + Falhas Evitadas) / Tempo gasto em registro, organização e manutenção

Mesmo que o número de notas aumente, se elas não forem reutilizadas, apenas o denominador está crescendo.

Capítulo 3: Uma Estrutura de Vault Fácil para Usuários Brasileiros

Se eu estivesse construindo do zero, usaria esta estrutura de nível superior:

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

Entradas não classificadas. Não organize aqui. Tags são geralmente desnecessárias. Este é um lugar "apenas para salvar."

10_Daily

Registros de trabalho cronológicos. Deixe memorandos, conversas, percepções e progressos que não valem a pena criar notas independentes.

20_Projects

Atividades com uma condição de conclusão. "Aumentar vendas" é uma Área ou Meta, mas "Revisar precificação do plano corporativo até setembro de 2026" é um Projeto. Projetos devem sempre ter um next_action.

30_Areas

Áreas contínuas de responsabilidade. Gestão, vendas, contratação, finanças, saúde, família, aprendizado, etc. As Áreas permanecem mesmo após um Projeto ser concluído.

40_Notes

Conhecimento para reutilização a longo prazo. Coloque aqui conteúdo que você pode explicar com suas próprias palavras, não apenas trechos. Não há necessidade de seguir rigorosamente "uma nota, um conceito." Em português, sujeitos e premissas são facilmente omitidos, então fragmentar demais quebra o contexto. O padrão é:

1 Nota = Conteúdo que você deseja reutilizar como uma unidade única no futuro

50_Sources

Registros de informações externas. Livros, artigos acadêmicos, artigos, vídeos, materiais de reunião, dados de pesquisa, etc. Separe "o que a outra parte disse" de "como eu interpretei."

60_Entities

Entidades como pessoas, empresas, produtos, clientes, concorrentes e tecnologias. Mesmo que a mesma pessoa ou empresa apareça em múltiplos projetos, mantenha apenas uma Nota de Entidade.

70_Outputs

Artigos, documentos de planejamento, propostas, roteiros de vídeo, apresentações, materiais de vendas, especificações de produto, etc. É crucial colocar as Saídas em uma pasta independente de nível superior. Um Vault voltado apenas para armazenamento se torna um cemitério de conhecimento.

90_System

Mecanismos que executam o próprio Vault, como templates, Schemas, Bases, regras de IA e Skills. Ao construir isso, você se torna capaz de explicar suas próprias operações.

Deve ser um único Vault?

Em princípio, sim. Os links internos no Obsidian são resolvidos dentro de um Vault; dividir Vaults desconecta relacionamentos entre o conhecimento. No estudo mencionado, participantes que dividiram seu Vault em três relataram confusão na busca.

No entanto, separe fisicamente o seguinte:

• Informações onde a entrada de IA externa é proibida por contrato.
• Dados médicos, números de identificação pessoal, credenciais.
• Informações de RH altamente sensíveis.
• Dados regulamentados.
• Informações que não podem ser passadas para modelos externos de acordo com a política organizacional.

Pense nisso como separar um "Vault Pessoal" e um "Vault Regulamentado."

Capítulo 4: Não Misture as Funções de Pastas, Properties, Links e Tags

A maior razão pela qual os sistemas do Obsidian colapsam é expressar a mesma classificação usando pastas, tags, properties e links todos ao mesmo tempo. Fixe suas funções da seguinte forma:

Pastas são para o "Ciclo de Vida"

Inbox, Project, Source, Output, Archive, etc. Elas representam em qual estágio do processo uma nota se encontra atualmente.

Properties são para "Tipos e Estados Manipulados por Máquina"

type, status, created, project, revisit, etc. As Properties do Obsidian são salvas como YAML e podem ter tipos como texto, lista, número, checkbox, data, datetime e tags.

Links são para "Relações Semânticas"

[[Estratégia de Precificação]], [[ABC Corp]], [[Reversibilidade de Decisões]], etc. Tornar um tópico uma nota em vez de uma tag permite que esse tópico em si contenha explicações, contra-evidências, materiais de referência e MOCs.

Tags são para "Estados Transitórios Transversais"

Limite as tags a coisas como #review, #waiting, #question, #contradiction, #publish.

Conceitos como "Marketing" ou "IA" devem ser links sempre que possível. Usar tags como um dicionário conceitual leva à proliferação de tags (ex: #IA, #InteligenciaArtificial, #IAGenerativa). Em vez disso, use Apelidos em notas de conceito.

Capítulo 5: Esquema Mínimo de Properties

Não tente preencher 20 itens desde o início. Divida o Schema em três estágios:

Estágio de Captura

Apenas o essencial:
``yaml
type: inbox
created: 2026-07-24
status: inbox
``

Estágio Promovido

Adicione quando ganhar valor para armazenamento de longo prazo:
``yaml
type: note
created: 2026-07-24
status: active
topics:
- "[[Estratégia de Precificação]]"
- "[[B2B SaaS]]"
source_notes:
- "[[SRC Pesquisa de Precificação Concorrentes 2026-07]]"
confidence: medium
sensitivity: internal
``

Estágio Operacional

Adicione itens necessários para Projetos ou Decisões:
``yaml
type: project
created: 2026-07-24
status: active
owner: me
area: "[[Gestão]]"
due: 2026-09-30
next_action: Comparar planos anuais de 5 concorrentes
``

Capítulo 6: Regras para Nomes de Arquivos em Português

Não há necessidade de forçar o texto do corpo ou títulos em português para o inglês. No entanto, mantenha os nomes das Properties e nomes de pastas usados para processamento por máquina em ASCII. Eu uso estas convenções de nomenclatura:

• Projeto: PJT Redesenho da Precificação Corporativa
• Decisão: DEC 2026-07-24 Tornar Plano Anual a Proposta Padrão
• Nota Perene: O Preço é Determinado pelo Risco de Falha na Implementação, Não pela Quantidade de Funcionalidades

Torne os títulos das Notas Perenes "Afirmações" em vez de "Nomes de Categorias." Títulos afirmativos ajudam você a lembrar do conteúdo apenas pelos resultados da busca.

Capítulo 7: Templates para Incluir de Fato

Nota Diária

Inclua um "Registro de Fricção." Registrar "o que procurei mas não encontrei" permite que você melhore o Vault com base em falhas reais de busca. Evolua a estrutura a partir de falhas de busca, não de preferência estética.

Nota de Projeto

Uma Nota de Projeto não é um depósito de tarefas. É o Centro de Comando do Projeto onde qualquer um pode entender o status atual em 30 segundos.

Nota de Decisão

Em trabalhos de alto lucro, a qualidade das decisões é mais importante que a informação. Assim, as Notas de Decisão são o tipo de nota mais valioso. O campo mais importante é o Gatilho de Reversão. Um excelente tomador de decisão é alguém que consegue escrever, no momento da decisão, sob quais condições mudaria de ideia.

Capítulo 8: MOCs são "Modelos de Pensamento Editados," Não Listas de Links

Um bom MOC (Mapa de Conteúdo) contém o julgamento do editor. É um modelo cognitivo editado que comprime como você entende atualmente um campo inteiro, em vez de apenas uma lista de notas relacionadas.

Capítulo 9: Criando um "Painel de Gestão" com Bases

O Obsidian Bases é um recurso principal que permite exibir, filtrar e classificar as Properties das notas como um banco de dados. Use-o para criar uma "Base de Projetos Ativos" ou uma "Base de Revisão de Decisões" para recuperar julgamentos que ficaram pendentes.

Capítulo 10: Plugins em Camadas

• Camada 0 (Apenas principal): Properties, Templates, Daily Notes, Bases, Search, Canvas, etc.
• Camada 1 (Quando surgir atrito): QuickAdd, Templater, Tasks.
• Camada 2 (Apenas se Bases não for suficiente): Dataview.

Mantenha os Community Plugins ativos em 12 ou menos. Registre o propósito, alternativa e condições de exclusão para cada um.

Capítulo 11: A Mudança Decisiva em 2026—CLI Oficial do Obsidian

Em julho de 2026, o Obsidian tem uma CLI oficial. Ela permite operar a versão desktop a partir do terminal: pesquisar, ler, criar, atualizar properties e verificar tarefas. Isso permite que o Claude e o Codex operem usando a lógica de resolução própria do Obsidian, em vez de apenas editar o Markdown diretamente.

Capítulo 12: A Estrutura Correta para um Vault Nativo de IA

Deixar a IA editar livremente todas as notas não é "utilização de IA." Isso é como entregar todos os documentos da empresa a um estagiário não verificado. A divisão correta de trabalho é:

• Humano: Metas, julgamentos de valor, aprovação final, edição de MOC.
• Obsidian: Fonte da verdade, relacionamentos, histórico, visualizações.
• Claude: Destilação de significado, comparação, contra-argumentos, rascunho.
• Codex: Mudanças estruturais, scripts, validação, revisão de diffs.
• Git: Recuperação, auditoria, isolamento de experimentos.
• Validador: Detectando violações de esquema e anomalias de link.

Capítulo 13: Colocando CLAUDE.md e AGENTS.md

O Claude Code lê CLAUDE.md como instruções contínuas. O Codex procura por AGENTS.md. Coloque um "Contrato de Operação do Vault" nestes arquivos para definir idioma (prosa em português, properties em ASCII), regras de segurança (dry-run por padrão) e regras de esquema.

Capítulo 14: Transformando Tarefas do Obsidian em Skills via Claude

Defina "Agent Skills" para tarefas que você faz mais de três vezes ou para qualidade padronizada. Por exemplo, uma skill obsidian-distill pode converter notas de reunião brutas em Decisões, Tarefas e Notas Perenes. Uma boa Skill é um padrão de trabalho reexecutável com entradas, procedimentos, proibições e condições de conclusão explícitas.

Capítulo 17: Padrões de Colaboração para Claude, Codex e CLI do Obsidian

• Padrão 1: Destilação de Notas de Reunião (Claude extrai decisões/tarefas).
• Padrão 2: Revisão Semanal de Gestão (Claude resume o progresso da semana e projetos parados).
• Padrão 3: Auditoria de Desvio de Esquema (Codex detecta inconsistências de properties).
• Padrão 4: Auditoria de Premissa de Decisão (Claude verifica se as suposições por trás de decisões passadas ainda são válidas).

Este é um uso que vai além de "resumir notas com IA." Você usa a IA como um controlador intelectual que audita seus julgamentos passados.

Capítulo 18: Incluindo um Validador de Vault

Se a IA está editando seu Vault, não se contente apenas com "parece ok." Implemente testes estáticos mínimos via scripts (ex: vault_check.py) para verificar tipos permitidos, status e properties obrigatórias.