Los últimos días han sido una verdadera lucha para lograr que esta habilidad funcione.
Empecé con Opus 4.6. Gasté más de 20 dólares. Aun así no conseguí que funcionara. Incluso me pregunté si el nuevo modelo que salió la mañana del 8 de abril de 2026 había consumido toda su capacidad de cómputo. Si no, ¿cómo podía entender un momento y luego desviarse al siguiente?
Después cambié a Codex, y logré construirla.
Pero surgió un nuevo problema: que la construyas no significa que funcione de forma fiable.
Especialmente cuando empiezas a probarla en serio, de vez en cuando ignoraba las instrucciones y hacía cambios por su cuenta, lo que me volvía loco.
Así que en este artículo no solo quiero decir “he creado una habilidad, siéntete libre de descargarla”.
Quiero dejar claro algo más: cómo implementar realmente el método LLM Wiki que Karpathy propuso en una bóveda de Obsidian.
El capítulo anterior cubría el método. Este capítulo trata sobre la práctica.
Si quieres descargar la versión actual saneada de mi habilidad, aquí tienes el enlace:
https://blog.discoverlabs.ac.cn/downloads/obsidian-wiki-skill/
Ya he eliminado las claves API, rutas locales, etc. Pero te lo digo de antemano: no la copies al pie de la letra.
Puedes aprender de este método. También puedes modificar esta habilidad. Pero no esperes que funcione sin más. La bóveda de notas de cada persona es demasiado diferente.
Lo que construí no es “IA organizando mis notas”, sino “IA haciendo mi contabilidad”
Primero, revisemos el Gist de Karpathy.
Enlace original:
https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
La idea central es realmente simple:
La mayoría de la gente usa actualmente los LLM para procesar documentos mediante RAG: meten un montón de archivos y, al consultar, recuperan y generan respuestas sobre la marcha.
Eso funciona, claro.
Pero el problema es que todo es ad hoc.
Pregunta una vez, ensambla una vez. Pregunta otra vez, empieza desde cero. Sin acumulación.
Así que él propuso una capa intermedia: en lugar de ensamblar respuestas sobre la marcha para cada consulta, mantener un Wiki de forma continua.
Cuando leí esto, mi primera reacción no fue “esto es genial”.
Fue: ¿no es exactamente el tipo de tarea para la que Obsidian es más adecuado?
Porque Obsidian es inherentemente una bóveda de archivos Markdown locales.
El Wiki que describe Karpathy es esencialmente una colección de archivos Markdown.
El formato subyacente es casi idéntico.
La diferencia es:
- Antes mantenías manualmente backlinks, páginas de temas y páginas de estructura
- Ahora la IA te ayuda con ese trabajo de “contabilidad”
Nota: contabilidad, no pensamiento.
Cada vez estoy más de acuerdo con esto.
Leer artículos, hacer juicios, escribir tus propias opiniones: eso sigue siendo cosa tuya.
Pero tareas como completar backlinks, normalizar nombres de autores, verificar el formato y actualizar páginas derivadas son esencialmente trabajo mecánico. La IA puede encargarse de ellas.
Cómo implementé la estructura de tres capas de Karpathy en Obsidian
La parte más importante del método de Karpathy son las tres capas:
- Raw Sources (Fuentes originales)
- The Wiki (El Wiki)
- The Schema (El Esquema)
Mi habilidad obsidian-wiki también se basa en estas tres capas.
Primera capa: Raw Sources
En mi bóveda, esta capa consiste en:
01-Notes/04-Output/
Es decir, colecciones originales, notas originales y artículos que he escrito.
Mantengo esta capa muy restringida.
Su única responsabilidad es preservar el contenido original.
No dejo que asuma funciones adicionales.
No mezclo contenido derivado.
No permito que un artículo original se convierta en mitad página de tema, mitad página de índice.
Porque una vez que se mezcla, se vuelve difícil de mantener.
Esta es una de las lecciones más profundas que aprendí al construir esta habilidad: cuanto más limpia sea la capa original, más fácil será todo lo demás.
Segunda capa: The Wiki
Esta capa está separada en mi bóveda:
01-Notes/wiki/
Aquí se encuentra la capa estructural derivada por la IA, como:
- Páginas de autores
- Páginas de temas
- Índice
- Registro
- Directorio de backlinks
En otras palabras, el texto original sigue siendo el texto original.
El Wiki es el Wiki.
Las dos capas están separadas.
Esto suena trivial, pero en realidad es muy importante.
Porque si no separas las capas, cada vez que la IA organiza, tiende a ensuciar el texto original.
Hoy añade un bloque de tema.
Mañana inserta un índice.
Pasado mañana añade un resumen generado automáticamente.
Al final, toda la bóveda parece una habitación que se ordena constantemente pero se vuelve más desordenada.
Tercera capa: The Schema
Mucha gente pasa por alto esta capa.
Karpathy menciona el esquema en su publicación original. Mi interpretación es: necesitas decirle a la IA cómo debería ser la bóveda.
En mi caso, esto incluye:
SKILL.md- Un montón de
scripts/ - Convenciones de frontmatter
- Restricciones sobre cómo se escriben autores y temas
- Restricciones de proceso para lint e ingest
Por ejemplo, ahora exijo:
- Los autores deben estar en formato de backlink
- Los temas deben ser una lista de backlinks
- Las páginas de autores y temas solo pueden ir en
01-Notes/wiki/ 00-Inbox/es solo una bandeja de procesamiento, no se mezcla directamente en el Wiki- Los artículos originales ya no contienen párrafos derivados
Descubrirás que lo que hace que la habilidad funcione no es lo bonito que esté escrito el prompt. La clave real es que estas restricciones se establezcan primero.
Traduciendo las tres acciones en flujos de trabajo ejecutables
Karpathy también tiene tres acciones principales:
- Ingest
- Query
- Lint
Yo seguí el mismo enfoque.
En términos del flujo de trabajo real en esta habilidad, se ve así:
- Ingest:
wiki_lint.py --preflight+ob_shuanglian.py suggest/apply+wiki_ingest.py - Query: Primero leer
wiki/index.md,authors/*.md,topics/*.md, luego volver al texto original para los detalles - Lint:
wiki_lint.py,wiki_migrate.py,wiki_build_skeleton.py
Ingest: Revisar el contenido nuevo antes de añadirlo a la bóveda
No dejo que la IA “vea un artículo e improvise” de inmediato.
Mi flujo de trabajo actual comienza con una comprobación previa (preflight).
Primero verifica si el frontmatter es correcto.
Luego verifica si hay contaminación histórica.
Después hace sugerencias de backlinks.
Tras la confirmación del usuario, aplica los cambios.
Finalmente, actualiza la capa derivada del Wiki.
¿Por qué tantas molestias?
Porque los modelos me lo han enseñado muchas veces.
Si no añades estas barreras de seguridad, la IA se apresurará a “tomar decisiones” por ti.
El problema es que sus decisiones pueden no ser lo que tú quieres.
Así que añadí fuertes puertas de confirmación.
No dejes que escriba temas arbitrariamente.
No dejes que aplique backlinks directamente.
No dejes que decida alias de autores por su cuenta.
Da sugerencias, yo confirmo, luego escribe.
Esto puede parecer menos eficiente.
Pero con una base de conocimiento, el mayor miedo no es la lentitud; es escribir algo incorrecto en silencio.
Query: No pescar en el mar del texto original, sino leer primero la capa del Wiki
Para las consultas, mi enfoque no es “buscar en toda la bóveda y dárselo a la IA para que resuma”.
En su lugar, primero pasa por:
wiki/index.mdauthors/*.mdtopics/*.md
Deja que la IA mire primero la capa estructurada.
Cuando sea necesario, vuelve a artículos específicos para obtener detalles.
Los beneficios son claros:
No tiene que reensamblar desde texto original disperso cada vez.
En cambio, responde desde una capa ya organizada.
Esto se acerca más a lo que Karpathy entiende por “acumulación”.
Lint: El paso más importante y más subestimado
Mucha gente se centra en Query cuando ve LLM Wiki.
Pero cuanto más trabajo en ello, más siento que Lint es donde reside el verdadero valor.
Porque una vez que la base de conocimiento crece, tu mayor dolor de cabeza no es “no poder obtener respuestas”, sino:
- Frontmatter desordenado
- Nombres de autores inconsistentes
- Temas dispersos
- Estructuras históricas que permanecen en el texto original
- Páginas derivadas cada vez más distorsionadas
- El mismo concepto aparece con varios nombres diferentes
Si intentas mantener todo esto manualmente, es desesperante.
Y no podrás mantenerlo.
Esto es exactamente para lo que la IA es mejor.
No para entender el mundo por ti.
Sino para patrullar la bóveda, conciliar, encontrar datos sucios y completar referencias cruzadas.
Por eso el término de Karpathy es tan acertado: contabilidad.
El verdadero escollo no es el modelo, es mi antigua bóveda de notas
Esto es también lo que más quiero advertir a todos.
Mucha gente lee un artículo como este y piensa instintivamente:
“Ah, puedo descargar la habilidad, instalarla y la IA gestionará mi base de conocimiento.”
Ese no es el caso.
El mayor desafío con esta habilidad no es el prompt, los scripts, ni siquiera el modelo.
Es que tengo demasiadas notas antiguas y sus formatos son inconsistentes.
Cuando ejecuto lint ahora, esta es la escala que veo:
- Fuentes originales tipo artículo: 457
- Archivos originales totales: 833
- Cola pendiente: 249
- El directorio de backlinks ya tiene 471 temas
Piensa en ese volumen.
Esto ya no se trata de “organizar unas cuantas notas”.
Es más como hacerse cargo de un sistema antiguo con una larga historia y sin estándares consistentes.
Algunos artículos tienen nombres completos de autores.
Algunos tienen alias.
Algunos temas son muy detallados.
Algunos están muy dispersos.
Algunos archivos antiguos aún contienen restos de estructuras previas.
Así que me fui convenciendo cada vez más de una cosa:
Si quieres construir un LLM Wiki, el primer paso no es dejar que la IA tome el control. El primer paso es limpiar tu bóveda hasta un estado “que merezca la pena asumir”.
De lo contrario, cuanto más diligente sea la IA, más propagará el desorden.
Entonces, ¿qué cosas extra hace realmente esta habilidad?
Si solo lees la publicación original de Karpathy, pensarías que es una metodología muy elegante.
Pero al construirla realmente, encontré muchos detalles de ingeniería que completar.
Por ejemplo:
- Estandarización del frontmatter
- Normalización de alias de autores
- Exigir formato de backlink para los temas
- Separar completamente las capas original y derivada
- Usar
00-Inbox/como bandeja de procesamiento - Añadir puertas de confirmación del usuario en pasos clave
- Dividir el flujo de trabajo con scripts como lint, migrate, ingest
No es que Karpathy no pensara en esto.
Es que su Gist describe un patrón, no la implementación específica para tu bóveda.
Al implementarlo realmente, debes completar esta capa tú mismo.
Mi habilidad actual obsidian-wiki esencialmente hace esto:
Traducir un patrón abstracto en un flujo de trabajo que se ejecuta en mi propia bóveda de Obsidian.
Así que si la descargas, lo más importante que debes aprender no es “copiar mi estructura de directorios”.
Es entender por qué organicé las capas de esta manera, por qué se necesita confirmación aquí, por qué se hace lint aquí, por qué no se usa la aplicación automática aquí.
Si quieres hacer esto también, modifica primero estas cosas
He puesto la versión saneada en la página de descarga de mi blog:
https://blog.discoverlabs.ac.cn/downloads/obsidian-wiki-skill/
Pero después de descargarla, lo primero no es ejecutarla.
Es modificarla.
Al menos revisa estas cosas:
- ¿Tu ruta de bóveda es la misma que la mía?
- ¿Tu estructura de
01-Notes/,04-Output/,00-Inbox/es la misma? - ¿Tus campos de frontmatter son consistentes con los míos?
- ¿Tus nombres de autores y nombres de temas ya son bastante consistentes?
- ¿Quieres mantener mi flujo de trabajo de “sugerir, confirmar, luego escribir”?
- Si los scripts involucran APIs, ¿los has reemplazado con tus propias claves?
La versión que publiqué ya ha saneado las claves API y las rutas locales.
Una vez que la obtengas, debes adaptarla a tu propio entorno.
Y sigo recomendando: no trates mi método como una plantilla, solo como una referencia.
Si tu bóveda es principalmente de notas de lectura, las reglas pueden diferir de las mías.
Si tu bóveda es principalmente de notas de proyectos, la granularidad de los temas será diferente.
Si tu bóveda aún está en la fase de “primero recolectar, luego organizar”, probablemente no deberías centrarte primero en Query, sino en hacer que Lint e Ingest funcionen correctamente.
Así que no copies al pie de la letra.
Modifica basándote en el enfoque, eso es más fiable.
Resumen
Al final de este artículo, mi propia sensación se ha vuelto más clara.
La propuesta de Karpathy no es solo una idea de que “la IA puede ayudarte a organizar tu base de conocimiento”.
Su verdadero valor es que redefine la división del trabajo entre humanos e IA en la gestión del conocimiento.
Los humanos se encargan del juicio.
La IA se encarga de la contabilidad.
Cuanto más trabajo en esto, más creo en esa afirmación.
Lo que aprendí hoy:
- La clave del LLM Wiki de Karpathy es la estructura de tres capas y las tres operaciones, no un solo prompt
- La clave de habilidades como
obsidian-wikino es “si puede resumir”, sino si puede separar Raw Sources, Wiki y Schema - En la práctica, Lint suele ser más importante que Query, porque la limpieza de datos históricos es la mayor parte del trabajo
- Cuantas más notas antiguas y más desordenado el formato, menos deberías copiar directamente la habilidad de otra persona
- Descargar una habilidad es fácil; el verdadero desafío es adaptarla para que encaje en tu propia base de conocimiento
Conclusiones clave:
- La IA es más adecuada para la contabilidad, no para pensar por ti
- Las capas original y derivada deben estar separadas, de lo contrario la base de conocimiento se vuelve más desordenada cuanto más la organizas
- Las puertas de confirmación del usuario no son pasos adicionales; son barreras de seguridad necesarias para evitar que la IA actúe por su cuenta
- Primero estandariza los formatos, luego habla de automatización; si inviertes el orden, sufrirás después
- Esta habilidad se puede modificar, pero no se recomienda copiarla tal cual