Prompt Migliori per un Generatore di Descrizione Lavoro con IA
Perché le descrizioni di lavoro dell'IA suonano tutte uguali
Chiedi a un LLM di "scrivere una descrizione di lavoro per un software engineer" e ottieni:
Siamo alla ricerca di un Software Engineer talentuoso per unirsi al nostro team innovativo. Lavorerai su tecnologie all'avanguardia, collaborerai con team cross-funzionali e avrai impatto. Richiesto: 5+ anni di esperienza, forti competenze di comunicazione, passione per la risoluzione dei problemi...
Ogni azienda ottiene la stessa descrizione di lavoro. Le parole sono generiche, i requisiti sono boilerplate, il tono è indistinguibile da cinquanta altri posting. Non riflette la tua azienda, il tuo ruolo o le tue reali necessità.
Il problema non è l'LLM. È il prompt. Un prompt vago ottiene un output vago.
Come strutturare un prompt che funziona
Un prompt di JD funzionante ha cinque sezioni:
1. Contesto aziendale (2–3 frasi)
Non "siamo un'azienda tech innovativa" — è ogni azienda. Dai contesto specifico:
Acme Systems produce automazione infrastrutturale per compagnie di assicurazione. Siamo una azienda B2B SaaS di $50M, 12 persone nel team engineering, fondata nel 2018. Ci importa più di spedire prodotti solidi che di muoverci velocemente, e facciamo intervista per culture-add non culture-fit.
L'LLM ora ha veri vincoli. Non suggerirà "move fast and break things"; suggerirà qualcuno che valuta la spedizione di qualità.
2. Il vero lavoro (titolo del ruolo, cosa faranno, realtà quotidiana)
Non "le responsabilità includono..." — descrivi quello che la persona fa il giorno uno:
Senior Backend Engineer, piattaforma di pagamenti. Possiederai il sistema di fatturazione: progettando schema, spedendo funzionalità che riducono i fallimenti di pagamento, rispondendo al supporto clienti relativo ai pagamenti. Lavorerai con un product manager (Carol) e uno frontend engineer (Dev). Spenderai ~40% codifica, ~30% design/review, ~20% supporto on-call, ~10% in riunioni.
La specificità batte l'astrazione. "Il giorno 30 avrai spedito la funzionalità X" batte "contribuirai alla nostra product roadmap".
3. Quello che davvero hanno bisogno di sapere o avere (non wish-list)
Separa must-have da nice-to-have:
Must-have:
- 5+ anni di ingegneria software backend
- Forte SQL e design di schema
- Spedito un'integrazione di pagamento (Stripe, Square, PayPal, qualunque)
- A tuo agio nel stare on-call e debuggare problemi di produzione
Nice-to-have:
- Esperienza Scala o Rust (usiamo Scala per i pagamenti)
- Contributi open source
- Conoscenza di dominio assicurazioni/pagamenti
I must-have onesti sono rari. La maggior parte delle aziende elenca 8 must-have quando intendono 4. Sii reale. Un LLM seguirà il tuo piombo ed sarà realistico anche lui.
4. Cultura aziendale / stile di lavoro (non buzzword)
Non "collaborativo, innovativo, veloce". Invece:
Abbiamo documentazione async-first. Le riunioni sono uno standuo di 30 min una volta al giorno più office hours. Code-review tutto; il tuo primo PR potrebbe ricevere 10 commenti. Usiamo Postgres, niente NoSQL. Spediamo funzionalità ogni due settimane. Non facciamo Agile o Scrum — spediamo quando le funzionalità sono fatte.
Questi dettagli permettono all'LLM di ragionare su chi prospererebbe. Un engineer che odia code review o lavoro async non applicherà. Un engineer che ama il pensiero di sistemi profondamente sarà entusiasta.
5. Trasparenza della compensazione
Questo è critico e la maggior parte dei team lo salta:
Stipendio: $180k–$220k a seconda dell'esperienza. Equity: 0.15–0.4%. Benefici: 401k match, health/dental/vision, 4 settimane PTO, congedo parentale 16 settimane.
Le descrizioni di lavoro senza informazioni salariali sono irrispettose. Stai chiedendo a qualcuno di candidarsi senza sapere l'intervallo? La trasparenza della compensazione segnala anche un'azienda che si fida della sua stessa posizione di mercato.
Failure mode da evitare
Linguaggio gendered. La maggior parte degli LLM sono stati addestrati a riconoscere e spogliare parole gendered ("lui guida," "lei nutre") ma a volte ancora le generano. Aggiungi questo al tuo prompt:
Evita linguaggio gendered. Non dire "lui/lei" o aggettivi che virano maschio (aggressivo, pioneering) o femmina (collaborativo, nurturing).
Stack di requisiti non realistici. Il classico: "5+ anni con questo framework di 2 anni fa." Il tuo prompt dovrebbe richiamare questo:
Non richiedere esperienza con strumenti che abbiamo costruito in-house o che sono < 3 anni vecchi nel mercato.
Buzzword eccessivi. "Sinergizzare, fare leva, innovare, disturbare." Aggiungi:
Usa linguaggio semplice. Evita buzzword come "sinergia," "fare leva," "cutting-edge," "best-in-class." Sii specifico e onesto.
Mancanza del vero problema del ruolo. Se stai assumendo un backend engineer perché il tuo sistema di pagamenti sta fallendo, dillo:
Abbiamo un problema di technical debt nel sistema di fatturazione. Questo ruolo esiste per fissarlo, non solo per aggiungere headcount.
Un LLM dato questo contesto scriverà una descrizione di lavoro che attrae persone che vogliono risolvere problemi tecnici duri, non persone che cercano un titolo.
Cosa un umano deve ancora decidere
Gli LLM non sono la tua intera JD. Sono una bozza. Un umano deve:
- Verificare la banda di compensazione sia corretta per il tuo mercato, la tua posizione e il tuo livello di ruolo.
- Confermare i "nice-to-have" siano davvero nice e non deal-breaker travestiti.
- Possedere l'affermazione di missione — perché questo ruolo conta per il futuro della tua azienda. Nessun LLM dovrebbe scrivere "il tuo lavoro conta per noi"; dovresti farlo tu.
- Decidere chiaro su remote/hybrid/office. Non lasciare che l'LLM sia vago.
- Review per conformità legale. Alcune giurisdizioni richiedono disclosure specifiche. Il tuo team legale, non l'LLM, dovrebbe approvare.
ClarityHire's job description generator ti dà un'interfaccia di prompt strutturato (contesto aziendale, ruolo, must-have, cultura, comp) e genera una bozza di JD in 30 secondi. È abbastanza buona da spedire dopo una review umana. Non è abbastanza buona da spedire intoccata.