Criar um Open Knowledge Format com Draft_: o guia prático
Um bundle OKF não é mais do que um diretório de ficheiros Markdown bem arrumados: exatamente o que o Draft_ produz, sem configurar nada. Porquê escrever a tua base de conhecimento num processador de texto Markdown e depois entregá-la tal como está a um agente de IA. Três casos onde muda tudo.
O Open Knowledge Format da Google (OKF) não exige nenhuma ferramenta proprietária. Um bundle é um diretório de ficheiros Markdown, um pouco de frontmatter YAML, ligações entre os conceitos, e nada mais. Por outras palavras, o formato já é o teu editor de texto.
Dito isto, «poder» e «com conforto» não são sinónimos. Escrever uma base de conhecimento é um trabalho de escrita: queres um lugar tranquilo para o fazer, não um terminal. É aqui que o Draft_ encaixa, não graças a uma funcionalidade «OKF» dedicada, mas porque o seu formato nativo já é o do OKF. Vejamos porquê, e depois três casos concretos onde conta.
Porquê um processador de texto Markdown para o OKF?
O OKF separa dois papéis: quem produz o conhecimento e quem o consome. O consumidor é um agente de IA. O produtor é um humano que escreve, e que merece algo melhor do que um campo de entrada para o fazer.
Esta inversão é a linha do Draft_: és tu que alimentas a IA, não a IA que cria no teu lugar. Por mais que o OKF se dirija a máquinas, tudo o que contém nasce de um pensamento humano: escrito, estruturado, assumido. E quem segura o teclado não é uma escolha neutra: delegar a escrita a um assistente tem um custo cognitivo agora medido, da sobrecarga mental à dependência da IA, enquanto a hierarquia neurocientífica mão > teclado > IA mostra que é o envolvimento de quem escreve que dá valor ao que é produzido. Uma base de conhecimento só vale pelo que lá pões. Mais vale escrevê-la tu mesmo, numa ferramenta construída para isso.
E é que as peças do OKF são, uma a uma, as do Draft_:
| Convenção OKF | Draft_, tal como está |
|---|---|
| Diretório de ficheiros Markdown | Formato de armazenamento nativo |
| Frontmatter YAML | Zona de metadados no cabeçalho do documento |
| Ligações cruzadas entre conceitos | Ligações internas relativas ([texto](../pasta/doc.md)) |
| Árvore de conceitos | Espaços e pastas |
| Bundle versionado | Sincronização com o GitHub integrada |
| Legível por um humano | Editor Markdown sem distrações |
Nada a instalar, nada a ligar. A correspondência não é por acaso: o OKF apenas formalizou o que os bons editores Markdown fazem há muito tempo.
O fluxo de trabalho concreto
Crias um espaço: é a raiz do teu bundle. Lá dentro arrumas pastas (personagens/, tabelas/, lugares/…) que se tornam as famílias de conceitos. Cada documento abre com uma zona de metadados onde escreves o frontmatter em claro (type: Personagem, title, tags), sem sequer os delimitadores ---, que o Draft_ acrescenta na exportação. O nome do documento torna-se o nome do ficheiro (orders → orders.md), por isso controlas o caminho de cada conceito; as tuas ligações internas tornam-se as arestas do grafo que o agente seguirá; e a sincronização com o GitHub transforma o conjunto num repositório versionado. Um bundle OKF válido, saído de um editor onde sobretudo escreveste.
Três casos concretos
Caso 1: a bíblia de um universo de ficção
Estás a escrever um romance, uma série, um jogo. Manténs um espaço biblia/:
personagens/
└── elena.md (type: Personagem)
lugares/
└── valdris.md (type: Lugar)
faccoes/
└── pacto-de-ferro.md (type: Facção)A ficha de Elena cita Valdris e o Pacto de Ferro através de simples ligações. Mais tarde, entregas o repositório a um LLM: «Aqui está a minha bíblia. Escreve uma cena em que Elena regressa a Valdris, fiel à sua história e à atmosfera do lugar.» O agente recupera as fichas pertinentes seguindo as ligações e escreve dentro do teu universo, sem que tenhas de o reexplicar a cada sessão. A tua coerência torna-se um ativo, não um peso mental.
Caso 2: uma documentação técnica viva
Documentas uma API ou um produto, por tipo: endpoints/, conceitos/, runbooks/, cada um com o seu type. O repositório vive ao lado do código, no mesmo GitHub, versionado pelos mesmos commits. A documentação deixa de ser um wiki paralelo que envelhece: é legível por um agente de CI, pelo assistente que responde às perguntas da equipa, ou pela programadora que chega na segunda-feira. Uma única fonte, e todos, humanos e máquinas por igual, ali bebem.
Caso 3: notas de investigação consultáveis
Acumulas notas sobre um tema: concorrentes, leituras, ideias. Cada nota é um conceito, ligado aos outros. O bundle sincronizado torna-se uma memória externa que interrogas: «Que tensões atravessam estas duas abordagens nas minhas notas?» O LLM percorre o grafo do teu pensamento para responder: não a Wikipédia, o teu próprio raciocínio, estruturado e citado.
O perímetro, numa linha
O Draft_ cobre o elo humano da cadeia OKF: escrever, nomear, ligar, versionar. O consumo faz-se depois com qualquer LLM, e é todo o interesse de um formato portátil. Escreves o frontmatter e manténs o controlo da coerência, exatamente o nível de controlo que se espera de um trabalho de escrita cuidado.
Em resumo
- Um bundle OKF é um diretório de Markdown + frontmatter YAML; o Draft_ produz isso nativamente.
- Espaço = raiz, pastas = conceitos, zona de metadados = frontmatter, nome do documento = nome do ficheiro, ligações internas = grafo, sincronização com o GitHub = bundle versionado.
- Escreves num verdadeiro processador de texto e depois entregas o conhecimento tal como está a um agente.
- Três terrenos de jogo: bíblia de ficção, documentação técnica viva, notas de investigação consultáveis.
Para começar a construir a tua base de conhecimento OKF, já tens tudo o que precisas no Draft_: escreves, nomeias, sincronizas. O resto é Markdown, e já está nas tuas mãos.