La plupart des compétences écrites par la majorité des gens sont incorrectes : 5 réflexions après la publication de la méthodologie interne par Anthropic

Auteur : AI Produit A-Ying

J'ai lu un article de blog écrit par l'équipe Anthropic intitulé « Lessons from building Claude Code : How we use skills ». C'est probablement la synthèse la plus approfondie que j'ai vue jusqu'à présent sur le sujet des Skills.

Les Skills ne sont pas vraiment compliqués, mais je pense que faire un bon Skill n'est pas si facile que ça.

Je me souviens qu'à l'époque où les Skills ont commencé à devenir populaires, tout le monde aimait créer des Skills de style littéraire, de rédaction. On aurait dit qu'il suffisait d'y insérer son propre style d'écriture, et le modèle pouvait produire de manière stable dans ce style.

Mais après avoir essayé moi-même, j'ai découvert que souvent, ce n'était tout simplement pas faisable.

Car un Skill de style littéraire peut contenir quelques milliers, voire des dizaines de milliers de mots. Lorsqu'on le charge, le contexte occupe une grande partie de la mémoire. Avec un contexte lourd, la capacité de réflexion du modèle diminue souvent.

Ce qui arrive fréquemment, c'est : le style est bien appris, mais le contenu devient superficiel, et la capacité d'analyse s'affaiblit.

Il y a aussi un autre cas courant.

Beaucoup de gens, lorsqu'ils écrivent un Skill, aiment y insérer toutes sortes d'instructions opérationnelles : la première étape, la deuxième étape, la troisième étape. Résultat, lors de l'exécution, on constate que le modèle n'est pas toujours stable.

Plus tard, j'ai compris que beaucoup de ces tâches répétitives seraient mieux consolidées en scripts, plutôt qu'en instructions longues.

Après avoir lu cet article d'Anthropic, ma plus grande impression est que beaucoup de gens utilisent en réalité des Skills, mais ne comprennent pas forcément ce qu'est un Skill.

Au fond, un Skill consiste en une ingénierie du contexte. Quand faut-il mettre des connaissances dans un Skill, quand faut-il les diviser en références, quand faut-il écrire un script, quand faut-il utiliser des Gotchas pour contraindre le modèle, il y a en fait beaucoup d'expériences derrière.

Une fois que l'on comprend le fonctionnement du Skill, en regardant ces Skills performants, on se rend compte qu'ils ne résolvent pas tant le problème des prompts, mais plutôt celui du contexte, de la consolidation d'expérience et de la réutilisation des capacités.

Si vous souhaitez approfondir la recherche sur les Skills, je recommande particulièrement deux articles :

#01 Ne pas écrire de bavardages

Un Skill consiste essentiellement à consolider le « savoir tacite » au sein d'une organisation. Donc, dans un Skill, il ne faut pas répéter des connaissances évidentes déjà connues. Ce qui a vraiment de la valeur, ce sont en fait des informations que le modèle ne connaît pas du tout.

Chez Anthropic, on insiste souvent sur le fait que ce qu'il faut vraiment écrire dans un Skill, ce sont des Gotchas, c'est-à-dire des pièges courants.

Par exemple :

1. Ce tableau ne doit pas être trié par created_at

2. Un retour 200 de staging ne signifie pas forcément succès

3. request_id et trace_id sont la même chose

Car ces informations existent souvent dans l'expérience des employés. Il faut donc se rappeler que l'essence d'un Skill est quoi.

Skill = écrire l'expérience du maître d'œuvre.

Grâce au Skill, on peut consolider l'expérience dispersée dans différentes têtes.

#02 Le Skill est en réalité une ingénierie du contexte

C'est probablement l'une des idées les plus profondes d'Anthropic.

Un Skill n'est pas un simple fichier markdown, mais un dossier. Pour ceux qui ont déjà utilisé des Skills, cela peut sembler évident.

Mais ces deux derniers jours, en y réfléchissant, j'ai réalisé que leur intention était d'utiliser la structure de dossier pour exprimer la philosophie de l'ingénierie du contexte.

Reprenons la structure typique d'un Skill :

skill/ ├── SKILL.md ├── references/ (détails, API, conditions limites) ├── scripts/ (scripts exécutables) ├── examples/ (exemples) ├── assets/ (modèles, images, ressources fixes)

Lorsqu'on appelle un Skill, le modèle lit d'abord le fichier SKILL.md. Si on met toutes les informations dans ce seul fichier, le contexte va rapidement exploser.

Supposons qu'il s'agisse d'un Skill de dépannage de paiement, comprenant à la fois des codes d'erreur Stripe, des cas de panne historiques, des scripts de diagnostic et un modèle de rapport final.

Si tout cela est empilé dans SKILL.md, chaque fois qu'on appelle ce Skill, Claude doit tout relire.

Même si l'utilisateur veut simplement confirmer la signification d'un code d'erreur, ou vérifier pourquoi un paiement n'a pas été mis à jour, beaucoup d'informations inutiles seront aussi chargées dans le contexte.

La philosophie d'Anthropic est totalement différente.

SKILL.md agit plutôt comme une page de navigation. Sa tâche est d'informer le modèle, lorsqu'il rencontre une erreur Stripe, d'aller consulter la référence correspondante dans le dossier references.

Quand il faut consulter des cas historiques, on regarde dans examples. Quand il faut réellement exécuter un diagnostic, on lance un script dans scripts. Et quand il faut générer un rapport final, on utilise le modèle dans assets.

Tout ce processus est une exposition progressive.

Voici une image que je recommande vivement de sauvegarder.

#03 Utiliser autant que possible des scripts

Il ne faut pas gaspiller la capacité limitée du contexte et de la raisonnement du modèle dans des tâches répétitives. Confiez ces tâches à des scripts.

Par exemple, beaucoup de gens écrivent un Skill comme ceci :

1. Interroger les données d'inscription ; 2. Interroger les données de paiement ; 3. Calculer le taux de conversion ; 4. Analyser les causes d'anomalie.

Ce genre de méthode est bien sûr acceptable. Le modèle peut aussi le faire. Mais à chaque exécution, il doit refaire tout le processus d'analyse.

Interroger, organiser, gérer les cas limites, ces tâches sont en réalité répétitives.

Puisque ces capacités ont été vérifiées maintes fois, pourquoi laisser le modèle réinventer la roue ? Mieux vaut fournir directement un script précis.

De plus, en utilisant des scripts, l'exécution du Skill sera plus précise et consommera moins de tokens.

D’un certain point de vue, les Scripts dans un Skill représentent la consolidation des capacités de l’organisation. Chaque script est souvent le résultat d’un travail d’équipe ayant évité de nombreux pièges, synthétisé en meilleures pratiques.

En fixant ces capacités, Claude pourra travailler à partir de cette expérience, plutôt que de repartir de zéro à chaque fois.

Je pense de plus en plus que, dans un Skill, Instructions et Scripts répondent à deux niveaux différents.

Les Instructions apportent de l’expérience et du jugement, les Scripts apportent des capacités et une exécution.

Par exemple, dans un Skill de dépannage de paiement, on pourrait avoir cette instruction :

Si Stripe retourne 200, ne pas considérer le paiement comme réussi, il faut vérifier la table payment_events.

Ceci appartient aux Instructions, car c’est une expérience. La fonction check_payment_events() appartient au Script, car c’est une capacité d’exécution.

Si on n’a que le Script, le modèle sait comment faire la vérification, mais pas pourquoi.

Si on n’a que les Instructions, le modèle sait ce qu’il doit faire, mais doit tout réinventer à chaque fois. Les deux sont indispensables.

#04 La description ressemble à une règle de routage

Beaucoup de gens écrivent leur Skill Description de manière erronée dès le départ.

Ils ont tendance à décrire la fonction, par exemple : PR Management Skill aide à surveiller l’état des PR, gérer les problèmes de CI, faire des merges automatiques.

Mais le problème, c’est que le modèle ne cherche pas un Skill par ses fonctionnalités, mais par son nom et sa description.

Lors du lancement de Claude Code, il scanne tous les noms et descriptions des Skills, puis décide quel Skill charger en fonction de la question de l’utilisateur.

Donc, dans la description, l’information la plus importante n’est pas ce que fait le Skill, mais dans quelles situations il doit être chargé.

La description joue en réalité un rôle de routage pour le Skill.

Dans le monde réel, peu de gens disent : « Aide-moi à utiliser un outil de gestion PR. » La plupart diraient plutôt : « Surveille ce PR, ou le CI est en panne. »

Un bon Description doit donc décrire l’intention de l’utilisateur, plutôt que de lister des fonctionnalités.

Je pense même à une méthode très simple pour vérifier cela.

Après avoir écrit la description, supprimez tout le Skill, ne laissez que cette ligne. Demandez-vous : en voyant la question de l’utilisateur, le modèle peut-il deviner quand charger ce Skill ?

Si ce n’est pas le cas, il faut probablement continuer à l’améliorer.

#05 La gestion et la distribution des Skills

Il y a aussi la question de la gestion des Skills.

Pour une personne seule, c’est simple : écrire quelques Skills, les maintenir, les mettre à jour soi-même. Mais je pense que la majorité des équipes seront confrontées à un problème similaire.

Quand le nombre de Skills passe de quelques-uns à une dizaine, puis à plusieurs dizaines ou centaines, comment gérer ces Skills ? Comment les faire évoluer ? Comment les distribuer aux membres de l’équipe ?

Chez Anthropic, leur expérience est très instructive.

Dans une petite équipe, les Skills suivent directement le dépôt de code. Ils sont dans le dossier .claude/skills du projet. Tout le monde partage la même collection de Skills, la même méthode de travail.

Mais avec l’augmentation du nombre de Skills, un nouveau problème apparaît.

Lors du lancement de Claude Code, il scanne tous les noms et descriptions des Skills, puis décide quel Skill utiliser selon la tâche. Plus il y a de Skills, plus le routage devient coûteux.

C’est aussi pour cela qu’Anthropic a commencé à créer un Marketplace. Mais ce qui est encore plus intéressant, c’est leur façon de gérer ce Marketplace.

Beaucoup d’entreprises réagissent en créant un processus d’approbation. Qui a écrit le Skill, il doit d’abord soumettre une demande ; après validation, il entre dans la bibliothèque officielle. Nous avons aussi fait cela, mais c’était très lourd. Juste pour gérer.

Chez Anthropic, leur organisation est très légère.

Ils laissent d’abord les nouveaux Skills se diffuser à petite échelle, pour que les collègues puissent les installer et les tester eux-mêmes.

Si de plus en plus de personnes commencent à utiliser un Skill, cela prouve qu’il résout un vrai problème. À ce moment-là, l’auteur peut le soumettre au Marketplace officiel.

Ils ne discutent pas d’abord de la valeur du Skill, mais laissent d’abord le Skill faire ses preuves dans des scénarios réels. Plus il y a d’utilisateurs, plus il entre dans le système officiel. Les Skills qui en ressortent sont donc ceux dont l’équipe a vraiment besoin.