AI-генератор вакансий: workflow для hiring manager

Вакансия не становится хорошей от гладкого текста LLM. Она хороша, когда qualified кандидат быстро отвечает на пять вопросов:

1. Над какой проблемой я буду работать?
2. Какой результат от меня ожидается?
3. Какие у меня authority и constraints?
4. Каковы условия и этапы найма?
5. Какие требования действительно essential?

AI превращает ответы в читаемый текст. Но не создаёт ответы, о которых не договорилась команда. Если input содержит только «senior backend engineer», уверенный output всё равно будет догадкой.

Разделите три документа

Команды часто называют всё job description, хотя артефакты разные:

Public advert не обязан содержать каждую внутреннюю деталь, но не может противоречить internal role. Все channel variants создавайте из одного approved baseline, иначе версии для careers page, recruiter и job board разойдутся.

Соберите source-of-truth intake

До prose получите факты от hiring manager.

Почему появилась роль

• Это growth, replacement, temporary capacity или новая capability?
• Какая business или customer problem требует найма сейчас?
• Что произойдёт, если позиция останется открытой?
• Утверждены ли headcount и budget?

Не публикуйте чувствительные performance details человека, которого заменяют.

Outcomes и работа

Запишите три–пять outcomes на первые шесть или двенадцать месяцев, затем work, который может к ним привести. Outcome должен быть в зоне контроля роли.

Слабо:

Отвечать за backend development и улучшать scalability.

Точнее:

В первом квартале зафиксировать measured latency baseline billing path,
устранить две крупнейшие подтверждённые причины задержки и описать следующий
capacity constraint.

Второй вариант не обещает придуманную latency target и не навязывает преждевременную architecture. Он показывает evidence прогресса.

Scope и environment

• размер team и reporting line;
• важные collaborators;
• decisions, которыми роль владеет, на которые влияет или которые escalates;
• текущий production stack и действительно optional tools;
• legacy, on-call, travel, location и time-zone constraints;
• work arrangement и expected overlap;
• accessibility и accommodation contact;
• interview stages и work-sample expectations.

Публикуйте только утверждённые scale figures. Модель не должна украшать роль выдуманными traffic, revenue, growth или migration plans.

Conditions

Соберите verified compensation range и basis, currency, employment type, location, benefits, equity treatment, schedule, leave, probation и start constraints, где это применимо. Local disclosure rules меняются. Каждый variant проходит HR или legal review; AI не определяет required legal fields.

Превратите требования в evidence

Требование отвечает на вопрос: что человек должен уметь и чем это можно показать?

В regulated или licensed role proxy иногда обоснован. Hiring owner документирует почему. Модель не добавляет degree, certification, years, language, location или physical requirement только потому, что они встречаются в похожих вакансиях.

Разделите criteria:

• essential on day one: нужно для безопасного или законного core work;
• learnable after joining: capability с реалистичным ramp plan;
• useful context: experience, который ускоряет ramp, но не является filter.

Не нужен произвольный maximum count. Короткий список обычно яснее, но настоящий test: каждый essential criterion обоснован и проверяется дальше в том же hiring process.

Генерируйте только из фактов

Prompt должен запрещать заполнение стереотипом:

Ты редактируешь public job advert из approved role intake.
Используй только переданные facts. Не выводи и не придумывай company claims,
duties, stack, scale, compensation, benefits, location, credentials,
years of experience, legal notices и candidate traits.

Если required field отсутствует, вставь [MISSING: field] и добавь его в open_questions.
Сохраняй uncertainty: например, "planned", а не "in production".

Структура:
1. role и problem в одном предложении;
2. outcomes и representative work;
3. scope, team и decision rights;
4. essential evidence;
5. learnable или useful experience;
6. verified conditions;
7. hiring process и accommodation route;
8. короткий factual call to apply.

Style:
- описывай job, а не идеализированного человека;
- direct language и короткие paragraphs;
- убери unsupported superlatives и corporate clichés;
- не отговаривай людей, которые соответствуют essentials, но не всем preferences.

Верни:
- advert_markdown;
- open_questions;
- claims_requiring_verification;
- source_map с привязкой factual sections к intake field IDs.

APPROVED INTAKE:
{role_intake}

Source map показывает hallucinated facts на review. Тот же принцип — structured inputs, explicit omissions и controlled output — разобран в гайде по context engineering.

Проведите пять review passes

1. Factual pass

Hiring manager сверяет каждый claim с role intake. Убедитесь, что stack используется этой командой, planned work обозначена как planned, а outcomes не являются fiction.

2. Job-relatedness pass

Для каждого filter спросите:

• Какая task требует этого?
• Как interview это оценит?
• Покажет ли capability другой background?
• Исключает ли criterion людей, не улучшая решение?

Удалите требования без ответа.

3. Inclusion и accessibility pass

Проверьте job title, pronouns, idioms, age-coded language, лишние physical и location requirements, schedule assumptions и способ предложения accommodation. Не описывайте demographic proxy вместо работы.

В США EEOC указывает, что job advertisement не должен выражать preference или отговаривать applicants по protected characteristics; neutral practices тоже могут создать unlawful disparate effect, если они не job-related и не необходимы. См. EEOC recruitment guidance. В UK Acas рекомендует inclusive language, которая определяет job, а не applicant, и учитывает distribution advert. См. Acas guidance. Другим юрисдикциям нужен свой review.

4. Transparency pass

Какой пропущенный факт заставит кандидата уйти позже: pay, location, schedule, travel, on-call, employment type, interview workload, reporting line или рабочий язык? Сначала проверьте факт. «Competitive compensation» не заменяет approved range.

5. Legal и policy pass

HR или counsel проверяет local advertising, pay-transparency, equality, privacy, classification, right-to-work, works-council, union, record-retention и required-notice rules. Это release gate, а не prompt instruction.

Если AI дальше scores CV, ranks applicants, проводит assessments или targets delivery, это отдельная higher-risk system. Writing assistance не валидирует selection automation. EEOC и US Department of Justice предупреждали, что AI hiring tools могут screen out людей с disability, а employer по-прежнему отвечает за accommodation и anti-discrimination safeguards. См. technical-assistance announcement.

Запустите adversarial editing prompt

После human factual review второй model pass может найти defects, но не должен молча переписывать advert:

Проведи audit approved draft. Не изменяй его.

Верни findings с точными excerpts и proposed edits по категориям:
- unsupported или unverifiable claim;
- requirement без связи с stated task;
- essential versus learnable mismatch;
- ambiguous responsibility или success evidence;
- discriminatory или exclusionary language risk;
- missing condition, способное вызвать expectation mismatch;
- cliché, repetition или inflated tone;
- conflict между advert и source intake.

Не давай legal conclusion. Отметь пункты для HR или legal review.

DRAFT:
{job_advert}
SOURCE INTAKE:
{role_intake}

Reviewer принимает или отклоняет каждую edit. Не публикуйте full rewrite второй модели без повторного factual pass.

Короткий before-and-after example

Это fictional example: facts являются placeholders, а не hiring benchmarks.

До:

Senior Backend Engineer

Мы быстрорастущая компания и ищем proactive team player.
Вы будете строить scalable services, работать cross-functionally и drive innovation.
Требования: 7+ лет, Python, Django, FastAPI, Kubernetes, Kafka, AWS, Redis,
PostgreSQL, Terraform и высшее техническое образование.
Competitive salary и flexible work.

После intake и review:

Backend Engineer — Billing Reliability

Billing team нужен инженер, который сократит recurring payment failures и ускорит
incident diagnosis. Это существующая система на Python и PostgreSQL с on-call;
service split исследуется, но ещё не выбран.

Initial outcomes
- задать общую failure taxonomy и baseline по production data;
- устранить две крупнейшие подтверждённые причины failed renewals;
- добавить runbooks и traces для поиска failing step on-call инженером.

Essential evidence
- эксплуатировал backend service в production;
- диагностировал failures на границе application и database;
- писал и review tests для money-sensitive workflows.

Useful context, not a filter
- Python или сопоставимый backend language;
- PostgreSQL performance work;
- event-driven systems.

Team and conditions
[VERIFIED TEAM, REPORTING LINE, LOCATION, SCHEDULE, ON-CALL, PAY RANGE,
EMPLOYMENT TYPE, BENEFITS, INTERVIEW STAGES, ACCOMMODATION CONTACT]

Версия лучше не из-за длины. Она отделяет observed work от possible architecture, заменяет technology inventory на evidence и показывает missing facts до публикации.

Создавайте channel variants без изменения job

Short social post, full careers-page advert, recruiter brief и internal referral note производятся из одного approved baseline. Factual fields locked; меняются только length, heading и format. Каждый variant хранит baseline version ID.

Localization — не только translation. Local reviewer проверяет terminology, compensation basis, employment classification, required notices и accessibility application channel.

Измеряйте весь funnel

Оценивайте quality, не превращая advert в volume game:

• views → completed applications по source;
• applicants, соответствующие documented essential criteria;
• progression и withdrawal на каждом stage;
• time in stage;
• expectation mismatches на interviews;
• offer acceptance и decline reasons;
• поздний evidence, что role definition или assessment были неверны.

Demographic impact анализируйте только при lawful collection, access controls, достаточных samples и qualified HR/legal guidance. Не отправляйте protected-characteristic data в public model.

Сравнение старой вакансии на одной платформе и новой на другой — не A/B test: сменились audience и distribution. Если тест уместен, сравнивайте внутри одного channel и market, аккуратно randomize или rotate, оставляйте conditions одинаковыми и проверяйте compliance обеих версий. Плейбук экспериментов описывает predeclared metrics и stopping rules.

Operating rule

AI должен сделать утверждённую роль понятнее, а не компанию привлекательнее на бумаге. Если модель пометила missing compensation, unclear decision rights или unsupported requirement, это хороший output. Она нашла hiring problem до того, как его пришлось обнаружить кандидату.