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 partager, faisons un petit sondage.

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

À première vue, ce besoin semblait difficile à mettre en œuvre. Car les articles de mon site ne sont pas stockés dans une base de données, ils sont 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 : lors de la résolution de problèmes, nous ne devons pas donner directement le besoin brut à Claude Code, pour plusieurs raisons :

1. Le besoin initial est relativement vague, il pourrait être mal interprété. Si c'est le cas, même s'il ajoute finalement une date, cette date pourrait ne pas être fiable.

2. La consommation de tokens de Claude Code est vraiment très chère. Par conséquent, un besoin vague pourrait entraîner une consommation massive de tokens de manière inutile.

Ainsi, nous devons décomposer le besoin initial. J'ai d'abord consulté DeepSeek, qui m'a donné deux solutions :

1. Le temps de construction du fichier. À chaque build, nous devons obtenir le temps de construction du fichier. Cependant, la stratégie de packaging de turbopack est un peu différente ; à chaque construction, la valeur de hachage du fichier change, donc ce temps de construction pourrait ne pas être fiable.

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

Ayant une direction de solution approximative, j'ai créé 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 directement.

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

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

Un point très problématique ici est que 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 je suis tombé dans un piège 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

Mon expression, en y réfléchissant, avait une certaine ambiguïté. Car Claude Code m'avait déjà donné une solution suggérée, mais je ne l'approuvais pas. Mon intention était de modifier les fichiers ignorés en utilisant le même schéma que les centaines de fichiers déjà modifiés. Mais lors de l'exécution, il a interprété cela comme : la solution qu'il m'avait suggérée ci-dessus.

Cette ambiguïté a directement conduit à une exécution de 20 minutes selon un schéma que je ne voulais pas, avec même 2 erreurs d'auto-réparation en cours de route, avalant 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 doit réfléchir, mieux c'est, cela réduit le taux d'hallucinations.

2. Les prompts de besoins ne doivent absolument pas contenir d'ambiguïté. L'ambiguïté peut facilement entraîner des erreurs. Bien que Claude Code puisse finalement les corriger, cela entraîne une consommation massive de tokens. De plus, comme les LLM produisent des résultats basés sur des mécanismes de prédiction, une mauvaise interprétation ou une ambiguïté précoce peuvent conduire chaque étape suivante à s'éloigner de plus en plus dans la mauvaise direction. En outre, il essaiera de maintenir une cohérence logique, générant des choses qui n'existent pas, aggravant les problèmes et augmentant la difficulté de vérification pour 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 spécifiques au code, etc., dans les prompts réduit considérablement les hallucinations de Claude Code.