De un canal de YouTube a una base de conocimiento con NotebookLM y Claude Code
De cientos de vídeos guardados a una biblioteca en Markdown que uso mientras trabajo. La extensión que lo abre todo, el experimento real —de 300 fuentes a una base de unas 59.000 palabras— y cómo lo hice, paso a paso.
Una extensión que hace de puente
Manda a NotebookLM no solo un vídeo: playlists, canales enteros y hasta los resultados de una búsqueda de YouTube. Instalar, probar e importar en masa.
300 fuentes y un giro
Un volcado único «sácamelo todo» condensa demasiado. La clave está en extraer el conocimiento por dominios, no por vídeo. Con el prompt exacto que usé.
Casi 59.000 palabras en local
Una base de conocimiento en Markdown, con sus fuentes, que trabajo desde Claude Code. Investigar un corpus, no resumir un vídeo.
No clono a nadie
Es contenido público estructurado para investigar. Más fuentes no es mejor base. Fuentes buenas, con propósito, conservando siempre el origen.
Tengo un problema con YouTube. Guardo demasiadas cosas. Tutoriales. Entrevistas. Podcasts de hora y media. Fundadores explicando cómo construyeron sus empresas. Ingenieros enseñando las tripas de sistemas que quiero entender. Y hago lo que hacemos todos: guardar, «Ver más tarde», otra playlist, otro favorito, otra pestaña abierta.
Hasta que seis meses después recuerdo perfectamente que alguien explicó justo lo que necesito… pero no recuerdo quién. Ni en qué vídeo. Ni en qué minuto. Ni siquiera estoy segura de en qué canal estaba.
Yo quería otra cosa. Quería coger un canal de YouTube —o varios—, llevarme sus fuentes a NotebookLM, exprimir ese conocimiento, sacarlo en Markdown, guardarlo en mi ordenador y poder utilizarlo después desde Claude Code. No un resumen de diez páginas. No un PDF monstruoso. No un chat al que hacerle cuatro preguntas y olvidarme. Quería construir una biblioteca.
En mi primera prueba trabajé con un notebook que terminó teniendo 300 fuentes, y acabé con una base de aproximadamente 59.148 palabras. Te lo cuento entero, desde cero.
El juguetito: una extensión que manda YouTube entero a NotebookLM
NotebookLM ya permite añadir vídeos de YouTube como fuentes. El problema no es meter uno. Es meter trescientos sin copiar trescientas URLs a mano.
Si quieres añadir tres vídeos, puedes hacerlo uno a uno. Copias URL, añades fuente, siguiente. No pasa nada. El problema aparece cuando quieres trabajar con 50 vídeos. 100. 200. Un canal entero. Una playlist enorme. Yo no iba a copiar 300 URLs manualmente.
Ahí encontré una extensión de Chrome llamada YouTube to NotebookLM – YouTube to Gemini Notebook. Su función es sencilla: hacer de puente entre YouTube y NotebookLM. Y no únicamente con un vídeo. La ficha de la extensión que utilicé indica soporte para vídeos individuales, varios vídeos, playlists, canales y resultados de búsqueda, además de elegir un notebook existente o crear uno nuevo durante el flujo.
Eso cambia lo que puedes hacer. Ya no piensas «quiero guardar este vídeo». Piensas: «quiero construir una biblioteca alrededor de este tema». Puedes partir de un canal entero y tratarlo como un corpus de investigación, y quedarte solo con los vídeos que de verdad te interesan.
Pero lo que más me interesa no es ni siquiera el canal. Es poder partir de una búsqueda. No construyes la biblioteca alrededor de una persona: la construyes alrededor de un problema. Voy a YouTube, busco algo concreto, y me llevo una colección de fuentes de creadores distintos alrededor de esa pregunta.
Pasas de «canal → biblioteca» a «problema → búsqueda → fuentes diferentes → biblioteca». Para investigar, la segunda estructura puede ser incluso mejor. Eso convierte YouTube en algo distinto de una plataforma donde sentarte a ver vídeos: empieza a funcionar como una fuente de materiales para construir una investigación.
La extensión que utilicé no es una extensión oficial de Google: es una herramienta de terceros. Como con cualquier extensión que metes en tu navegador de trabajo, yo revisaría quién la publica, qué permisos solicita, cuándo se actualizó y su política de privacidad antes de darle a «Añadir a Chrome». No le doy como si fueran pipas. Reviso primero.
Tutorial desde cero: instala, prueba, importa en masa
Cinco movimientos. Ni uno más. No hace falta convertir «fijar una extensión en Chrome» en una oposición.
Instala la extensión
En Chrome Web Store, busca YouTube to NotebookLM, comprueba que estás en la correcta, revisa permisos y privacidad, y añádela. Si la vas a usar mucho, déjala fijada en la barra. Ya está, no tiene más misterio.
Prueba un vídeo antes de hacer nada bestia
Crea un notebook de prueba (PRUEBA-YOUTUBE, da igual el nombre). Abre un vídeo con bastante conversación —no uno de veinte minutos compartiendo pantalla sin hablar—, pulsa la extensión, mándalo a ese notebook y comprueba que aparece entre tus fuentes. Pregúntale algo concreto y mira las referencias. Si esto falla con un vídeo, no tiene sentido meter 300.
Importa en masa: playlist, canal o búsqueda
Sube un escalón: una playlist de 5, 10 o 20 vídeos. No 600. Todavía. Cuando funcione, ve a por el canal o la búsqueda. Empieza pequeño porque en un corpus grande hay shorts, clips, duplicados, directos y fragmentos de entrevistas que ya tienes completas. La automatización te quita el trabajo mecánico, no la decisión de qué merece entrar.
Organiza NotebookLM por propósito
No construyas un cajón enorme llamado COSAS BUENAS DE YOUTUBE: dentro de seis meses es un vertedero. Agrupa por tema en notebooks distintos —SAAS-PRODUCT, FOUNDERS, VENTAS-B2B, VOICE-AI-TRIPAS—. Y ojo con los límites: en mi caso, ese notebook topó en 300 fuentes, pero eso depende de tu plan. Comprueba el tuyo.
Empieza a trabajar
Ya tienes un corpus dentro de NotebookLM. La extensión te ahorró los clics; el criterio sigue siendo tuyo.
El salto de verdad es la importación en masa: una playlist entera pasa a tu cuaderno de una sola vez, con sus transcripciones.
Para no hacernos películas: lo que llega a NotebookLM es el contenido textual asociado a la fuente, no el archivo de vídeo ni todo lo visual. Si alguien explica verbalmente durante una hora, tienes muchísimo material. Si solo comparte pantalla sin apenas hablar, ese conocimiento visual puede no quedar representado igual. Por eso la calidad de la fuente importa: si metes ruido, después tendrás ruido maravillosamente organizado.
Tener 300 vídeos dentro de NotebookLM no es tener una base de conocimiento
Aquí está lo mejor de todo esto: cómo pasé de un montón de fuentes a una base que puedo trabajar de verdad — con el prompt exacto que usé.
Mi experimento: llegué a 300 fuentes
Reuní un corpus grande. NotebookLM podía trabajar con él. Y entonces quise llevármelo más lejos.
En mi primera prueba llené un notebook hasta el límite que tenía disponible: 300 fuentes. Podía preguntarle, localizar contenido, revisar referencias. Todo bien. Pero seguía teniendo 300 fuentes dentro de NotebookLM. Y yo no quería un chat con 300 vídeos. Quería sacar ese conocimiento, llevarlo a Markdown en mi ordenador y trabajarlo desde Claude Code. Quería una base de conocimiento local.
Así que empecé por lo más obvio. Y ahí aprendí cómo funciona esto de verdad.
El primer volcado: «sácamelo todo» → 18 KB
Lo primero que probé fue pedir que lo volcara todo de golpe. Es lo que haría cualquiera — y ahí entendí cómo se comporta la herramienta.
Le pedí algo parecido a esto:
Genera un documento en Markdown con todo el conocimiento disponible en estas fuentes. No inventes nada. Mantén las citas.
NotebookLM creó desde Studio un documento. Lo descargué. Aproximadamente 18 KB. Unas diez secciones. Lo abrí y estaba bien: ordenado, coherente, basado en las fuentes, con referencias. Pero tenía delante unas 300 fuentes, y eso se me quedaba muy corto para lo que quería construir.
No porque un documento tenga que ser gigantesco para ser bueno. Sino porque mi objetivo no era un resumen: quería un corpus lo bastante profundo como para usarlo después como referencia. La primera petición intentaba meter una colección enorme en una única salida, y NotebookLM hizo lo razonable: condensó. Yo no quería condensar tanto.
Evaluamos una salida preguntando «¿está bien escrita?». Pero la pregunta real es «¿resuelve lo que quería construir?». Mi documento estaba bien. Y no me servía. Una respuesta correcta puede no servirte.
Pensé en la vía obvia: «pues me bajo las 300 transcripciones, una por vídeo». Pero en el flujo con el que trabajaba, NotebookLM no me ofrecía un botón de «descargar las 300 transcripciones completas como .md». Podía consultar la fuente por dentro, no exportarla en masa en el formato que yo quería. Así que descarté esa ruta. No porque el contenido no estuviera: porque mi flujo no tenía la salida que yo necesitaba. Otra cosa distinta.
El giro: extraer por dominios, no por vídeo
Aquí está la decisión que lo cambió todo. No cambié la herramienta. Cambié la unidad de extracción.
Extraer por tema, no por vídeo ni en un único documento gigantesco.
Un dominio es simplemente una parte suficientemente coherente del conocimiento. No hay una lista universal: depende del corpus. En ventas B2B podrían salir prospección, discovery, objeciones, cierre, pricing, pipeline. En producto SaaS: discovery, roadmap, pricing, onboarding, retención, growth. En voice AI: arquitectura, latencia, STT, TTS, turn-taking, telefonía, SIP, observabilidad, producción.
No decido los dominios antes de mirar. Los saco después de mirar las fuentes. Una buena primera pregunta es pedirle a NotebookLM que identifique los grandes dominios presentes en las fuentes, usando solo las fuentes y sin inventarse categorías para rellenar una estructura. Reviso esa clasificación, quito solapamientos, uno lo que va junto, separo lo que no. Y entonces empiezo a extraer, dominio por dominio.
El objetivo es dividir el conocimiento de forma que pueda pedir mucha más profundidad sin obligar a la herramienta a resumirlo todo de golpe. Si tienes un corpus enorme y dices «dímelo todo», tiene que decidir qué cabe. Si dices «ahora solo trabajamos esta parte, y la quiero profunda», la situación cambia por completo.
El prompt real que utilicé
Después de varias pruebas, este es el patrón que me funcionó. Lo adaptas al dominio y lo repites por cada uno.
Crea AHORA directamente en Studio, sin proponer plan ni pedirme
confirmación, un documento .md titulado "[NOMBRE DEL DOMINIO]".
Extrae de las fuentes ABSOLUTAMENTE TODO lo relacionado con:
[DESCRIPCIÓN DEL DOMINIO]
No resumas ni omitas información relevante.
Organiza el contenido para poder utilizarlo posteriormente
como base de conocimiento.
Mantén las citas [n].
No añadas conocimiento externo.
No completes huecos.
Si algo no aparece en las fuentes, no lo inventes.
Escribe en español claro y limpio.La parte de «sin proponer plan ni pedirme confirmación» no está ahí porque quede elegante. Está ahí porque me hizo falta. La primera vez que pedí un documento exhaustivo, NotebookLM me respondió proponiéndome una estructura. Muy amable. Muy ordenado. Muy poco útil para lo que yo estaba haciendo. Yo no quería «podemos organizarlo así…». Quería haz el documento. Con esa frase, el comportamiento cambió.
Lo cuento porque luego pruebas el procedimiento, la herramienta decide tener iniciativa y piensas «pues a Mili esto le funcionaba». Sí. Después de pegarle un par de collejas al prompt.
De NotebookLM a mi ordenador: Claude in Chrome + Claude Code
Hasta aquí me movía entre YouTube, NotebookLM y la carpeta de Descargas. Ahora quería llevarme el proceso a mi entorno de trabajo.
Por cada dominio, el proceso fue mecánico: escribir el prompt con ese dominio, esperar a que NotebookLM cree el documento en Studio, comprobar que realmente lo ha creado (y no me ha devuelto solo un plan), revisar por encima que tiene profundidad y conserva referencias, y descargarlo. Y otra vez. Y otra.
Aquí entró Claude in Chrome junto con Claude Code. En mi caso, Claude estaba operando mi Chrome real: mi sesión, mi NotebookLM ya abierto, mi cuenta de Google autenticada. No tuve que inventarme otra capa de login para que trabajara con lo que yo ya tenía abierto. Eso me dejó combinar dos mundos: el navegador (NotebookLM) y el sistema de archivos (los Markdown en mi ordenador, que Claude Code podía recorrer). Ahí las piezas empezaron a encajar.
Trabajé en Markdown a propósito. Es texto: lo leo con cualquier editor, lo busco, lo muevo, lo versiono, lo proceso con scripts y Claude Code lo recorre sin depender de ninguna aplicación concreta. No estoy construyendo un documento bonito; estoy construyendo material de trabajo. Y monté una estructura clara —nada del otro mundo— conservando cada pieza por separado:
knowledge/
└── voice-ai/
├── README.md
├── BASE-CONOCIMIENTO.md
└── piezas/
├── 01-arquitectura.md
├── 02-latencia.md
├── 03-stt.md
├── 04-tts.md
└── ...No junté las piezas y las borré. Las conservo: puedo regenerar una, revisarla, compararla o actualizar solo un dominio sin tocar el resto. El documento maestro es un derivado; las piezas siguen mandando.
Opcional · el script que une las piezas en un maestro
Si además quieres unir automáticamente todas las piezas en un único BASE-CONOCIMIENTO.md, este es el script mínimo que utilicé. No hace falta montar un cohete: si cambias una pieza, vuelves a ejecutarlo y ya. No mantienes el maestro a mano.
from pathlib import Path
BASE = Path("piezas")
OUTPUT = Path("BASE-CONOCIMIENTO.md")
files = sorted(BASE.glob("*.md"))
with OUTPUT.open("w", encoding="utf-8") as out:
out.write("# Base de conocimiento\n\n## Índice\n\n")
for file in files:
out.write(f"- {file.stem}\n")
out.write("\n---\n\n")
for file in files:
out.write(file.read_text(encoding="utf-8"))
out.write("\n\n---\n\n")
print(f"Generado: {OUTPUT}")Resultado: unas 59.000 palabras (y el lío de las citas)
La misma herramienta, el mismo corpus. Solo cambié cómo se lo pedía.
Esto no significa «cuantas más palabras, mejor». En absoluto. Significa que un volcado único pide una condensación gigantesca, y al dividir el problema por dominios pude recuperar mucha más profundidad. Es una diferencia importante.
Pero apareció una trampa. Los documentos conservaban referencias del tipo [1], [2], [3] —justo lo que quiero, para poder volver a la fuente—. El problema: cuando unes varios dominios en un maestro, el [3] de una pieza no tiene por qué ser la misma fuente que el [3] de otra. La numeración vive dentro de cada documento; no es un índice universal compartido por toda la base. Así que añadí una nota explícita al maestro:
La numeración [n] se conserva tal y como aparece en cada pieza generada. Las referencias deben interpretarse dentro de su dominio de origen y no como un índice global compartido por toda la base.
Parece una chorrada. Hasta que dentro de seis meses intentas rastrear una afirmación y acabas mirando el vídeo equivocado.
Qué puedes hacer ahora con esta biblioteca
Aquí es donde todo el trabajo empieza a merecer la pena. Esto ya no es resumir un vídeo. Es investigar un corpus.
No quiero preguntarle «resume Retell» —eso lo hago sin todo este montaje—. Quiero preguntas que cruzan decenas de fuentes a la vez:
Busca todas las referencias a latencia end-to-end y agrupa las causas mencionadas por las diferentes fuentes.
Compara lo que explican LiveKit, Daily y Pipecat sobre transporte de audio. Separa coincidencias, diferencias y aspectos que no sean comparables.
Encuentra afirmaciones aparentemente contradictorias y comprueba si pueden explicarse por fecha, arquitectura o caso de uso.
Localiza todas las explicaciones sobre pricing entre estas entrevistas y separa los enfoques por tipo de empresa. No me des una síntesis genérica: conserva las diferencias entre fuentes.
Ese último matiz es importante. No quiero aplastar diez opiniones hasta conseguir una papilla promedio. Quiero conservar las discrepancias: son parte del conocimiento. Y una aparente contradicción entre dos vídeos a veces no es contradicción — es que uno es de 2024 y otro de 2026. El tiempo forma parte del conocimiento, y por eso conservo siempre que puedo fecha, título, fuente y enlace original.
Dos límites que me pongo yo misma. Uno: que la base tenga 59.000 palabras no la convierte en un oráculo. Si trabajo una función actual de un servicio que cambia —Retell, ElevenLabs, LiveKit—, compruebo la documentación vigente cuando la exactitud dependa de ello. La biblioteca sirve para investigar, comparar y recuperar; no para congelar el mundo. Dos: más fuentes no es mejor base. Prefiero 120 fuentes técnicas bien elegidas a 5.000 vídeos sin criterio, porque las primeras las puedo mantener, auditar e interrogar. El objetivo no es acumular tokens. Es poder trabajar.
No he clonado el cerebro de nadie. Tengo contenido público, lo he estructurado y he creado herramientas para investigarlo. No quiero que Claude finja ser la persona que publicó los vídeos; quiero poder preguntar «¿qué explicó esta persona sobre esto?». Construir una biblioteca para estudiar no convierte ese material en mío ni me da licencia para republicar el trabajo de nadie con otro nombre. Por eso conservo siempre la fuente.
Y fui más lejos: de la base a Skills
Podría haber parado aquí. De hecho, no necesitas Skills para que este flujo merezca la pena. Yo seguí porque me interesaba otra cosa.
Con la base ya podía investigar, buscar y comparar desde Claude Code. Si eso es lo que buscas, puedes parar tranquilamente en knowledge/BASE-CONOCIMIENTO.md con su carpeta de piezas/. Ya tienes una biblioteca potentísima.
Pero a mí no me interesaba solo «¿qué contienen estas fuentes?». También: «¿cómo quiero que se utilicen para determinadas tareas?». Ahí entran las Skills. Y la decisión de fondo fue separar dos cosas que suelo ver mezcladas: el conocimiento (qué dicen las fuentes) vive en references/, y el comportamiento (cómo quiero trabajar con ellas) vive en SKILL.md. Así actualizo las fuentes sin reescribir el comportamiento, y al revés.
mi-skill/
├── SKILL.md # instrucciones: para qué sirve, cuándo usarla, qué no inventar
└── references/ # la profundidad: un .md por dominio
├── dominio-1.md
└── dominio-2.mdNo hice una mega-Skill que lo sabe todo. Preferí varias pequeñas, por función, y que cada una lea solo el dominio que necesita, no las 59.000 palabras «por si acaso». Si analizo una arquitectura de voz, no quiero cargar conocimiento de contratación. Cuanto más específico es el trabajo, más sentido tiene cargar solo el contexto relevante.
Datos reales > metodología. Si le doy a una Skill de ventas mi conversión, mis precios y mis restricciones, no quiero que responda «según el método deberías…» ignorando mis datos. La biblioteca es referencia. No religión.
Pero destripar de verdad esto —el SKILL.md por dentro, los references/, la lectura selectiva, los symlinks para tenerlas visibles, la Skill-brújula que decide cuándo ninguna basta, la de-duplicación y la auditoría final que encontró problemas reales— da para un artículo entero. Y lo voy a escribir aparte, para no robarle el sitio a lo que va este: llevar YouTube a una base de conocimiento que puedes trabajar.
Lo próximo: VOICE AI / TRIPAS
Lo siguiente para mí no es importar 20.000 vídeos. Es probar hasta dónde puedo llevar una biblioteca buena.
La que tengo ganas de abrir por dentro es VOICE AI / TRIPAS. Ahí enfrentaría Retell, ElevenLabs, LiveKit, Daily, Pipecat, HappyRobot, entrevistas técnicas y arquitecturas distintas. No una biblioteca genérica sobre agentes de voz. Las tripas:
Y empezaría a hacerle preguntas difíciles. No «¿qué es un agente de voz?» —eso me aburre—. Quiero saber dónde se genera realmente la latencia según cada arquitectura, qué parte controla cada proveedor, qué estrategias aparecen para las interrupciones, qué cambia cuando entra la telefonía tradicional y dónde encaja SIP, cómo se mide una conversación buena, qué problemas aparecen solo en producción y qué recomendaciones antiguas han quedado desfasadas. Ahí es donde quiero llevar este juguetito.
Empecé queriendo guardar mejor unos vídeos. Terminé montando una tubería.
Lo gracioso es que ninguna pieza por separado es especialmente loca. YouTube ya estaba ahí. NotebookLM ya estaba ahí. Chrome ya estaba ahí. Claude Code ya estaba ahí. Markdown existe desde antes de que tuviéramos tantas pestañas abiertas. La parte interesante fue conectarlo.
Porque tengo una cantidad absurda de conocimiento guardado que casi nunca vuelvo a usar, y durante años el sistema ha sido guardar primero y rezar para acordarme después. No quiero seguir haciendo eso. Quiero elegir fuentes buenas, conservarlas, poder volver al origen, extraer lo que me interesa y tenerlo disponible justo donde trabajo.
Algún vídeo de hora y media seguirá cayendo. Eso no me lo quita nadie. Pero al menos ya no va directo al cementerio de «Ver más tarde».
Preguntas frecuentes
Las cuatro que me llegan cada vez que enseño este flujo.
¿Se puede meter un canal entero de YouTube en NotebookLM?
Sí, con una extensión de Chrome de terceros llamada «YouTube to NotebookLM – YouTube to Gemini Notebook». Su ficha declara soporte para vídeos individuales, varios vídeos, playlists, canales y resultados de búsqueda de YouTube, además de elegir un notebook existente o crear uno nuevo. No es una extensión oficial de Google, así que conviene revisar desarrollador, permisos y privacidad antes de instalarla.
¿Qué recibe NotebookLM de un vídeo de YouTube?
El contenido textual asociado a la fuente. No estás descargando el archivo de vídeo ni convirtiendo automáticamente todo lo visual en documentación. Si una persona explica verbalmente durante una hora, tienes muchísimo material; si solo comparte pantalla sin verbalizar, parte de ese conocimiento visual puede no quedar representado igual. Por eso la calidad de la fuente importa.
¿Por qué mi extracción de NotebookLM sale demasiado corta?
Porque pedir «sácamelo todo de golpe» con cientos de fuentes obliga a la herramienta a condensar. En una prueba con unas 300 fuentes, un único documento salió de unos 18 KB. La solución es cambiar la unidad de extracción: extraer por dominios de conocimiento, uno a uno y con profundidad, en lugar de por vídeo o en un solo documento. Así se pasó de 18 KB a una base de aproximadamente 59.148 palabras.
¿Esto es clonar el cerebro de alguien?
No. Es contenido público estructurado para investigarlo. No se trata de que la IA finja ser la persona que publicó los vídeos ni de republicar su trabajo con otro nombre. Construir una biblioteca para estudiar no convierte ese material en propio; por eso conviene conservar siempre la fuente original, la fecha y el enlace.
Cada semana, desde las trincheras
Casos reales, errores documentados y lo que funciona de verdad en IA aplicada a negocio.
Sin teoría. Sin hype. Desde producción.
Contacto
¿Quieres montar tu propia base de conocimiento y no sabes por dónde empezar?
Si tienes un montón de fuentes buenas muertas de risa —vídeos, cursos, documentación— y quieres convertirlas en algo que uses mientras trabajas, hablemos.
Escríbeme directo. Sin formularios. Sin intermediarios.
Si tienes proyecto, dame contexto. Si no encajamos, te lo digo.