Transformer un Wiki de style Karpathy en une compétence réutilisable

Ces derniers jours ont été une vraie lutte pour faire fonctionner cette compétence.

J’ai commencé avec Opus 4.6. J’ai dépensé plus de 20 dollars. Je n’arrivais toujours pas à la faire fonctionner. Je me suis même demandé si le nouveau modèle sorti le matin du 8 avril 2026 n’avait pas accaparé toute leur puissance de calcul. Sinon, comment pouvait-il comprendre un instant puis dérailler le suivant ?

Plus tard, je suis passé à Codex, et j’ai réussi à la construire.

Mais un nouveau problème est apparu : la construire ne signifie pas qu’elle fonctionne de manière fiable.

Surtout quand on commence à la tester sérieusement, il lui arrivait parfois d’ignorer les instructions et de faire des modifications de lui-même, ce qui me rendait fou.

Donc dans cet article, je ne veux pas simplement dire « j’ai construit une compétence, n’hésitez pas à la télécharger ».

Je veux clarifier autre chose : comment implémenter concrètement la méthode LLM Wiki que Karpathy a proposée dans un coffre Obsidian.

Le chapitre précédent couvrait la méthode. Celui-ci parle de la pratique.

Si vous voulez télécharger la version actuelle nettoyée de ma compétence, voici le lien :

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

J’ai déjà supprimé les clés API, les chemins locaux, etc. Mais je le dis d’emblée : ne la copiez pas mot pour mot.

Vous pouvez apprendre de cette méthode. Vous pouvez aussi modifier cette compétence. Mais ne vous attendez pas à ce qu’elle fonctionne prête à l’emploi. Le coffre de notes de chacun est trop différent.

Ce que j’ai construit n’est pas « l’IA qui organise mes notes », mais « l’IA qui fait ma comptabilité »

Revenons d’abord au Gist de Karpathy.

Lien original :

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

L’idée centrale est en fait simple :

La plupart des gens utilisent actuellement les LLM pour le traitement de documents via RAG : on jette un tas de fichiers dedans, et lors de l’interrogation, on récupère et on génère des réponses à la volée.

Cela fonctionne, bien sûr.

Mais le problème est que tout est ad hoc.

Demander une fois, assembler une fois. Redemander, repartir de zéro. Pas d’accumulation.

Il a donc proposé une couche intermédiaire : au lieu d’assembler des réponses à la volée pour chaque requête, maintenir en continu un Wiki.

Quand j’ai lu cela, ma première réaction n’a pas été « c’est cool ».

C’était : n’est-ce pas exactement le genre de tâche pour lequel Obsidian est le mieux adapté ?

Parce qu’Obsidian est intrinsèquement un coffre de fichiers Markdown locaux.

Le Wiki que décrit Karpathy est essentiellement une collection de fichiers Markdown.

Le format sous-jacent est presque identique.

La différence est :

• Avant, vous mainteniez manuellement les rétroliens, les pages de sujets et les pages de structure
• Maintenant, l’IA vous aide pour ce travail de « comptabilité »

Note : comptabilité, pas réflexion.

Je suis de plus en plus d’accord avec cela.

Lire des articles, porter des jugements, écrire vos propres opinions – cela reste à faire par vous.

Mais des tâches comme compléter les rétroliens, normaliser les noms d’auteurs, vérifier le formatage et rafraîchir les pages dérivées sont essentiellement des tâches subalternes. L’IA peut les gérer.

Comment j’ai implémenté la structure à trois couches de Karpathy dans Obsidian

La partie la plus importante de la méthode de Karpathy réside dans les trois couches :

• Sources brutes
• Le Wiki
• Le Schema

Ma compétence obsidian-wiki est également construite autour de ces trois couches.

Première couche : Sources brutes

Dans mon coffre, cette couche se compose de :

• 01-Notes/
• 04-Output/

C’est-à-dire les collections brutes, les notes brutes et les articles que j’ai écrits.

Je garde cette couche très restreinte.

Sa seule responsabilité est de préserver le contenu original.

Je ne la laisse pas assumer de fonctions supplémentaires.

Je n’y mélange pas de contenu dérivé.

Je ne laisse pas un article brut devenir à moitié page de sujet, à moitié page d’index.

Parce qu’une fois mélangé, cela devient difficile à maintenir.

C’est l’une des leçons les plus profondes que j’ai apprises en construisant cette compétence : plus la couche brute est propre, plus tout le reste devient facile.

Deuxième couche : Le Wiki

Cette couche est séparée dans mon coffre :

01-Notes/wiki/

Elle contient la couche structurelle dérivée par l’IA, comme :

• Pages d’auteurs
• Pages de sujets
• Index
• Journal
• Répertoire de rétroliens

En d’autres termes, le texte original reste le texte original.

Le Wiki est le Wiki.

Les deux couches sont séparées.

Cela semble trivial, mais c’est en fait très important.

Parce que si vous ne séparez pas les couches, chaque fois que l’IA organise, elle a tendance à rendre le texte original plus désordonné.

Aujourd’hui, elle ajoute un bloc de sujet.

Demain, elle insère un index.

Le jour suivant, elle ajoute un résumé généré automatiquement.

Finalement, tout le coffre ressemble à une pièce constamment rangée mais qui devient de plus en plus en désordre.

Troisième couche : Le Schema

Beaucoup de gens négligent cette couche.

Karpathy mentionne le schema dans son article original. Ma compréhension est : vous devez dire à l’IA à quoi le coffre doit ressembler.

Dans mon cas, cela inclut :

• SKILL.md
• Un tas de scripts/
• Conventions de frontmatter
• Contraintes sur la façon dont les auteurs et les sujets sont écrits
• Contraintes de processus pour lint et ingest

Par exemple, j’impose maintenant :

• Les auteurs doivent être au format de rétrolien
• Les sujets doivent être une liste de rétroliens
• Les pages d’auteurs et les pages de sujets ne peuvent aller que dans 01-Notes/wiki/
• 00-Inbox/ est uniquement une boîte de réception de traitement, pas directement mélangée au Wiki
• Les articles bruts ne contiennent plus de paragraphes dérivés

Vous constaterez que ce qui fait fonctionner la compétence, ce n’est pas la beauté du prompt. La vraie clé est que ces contraintes sont établies en premier.

Traduire les trois actions en flux de travail exécutables

Karpathy a également trois actions centrales :

• Ingest
• Query
• Lint

J’ai suivi la même approche.

En termes de flux de travail réel dans cette compétence, cela ressemble à :

• Ingest : wiki_lint.py --preflight + ob_shuanglian.py suggest/apply + wiki_ingest.py
• Query : Lire d’abord wiki/index.md, authors/*.md, topics/*.md, puis revenir au texte original pour les détails
• Lint : wiki_lint.py, wiki_migrate.py, wiki_build_skeleton.py

Ingest : Vérifier le nouveau contenu avant de l’ajouter au coffre

Je ne laisse pas l’IA « voir un article et improviser » tout de suite.

Mon flux de travail actuel commence par une vérification préliminaire.

D’abord, vérifier si le frontmatter est correct.

Ensuite, vérifier la contamination historique.

Puis faire des suggestions de rétroliens.

Après confirmation de l’utilisateur, appliquer réellement.

Enfin, rafraîchir la couche dérivée du Wiki.

Pourquoi tant de complications ?

Parce que les modèles me l’ont appris à plusieurs reprises.

Si vous n’ajoutez pas ces garde-fous, ils prendront avec empressement des « décisions » pour vous.

Le problème est que leurs décisions peuvent ne pas être ce que vous voulez.

J’ai donc ajouté de solides portes de confirmation.

Ne le laissez pas écrire des sujets arbitrairement.

Ne le laissez pas appliquer des rétroliens directement.

Ne le laissez pas décider seul des alias d’auteurs.

Donnez des suggestions, je confirme, puis j’écris.

Cela peut sembler moins efficace.

Mais avec une base de connaissances, la plus grande peur n’est pas la lenteur ; c’est d’écrire silencieusement quelque chose de faux.

Query : Ne pas pêcher dans la mer du texte original, mais lire d’abord la couche Wiki

Pour les requêtes, mon approche n’est pas « chercher dans tout le coffre et le donner à l’IA pour résumé ».

Au lieu de cela, elle passe d’abord par :

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

Laissez l’IA regarder d’abord la couche structurée.

Quand c’est nécessaire, revenir à des articles spécifiques pour les détails.

Les avantages sont clairs :

Elle n’a pas besoin de réassembler à partir de textes originaux dispersés à chaque fois.

Au lieu de cela, elle répond à partir d’une couche déjà organisée.

C’est plus proche de ce que Karpathy entend par « accumulation ».

Lint : L’étape la plus importante et la plus sous-estimée

Beaucoup de gens se concentrent sur Query quand ils voient LLM Wiki.

Mais plus je travaille dessus, plus je ressens que Lint est là où se trouve la vraie valeur.

Parce qu’une fois que la base de connaissances grandit, votre plus gros casse-tête n’est pas « ne pas pouvoir obtenir de réponses », mais :

• Le frontmatter est en désordre
• Les noms d’auteurs sont incohérents
• Les sujets sont dispersés
• Les structures historiques subsistent dans le texte original
• Les pages dérivées deviennent de plus en plus déformées
• Le même concept apparaît sous plusieurs noms différents

Si vous essayez de maintenir cela manuellement, c’est exaspérant.

Et vous ne pourrez pas suivre.

C’est exactement ce que l’IA fait de mieux.

Pas comprendre le monde à votre place.

Mais patrouiller le coffre, réconcilier, trouver des données sales et remplir les références croisées.

C’est pourquoi le terme de Karpathy est si juste : comptabilité.

Le véritable écueil n’est pas le modèle, c’est mon ancien coffre de notes

C’est aussi ce que je veux le plus vous avertir.

Beaucoup de gens lisent un article comme celui-ci et pensent instinctivement :

« Oh, je peux simplement télécharger la compétence, l’installer, et l’IA gérera ma base de connaissances. »

Ce n’est pas le cas.

Le plus grand défi avec cette compétence n’est pas le prompt, les scripts, ni même le modèle.

C’est que j’ai trop de vieilles notes, et leurs formats sont incohérents.

Quand j’exécute lint maintenant, voici l’échelle que je vois :

• Sources brutes de type article : 457
• Total de fichiers bruts : 833
• File d’attente : 249
• Le répertoire de rétroliens a déjà 471 sujets

Pensez à ce volume.

Ce n’est plus une question d’« organiser quelques notes ».

C’est plutôt comme reprendre un ancien système avec une longue histoire et sans normes cohérentes.

Certains articles ont des noms d’auteurs complets.

Certains ont des alias.

Certains sujets sont très détaillés.

Certains sont très dispersés.

Certains vieux fichiers contiennent encore des vestiges de structures précédentes.

Je suis donc devenu de plus en plus certain d’une chose :

Si vous voulez construire un LLM Wiki, la première étape n’est pas de laisser l’IA prendre le contrôle. La première étape est de nettoyer votre coffre jusqu’à un état « digne d’être pris en charge ».

Sinon, plus l’IA est diligente, plus elle propage le désordre.

Alors, quelles choses supplémentaires cette compétence fait-elle réellement ?

Si vous lisez seulement l’article original de Karpathy, vous penseriez que c’est une méthodologie très élégante.

Mais en la construisant réellement, j’ai trouvé de nombreux détails d’ingénierie à combler.

Par exemple :

• Standardisation du frontmatter
• Normalisation des alias d’auteurs
• Imposer le format de rétrolien pour les sujets
• Séparer complètement les couches brutes et dérivées
• Utiliser 00-Inbox/ comme boîte de réception de traitement
• Ajouter des portes de confirmation utilisateur aux étapes clés
• Décomposer le flux de travail avec des scripts comme lint, migrate, ingest

Ce n’est pas que Karpathy n’y a pas pensé.

C’est que son Gist décrit un modèle, pas l’implémentation spécifique pour votre coffre.

Lors de l’implémentation réelle, vous devez remplir cette couche vous-même.

Ma compétence actuelle obsidian-wiki fait essentiellement cela :

Traduire un modèle abstrait en un flux de travail qui s’exécute sur mon propre coffre Obsidian.

Donc si vous la téléchargez, la chose la plus importante à apprendre n’est pas « copier ma structure de répertoires ».

C’est de comprendre pourquoi j’ai organisé les couches de cette façon, pourquoi une confirmation est nécessaire ici, pourquoi lint est fait ici, pourquoi je n’utilise pas l’application automatique ici.

Si vous voulez faire de même, modifiez d’abord ces éléments

J’ai mis la version nettoyée sur la page de téléchargement de mon blog :

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

Mais après le téléchargement, la première chose n’est pas de l’exécuter.

C’est de la modifier.

Vérifiez au moins ces points :

1. Votre chemin de coffre est-il le même que le mien ?
2. Votre structure 01-Notes/, 04-Output/, 00-Inbox/ est-elle la même ?
3. Vos champs frontmatter sont-ils cohérents avec les miens ?
4. Vos noms d’auteurs et noms de sujets sont-ils déjà assez cohérents ?
5. Voulez-vous conserver mon flux de travail « suggérer, confirmer, puis écrire » ?
6. Si les scripts impliquent des API, les avez-vous remplacées par vos propres clés ?

La version que j’ai publiée a déjà nettoyé les clés API et les chemins locaux.

Après l’avoir récupérée, vous devez l’adapter à votre propre environnement.

Et je recommande toujours : ne considérez pas ma méthode comme un modèle, mais comme une référence.

Si votre coffre est principalement des notes de lecture, les règles peuvent différer des miennes.

Si votre coffre est principalement des notes de projet, la granularité des sujets différera.

Si votre coffre est encore dans la phase « collecter d’abord, organiser ensuite », vous ne devriez probablement pas vous concentrer d’abord sur Query, mais plutôt faire fonctionner Lint et Ingest correctement.

Donc ne copiez pas mot pour mot.

Modifiez en fonction de l’approche, c’est plus fiable.

Résumé

À la fin de cet article, mon propre sentiment est devenu plus clair.

La proposition de Karpathy n’est pas seulement une idée selon laquelle « l’IA peut vous aider à organiser votre base de connaissances ».

Sa vraie valeur est qu’elle redéfinit la division du travail entre l’humain et l’IA dans la gestion des connaissances.

L’humain gère le jugement.

L’IA gère la comptabilité.

Plus je travaille là-dessus, plus je crois en cette affirmation.

Ce que j’ai appris aujourd’hui :

1. La clé du LLM Wiki de Karpathy est la structure à trois couches et les trois opérations, pas un seul prompt
2. La clé des compétences comme obsidian-wiki n’est pas « peut-elle résumer », mais si elle peut séparer Sources brutes, Wiki et Schema
3. En pratique, Lint est souvent plus important que Query, car le nettoyage des données historiques représente l’essentiel du travail
4. Plus il y a de vieilles notes et plus le format est désordonné, moins vous devriez copier directement la compétence de quelqu’un d’autre
5. Télécharger une compétence est facile ; le vrai défi est de l’adapter pour qu’elle corresponde à votre propre base de connaissances

Points clés à retenir :

• L’IA est la mieux adaptée pour la comptabilité, pas pour penser à votre place
• Les couches brutes et dérivées doivent être séparées, sinon la base de connaissances devient de plus en plus désordonnée à mesure que vous organisez
• Les portes de confirmation utilisateur ne sont pas des étapes supplémentaires ; ce sont des garde-fous nécessaires pour empêcher l’IA d’agir seule
• Standardisez d’abord les formats, puis parlez d’automatisation ; si vous inversez l’ordre, vous en souffrirez plus tard
• Cette compétence peut être modifiée, mais il n’est pas recommandé de la copier telle quelle