Voltar ao Blog
Disponível em:
26 de fev. de 20265 min read

Zettelkasten para Engenheiros: Por Que e Como Eu Uso

Niklas Luhmann publicou 70 livros e 400 artigos em 30 anos usando um fichário de papel. O dado é repetido tantas vezes que já perdeu o corte, então vamos à parte que importa: o Zettelkasten não era um sistema de organização. Era um sistema de pensamento. Luhmann descrevia o trabalho com ele como "uma conversa com o arquivo".

Para engenheiros, o problema nunca foi falta de informação. O problema é que conhecimento técnico decai.

Três problemas ao mesmo tempo

Engenheiros carregam três problemas de conhecimento simultâneos, e eles se acumulam.

Decaimento. O que você aprendeu sobre consumer groups do Kafka e seus edge cases de rebalancing em 2023 evaporou em 2025. Sem indexação, é como se nunca tivesse acontecido.

Reinvenção. Sem registro de por que descartamos aquela abordagem, a mesma decisão é tomada de novo oito meses depois — muitas vezes chegando à mesma conclusão pelo mesmo caminho custoso.

Fragmentação. O conhecimento se espalha entre Slack, Confluence, comentários de PR e a cabeça de pessoas específicas. Nenhuma fonte de verdade navegável.

O que é um Zettelkasten de verdade

Cada nota é uma ideia atômica, escrita em prosa completa, conectada a outras notas. As categorias emergem das conexões em vez de serem decididas de antemão.

A distinção que o separa do arquivamento convencional: você não arquiva informação num Zettelkasten. Você a reformula com suas próprias palavras, conecta a outras ideias e deixa que os links emergentes guiem o pensamento. O esforço de reformular é onde o aprendizado acontece — que é exatamente por que copiar e colar não produz nada.

Por que Logseq

Avaliei as alternativas óbvias antes de decidir.

  • Obsidian — excelente, mas plugins críticos ficam atrás do Sync pago, e a história de queries nativas é mais fraca.
  • Roam Research — o precursor do ZK baseado em outline, mas caro, e seus dados não ficam no filesystem, o que limita a portabilidade.
  • Notion — uma ótima wiki hierárquica, e a hierarquia é justamente o problema. Não é feito para conexões emergentes, e prende você.

Escolhi o Logseq porque é baseado em outline, então cada bloco é linkável; tem graph view nativo e queries Datalog; e guarda arquivos .md puros no filesystem, o que significa versionável em git, portável, sem lock-in, gratuito e open source.

Zettelkasten vs. wiki — a diferença que importa

Uma wiki pede que você escolha a categoria antes de escrever. A estrutura é top-down, e ela tende a virar arquivo morto no momento em que o projeto muda. Você a busca, o que exige já saber o que está procurando.

Um Zettelkasten deixa as categorias emergirem das conexões depois que você escreve. A estrutura é bottom-up e cada nota se sustenta sozinha. Você a navega, e descobre links que não sabia que existiam.

Vale ter os dois. Wikis são boas para documentação de projeto — READMEs, ADRs, runbooks. Um Zettelkasten é para conhecimento pessoal acumulado que sobrevive a qualquer projeto isolado. O Confluence responde "o que o sistema faz". O Zettelkasten responde "o que eu aprendi sobre sistemas".

Os quatro tipos de nota

  • Fleeting — captura rápida no journal diário. Ideias brutas, links, fragmentos. Descartável. Não precisa estar correta.
  • Literature — conhecimento extraído de uma fonte, sempre com source::. Resumido com suas próprias palavras, nunca colado.
  • Permanent — uma ideia atômica em prosa completa, compreensível sem nenhum contexto externo. É o coração de tudo. Mais lenta de escrever, dura anos.
  • Structure (MOC) — um mapa de conteúdo. Não é uma nota de conteúdo, e sim um índice: lista as notas de um cluster em vez de explicar o tema.

Quatro regras que mantêm o sistema vivo

  1. Uma ideia por nota. Se uma nota cobre dois conceitos distintos, são duas notas. O teste: o título deve capturar a ideia inteira em uma única frase.
  2. Escreva como se o leitor não tivesse contexto. A nota precisa fazer sentido sem saber de onde você veio. Isso força clareza de pensamento mais do que qualquer outra regra.
  3. Adicione ao menos duas conexões a cada nota permanente. As conexões são o produto de verdade. Uma nota sem nenhuma é conhecimento isolado.
  4. O journal é captura; a nota permanente é destilação. Nunca promova um rascunho sem reformular.

O que você ganha e o que custa

Você ganha uma memória técnica navegável que não decai, padrões emergentes que wikis hierárquicas escondem e — efeito colateral agradável — artigos que se escrevem sozinhos, porque toda nota permanente já é um rascunho.

Você paga com 10 a 20 minutos por nota permanente e com a sensação persistente de que deveria estar codando, não escrevendo. Sem disciplina, o journal cresce e as notas permanentes nunca são escritas.

Como isso falha

"O ZK virou inbox". O journal enche e as notas permanentes nunca aparecem. Sintoma: muitas fleeting, poucas permanent. Correção: processar o journal semanalmente — converter ou descartar.

Notas longas demais. Uma nota com vinte bullets em "key ideas" provavelmente são cinco notas. Toda ideia que merece duas ou mais conexões distintas merece a própria nota.

MOCs desatualizadas. A nota de estrutura deixa de refletir o cluster. Correção: atualizá-la ao encerrar cada sessão.

O que eu de fato aprendi

As melhores notas permanentes vêm de perguntas, não de afirmações. "Por que Proxmox e não VMware?" gera uma nota melhor do que "Características do Proxmox".

E o grafo conta a verdade sobre o que você sabe. Clusters densos são domínios reais. Nós isolados são informação, não conhecimento.

Referências

ConhecimentoZettelkastenLogseqEngenharia