Bazat pe un caz real de programare automată Claude Code, împărtășesc câteva tehnici de prompt
Acest articol, printr-un caz real, vă împărtășește un exemplu real de utilizare a Claude Code. Înainte de a împărtăși, să facem o mică anchetă
Cerința originală: un utilizator plătitor de prestigiu dorea ca în articole să adaug timpul modificării articolului
La prima vedere, această cerință pare dificil de implementat. Deoarece articolele site-ului meu nu sunt stocate într-o bază de date, ci sunt construite folosind SSG din next.js. Ele nu au deloc un timp de actualizare.
Un truc aici este: atunci când rezolvăm probleme, nu ar trebui să dăm direct cerința originală lui Claude Code, din următoarele motive
1. Cerința originală este relativ vagă, s-ar putea să o înțeleagă greșit, iar dacă o înțelege greșit, deși în cele din urmă va adăuga un timp, acel timp poate să nu fie fiabil
2. Consumul de Token al Claude Code este într-adevăr foarte scump, prin urmare, cerințele vagi ar putea duce la un consum mare de Token fără sens
Prin urmare, trebuie să dezasamblăm cerința originală o dată. Am consultat mai întâi deepseek, iar deepseek mi-a oferit două soluții
1. Timpul de construire a fișierului, de fiecare dată când construim, trebuie să obținem timpul de construire a fișierului, dar strategia de împachetare a turbopack este puțin diferită, de fiecare dată când construiește, valoarea hash a fișierului se schimbă, acest timp de construire poate să nu fie foarte fiabil
2. timpul de commit git, m-am gândit că acesta ar trebui să fie mai fiabil
După ce am avut o direcție generală de rezolvare, am avut acest prompt simplu: compilați timpul de commit git în antetul fiecărui articol .mdx
Claude Code este destul de fiabil, dacă promptul este relativ precis, în general nu are probleme, și a început să execute rapid
După ce mi-a consumat 7 dolari din credit, în aproximativ 20 de minute, a reușit în sfârșit să execute.
Dacă totul merge bine, apare o problemă, a sărit peste modificările a 171 de fișiere.
Un loc foarte problematic este aici, de fapt fișierele omise aici au doar un parametru suplimentar pass transmis, în rest sunt complet la fel
<PostLayout pass>...Dar el nu a fost flexibil, a definit acest parametru suplimentar transmis ca o componentă personalizată complet diferită. Și apoi a sărit peste el fără să-l proceseze ～ ～
import Layout from 'components/post-layout';
import { getGitFileInfo } from '@/utils/git-info';
export default function Article({ children }: any) {
const gitInfo = getGitFileInfo('src/app/你的路径/page.mdx');
return (
<Layout gitInfo={gitInfo || undefined}>
{children}
</Layout>
);
}Dar situația reală este că am nevoie de acest rezultat, iar rezultatul rulării este complet identic.
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 atunci, am căzut într-o capcană cu promptul
Am introdus din nou promptul: refactorizați cele 171 de fișiere omise folosind aceeași metodă ca mai sus
Această expresie a mea, dacă mă gândesc bine, are o oarecare ambiguitate. Pentru că Claude Code mi-a oferit deja o soluție sugerată, dar eu nu sunt de acord cu această soluție, intenția mea era să modific fișierele omise folosind schema celor sute de fișiere deja modificate, dar în procesul de execuție, a fost înțeleasă ca: soluția sugerată pe care mi-a oferit-o mai sus
Această ambiguitate a făcut ca el să execute timp de 20 de minute conform schemei pe care nu o doream, în mijloc au apărut și 2 erori de auto-reparare, consumând rapid tokenii mei, cele două ambiguități au început să se lupte și au cauzat erori.
În cele din urmă, am fost nevoit să renunț din nou la această execuție și să clarific din nou semantica mea.
Rezumat
1. În prompturi, este mai bine să conțină soluții relativ stabile și precise, lăsând AI să gândească cât mai puțin, astfel încât să reducă rata de halucinații.
2. În prompturile de cerințe, nu trebuie să existe ambiguități, ambiguitățile pot duce la erori, deși Claude Code poate repara în cele din urmă, dar acest lucru va provoca un consum mare de tokeni. Și deoarece LLM-ul produce rezultate bazate pe mecanisme de predicție, interpretările greșite timpurii, ambiguitățile etc., vor face ca fiecare pas ulterior să se îndepărteze tot mai mult în direcția greșită, iar el va încerca să fie logic consistent, generând lucruri care nu există, scriind din ce în ce mai multe probleme, crescând și dificultatea de verificare a dezvoltatorului, dacă ești păcălit de halucinațiile sale, atunci vor apărea consecințe grave
3. Constricțiile limbajului natural nu sunt la fel de precise ca codul, în prompturi, includerea numelor de fișiere, variabilelor de cod, termenilor specifici codului, termenilor tehnici etc., va reduce foarte mult halucinațiile Cluade Code
