Basandosi su un caso reale di programmazione automatica con Claude Code, condivido alcune tecniche per i prompt

Questo articolo, attraverso un caso reale, condivide con tutti un esempio pratico di utilizzo di Claude Code. Prima di condividere, facciamo un piccolo sondaggio

Requisito originale: un utente premium a pagamento desiderava che aggiungessi la data di modifica agli articoli

A prima vista, soddisfare questa richiesta sembrava piuttosto difficile. Perché gli articoli del mio sito non sono archiviati in un database, ma vengono generati utilizzando la SSG di next.js. Non hanno affatto una data di aggiornamento.

Un trucco qui è: quando si risolve un problema, non dobbiamo semplicemente fornire il requisito originale a Claude Code, per le seguenti ragioni

1. Il requisito originale è relativamente vago, potrebbe essere frainteso. Se viene frainteso, anche se alla fine aggiunge una data, questa potrebbe non essere affidabile

2. Il consumo di Token di Claude Code è davvero molto costoso, quindi una richiesta vaga potrebbe portare a un enorme spreco inutile di Token

Pertanto, dobbiamo scomporre il requisito originale. Ho prima consultato deepseek, che mi ha dato due soluzioni

1. Tempo di costruzione del file: ad ogni build, dobbiamo ottenere il tempo di costruzione del file. Ma la strategia di bundling di turbopack è un po' diversa; ad ogni build, l'hash del file cambia, quindi questo tempo di costruzione potrebbe non essere affidabile

2. Il tempo di commit git, ho pensato che questo dovesse essere più affidabile

Avendo una direzione generale di soluzione, ho creato questo prompt semplice: Compila il tempo di commit di git nell'intestazione di ogni articolo .mdx

Claude Code è abbastanza affidabile; se il prompt è preciso, generalmente non ci sono problemi, e procede spedito nell'esecuzione

Dopo aver consumato 7 dollari del mio credito, impiegando circa 20 minuti, finalmente l'esecuzione è riuscita.

Come previsto, è successo l'imprevisto: ha saltato le modifiche di 171 file.

Il punto critico qui è che in realtà i file saltati avevano solo un parametro aggiuntivo pass passato, tutto il resto era esattamente lo stesso

<PostLayout pass>...

Ma non è stato flessibile, ha definito questo parametro extra passato come un componente personalizzato completamente diverso. E quindi li ha saltati senza elaborarli ~ ~

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

Ma la situazione reale è che il risultato di cui avevo bisogno era questo, e il risultato dell'esecuzione sarebbe stato completamente identico.

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

E qui ho incontrato una difficoltà con il prompt

Ho inserito nuovamente il prompt: Usa lo stesso metodo di sopra per rifattorizzare i 171 file saltati

La mia espressione, pensandoci bene, ha un po' di ambiguità. Perché Claude Code mi aveva già dato una soluzione suggerita, ma io non l'approvavo. La mia intenzione era di modificare i file saltati utilizzando lo schema dei centinaia di file già modificati, ma durante l'esecuzione, è stato interpretato come: lo schema suggerito che mi aveva dato sopra

Questa ambiguità ha portato direttamente a eseguire per 20 minuti secondo lo schema che non volevo, con anche 2 errori e auto-riparazioni nel mezzo, divorando avidamente i miei token, e le due interpretazioni ambigue hanno iniziato a confliggere causando errori.

Alla fine ho dovuto abbandonare nuovamente questa esecuzione e ridefinire chiaramente la mia semantica.

Riepilogo

1. Nei prompt, è meglio includere soluzioni relativamente stabili e accurate, facendo pensare il meno possibile all'IA, per ridurre il tasso di allucinazioni.

2. Nei prompt dei requisiti non ci devono essere ambiguità, le ambiguità possono facilmente portare a errori. Anche se Claude Code alla fine può correggersi, ciò causerebbe un enorme consumo di token. E poiché gli LLM producono risultati basandosi su meccanismi predittivi, fraintendimenti o ambiguità iniziali porteranno ogni passo successivo ad allontanarsi sempre più nella direzione sbagliata, e cercheranno anche di essere logicamente coerenti, generando cose che non esistono, peggiorando sempre più il problema e aumentando la difficoltà di revisione per lo sviluppatore. Se si viene ingannati dalle sue allucinazioni, le conseguenze possono essere gravi

3. I vincoli del linguaggio naturale non sono precisi come il codice. Nei prompt, includere nomi di file, variabili di codice, termini specifici del codice, terminologia tecnica, riduce enormemente le allucinazioni di Claude Code