Partage de techniques de prompts basées sur un cas réel de programmation automatique avec Claude Code

Cet article partage un cas d'utilisation réel de Claude Code à travers un exemple concret. Avant de commencer, faisons un petit sondage.

Demande initiale : Un utilisateur payant prestigieux souhaitait que j'ajoute la date de modification des articles dans mes publications.

À première vue, cette demande semblait difficile à mettre en œuvre. Les articles de mon site ne sont pas stockés dans une base de données, mais générés via la SSG de next.js. Ils n'ont tout simplement pas de date de mise à jour.

Une astuce ici est la suivante : lors de la résolution de problèmes, nous ne devons pas donner la demande brute directement à Claude Code, pour plusieurs raisons :

1. La demande initiale est relativement vague, ce qui peut entraîner une mauvaise interprétation. Si elle est mal comprise, même si une date est ajoutée, celle-ci pourrait ne pas être fiable.

2. La consommation de tokens de Claude Code est vraiment très coûteuse. Une demande vague pourrait donc entraîner une consommation inutile de nombreux tokens.

Par conséquent, nous devons décomposer la demande initiale. J'ai d'abord consulté deepseek, qui m'a proposé deux solutions :

1. Le temps de construction des fichiers : à chaque build, nous devrions obtenir le temps de construction du fichier. Cependant, la stratégie de packaging de turbopack est un peu différente ; à chaque construction, le hash du fichier change, ce qui rend ce temps de construction peu fiable.

2. Le temps de commit git : j'ai pensé que cela devrait être plus fiable.

Avec une direction de solution approximative, j'ai formulé ce prompt simple : Compiler le temps de commit git dans l'en-tête de chaque article .mdx.

Claude Code est assez fiable ; si le prompt est précis, globalement, il n'y a pas de problème, il exécute simplement.

Après avoir utilisé 7 dollars de crédit et environ 20 minutes, l'exécution a finalement réussi.

Comme on pouvait s'y attendre, un imprévu est survenu : il a sauté la modification de 171 fichiers.

Un point problématique se trouve ici : en réalité, les fichiers ignorés ne faisaient que passer un paramètre supplémentaire pass, tout le reste étant exactement identique.

<PostLayout pass>...

Mais il n'a pas fait preuve de flexibilité, définissant ce paramètre supplémentaire comme un composant personnalisé complètement différent. Puis il a sauté le traitement ~ ~

import Layout from 'components/post-layout';
import { getGitFileInfo } from '@/utils/git-info';
export default function Article({ children }: any) {
  const gitInfo = getGitFileInfo('src/app/votre-chemin/page.mdx');
  return (
    
      {children}
    
  );
}

Mais en réalité, le résultat dont j'avais besoin était celui-ci, et le résultat d'exécution est complètement identique.

import MdxLayout from 'components/mdx-layout';
export default function Article({ children }: any) {
  return (
    
      {children}
    
  );
}

C'est à ce moment-là que j'ai rencontré un problème avec le prompt.

J'ai saisi à nouveau le prompt : Refactorisez les 171 fichiers ignorés en utilisant la même méthode que ci-dessus.

Cette formulation, en y réfléchissant, présente une certaine ambiguïté. Claude Code m'avait déjà proposé une solution, mais je ne l'approuvais pas. Mon intention était d'utiliser la même méthode que pour les centaines de fichiers déjà modifiés pour corriger les fichiers ignorés. Cependant, pendant l'exécution, il a interprété cela comme : la solution qu'il m'avait suggérée précédemment.

Cette ambiguïté a directement conduit à une exécution de 20 minutes selon une méthode que je ne voulais pas, avec deux erreurs d'auto-réparation en cours de route, engloutissant mes tokens à toute vitesse. Les deux interprétations ambiguës ont commencé à entrer en conflit, provoquant des erreurs.

Finalement, j'ai dû abandonner cette exécution et clarifier à nouveau mon intention.

Résumé

1. Dans les prompts, il est préférable d'inclure des solutions relativement stables et précises. Moins l'IA réfléchit, mieux c'est, cela réduit le taux d'hallucinations.

2. Les prompts de demande ne doivent absolument pas contenir d'ambiguïtés, car elles peuvent entraîner des erreurs. Bien que Claude Code puisse finalement les corriger, cela consomme beaucoup de tokens. De plus, comme les LLM produisent des résultats basés sur des prédictions, une mauvaise interprétation ou une ambiguïté précoce peut conduire à s'éloigner de plus en plus dans la mauvaise direction à chaque étape suivante. L'IA essaiera également de maintenir une cohérence logique, générant parfois des éléments inexistants, aggravant les problèmes et compliquant la revue par le développeur. Si vous êtes trompé par ses hallucinations, les conséquences peuvent être graves.

3. Les contraintes du langage naturel sont moins précises que celles du code. Inclure des noms de fichiers, des variables de code, des termes techniques ou du jargon dans les prompts réduit considérablement les hallucinations de Claude Code.