Na podlagi resničnega primera avtomatskega programiranja s Claude Code, delimo nekaj nasvetov o promptih

Ta članek skozi resnični primer deli dejanski primer uporabe Claude Code. Preden začnem, naj naredim majhno anketo.

Prvotna zahteva: Plačljivi uporabnik je želel, da v člankih dodam čas zadnje spremembe.

Na prvi pogled se je ta zahteva zdela težko izvedljiva. Ker članki na moji spletni strani niso shranjeni v podatkovni bazi, ampak so zgrajeni z SSG next.js. Preprosto nimajo časa posodobitve.

Tukaj je en trik: pri reševanju problema ne podajamo prvotne zahteve neposredno Claude Code-u, iz naslednjih razlogov:

1. Prvotna zahteva je razmeroma nejasna in jo lahko napačno razume. Če jo napačno razume, bo morda dodal čas, vendar ta čas morda ne bo zanesljiv.

2. Poraba tokenov pri Claude Code je res zelo draga. Zato lahko nejasna zahteva povzroči veliko nesmiselne porabe tokenov.

Zato moramo prvotno zahtevo razčleniti. Najprej sem se posvetoval z deepseek, ki mi je dal dve rešitvi:

1. Čas izgradnje datoteke. Ob vsaki gradnji moramo pridobiti čas izgradnje datoteke. Vendar je pakiranje turbopack nekoliko drugačno – hash vrednost datoteke se spreminja ob vsaki gradnji, zato ta čas izgradnje morda ni zanesljiv.

2. Čas git commit-a. Pomislil sem, da bi to moralo biti bolj zanesljivo.

Ko sem imel približno smer rešitve, sem imel ta preprost prompt: Vključi čas git commit-a v glavo vsakega članka .mdx.

Claude Code je bil precej zanesljiv. Če je prompt natančen, na splošno ni težav, samo dela kot nor.

Po porabi 7 dolarjev kredita in približno 20 minutah je končno uspešno izvedel nalogo.

Kot ponavadi, se je pojavila napaka. Preskočil je spremembe v 171 datotekah.

Tukaj je zelo zapleteno: te preskočene datoteke so imele le dodaten parameter pass, vse ostalo je bilo popolnoma enako.

<PostLayout pass>...

Vendar ni bil prilagodljiv in je ta dodaten parameter definiral kot popolnoma drugačen komponentni tip. Nato ga je preskočil in ni obdelal ~ ~

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

Toda dejansko potrebujem takšen rezultat, ki deluje popolnoma enako.

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

Takrat sem padel v past z izbiro besed v promptu.

Ponovno sem vnesel prompt: Na enak način kot zgoraj preoblikuj preskočenih 171 datotek.

Moj izraz je, če pomislim, nejasen. Ker mi je Claude Code že predlagal rešitev, vendar je nisem sprejel. Moj namen je bil, da preskočene datoteke spremenim na enak način kot že spremenjene stotine datotek. Vendar je med izvajanjem to razumel kot: rešitev, ki mi jo je zgoraj predlagal.

Ta nejasnost je povzročila, da je 20 minut izvajal po shemi, ki je ni želel. Medtem se je dvakrat sam popravil in močno požiral moje tokene. Dve nejasnosti sta se spopadli in povzročili napako.

Na koncu sem moral opustiti to izvedbo in na novo pojasniti svoj namen.

Povzetek

1. V promptih je najbolje vključiti relativno stabilne in natančne rešitve. Manj kot AI razmišlja, manjša je verjetnost halucinacij.

2. V promptih za zahteve nikoli ne sme biti nejasnosti, saj lahko povzročijo napake. Čeprav se jih Claude Code na koncu lahko popravi, to povzroči veliko porabo tokenov. Ker LLM deluje na podlagi napovednega mehanizma, zgodnje napačno branje ali nejasnosti vodijo do tega, da vsak naslednji korak gre v napačno smer. Poskuša tudi biti logično dosleden in ustvarja stvari, ki ne obstajajo, kar povzroča večje težave in povečuje težavnost pregleda za razvijalca. Če se pustite prevarati z njegovimi halucinacijami, lahko pride do resnih posledic.

3. Omejitve naravnega jezika niso tako natančne kot kode. Vključitev imen datotek, kodnih spremenljivk, kodnih izrazov in strokovne terminologije v prompte močno zmanjša halucinacije Cluade Code.