Introducció: Al codi no li importen les teves vibracions
Aquesta és la veritat sobre els models de llenguatge grans i el codi: són sorprenentment segurs i completament indiferents a si el teu programa compila o no. Claude Haiku 4.5 escriurà feliçment un script de Python que resolgui el teu problema, més dos que s'inventi per esport. El truc—l'únic truc que importa—és aprendre a fer *prompts* a Claude Haiku 4.5 per a una generació de codi precisa d'una manera que no deixi espai per a vibracions i maximitzi l'espai per a la veritat. No vols prosa que soni com a codi. Vols codi que actuï com a codi. Hi ha una diferència.
La gent tracta els *prompts* com si fossin un encanteri místic: digues les paraules correctes i obtindràs una aplicació perfecta. Això és un pensament de culte al càrrec. El codi és un contracte. Si vols precisió de Claude Haiku, has d'escriure el contracte. “Construeix una aplicació web” no és un contracte. “Genera un endpoint de FastAPI en Python 3.12 que accepti JSON, validi l'esquema amb Pydantic v2 i retorni 422 en errors d'esquema amb un format de *payload* específic” és un contracte. Així és com es fa un *prompt* a Claude Haiku 4.5 per a una generació de codi precisa: defineixes bé el contracte.
Què és això (i què no)
- És una guia pràctica per obtenir codi fiable i provable de Claude Haiku 4.5.
- No és un sermó sobre “la IA que reemplaça els desenvolupadors”. Les eines no reemplacen el pensament.
- Està centrat en *prompts* pràctics, estructura i proteccions: les parts avorrides que fan que la màgia funcioni.
Si vols codi que s'executi, has de donar a Claude una definició funcional de “s'executa”. Si vols una generació de codi precisa, has de definir la precisió en termes clars i provables. Aquest és tot el joc.
Defineix la precisió com un advocat, no com un poeta
El codi “precís” no és codi que “sembla plausible”. La precisió és:
- Validesa sintàctica: compila o s'executa sota l'intèrpret.
- Fidelitat semàntica: fa el que diu l'especificació.
- Comportament determinista: mateixes entrades, mateixes sortides, dins dels límits d'error definits.
- Correcció de la versió: utilitza els SDKs, les versions d'API i les característiques de llenguatge correctes.
Claude et donarà el que demanis. Si demanes “una funció que ordeni una llista”, probablement n'obtindràs una. Si demanes “un ordenament estable in-place utilitzant la semàntica de Timsort amb espai extra O(1)”, aquesta és una promesa diferent. “Com fer un *prompt* a Claude Haiku 4.5 per a una generació de codi precisa” comença amb escriure aquestes promeses al *prompt*.
El *Prompt* Mínim Viable, Actualitzat
Dolent: “Escriu una API de Node per a tasques.”
Millor: “Escriu una API de Node 20 Express 4 amb una ruta /tasks POST que validi els camps {title: string, dueDate: ISO 8601} i respongui 201 amb l'objecte creat o 400 amb detalls de l'error.”
Correcte: “Genera un servidor Node 20 Express 4 amb un únic endpoint /tasks POST. Requisits: 1) Valida el cos amb [email protected]; 2) Camps: title (string no buit, màxim 140), dueDate (data ISO 8601 futura); 3) En cas d'èxit: 201 amb {id: ULID, title, dueDate}; 4) En cas d'invalid: 400 amb {error: 'VALIDATION', details: array}; 5) Sense base de dades; Map en memòria; 6) Inclou un fitxer de prova Jest 29 que cobreixi casos vàlids, invàlids (títol buit, data passada); 7) Proporciona scripts npm per a prova i desenvolupament; 8) Utilitza ESM; 9) No incloguis comentaris estranys.” Fixa't en la forma: versió del llenguatge, biblioteques, restriccions, sortides, errors, proves i fins i tot l'estructura del paquet. Has eliminat l'ambigüitat. La feina de Claude és omplir el codi, no els requisits.
El Patró d'Encaix: Sistema, Especificació, Proves, Després Codi
Si vols una generació de codi precisa de Claude Haiku 4.5, has de donar-li una pista d'aterratge:
- Enquadrament del sistema (la corretja curta)
- Tu: “Estàs escrivint TypeScript de qualitat de producció per a Node 20. Només mostra blocs de codi amb noms de fitxer i res més.”
- Per què: controles el to i el format de sortida. No ho deixis a l'atzar.
- Especificació (el contracte)
- Inclou versions de llenguatge, opcions de paquet, semàntica d'error, formats d'E/S, límits de rendiment i restriccions de seguretat.
- Digues a Claude que escrigui proves unitàries primer. Les proves defineixen “precís” millor que els adjectius. Si una línia de codi no serveix per a una prova, és decorativa.
- Només després de les proves. Sí, això és bàsicament TDD, però amb un robot que mai s'avorreix d'escriure *boilerplate*.
- Instruccions per a reexecucions
- “Si les proves fallen o les importacions no coincideixen, actualitza només les parts que fallen. No reescriguis tot el projecte.”
Claude funciona bé quan té context i rails. Dóna-li rails.
L'ancoratge de versions no és opcional
Les dades d'entrenament de Claude estan plenes de documents antics i nous. Aquesta és una manera educada de dir que ha vist molts consells contradictoris. “Utilitza React Router” és vague. “Utilitza [email protected] amb *data routers*” és direcció. No confiïs en els valors per defecte: - Llenguatges: fixa't a Python 3.12, Node 20, Go 1.22, Java 21—el que realment executis.
- Frameworks: especifica versions majors exactes i qualsevol *flag* de canvi que trenqui la compatibilitat.
- SDKs de núvol: fixa les versions; aws-sdk v2 vs v3 importa.
- Linters/formatters: especifica regles per evitar reescriptures d'estil “ping-pong”.
Si no fixes, obtindràs un *greatest-hits medley* de cinc anys de publicacions de bloc. La generació de codi precisa és al·lèrgica a la nostàlgia.
Esquema primer, sempre
No demanis estructures de “perfil d'usuari”. Defineix esquemes al *prompt* i exigeix validació:
- Esquema JSON o tipus Zod/Yup a JS/TS
- Protobuf o Avro per a serveis
Llavors, fes que Claude faci complir els esquemes als límits—entrades de l'API, escriptures de bases de dades i cues de missatges. Demana *payloads* i codis d'error explícits. A la precisió li encanten els esquemes. L'ambigüitat no.
Fes-ho observable, o no pretenguis que és real
Digues a Claude que afegeixi *logging*, mètriques i rastrejos on els necessitis—i que els mantingui silenciosos on no. Un bon *prompt* inclou:
- Política de *logging*: nivells, redacció de PII, estructura (registres JSON, si us plau)
- Mètriques: temps per petició, recomptes d'error
- Endpoints de salut: /healthz que provi que les dependències estan en marxa
Claude afegirà el que demanis. Si no demanes, obtindràs declaracions d'impressió—si tens sort.
*Prompts* de prova primer superen “Només confia en mi”
Una bona manera de fer un *prompt* a Claude Haiku 4.5 per a una generació de codi precisa és fer que les proves siguin la font de la veritat. Exemple:
“Escriu proves pytest per a una funció normalize_email(s) que:
- converteix a minúscules les parts locals i de domini;
- elimina els punts a la part local només per a gmail.com;
- elimina les subadreces (+tag) només per a gmail.com;
- rebutja les entrades sense un sol @ o amb espais;
- manté el *punycode* del domini unicode tal com està.
Cobreix casos límit. Després d'escriure les proves, implementa la funció per aprovar-les.”
Claude sovint escriurà millor codi quan es vegi obligat a satisfer les proves que has descrit. Si no ho fa, tens un fracàs concret, no un argument de vibracions.
Sense al·lucinacions per construcció
No pots eliminar les al·lucinacions, però pots tancar-les:
- Demana citacions o URLs de font només quan existeixen fonts. Per als mètodes SDK, exigeix enllaços de documentació i requereix que el codi coincideixi amb aquests documents.
- Per a les APIs privades, enganxa l'especificació al *prompt*. No esperis que Claude conegui els teus endpoints interns.
- Per a biblioteques amb APIs confuses, inclou un fragment d'exemple de la documentació oficial i digues a Claude que s'adhereixi a ell.
El codi precís és majoritàriament referències precises. Dóna a Claude les referències.
Guies d'estil: El més poc sexy, el més útil
Claude escriu codi amb l'estil que dedueix. Aquesta és una recepta per a la rotació. Enganxa la teva guia d'estil. Especifica:
- Format (Prettier, Black, gofmt per defecte)
- Convencions de nomenclatura
- Patrons de maneig d'errors
També exigeix un comentari de justificació curt per a les eleccions no òbvies. El teu jo futur t'ho agrairà, i l'actual Claude produirà menys PRs de “correcció”.
*Prompts* llargs, sortides curtes
Una altra manera de pensar sobre com fer un *prompt* a Claude Haiku 4.5 per a una generació de codi precisa: gasta les teves paraules al *prompt*, no a la sortida. Vols:
- Restriccions exhaustives al *prompt*
- Narració estranya mínima a la sortida
Digues-li que suprimeixi les explicacions i que només retorni blocs de codi amb noms de fitxer i un README curt. Si vols comentaris, demana'ls en una execució separada. Intercalar prosa i codi és com les errades s'escolen portant un monocle i un barret de copa.
Refinament: El bucle ajustat que realment funciona
El camí més ràpid cap a un codi fiable no és “fer-ho bé al primer intent”. Són bucles curts i correctius:
- Executa localment. Enganxa la sortida de la prova fallida i els errors del compilador de nou a Claude textualment.
- Instrucció: “Modifica només les línies mínimes necessàries; no canviïs les signatures de la funció tret que ho exigeixin les proves que fallen.”
- Repeteix fins que sigui verd.
Claude és excel·lent per aplicar *diffs* quan li dius exactament què s'ha trencat. No parafrasegis els registres de fallada. Enganxa'ls. Els registres són la veritat.
La seguretat és una característica, no una postdata
Com que els models s'entrenen amb codi públic (bo, dolent i maleït), vols fer de la seguretat un requisit de primera classe:
- Prohibeix explícitament eval, shell=True i SQL amb tipus de cadena
- Exigeix consultes parametritzades, protecció CSRF i límit de velocitat
- Demana l'ancoratge de dependències més un fitxer de bloqueig
- Exigeix el maneig de secrets mitjançant variables d'entorn o un gestor de secrets
Un *prompt* segur per defecte produeix un codi més segur. Un *prompt* de “ja ho arreglarem més tard” produeix titulars.
Rendiment: Digues què significa “ràpid”
“Fes-ho ràpid” es tradueix en “fes el que sigui”. En canvi, especifica mètriques:
- Objectius de latència (p95 < 50ms per a memòria, p95 < 300ms per a operacions de base de dades)
- Límits de memòria (RSS < 150MB)
- Complexitat temporal (ha de ser O(n log n), no O(n^2))
Claude triarà algorismes per ajustar-se al pressupost que has definit. Dóna-li un pressupost.
Documentació: Suficient per incorporar un estrany
Demana a Claude un README que inclogui:
- Instruccions de configuració amb versions exactes
- Comandes per a prova, lint, *typecheck*, execució
- Exemples de sol·licituds/respostes
- Limitacions i compromisos coneguts
El “codi precís” inclou documents precisos. Són part del lliurament.
Plantilles de *Prompt* concretes que pots robar
Plantilla: Endpoint Backend
Sistema: Ets un enginyer de Python 3.12 meticulós. Només mostra blocs de codi amb noms de fitxer.
Usuari:
- Construeix una aplicació FastAPI 0.111 amb un endpoint POST /convert.
- Sol·licitud: {amount: Decimal com a string, from: 'USD'|'EUR', to: same}.
- Valida amb pydantic v2; retorna forma 422 en errors d'esquema.
- Utilitza una funció pura convert(amount, from, to) amb taxes fixes {USD:1, EUR:1.1}.
- Retorna {amount: string, currency: string} amb 200.
- Inclou proves pytest que cobreixin casos vàlids, invàlids (decimal dolent, codi desconegut) i límit (0).
- Proporciona pyproject.toml amb dependències ancorades; inclou configuracions ruff i mypy.
- Sense trucades de xarxa, sense comentaris.
Plantilla: Utilitat CLI
Sistema: Estàs escrivint Go 1.22. Només mostra blocs de codi amb noms de fitxer.
Usuari:
- Crea una CLI anomenada slugify que llegeixi stdin i imprimeixi slugs segurs per a URLs.
- Regles: minúscules, només ASCII, separadors de guions, col·lapsa l'espai en blanc, elimina la puntuació.
- Proporciona main.go i slugify_test.go amb proves de taula.
- Utilitza només la stdlib de Go.
- Inclou Makefile amb objectius de prova i construcció.
Plantilla: Component Frontend
Sistema: Ets un enginyer de React pragmàtic que apunta a React 18 + TypeScript.
Usuari:
- Implementa un component <DebouncedInput>.
- Props: value: string, onChange(value): void, delay=300.
- Utilitza useRef/useEffect; sense hooks de tercers.
- Inclou proves vitest amb temporitzadors falsos.
- Proporciona una història mínima de Storybook.
Aquestes plantilles demostren com fer un *prompt* a Claude Haiku 4.5 per a una generació de codi precisa ancorant versions, definint el comportament i exigint proves.
Negant-se a ser intel·ligent: Quan dir “No optimitzis”
Si no vols micro-optimitacions prematures (i no en vols), digues-ho:
- “Prefereix la llegibilitat per sobre de la intel·ligència; sense retorçament de bits tret que les proves ho exigeixin.”
- “Sense recursió si iteratiu és més clar.”
- “Sense metaprogramació; explícit > implícit.”
A Claude li encanta impressionar. No ho permetis. Fes que aprovi les proves i sigui llegible. Això ja és prou impressionant.
Sider.AI al flux de treball, on realment ajuda He vist gent fer malabars amb *prompts* en pestanyes de xat aleatòries com si fos un ritual de productivitat. Utilitza un espai de treball que entengui el context del codi. Sider.AI, per exemple, està construït al voltant de mantenir la teva especificació, codi, *diffs* i registres de prova a la vista, de manera que el bucle “enganxa l'error, arregla la línia” és realment ajustat. No és màgia; és un encaix avorrit que t'impedeix perdre el fil. Si la teva eina manté el contracte, les proves i el codi a la mateixa conversa—sense molestar-te amb confeti—utilitza-la. Sider ho fa. Com depurar amb Claude com a company d'equip, no com a oracle
- Enganxa la sortida de la prova que falla exactament tal com està. No resumeixis.
- Demana un *diff*: “Respon només amb *diff* unificat contra el fitxer X.”
- Per a errors d'execució, afegeix el fragment reproduïble més petit i exigeix una explicació més un *patch*.
- Per a errors de biblioteca, enganxa l'extracte de documentació que creus que s'aplica i pregunta: “És aquesta l'API correcta per a la versió X? Si no, actualitza el codi i cita l'extracte correcte.”
L'objectiu és fer que Claude discuteixi amb proves. Tu portes les proves.
La desfilada de paranys (i com esquivar-la)
- La trampa de l'API “més recent”: No diguis “utilitza la més recent”. Digues “utilitza la versió X.Y” i mantén-t'hi.
- El fitxer de prova buit: Si no exigeixes proves, no les obtindràs.
- La fal·làcia d'un sol intent: Planifica dos o tres refinaments curts. És més ràpid que un *prompt* inflat.
- La política d'errors ambigua: Defineix codis d'estat i *payloads*. “Retorna un error” no significa res.
- La dependència sense amo: Si el codi es basa en un servei que no pots controlar, fes-ne un *stub*. Demana *fakes*.
La teva llista de verificació de *Prompts* (Enganxa això a prop del teu monitor)
- Llenguatge i versió d'execució ancorats
- Versions de biblioteca ancorades
- Esquemes de dades definits
- Semàntica d'error definida (codis, formes)
- Proves primer, després codi
- Restriccions de seguretat explícites
- Pressupostos de rendiment establerts
- Estil i estructura especificats
- Format de sortida restringit (noms de fitxer, blocs de codi, *diffs*)
- Bucle de refinament curt amb registres enganxats
Si compleixes els deu, Claude Haiku 4.5 generalment produeix una generació de codi precisa que sobreviu a la llum del dia.
Un exemple treballat: De vague a verificat
*Prompt* vague: “Escriu una funció per analitzar CSV de forma segura.”
Resultat: Probablement bé, possiblement malament, certament sense provar.
*Prompt* precís:
“Estàs escrivint Python 3.12. Només mostra blocs de codi amb noms de fitxer.
Crea csvsafe/init.py i csvsafe/reader.py amb una funció read_rows(path: Path) -> list[dict[str,str]]. Requisits: utilitza csv.DictReader amb newline='' i encoding='utf-8'; no permetis bytes nuls; rebutja fitxers >10MB; limita les columnes a 100; elimina BOM; tracta les cel·les buides com a strings buits; eleva ValueError amb codis de missatge {FILE_TOO_LARGE, NULL_BYTE, TOO_MANY_COLUMNS}. Inclou proves a tests/test_reader.py amb pytest que cobreixin el camí feliç, byte nul, fitxer d'11 MB, 101 columnes i maneig de BOM. Proporciona pyproject.toml amb dependències ancorades i configuració de black.”
Obtindràs codi, proves i maneig de límits. Llavors executes les proves, enganxes les fallades i iteres amb *diffs* mínims. Això és una generació de codi precisa a la pràctica.
Sobre la “creativitat” i altres paraules de màrqueting
No necessito codi “creatiu”. Necessito codi correcte. Guarda la creativitat per posar nom al teu gat. Quan fas un *prompt* a Claude, la creativitat és el subproducte natural de les restriccions sòlides. Les proves correctes i les especificacions clares produeixen solucions elegants. El *prompt* incorrecte produeix “base64 reinventat amb emojis”. No el temptis.
El secret no secret
La manera de fer un *prompt* a Claude Haiku 4.5 per a una generació de codi precisa és avorrida: escriu el que necessites, fixa les versions, defineix els esquemes, exigeix proves i itera amb fallades reals. Això és tot. Sense misticisme. Només disciplina d'enginyeria, amb un model que pot escriure molt ràpid i no li importa escriure quinze casos de prova gairebé idèntics.
I aquest és el gir: la precisió no és glamurosa. Els *prompts* que funcionen es llegeixen com una llista de verificació de la TSA. El codi que s'envia es llegeix com si l'hagués escrit un humà que s'importava. Obtens ambdues coses tractant el model com un enginyer *junior* que prospera sota requisits clars i es marceix sota una direcció vaga. Dóna-li un contracte. Fes que aprovi les proves. Llavors, potser, pots confiar-hi—amb el tipus de confiança que dones a una eina, no a un profeta.
Conclusió: Menys màgia, més garantia
Si vols màgia, ves a un espectacle de màgia. Si vols programari que compila i es comporta, escriu *prompts* que funcionin com a garanties. Com fer un *prompt* a Claude Haiku 4.5 per a una generació de codi precisa no es tracta de frases florides o paraules clau secretes. Es tracta de restriccions, proves, versions i bucles de *feedback*. Fes aquestes quatre coses i obtindràs codi que s'executa. Omet-les i obtindràs ficció bellament formatada.
El codi no es preocupa per les teves sensacions. Per sort, els tests tampoc.
FAQ
Q1:Quina és la manera més senzilla de donar instruccions a Claude Haiku 4.5 per a generar codi precís?
Tracta-ho com un contracte: fixa versions, defineix esquemes, especifica formats d'errors i demana tests primer. Com més clars siguin els requisits, més precís serà el codi.
Q2:Com puc reduir les al·lucinacions quan Claude escriu codi?
Enganxa documentació o especificacions autoritzades i exigeix que es respectin exactament aquestes APIs. Per a punts finals privats, inclou la teva pròpia especificació—no esperis que ho endevini.
Q3:He de demanar a Claude que faci els tests o els faig jo mateix?
Demana a Claude que generi els tests primer, després implementa el codi per satisfer-los. Els tests defineixen millor la precisió que els adjectius i mantenen el model honest.
Q4:Quina especificitat ha de tenir la fixació de versions en les instruccions?
Molt específica: temps d’execució del llenguatge, versions principals i menors del framework i versió del SDK. “Últim” convida a patrons contradictoris; la precisió depèn d’objectius estables.
Q5:On encaixa Sider.AI en les instruccions per obtenir codi precís?
Fes servir Sider.AI per mantenir especificacions, codi, diffs i registres de tests en un mateix flux. No fa màgia—només preserva el context perquè les correccions de Claude reflecteixin els teus errors reals. 
