Basat en un cas real de programació automàtica amb Claude Code, compartim alguns consells sobre com redactar prompts
En aquest article, a través d'un cas real, us compartiré un exemple d'ús real de Claude Code. Abans de compartir, fem una petita enquesta.
Requisit original: Un usuari premium de pagament volia que afegís l'hora de modificació als articles.
A primera vista, aquest requisit semblava una mica difícil d'implementar. Perquè els articles del meu lloc web no s'emmagatzemen en una base de dades, sinó que es construeixen utilitzant SSG de next.js. Simplement no tenen hora d'actualització.
Un truc aquí és: a l'hora de resoldre problemes, no hem de donar directament el requisit original a Claude Code, per les següents raons:
1. El requisit original és relativament vague, i podria malinterpretar-lo. Si ho fa, tot i que finalment afegeix una hora, aquesta hora potser no sigui fiable.
2. El consum de tokens de Claude Code és realment molt car. Per tant, una demanda imprecisa podria provocar un consum significatiu de tokens sense sentit.
Per això, hem de desglossar el requisit original. Primer vaig consultar a deepseek, que em va donar dues solucions:
1. Hora de construcció del fitxer. Durant cada build, necessitem obtenir l'hora de construcció del fitxer. Però l'estratègia d'empaquetament de turbopack és una mica diferent; cada vegada que es construeix, el valor hash del fitxer canvia, de manera que aquesta hora de construcció pot no ser gaire fiable.
2. Hora de commit de git. Vaig pensar que això probablement seria més fiable.
Amb una direcció de solució aproximada, vaig tenir aquest prompt senzill: Compila l'hora de commit de git a la capçalera de cada article .mdx.
Claude Code és bastant fiable. Si el prompt és precís, en general no hi ha cap problema, i es posa a executar sense parar.
Després de consumir 7 dòlars del meu crèdit i uns 20 minuts, finalment es va executar amb èxit.
I com era d'esperar, va passar l'inesperat: va saltar els canvis de 171 fitxers.
Aquí hi ha una part complicada: en realitat, els fitxers que es van saltar només tenien un paràmetre addicional pass passat, tot la resta era exactament igual.
<PostLayout pass>...Però no va saber adaptar-se i va definir aquest paràmetre addicional com un component personalitzat completament diferent. I llavors el va saltar i no el va processar ~ ~
import Layout from 'components/post-layout';
import { getGitFileInfo } from '@/utils/git-info';
export default function Article({ children }: any) {
const gitInfo = getGitFileInfo('src/app/el-teu-cami/page.mdx');
return (
<Layout gitInfo={gitInfo || undefined}>
{children}
</Layout>
);
}Però la situació real és que necessitava aquest resultat, i el resultat de l'execució seria completament idèntic.
import MdxLayout from 'components/mdx-layout';
export default function Article({ children }: any) {
return (
<MdxLayout pass filePath="src/app/r19base/(4.compiler)/23.compilerlower/page.mdx">
{children}
</MdxLayout>
);
}I llavors, en aquest punt, vaig caure en una trampa amb el prompt.
Vaig introduir de nou el prompt: Utilitza la mateixa manera que abans per refactoritzar els 171 fitxers que es van saltar.
La meva expressió, si es pensa bé, té una mica d'ambigüitat. Perquè Claude Code ja m'havia donat una solució suggerida, però jo no estava d'acord amb aquesta solució. La meva intenció era modificar els fitxers saltats amb el mateix esquema que els centenars de fitxers ja modificats. Però durant l'execució, ho va interpretar com: el pla que ell m'havia suggerit anteriorment.
Aquesta petita ambigüitat va fer que executés durant 20 minuts segons el pla que jo no volia, i fins i tot va tenir 2 errors d'auto-reparació al mig, devorant els meus tokens sense parar. Les dues interpretacions diferents van començar a xocar i van causar errors.
Finalment, vaig haver d'abandonar aquesta execució i aclarir de nou la meva semàntica.
Resum
1. En els prompts, és millor incloure solucions relativament estables i precises. Com menys hagi de pensar la IA, millor, això pot reduir la taxa d'al·lucinacions.
2. Els prompts de demanda no han de tenir cap ambigüitat. L'ambigüitat pot provocar errors. Tot i que Claude Code finalment pot reparar-ho, això provoca un gran consum de tokens. I com que els LLM produeixen resultats basats en mecanismes predictius, les males interpretacions o ambigüitats inicials faran que cada pas posterior vagi cada vegada més lluny en la direcció equivocada. A més, intentarà ser lògicament coherent, generant coses que no existeixen. Com més escrigui, més gran serà el problema, i també augmentarà la dificultat de revisió del desenvolupador. Si et deixes enganyar per les seves al·lucinacions, podria tenir conseqüències greus.
3. Les restriccions del llenguatge natural no són tan precises com el codi. Incloure noms de fitxers, variables de codi, termes propis del codi i terminologia especialitzada en els prompts reduirà enormement les al·lucinacions de Claude Code.
