Transforme uma Wiki no Estilo Karpathy em uma Habilidade Reutilizável

Os últimos dias têm sido uma verdadeira luta para fazer essa habilidade funcionar.

Comecei com o Opus 4.6. Gastei mais de 20 dólares. Ainda assim não consegui fazê-la funcionar. Cheguei a me perguntar se o novo modelo lançado na manhã de 8 de abril de 2026 tinha sugado todo o poder de computação deles. Caso contrário, como poderia entender uma coisa e depois sair do rumo na sequência?

Depois mudei para o Codex, e consegui construí-la.

Mas um novo problema surgiu: construí-la não significa que ela funciona de forma confiável.

Especialmente quando você começa a testá-la a sério, ela ocasionalmente ignorava instruções e fazia alterações por conta própria, o que me deixava louco.

Então, neste artigo, não quero apenas dizer “construí uma habilidade, fique à vontade para baixá-la”.

Quero deixar outra coisa clara: como implementar de fato o método LLM Wiki que o Karpathy propôs em um vault do Obsidian.

O capítulo anterior cobriu o método. Este capítulo é sobre a prática.

Se você quiser baixar a versão atual sanitizada da minha habilidade, aqui está o link:

https://blog.discoverlabs.ac.cn/downloads/obsidian-wiki-skill/

Já removi as chaves de API, caminhos locais, etc. Mas vou dizer isso de antemão: não copie na íntegra.

Você pode aprender com este método. Você também pode modificar esta habilidade. Mas não espere que ela funcione imediatamente. O vault de notas de cada pessoa é muito diferente.

O que construí não é “IA organizando minhas notas”, mas “IA fazendo minha contabilidade”

Vamos primeiro revisitar a Gist do Karpathy.

Link original:

https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f

A ideia central é na verdade simples:

A maioria das pessoas atualmente usa LLMs para processamento de documentos via RAG: despeja um monte de arquivos e, ao consultar, recupera e gera respostas na hora.

Isso funciona, claro.

Mas o problema é que é tudo ad hoc.

Pergunta uma vez, monta uma vez. Pergunta de novo, começa do zero. Sem acúmulo.

Então ele propôs uma camada intermediária: em vez de montar respostas na hora para cada consulta, manter continuamente uma Wiki.

Quando li isso, minha primeira reação não foi “isso é legal”.

Foi: não é exatamente o tipo de tarefa para a qual o Obsidian é mais adequado?

Porque o Obsidian é inerentemente um vault de arquivos Markdown locais.

A Wiki que Karpathy descreve é essencialmente uma coleção de arquivos Markdown.

O formato subjacente é quase idêntico.

A diferença é:

• Antes, você mantinha manualmente backlinks, páginas de tópicos e páginas de estrutura
• Agora a IA ajuda você com esse trabalho de “contabilidade”

Nota: contabilidade, não pensamento.

Cada vez mais concordo com isso.

Ler artigos, fazer julgamentos, escrever suas próprias opiniões — isso ainda é para você fazer.

Mas tarefas como completar backlinks, normalizar nomes de autores, verificar formatação e atualizar páginas derivadas são essencialmente trabalho braçal. A IA pode lidar com elas.

Como implementei a estrutura de três camadas do Karpathy no Obsidian

A parte mais importante do método do Karpathy são as três camadas:

• Raw Sources (Fontes Brutas)
• The Wiki (A Wiki)
• The Schema (O Esquema)

Minha habilidade obsidian-wiki também é construída em torno dessas três camadas.

Primeira Camada: Raw Sources

No meu vault, esta camada consiste em:

• 01-Notes/
• 04-Output/

Ou seja, coleções brutas, notas brutas e artigos que escrevi.

Mantenho esta camada muito contida.

Sua única responsabilidade é preservar o conteúdo original.

Não deixo que ela assuma funções extras.

Não misturo conteúdo derivado.

Não deixo um artigo bruto se tornar metade página de tópico, metade página de índice.

Porque uma vez misturado, fica difícil de manter.

Esta é uma das lições mais profundas que aprendi ao construir esta habilidade: quanto mais limpa a camada bruta, mais fácil tudo o resto se torna.

Segunda Camada: The Wiki

Esta camada é separada no meu vault:

01-Notes/wiki/

Aqui reside a camada estrutural derivada pela IA, como:

• Páginas de autores
• Páginas de tópicos
• Índice
• Log
• Diretório de backlinks

Em outras palavras, o texto original permanece o texto original.

A Wiki é a Wiki.

As duas camadas são separadas.

Isso parece trivial, mas na verdade é muito importante.

Porque se você não separar as camadas, toda vez que a IA organiza, ela tende a deixar o texto original mais bagunçado.

Hoje adiciona um bloco de tópico.

Amanhã insere um índice.

Depois de amanhã, adiciona um resumo gerado automaticamente.

Eventualmente, todo o vault parece um quarto que está sendo constantemente arrumado, mas fica mais bagunçado.

Terceira Camada: The Schema

Muitas pessoas ignoram esta camada.

Karpathy menciona schema em seu post original. Meu entendimento é: você precisa dizer à IA como o vault deve ser.

No meu caso, isso inclui:

• SKILL.md
• Um monte de scripts/
• Convenções de frontmatter
• Restrições sobre como autores e tópicos são escritos
• Restrições de processo para lint e ingest

Por exemplo, agora eu imponho:

• Autores devem estar no formato de backlink
• Tópicos devem ser uma lista de backlinks
• Páginas de autores e páginas de tópicos só podem ir em 01-Notes/wiki/
• 00-Inbox/ é apenas uma caixa de entrada de processamento, não misturada diretamente na Wiki
• Artigos brutos não contêm mais parágrafos derivados

Você descobrirá que o que faz a habilidade funcionar não é o quão bonito o prompt é escrito. A chave real é que essas restrições são estabelecidas primeiro.

Traduzindo as Três Ações em Fluxos de Trabalho Executáveis

Karpathy também tem três ações principais:

• Ingest
• Query
• Lint

Eu segui a mesma abordagem.

Em termos do fluxo de trabalho real nesta habilidade, fica assim:

• Ingest: wiki_lint.py --preflight + ob_shuanglian.py suggest/apply + wiki_ingest.py
• Query: Primeiro ler wiki/index.md, authors/*.md, topics/*.md, depois voltar ao texto original para detalhes
• Lint: wiki_lint.py, wiki_migrate.py, wiki_build_skeleton.py

Ingest: Verificar novo conteúdo antes de adicioná-lo ao vault

Não deixo a IA “ver um artigo e improvisar” imediatamente.

Meu fluxo de trabalho atual começa com uma verificação prévia (preflight).

Primeiro verifica se o frontmatter está correto.

Depois verifica contaminação histórica.

Então faz sugestões de backlinks.

Após confirmação do usuário, aplica de fato.

Finalmente, atualiza a camada derivada da Wiki.

Por que toda essa complicação?

Porque os modelos me ensinaram muitas vezes.

Se você não adicionar essas salvaguardas, eles vão ansiosamente “tomar decisões” por você.

O problema é que as decisões deles podem não ser o que você quer.

Então adicionei fortes portões de confirmação.

Não deixe que escrevam tópicos arbitrariamente.

Não deixe que apliquem backlinks diretamente.

Não deixe que decidam sobre aliases de autores por conta própria.

Dê sugestões, eu confirmo, depois escrevem.

Isso pode parecer menos eficiente.

Mas com uma base de conhecimento, o maior medo não é a lentidão; é escrever algo errado silenciosamente.

Query: Não pescar no mar de texto original, mas ler a camada Wiki primeiro

Para consultas, minha abordagem não é “pesquisar todo o vault e entregar à IA para resumir”.

Em vez disso, primeiro passa por:

• wiki/index.md
• authors/*.md
• topics/*.md

Deixe a IA olhar para a camada estruturada primeiro.

Quando necessário, volte a artigos específicos para detalhes.

Os benefícios são claros:

Ela não precisa remontar a partir de textos originais dispersos toda vez.

Em vez disso, responde a partir de uma camada já organizada.

Isso está mais próximo do que Karpathy quer dizer com “acúmulo”.

Lint: A etapa mais importante e mais subestimada

Muitas pessoas focam em Query quando veem LLM Wiki.

Mas quanto mais trabalho nisso, mais sinto que Lint é onde está o valor real.

Porque uma vez que a base de conhecimento cresce, sua maior dor de cabeça não é “não consigo obter respostas”, mas:

• Frontmatter bagunçado
• Nomes de autores inconsistentes
• Tópicos dispersos
• Estruturas históricas permanecendo no texto original
• Páginas derivadas cada vez mais distorcidas
• O mesmo conceito aparece sob vários nomes diferentes

Se você tentar manter isso manualmente, é enlouquecedor.

E você não conseguirá manter.

É exatamente nisso que a IA é melhor.

Não para entender o mundo por você.

Mas para patrulhar o vault, reconciliar, encontrar dados sujos e preencher referências cruzadas.

É por isso que o termo de Karpathy é tão adequado: contabilidade.

A Armadilha Real Não é o Modelo, é Meu Vault de Notas Antigo

Isso também é o que mais quero alertar a todos.

Muitas pessoas leem um artigo como este e pensam instintivamente:

“Ah, é só baixar a habilidade, instalar, e a IA vai gerenciar minha base de conhecimento.”

Não é o caso.

O maior desafio com esta habilidade não é o prompt, os scripts, ou mesmo o modelo.

É que eu tenho muitas notas antigas, e seus formatos são inconsistentes.

Quando executo lint agora, aqui está a escala que vejo:

• Raw Sources do tipo artigo: 457
• Total de arquivos brutos: 833
• Fila pendente: 249
• O diretório de backlinks já tem 471 tópicos

Pense nesse volume.

Isso não é mais sobre “organizar algumas notas”.

É mais como assumir um sistema antigo com uma longa história e sem padrões consistentes.

Alguns artigos têm nomes completos de autores.

Alguns têm aliases.

Alguns tópicos são muito detalhados.

Alguns são muito dispersos.

Alguns arquivos antigos ainda contêm resquícios de estruturas anteriores.

Então fiquei cada vez mais certo de uma coisa:

Se você quer construir um LLM Wiki, o primeiro passo não é deixar a IA assumir. O primeiro passo é limpar seu vault até um estado “que vale a pena assumir”.

Caso contrário, quanto mais diligente a IA, mais ela espalha a bagunça.

Então, o Que Esta Habilidade Faz de Extra?

Se você ler apenas o post original do Karpathy, pensará que é uma metodologia muito elegante.

Mas ao realmente construí-la, encontrei muitos detalhes de engenharia para preencher.

Por exemplo:

• Padronização de frontmatter
• Normalização de aliases de autores
• Imposição de formato de backlink para tópicos
• Separação completa das camadas bruta e derivada
• Uso de 00-Inbox/ como caixa de entrada de processamento
• Adição de portões de confirmação do usuário em etapas-chave
• Divisão do fluxo de trabalho com scripts como lint, migrate, ingest

Não é que Karpathy não pensou nisso.

É que a Gist dele descreve um padrão, não a implementação específica para o seu vault.

Ao implementar de fato, você deve preencher essa camada você mesmo.

Minha habilidade obsidian-wiki atual está essencialmente fazendo isso:

Traduzindo um padrão abstrato em um fluxo de trabalho que roda no meu próprio vault do Obsidian.

Então, se você baixá-la, o mais importante a aprender não é “copiar minha estrutura de diretórios”.

É entender por que eu organizei as camadas dessa forma, por que a confirmação é necessária aqui, por que o lint é feito aqui, por que o apply automático não é usado aqui.

Se Você Quiser Fazer Isso Também, Modifique Estas Coisas Primeiro

Coloquei a versão sanitizada na página de download do meu blog:

https://blog.discoverlabs.ac.cn/downloads/obsidian-wiki-skill/

Mas depois de baixar, a primeira coisa não é executá-la.

É modificá-la.

Pelo menos verifique estas coisas:

1. O caminho do seu vault é o mesmo que o meu?
2. Sua estrutura 01-Notes/, 04-Output/, 00-Inbox/ é a mesma?
3. Seus campos de frontmatter são consistentes com os meus?
4. Seus nomes de autores e nomes de tópicos já são razoavelmente consistentes?
5. Você quer manter meu fluxo de trabalho de “sugerir, confirmar, depois escrever”?
6. Se os scripts envolvem APIs, você os substituiu por suas próprias chaves?

A versão que lancei já sanitizou chaves de API e caminhos locais.

Depois de obtê-la, você deve adaptá-la ao seu próprio ambiente.

E ainda recomendo: não trate meu método como um modelo, apenas como uma referência.

Se seu vault é principalmente notas de leitura, as regras podem diferir das minhas.

Se seu vault é principalmente notas de projeto, a granularidade dos tópicos será diferente.

Se seu vault ainda está na fase de “coletar primeiro, organizar depois”, você provavelmente não deve focar em Query primeiro, mas sim fazer Lint e Ingest funcionarem bem.

Então não copie na íntegra.

Modifique com base na abordagem, isso é mais confiável.

Resumo

Ao final deste artigo, meu próprio sentimento ficou mais claro.

A proposta de Karpathy não é apenas uma ideia de que “a IA pode ajudar você a organizar sua base de conhecimento”.

Seu valor real é que ela redefine a divisão de trabalho entre humanos e IA na gestão do conhecimento.

Humanos lidam com julgamento.

IA lida com contabilidade.

Quanto mais trabalho nisso, mais acredito nessa afirmação.

O que aprendi hoje:

1. A chave do LLM Wiki de Karpathy é a estrutura de três camadas e três operações, não um único prompt
2. A chave de habilidades como obsidian-wiki não é “se ela consegue resumir”, mas se consegue separar Raw Sources, Wiki e Schema
3. Na prática, Lint é frequentemente mais importante que Query, porque a limpeza de dados históricos é a maior parte do trabalho
4. Quanto mais notas antigas e mais bagunçado o formato, menos você deve copiar diretamente a habilidade de outra pessoa
5. Baixar uma habilidade é fácil; o verdadeiro desafio é adaptá-la para se adequar à sua própria base de conhecimento

Principais conclusões:

• IA é mais adequada para contabilidade, não para pensar por você
• Camadas bruta e derivada devem ser separadas, senão a base de conhecimento fica mais bagunçada quanto mais você organiza
• Portões de confirmação do usuário não são etapas extras; são salvaguardas necessárias para evitar que a IA aja por conta própria
• Padronize formatos primeiro, depois fale sobre automação; se inverter a ordem, você sofrerá depois
• Esta habilidade pode ser modificada, mas não é recomendado copiá-la como está