Prima di bruciare un sacco di token con un grande sciame di agenti su un nuovo progetto, il vecchio detto di falegnameria "Misura due volte, taglia una volta!" vale la pena rivedere come "Controlla le tue perline N volte, implementa una volta," dove N è fondamentalmente quante più volte puoi sopportare. Ho scoperto che continui a ottenere sempre più miglioramenti, anche se sono sottili, più volte esegui questo in fila con Opus 4.5 (nota che il seguente prompt è solo per uso DOPO che hai già trasformato il tuo piano markdown iniziale in perline usando l'altro prompt che ti ho dato recentemente nel mio recente post molto lungo sui miei flussi di lavoro): "Rileggi AGENTS dot md così è ancora fresco nella tua mente. Controlla ogni perlina super attentamente-- sei sicuro che abbia senso? È ottimale? Potremmo cambiare qualcosa per far funzionare meglio il sistema per gli utenti? Se sì, rivedi le perline. È molto più facile e veloce operare nello "spazio di pianificazione" prima di iniziare a implementare queste cose! NON SEMPLIFICARE TROPPO LE COSE! NON PERDERE ALCUNE FUNZIONALITÀ O CARATTERISTICHE! Inoltre, assicurati che come parte di queste perline, includiamo test unitari completi e script di test e2e con ottimi log dettagliati così possiamo essere certi che tutto funzioni perfettamente dopo l'implementazione. Ricorda di utilizzare SOLO lo strumento `bd` per creare e modificare le perline e per aggiungere le dipendenze alle perline. Usa ultrathink." In passato eseguivo solo una o due volte prima di iniziare l'implementazione, ma recentemente ho sperimentato eseguendolo 6+ volte, e continuava a fare utili affinamenti. Se inizia a stabilizzarsi in termini di miglioramenti incrementali delle perline, potresti provare a iniziare una nuova sessione CC, iniziandola con: "Leggi prima TUTTO il file AGENTS dot md e il file README dot md super attentamente e comprendi TUTTO di entrambi! Poi usa la tua modalità agente di indagine del codice per comprendere appieno il codice, l'architettura tecnica e lo scopo del progetto. Usa ultrathink." E poi seguendo con lo stesso prompt come mostrato sopra, ma preceduto da: "Recentemente abbiamo trasformato un file di piano markdown in un mucchio di nuove perline. Voglio che tu riveda e analizzi molto attentamente queste usando `bd` e `bv`." Più complesso e intricato è il tuo piano markdown, più rilevante è questa tecnica. Se hai un piano piccolo e triviale e un progetto molto semplice, questo è ovviamente eccessivo. Ma in quel caso, probabilmente vedrai poco in termini di guadagni/cambiamenti incrementali con ogni round, quindi dovrebbe essere abbastanza ovvio quando è il momento di fermarsi. Ricorda solo: i token di pianificazione sono molto meno e più economici dei token di implementazione. Anche un piano markdown molto grande e complesso è più corto di alcuni file di codice sostanziali, per non parlare di un intero progetto. E i modelli sono molto più intelligenti quando ragionano su un piano che è molto dettagliato e ben sviluppato ma ancora abbastanza piccolo da adattarsi facilmente alla loro finestra di contesto (questo è davvero il punto chiave dietro il mio ossessivo focus sulla pianificazione e perché ho trascorso oltre l'80% del mio tempo su quella parte). E se ti affidi a GPT Pro con Ragionamento Esteso nell'app web per la pianificazione iniziale come consiglio vivamente (cioè, per creare e migliorare il tuo piano markdown che alla fine trasformi in perline), ottieni fondamentalmente quelli su base illimitata con un piano Pro, quindi approfitta al massimo di questo! Nessun altro modello può competere con Pro sul web quando si tratta di input che si adattano facilmente alla sua finestra di contesto. È davvero unico. ...