andrej-karpathy-skills

Lignes directrices du Code Claude inspiré par la Karpathie > Découvrez mon nouveau projet Multica — une plateforme open-source pour l'exécution et la gestion d'agents de codage avec des compétences réutilisables. > > Suivez-moi sur X: https://x.com/jiayuan jy Un seul fichier `CLAUDE.md` pour améliorer le comportement de Claude Code, dérivé des observations d'Andrej Karpathy sur les pièges de codage LLM. Français Les problèmes Dans le billet d'Andrej : > "Les modèles font de mauvaises hypothèses en votre nom et juste courir avec eux sans vérifier. Ils ne gèrent pas leur confusion, ne cherchent pas à obtenir des éclaircissements, ne font pas apparaître des incohérences, ne présentent pas de compromis, ne repoussent pas quand ils le devraient." > "Ils aiment vraiment trop compliquer le code et les API, les abstractions de ballonnement, ne pas nettoyer le code mort... implémenter une construction gonflée sur 1000 lignes quand 100 le feraient." > "Ils changent/suppriment parfois les commentaires et le code qu'ils ne comprennent pas suffisamment comme effets secondaires, même si orthogonale à la tâche." La solution Quatre principes dans un dossier qui traitent directement de ces questions : Principe Adresses C'est pas vrai. **Penser avant de codifier** **Simplicité Première** **Modifications chirurgicales** **Exécution de l'objectif** Les quatre principes en détail 1. Pensez avant de coder ** Ne présumez pas. Ne cachez pas la confusion. Échanges de surface** Les LLM choisissent souvent une interprétation silencieusement et courent avec elle. Ce principe impose un raisonnement explicite: ** Hypothèses de l'État explicitement** — Si vous êtes incertain, demandez plutôt que de deviner - **Présenter de multiples interprétations** — Ne pas choisir silencieusement lorsque l'ambiguïté existe - **Récupérer si nécessaire** — Si une approche plus simple existe, dites-le - **Arrêtez quand vous êtes confus** — Nommez ce qui n'est pas clair et demandez des éclaircissements 2. La simplicité d'abord **Code minimal qui résout le problème. Rien de spéculatif.** Combattre la tendance à la suringénierie : - Aucune caractéristique au-delà de ce qui a été demandé - Pas d'abstraction pour le code à usage unique - Pas de "flexibilité" ou de "configuration" qui n'était pas demandé - Pas d'erreur pour les scénarios impossibles - Si 200 lignes pouvaient être 50, réécrire **Le test:** Un ingénieur senior dirait-il que c'est trop compliqué ? Si oui, simplifiez. 3. Changements chirurgicaux **Touch seulement ce que vous devez. Nettoyez seulement votre propre désordre.** Lors de l'édition du code existant: - Ne pas « améliorer » le code, les commentaires ou le formatage adjacent - Ne refaites pas les choses qui ne sont pas cassées - Correspondez au style existant, même si vous le faites différemment - Si vous remarquez un code mort non lié, mentionnez-le — ne le supprimez pas Lorsque vos changements créent des orphelins : - Supprimer les importations/variables/fonctions que Vos modifications n'ont pas utilisées - Ne supprimez pas le code mort existant à moins de demander **Le test:** Chaque ligne modifiée doit suivre directement la demande de l'utilisateur. 4. Exécution axée sur les objectifs **Définir les critères de succès. Boucle jusqu'à vérification.** Transformer les tâches impératives en objectifs vérifiables : Au lieu de... C'est-à-dire... "Ajout la validation" "Ecrire les tests pour les entrées invalides, puis les faire passer" "Fixer le bogue" "Écrire un test qui le reproduit, puis le faire passer" "Refactor X"" "S'assurer que les tests passent avant et après" Pour les tâches en plusieurs étapes, énoncez un bref plan : Des critères de succès solides laissent la boucle LLM indépendamment. Les critères faibles ("faire fonctionner") nécessitent une clarification constante. Installer **Option A: Plugin Claude Code (recommandé)** De l'intérieur de Claude Code, d'abord ajouter le marché: Puis installez le plugin : Ceci installe les lignes directrices comme un plugin Claude Code, rendant la compétence disponible sur tous vos projets. **Option B: CLADE.md (par projet)** Nouveau projet : Projet en cours (annexe): Utilisation avec Cursor Ce dépôt comprend une règle de projet de Cursor (`.cursor/rules/karpathy-guidelines.mdc`) ainsi les mêmes lignes directrices s'appliquent lorsque vous ouvrez le projet dans Cursor. Voir **CURSOR.md** pour la configuration, l'utilisation de la règle dans d'autres projets, et la façon dont cela se rapporte à Claude Code. Aperçu clé De Andrej: > "Les LLM sont exceptionnellement bons à boucler jusqu'à ce qu'ils atteignent des objectifs spécifiques... Ne lui dites pas quoi faire, donnez-lui des critères de succès et regardez-le partir." Le principe de l'exécution axée sur l'objectif saisit ceci : transformer les instructions impératives en objectifs déclaratifs avec des boucles de vérification. Comment savoir que ça marche Ces lignes directrices fonctionnent si vous voyez : - **Modifications inutiles