Bessere Prompts für einen KI-Stellenausschreibungs-Generator
Warum KI-Stellenausschreibungen alle gleich klingen
Fragen Sie ein LLM, "schreibe eine Stellenausschreibung für einen Softwareentwickler" und Sie bekommen:
Wir suchen einen talentierten Softwareentwickler, um sich unserem innovativen Team anzuschließen. Sie werden an hochmodernen Technologien arbeiten, mit funktionsübergreifenden Teams zusammenarbeiten, und Impact machen. Erforderlich: 5+ Jahre Erfahrung, starke Kommunikationsfähigkeiten, Leidenschaft für Problemlösung...
Jedes Unternehmen bekommt die gleiche Stellenausschreibung. Die Wörter sind generisch, die Anforderungen sind Boilerplate, der Ton ist nicht zu unterscheiden von fünfzig anderen Postings. Es spiegelt nicht Ihr Unternehmen, Ihre Rolle, oder Ihre tatsächlichen Bedürfnisse wider.
Das Problem ist nicht das LLM. Es ist der Prompt. Ein vager Prompt bekommt eine vage Ausgabe.
Wie man einen funktionierenden Prompt strukturiert
Ein funktionierender KI-JD-Prompt hat fünf Abschnitte:
1. Unternehmens-Kontext (2–3 Sätze)
Nicht "wir sind ein innovatives Tech-Unternehmen" – das ist jedes Unternehmen. Geben Sie spezifischen Kontext:
Acme Systems macht Infrastruktur-Automatisierung für Versicherungsunternehmen. Wir sind ein $50M B2B SaaS-Unternehmen, 12 Menschen im Engineering-Team, gegründet 2018. Wir kümmern uns um solide Produkte zu verschiffen statt schnell zu bewegen, und wir interviewen auf Culture-Add nicht Culture-Fit.
Das LLM hat jetzt echte Einschränkungen. Es wird nicht "Schnell bewegen und Dinge brechen" vorschlagen; es wird jemanden vorschlagen, der solide Auslieferung wertschätzt.
2. Der tatsächliche Job (Rollentitel, was sie tun werden, täglich Realität)
Nicht "Verantwortlichkeiten enthalten..." – beschreibe, was die Person Tag eins macht:
Senior Backend Engineer, Zahlungs-Plattform. Sie werden das Abrechnungssystem führen: Schemas entwerfen, Features verschiffen, die Zahlungsausfälle reduzieren, auf Zahlungs-bezogene Kundensupport reagieren. Sie werden mit einem Produktmanager (Carol) und einem Frontend-Engineer (Dev) arbeiten. Sie werden ~40 % Codierung, ~30 % Design/Review, ~20 % On-Call-Support, ~10 % in Meetings verbringen.
Spezifität schlägt Abstraktion. "Tag 30 werden Sie Feature X ausgeliefert haben" schlägt "Sie werden zu unserer Produktroadmap beitragen".
3. Was sie tatsächlich wissen oder haben müssen (nicht Wish-List)
Trennen Sie Muss-Haves von Nice-To-Haves:
Muss haben:
- 5+ Jahre Backend-Software-Engineering
- Starkes SQL und Schema-Design
- Eine Zahlungs-Integration ausgeliefert (Stripe, Square, PayPal, egal)
- Komfortabel On-Call und Debugging-Produktion-Probleme
Nett zu haben:
- Scala oder Rust Erfahrung (wir nutzen Scala für Zahlungen)
- Open Source-Beiträge
- Versicherungs-/Zahlungs-Domain-Wissen
Ehrliche Muss-Haves sind selten. Die meisten Unternehmen listen 8 Muss-Haves auf, wenn sie 4 meinen. Seien Sie ehrlich. Ein LLM wird Ihrem Vorbild folgen und auch realistisch sein.
4. Unternehmens-Kultur / Arbeitsweise (nicht Buzzwords)
Nicht "kooperativ, innovativ, schnelllebig". Stattdessen:
Wir haben async-first Dokumentation. Meetings sind 30-min Standup einmal pro Tag plus Office Hours. Wir Code-Review alles; Ihr erstes PR könnte 10 Kommentare bekommen. Wir nutzen Postgres, kein NoSQL. Wir verschiffen Features alle zwei Wochen. Wir machen kein Agile oder Scrum – wir verschiffen, wenn Features fertig sind.
Diese Details lassen das LLM erkennen, wer gedeihen würde. Ein Engineer, der Code-Review oder Async-Arbeit hasst, wird nicht anwenden. Ein Engineer, der tiefes Systems-Denken liebt, wird begeistert sein.
5. Kompensations-Transparenz
Das ist kritisch und die meisten Teams überspringen es:
Gehalt: $180k–$220k abhängig von Erfahrung. Equity: 0.15–0.4 %. Benefits: 401k Match, Health/Dental/Vision, 4 Wochen PTO, Elternzeit 16 Wochen.
Stellenausschreibungen ohne Gehalts-Information sind respektlos. Sie fragen jemanden zu bewerben, ohne die Spanne zu wissen? Kompensations-Transparenz signalisiert auch ein Unternehmen, das sein eigenes Markt-Position vertraut.
Fehlermodi zu vermeiden
Gendered Language. Die meisten LLMs haben trainiert zu erkennen und gendered Wörter zu entfernen ("er fährt", "sie kümmert"), aber manchmal generieren sie noch. Fügen Sie das zu Ihrem Prompt:
Vermeiden Sie gendered Language. Sagen Sie nicht "er/sie" oder Adjektive, die männlich skewn ("aggressiv", "Pionier") oder weiblich ("kooperativ", "nährend").
Unrealistische Anforderungs-Stapel. Der Klassiker: "5+ Jahre mit diesem 2-Jahre-alten Framework." Ihr Prompt sollte das ausrufen:
Verlangen Sie nicht Erfahrung mit Werkzeugen, die wir In-House gebaut haben oder die < 3 Jahre alt auf dem Markt sind.
Überschüssige Buzzwords. "Synergize, Leverage, Innovate, Disrupt." Fügen Sie:
Nutzen Sie Klarsprache. Vermeiden Sie Buzzwords wie "Synergie", "Leverage", "Cutting-Edge", "Best-In-Class". Seien Sie spezifisch und ehrlich.
Die tatsächliche Problem der Rolle vermisst. Falls Sie einen Backend-Engineer einstellen, weil Ihr Zahlungssystem ausfällt, sagen Sie es:
Wir haben ein Technical-Debt-Problem im Abrechnungssystem. Diese Rolle existiert, um es zu beheben, nicht nur um Headcount hinzuzufügen.
Ein LLM, dem dieser Kontext gegeben wird, wird eine Stellenausschreibung schreiben, die Menschen anzieht, die schwierige technische Probleme lösen wollen, nicht Menschen, die nach einem Titel suchen.
Was ein Mensch noch entscheiden muss
LLMs sind nicht deine ganze JD. Sie sind ein Entwurf. Ein Mensch muss:
- Die Kompensations-Spanne verifizieren ist markt-korrekt für Ihren Ort und Rollen-Niveau.
- Die "Nice-To-Haves" bestätigen sind tatsächlich nett und nicht Deal-Breaker in Verkleidung.
- Die Mission-Aussage besitzen – warum diese Rolle zur Zukunft Ihres Unternehmens wichtig ist. Kein LLM sollte "Ihre Arbeit ist wichtig für uns" schreiben; Sie sollten.
- Remote/Hybrid/Office entscheiden klar. Lassen Sie das LLM nicht vage.
- Für Rechtliche Compliance überprüfen. Einige Jurisdiktionen benötigen spezifische Offenlegungen. Ihr Legal-Team, nicht das LLM, sollte unterschreiben.
ClarityHire's Stellenausschreibungs-Generator gibt Ihnen eine strukturierte Prompt-Interface (Unternehmens-Kontext, Rolle, Muss-Haves, Kultur, Comp) und generiert einen JD-Entwurf in 30 Sekunden. Es ist gut genug, nach einer menschlichen Überprüfung zu verschiffen. Es ist nicht gut genug, unberührt zu verschiffen.