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 discussão calma.

Não há nenhuma pesquisa que sugira 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, vou recuperar esta informação no futuro?"

Usuários ainda mais fortes rastreiam em qual decisão ou saída aquele conhecimento recuperado eventualmente se converteu.

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

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

O Obsidian salva notas como arquivos Markdown locais. Um Vault é apenas uma pasta, e as alterações feitas por 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ê alcança essa perspectiva, sua forma de usar o Obsidian muda completamente.

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

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

Há 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.

O insight mais importante deste estudo não foi como os participantes criavam notas.

Foi a descoberta de que a forma como eles pretendiam recuperá-las no futuro influenciava fortemente como eles 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 pesquisa 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 pesquisa.

Só este ponto já mostra que a maioria dos cursos comuns de Obsidian está 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 preocupado 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 direciona as notas de aprendizado além de registros pessoais para:

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

Essa "conversão de entrada para 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 trechos de código, reuniões e especificações de projetos até pesquisas 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. 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 as lista com Bases ou Dataview.

A conclusão aqui é clara:

Ser capaz de recuperar apenas com Markdown quando algo quebrar é mais importante do que ter alta funcionalidade.

4. Ian O’Byrne—Fluxo de 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, papers, 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, passando pela criação de significado, até 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 pontos em comum:

1. Pesquisa primeiro—Trabalhe de trás para frente a partir de pesquisas futuras
2. Centrado na saída—Flua para entregáveis, não apenas armazenamento
3. Local primeiro—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 utiliza

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

O número de notas, 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.

Aponte para 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 rastrear posteriormente:

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

5. Taxa de Conversão de Saída

A porcentagem de Notas Fonte ou Notas Evergreen 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 Claude ou Codex conseguem 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 Japoneses

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 de responsabilidade contínuas. Gestão, vendas, contratação, finanças, saúde, família, aprendizado, etc. As Áreas permanecem mesmo após a conclusão de um Projeto.

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 excertos. Não há necessidade de seguir rigorosamente "uma nota, um conceito." Em japonês, sujeitos e premissas são facilmente omitidos, então a fragmentação excessiva 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, papers, 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 vários 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 destinado apenas ao 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. Links internos no Obsidian são resolvidos dentro de um Vault; dividir Vaults desconecta relações entre conhecimentos. No estudo mencionado, participantes que dividiram seu Vault em três relataram confusão na pesquisa.

No entanto, separe fisicamente o seguinte:

• Informações onde a entrada de IA externa é proibida por contrato.
• Médicas, 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 os Papéis 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 seus papéis 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 está 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 Transversais Temporários"

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 Alias em notas de conceito.

Capítulo 5: Esquema Mínimo de Properties

Não tente preencher 20 itens desde o início. Divida o Esquema 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 de 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 Japonês

Não há necessidade de forçar o corpo do texto ou títulos em japonê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 Evergreen: O Preço é Determinado pelo Risco de Falha de Implementação, Não pela Quantidade de Funcionalidades

Faça os títulos das Notas Evergreen serem "Afirmações" em vez de "Nomes de Categoria." Títulos assertivos ajudam você a lembrar o conteúdo apenas pelos resultados da pesquisa.

Capítulo 7: Templates para Incluir de Fato

Nota Diária

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

Nota de Projeto

Uma Nota de Projeto não é um armazém 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 Controle Gerencial" com Bases

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, a alternativa e as condições de exclusão para cada um.

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

A partir de 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 Claude e Codex operem usando a lógica de resolução própria do Obsidian, em vez de apenas editar 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 links.

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 Operacional do Vault" nesses arquivos para definir idioma (prosa em japonê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 através do 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 Evergreen. 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 Gerencial Semanal (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 Premissas de Decisão (Claude verifica se as suposições por trás de decisões passadas ainda são verdadeiras).

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 através de scripts (ex: vault_check.py) para verificar tipos permitidos, status e properties obrigatórias.