eps1.4IA

Como construir um segundo cérebro com Claude Code e Obsidian

Engenharia de Contexto e a base de conhecimento do seu agente de IA.

7 min de leitura

Quando você precisa lembrar por que o time tomou uma decisão técnica há três meses, onde você procura? Provavelmente em quatro lugares: uma thread do Slack, um comentário de card, um Google Docs que ninguém mais abriu e a cabeça de quem estava na call.

A informação existe. Ela só não está onde você procura.

Nos posts anteriores falamos da janela de contexto, a memória de curto prazo do agente, das Rules e Skills, que funcionam como memória de longo prazo, e do Spec-Driven Development, que transforma especificações em fonte da verdade. Agora falta outra peça: a base de conhecimento que o agente consulta para responder sobre o seu contexto, e não sobre a internet.

Esse padrão tem nome: LLM wiki. E para montar o seu, você só precisa de duas ferramentas: Obsidian para escrever e o Claude Code para consultar.

Quem propôs a ideia

O termo vem do Andrej Karpathy. Ele foi membro fundador da OpenAI e depois diretor de IA da Tesla, onde liderou o time de visão computacional do Autopilot. Hoje é uma das vozes mais lidas sobre como trabalhar com LLMs no dia a dia. Foi ele, por exemplo, quem popularizou o termo “vibe coding”.

A proposta está num gist que ele publicou em abril de 2026, e a ideia central é simples: suas notas e documentos, organizados em markdown, podem se tornar uma base de conhecimento que uma LLM consegue pensar sobre. Em vez de procurar a informação no Notion, no Google Docs e nas notas fixas, você pergunta e o agente lê a sua base.

Vale ler o gist original, porque a proposta dele é mais ambiciosa do que o que vamos montar aqui. Karpathy separa três camadas: as fontes cruas (documentos que a LLM lê mas nunca modifica), a wiki em si (as páginas em markdown, mantidas pela própria LLM) e o schema (um arquivo de configuração, como o CLAUDE.md, que define as convenções). E descreve três operações sobre isso: ingest (uma fonte nova entra e a LLM atualiza as páginas afetadas), query (você pergunta e a resposta boa pode virar página nova) e lint (a LLM varre a wiki procurando contradições, páginas órfãs e lacunas).

A diferença dele em relação ao RAG tradicional está aí: em vez de recuperar pedaços de texto a cada pergunta, a LLM vai construindo um artefato que se acumula. Ele compara com o Memex, que Vannevar Bush imaginou em 1945, com a diferença de que agora existe alguém disposto a manter os links atualizados.

Neste post vamos montar uma versão mínima disso, onde você escreve as notas e o Claude consulta. É o suficiente para resolver o problema do começo, e você pode ir puxando as outras operações depois.

E aqui está o ponto mais importante: isso não é um produto. Não existe app para instalar, nem serviço para assinar. É um padrão de workflow. Você já tem tudo que precisa.

A diferença está em onde o agente procura

Quando você pergunta algo para uma LLM sem contexto, ela responde com base na documentação pública. A resposta é genérica: ela não conhece o nome dos seus módulos, as suas decisões ou o caminho que o time descartou no refinamento.

Quando você aponta a mesma LLM para uma pasta com as suas notas, a resposta vem ancorada no que o time já escreveu, com o histórico da decisão e o caminho do arquivo que a originou.

É a mesma diferença entre perguntar para um estranho e perguntar para alguém que leu a sua documentação.

A arquitetura tem três componentes

A arquitetura de uma LLM wiki é mínima:

1. Uma pasta com arquivos markdown. Essa é a sua base de conhecimento. Pode conter qualquer coisa: notas de pesquisa, resumos de reunião, documentação de projeto, anotações de livro, referência pessoal, blocos de código com explicação.

2. Uma estrutura consistente em cada arquivo. Título, um resumo de uma linha, tags e o conteúdo. Sempre no mesmo formato. É essa estrutura que o modelo usa para encontrar a informação relevante mais rápido.

3. O Claude Code como interface de busca. Você abre o terminal, navega até a pasta da wiki, abre o Claude e faz a pergunta. Ele lê os arquivos que precisa, sintetiza a resposta e pode até atualizar as notas, se você pedir.

É isso. Sem banco de dados. Sem servidor. Apenas arquivos e um modelo capaz.

Por que markdown é a fundação certa

Essa escolha não é detalhe. Markdown resolve quatro problemas de uma vez.

É portátil. Um .md é um arquivo de texto puro. Abre em qualquer editor e em qualquer sistema operacional.

LLMs leem markdown nativamente. Modelos como o Claude foram treinados com uma quantidade enorme de texto em markdown: README do GitHub, documentação, sites, fóruns. A sintaxe faz parte do que eles entendem: cabeçalhos, listas, blocos de código, negrito. O modelo interpreta isso como estrutura, não como ruído.

Força clareza. Para escrever em markdown você precisa nomear as seções nos cabeçalhos e separar os itens nas listas. O formato leva à organização.

Texto puro significa zero lock-in. Você sincroniza com o Git, abre no VS Code, visualiza no Obsidian, faz push num repositório privado, lê no terminal. O conhecimento é seu.

Configurando a wiki no Obsidian

O Obsidian é a recomendação para esse workflow. É um app markdown local-first, com uma interface limpa. Seus arquivos ficam no disco; o Obsidian é só a forma de ler e escrever eles.

Passo 1: instale o Obsidian e crie uma vault

Baixe do site oficial e crie uma nova vault numa pasta que você vá lembrar, como ~/wiki ou ~/Documents/llm-wiki. Uma vault no Obsidian é apenas uma pasta. Tudo é markdown puro.

Passo 2: defina um template de nota

Consistência é o que torna a sua wiki consultável. Crie um arquivo em _templates/nota.md:

# Título da nota

**Resumo**: uma frase descrevendo esta nota.
**Tags**: #topico1 #topico2
**Criado**: 2026-08-21
**Atualizado**: 2026-08-21

---

## Conteúdo

O conteúdo principal aqui.

## Notas relacionadas

- [[Título de outra nota]]

Você não precisa seguir isso exatamente. A chave é cada nota ter uma linha de resumo e suas tags. Isso permite que o Claude avalie a relevância do arquivo sem precisar ler o arquivo inteiro.

Passo 3: organize em tópicos

Não faça over-engineering aqui. Comece com quatro ou cinco pastas de alto nível:

wiki/
├── _templates/
├── projects/
├── research/
├── reference/
├── meetings/
└── inbox/

Na pasta inbox/ ficam as notas que ainda não foram organizadas. O Claude ajuda você a fazer essa triagem depois.

Passo 4: escreva as primeiras notas

Migre de onde o seu conhecimento está hoje. Comece pelo que você consulta repetidamente: processos que você já documentou, conceitos que pesquisou, decisões que tomou e o porquê delas.

Não tente importar tudo de uma vez. A wiki cresce naturalmente conforme você adiciona notas.

Passo 5: instale o Claude Code

Se você ainda não tem, instale. É a interface de busca da sua wiki.

Passo 6: consulte a wiki

Abra o terminal, navegue até a pasta e rode o Claude. Agora você pode perguntar:

  • Por que a gente decidiu usar webhook em vez de polling naquele fluxo?
  • O que ficou pendente do refinamento da semana passada?
  • Esse problema já apareceu antes em algum projeto?

O Claude vai ler os arquivos, identificar o que é relevante e responder.

Não esqueça do CLAUDE.md

Aqui a LLM wiki encontra o assunto do post anterior. A sua vault também precisa de Rules: um CLAUDE.md na raiz, explicando o que vive em cada pasta e como o agente deve trabalhar:

# Meu segundo cérebro: instruções

## Sobre mim
Sou engenheiro de software. Trabalho em 3 a 4 projetos por vez e
preciso de ajuda para sintetizar pesquisa e rastrear decisões.

## Estrutura da vault
- /inbox: notas que eu ainda não processei. Comece por aqui.
- /projects: uma pasta por projeto. Ativos têm `status: ativo`.
- /meetings: resumos de call, com o que ficou pendente.

## Protocolo de sessão
Ao começar:
1. Ler a nota de hoje (/inbox/YYYY-MM-DD.md)
2. Varrer a /inbox por notas não processadas
3. Checar o que está marcado com #revisar

Ao terminar:
1. Escrever o resumo da sessão em /sessoes/YYYY-MM-DD.md
2. Atualizar a nota de hoje com o que foi feito

Sem isso, você reexplica o contexto toda vez que abre uma sessão nova. Com isso, o resumo de hoje é o ponto de partida de amanhã.

Boas práticas para uma wiki que se mantém útil

1. Escreva resumos, não apenas conteúdo. Uma linha de resumo custa 10 segundos e economiza muitos tokens em cada consulta.

2. Use terminologia consistente. Se você escreve “RAG” em algumas notas e “Retrieval Augmented Generation” em outras, o modelo consegue conectar as duas. Mas o resultado é melhor se você escolher um termo e usar sempre o mesmo.

3. Linke as notas entre si. O Obsidian permite fazer essa conexão com [[wikilinks]], e é por isso que ele funciona tão bem aqui. Uma wiki conectada vira um grafo, e um grafo é melhor do que centenas de arquivos isolados.

4. Mantenha as notas focadas. Um documento com 10 mil palavras é mais difícil de localizar do que 10 documentos de mil palavras. Se uma nota está cobrindo vários tópicos, separe. Quanto mais específico cada arquivo, mais preciso o Claude consegue ser.

5. Use a /inbox como padrão de captura. Não deixe o perfeito ser inimigo do útil. Jogue a nota crua na inbox e periodicamente peça para o Claude organizar.

Cuidado com a otimização prematura

Ler os arquivos direto funciona bem para centenas de documentos. Acima disso, existem dois caminhos.

O primeiro é RAG. Uma ferramenta como o LlamaIndex permite construir um índice vetorial sobre os seus arquivos markdown, e o Claude busca só os trechos mais relevantes antes de responder.

O segundo é escrever uma Skill que faz um pré-filtro das notas, resume seções e roteia a consulta, cortando tokens em cada pergunta.

Mas para quem está começando, os dois são overkill. É otimização prematura. Comece lendo os arquivos direto e só troque quando sentir o limite.

Como decidir se vale para você

A pergunta é simples: o conhecimento que você mais consulta está espalhado em mais de duas ferramentas?

Se sim, você não precisa de uma plataforma nova. Precisa de uma pasta, um template de nota e um agente que saiba ler markdown.

E o começo é menor do que parece: crie a pasta, escreva uma nota sobre a última decisão técnica que você tomou (com o porquê) e faça a primeira pergunta. A wiki cresce com o uso.

Referências

Se você quiser acompanhar a série, os posts anteriores são sobre a janela de contexto, sobre Rules e Skills e sobre Spec-Driven Development.

A seguir