AI-генерация вакансий: как привлечь сильных кандидатов

78% откликов на вакансии на LinkedIn приходят от кандидатов, которые не соответствуют требованиям позиции. На HH.ru ситуация аналогична: рекрутеры тратят в среднем 23 часа в неделю на скрининг нерелевантных резюме. Основная причина — сами тексты вакансий. Размытые описания притягивают массовые отклики. Перегруженные ключевыми словами вакансии отпугивают сильных кандидатов и привлекают тех, кто научился подбирать резюме под ATS-фильтры.

Статья о том, как использовать LLM для генерации описаний вакансий, которые работают как фильтр: привлекают подходящих специалистов и отсекают нерелевантные отклики. Промпты, шаблоны, конкретные примеры трансформации типичных вакансий. Тот же подход структурированной генерации из сырых данных, что описан в руководстве по context engineering.

Почему стандартные вакансии не работают

Типичная вакансия собирается из трёх источников: шаблон с прошлого найма, список требований от тимлида, корпоративное описание компании из HR-отдела. Результат предсказуем.

Список требований вместо описания работы. «Опыт от 5 лет, знание Python, SQL, Docker, Kubernetes, CI/CD, Terraform, AWS/GCP, PostgreSQL, Redis, RabbitMQ, Kafka». Кандидат видит 12 технологий и не понимает, что из этого используется ежедневно, а что упомянуто «на всякий случай». Сильные специалисты пропускают вакансию, если не попадают в 100% списка. Слабые откликаются на всё подряд.

Корпоративный язык. «Мы динамично развивающаяся компания, лидер рынка в своём сегменте, ищем проактивного командного игрока с навыками мультитаскинга». Ноль конкретики. Эти фразы копируются из вакансии в вакансию и не несут информации о реальной работе.

Отсутствие контекста задач. Кандидат не знает, чем будет заниматься в первый месяц. Не знает, какие проблемы решает команда. Не знает, почему открылась позиция. Без этой информации решение принимается по зарплатной вилке и названию компании.

Скрытые фильтры в ATS. Applicant Tracking Systems фильтруют по ключевым словам. Рекрутеры добавляют больше ключевых слов, чтобы расширить воронку. Кандидаты учатся вставлять ключевые слова в резюме белым шрифтом. Обе стороны оптимизируют не под качество найма, а под алгоритм.

Что делает вакансию эффективной

Исследования показывают чёткую корреляцию между структурой текста вакансии и качеством откликов.

Конкретные задачи вместо абстрактных обязанностей. Не «разработка высоконагруженных систем», а «перевести монолит биллинга (PostgreSQL, 50M транзакций/месяц) на event-driven архитектуру за 6 месяцев». Кандидат сразу оценивает: интересно ли, по силам ли, хочет ли.

Разделение must-have и nice-to-have. 3-5 обязательных требований, 3-5 желательных. Исследование LinkedIn показало, что женщины откликаются на вакансию только при соответствии 100% требований, мужчины — при 60%. Чёткое разделение расширяет разнообразие воронки.

Прозрачность условий. Зарплатная вилка, формат работы, размер команды, стек в продакшне. Каждый скрытый параметр увеличивает число нерелевантных откликов: кандидат тратит время на собеседование и отказывается на этапе оффера.

Голос команды, не HR-отдела. Тексты, написанные непосредственным руководителем или членом команды, получают на 30-40% больше релевантных откликов. Проблема в том, что инженеры не любят и не умеют писать вакансии. LLM закрывает именно этот пробел.

Архитектура промпта для генерации вакансий

Генерация качественной вакансии через LLM требует структурированного контекста. Принцип тот же, что в документировании процессов: чем точнее входные данные, тем полезнее результат.

Шаг 1. Сбор сырых данных

Прежде чем запускать LLM, нужно собрать контекст из реальных источников. Минимальный набор:

• Описание от нанимающего менеджера. 5-10 минут голосового сообщения или текста в свободной форме: зачем нужен человек, какие задачи, что горит, что не горит.
• Текущий стек. Не «всё что мы используем», а конкретно: что использует эта команда, что в продакшне, что на этапе внедрения.
• Контекст команды. Размер, структура, кто есть сейчас, какие роли закрыты, какие нет. Уровень автономии: даётся задача или проблема.
• Причина открытия позиции. Рост, замена, новый проект. Это определяет тон и срочность.
• Провалы прошлого найма. Кто откликался, но не подошёл. Какие сигналы оказались ложными.

Шаг 2. Базовый промпт генерации

Ты — технический рекрутер с 10-летним опытом найма в IT.

Сгенерируй описание вакансии на основе входных данных ниже.

ПРАВИЛА:
- Начни с 2-3 предложений о реальной задаче, не о компании
- Раздели требования на "обязательно" (макс 5) и "будет плюсом" (макс 5)
- Опиши 3-5 конкретных задач на первые 3 месяца
- Укажи размер команды, формат работы, стек в продакшне
- Не используй: "динамично развивающаяся", "лидер рынка",
  "проактивный", "мультитаскинг", "быстро меняющаяся среда"
- Тон: прямой, конкретный, уважительный
- Длина: 400-600 слов

ВХОДНЫЕ ДАННЫЕ:
{вставить собранный контекст}

Этот промпт задаёт структуру и антипаттерны. Ключевое ограничение — список запрещённых фраз. Без него LLM воспроизводит корпоративные клише из обучающих данных.

Шаг 3. Промпт для критического ревью

Генерация без ревью даёт посредственный результат. Второй вызов LLM работает как редактор:

Проанализируй описание вакансии ниже. Оцени по критериям:

1. КОНКРЕТНОСТЬ: Может ли кандидат понять, чем будет заниматься
   в первый месяц? (да/нет + что исправить)
2. ФИЛЬТРАЦИЯ: Отсечёт ли текст нерелевантных кандидатов?
   (да/нет + что исправить)
3. КЛИШЕ: Есть ли фразы, которые не несут информации?
   (список + замены)
4. БАЛАНС ТРЕБОВАНИЙ: Реально ли найти человека со ВСЕМИ
   обязательными требованиями? (да/нет + что перенести в "плюсы")
5. ПРОЗРАЧНОСТЬ: Указаны ли условия, скрытие которых
   приведёт к отказам на этапе оффера? (список пропущенного)

Верни исправленную версию с пометками [ИЗМЕНЕНО] у каждой
правки.

ВАКАНСИЯ:
{вставить результат первого шага}

Двухшаговый подход (генерация + ревью) стабильно даёт лучший результат, чем одноразовая генерация с усложнённым промптом.

Пример до/после: Backend-разработчик

До (типичная вакансия)

Backend-разработчик (Python)

О компании: Мы — быстрорастущий стартап в сфере финтех,
разрабатываем инновационную платформу для управления финансами.

Требования:
- Python 5+ лет
- Django/FastAPI
- PostgreSQL, Redis
- Docker, Kubernetes
- CI/CD (Jenkins/GitLab CI)
- AWS (EC2, S3, Lambda, SQS, RDS)
- Kafka/RabbitMQ
- Опыт работы с высоконагруженными системами
- Понимание принципов SOLID, DDD
- Английский B2+

Обязанности:
- Разработка и поддержка серверной части
- Проектирование API
- Код-ревью
- Написание тестов
- Взаимодействие с продуктовой командой

Мы предлагаем:
- Конкурентную зарплату
- Гибкий график
- Дружный коллектив

Проблемы: 10 технических требований без приоритизации. Обязанности описывают любую backend-позицию в мире. «Конкурентная зарплата» — информационный ноль. Кандидат не понимает ни задачу, ни масштаб, ни вызов.

После (AI-генерация + ревью)

Backend-разработчик (Python) — миграция биллинга

Платёжная система обрабатывает 2M транзакций в месяц через
монолит на Django. Архитектура не масштабируется: время
ответа API выросло с 200ms до 1.2s за последний квартал.
Нужен инженер, который поможет декомпозировать биллинг
на сервисы и снизить latency до 300ms.

Задачи на первые 3 месяца:
- Спроектировать event-driven архитектуру для модуля
  транзакций (Kafka + PostgreSQL)
- Вынести расчёт комиссий из монолита в отдельный сервис
  на FastAPI
- Настроить нагрузочное тестирование (Locust)
  для критических эндпоинтов

Обязательно:
- Python 3+ года в продакшне
- Опыт работы с PostgreSQL при нагрузке от 100K записей/день
- Понимание event-driven паттернов (не обязательно Kafka)
- Опыт декомпозиции монолита (хотя бы один проект)

Будет плюсом:
- FastAPI в продакшне
- Kafka/RabbitMQ
- AWS (мы используем ECS + RDS)
- Опыт с нагрузочным тестированием

Команда: 4 backend-инженера, 1 DevOps, 1 QA. Решения
по архитектуре принимает команда, не менеджмент.

Формат: удалёнка, 2 синка в неделю (утро по МСК).
Зарплата: 350-450K на руки, пересмотр через 6 месяцев.

Разница: конкретная задача вместо абстрактных обязанностей. 4 обязательных требования вместо 10. Кандидат за 30 секунд понимает масштаб, вызов, условия. Сильный инженер видит интересную задачу. Слабый понимает, что не потянет. Оба экономят время.

Адаптация под разные роли

Структура промпта универсальна, но акценты различаются.

Технические роли (инженеры, DevOps, SRE)

Фокус на задачах, стеке и масштабе. Инженеры принимают решение на основе технического вызова. Добавить в промпт:

Дополнительные правила для технической вакансии:
- Укажи масштаб системы (RPS, объём данных, число пользователей)
- Опиши текущую архитектуру в 2-3 предложениях
- Назови главную техническую проблему, которую решает позиция
- Укажи степень автономии: задачи ставятся или проблемы

Продуктовые роли (PM, дизайнеры, аналитики)

Фокус на продукте, метриках и влиянии. Добавить:

Дополнительные правила для продуктовой вакансии:
- Опиши продукт: кто пользователи, какую проблему решает
- Укажи ключевые метрики, на которые влияет позиция
- Опиши процесс принятия решений (data-driven, founder-driven)
- Назови последнее значимое продуктовое решение команды

Менеджерские роли (тимлид, CTO, VP)

Фокус на контексте компании, стадии и вызовах. Добавить:

Дополнительные правила для менеджерской вакансии:
- Опиши стадию компании и размер инженерной команды
- Назови 2-3 стратегические задачи на ближайший год
- Укажи текущие процессы (или их отсутствие)
- Опиши ожидания от роли через 6 и 12 месяцев

Антипаттерны AI-генерации вакансий

LLM воспроизводит паттерны из обучающих данных. Без контроля результат будет лучше среднего, но не оптимальным.

Восторженный тон. LLM склонны к позитивной окраске: «уникальная возможность», «невероятная команда», «передовые технологии». Добавить в промпт: «Тон: сдержанный и фактологический. Не используй превосходные степени».

Раздувание требований. Модель добавляет требования, которых нет во входных данных, экстраполируя из типичных вакансий. Контрмера: «Используй ТОЛЬКО требования из входных данных. Не добавляй технологии, которые не упомянуты».

Шаблонные call-to-action. «Если вы амбициозный профессионал, который хочет изменить мир…» Заменить на конкретику: «Откликайтесь, если задача декомпозиции монолита вам знакома и интересна».

Гендерно-нейтральный язык. В русском языке это требует внимания: «кандидат/кандидатка» или нейтральные конструкции. Добавить в промпт правило по гендерному тону в зависимости от политики компании.

Игнорирование anti-requirements. Полезно явно указать, кому вакансия не подходит. Пример: «Позиция не подойдёт, если вы ищете чистый greenfield без легаси или позицию с минимумом коммуникации». Это снижает число нерелевантных откликов на 15-20%.

Автоматизация процесса

Ручной копипаст промптов работает для разовых вакансий. При регулярном найме имеет смысл автоматизировать.

Минимальная автоматизация

Шаблон в Notion/Google Docs с полями для заполнения нанимающим менеджером. Скрипт берёт данные из шаблона, подставляет в промпт, отправляет в API, записывает результат обратно в документ.

import openai

def generate_job_description(raw_input: dict) -> str:
    """Генерация вакансии из структурированного ввода."""
    context = f"""
    Роль: {raw_input['role']}
    Причина открытия: {raw_input['reason']}
    Задачи на 3 месяца: {raw_input['tasks_3m']}
    Стек в продакшне: {raw_input['stack']}
    Команда: {raw_input['team']}
    Обязательные навыки: {raw_input['must_have']}
    Условия: {raw_input['conditions']}
    Анти-паттерны прошлого найма: {raw_input['anti_patterns']}
    """

    response = openai.chat.completions.create(
        model="gpt-4o",
        messages=[
            {"role": "system", "content": SYSTEM_PROMPT},
            {"role": "user", "content": context}
        ],
        temperature=0.7
    )
    return response.choices[0].message.content

Расширенная автоматизация

Добавить второй вызов для ревью. Добавить генерацию версий для разных площадок (LinkedIn, HH.ru, Telegram-каналы): каждая платформа имеет свои ограничения по длине и формату. Хранить историю вакансий и результаты найма для fine-tuning промптов.

Метрики эффективности вакансий

Сгенерировать вакансию недостаточно. Нужно измерять результат и корректировать промпты.

Конверсия просмотр → отклик. Целевой диапазон: 8-15%. Ниже 5% — текст не мотивирует, выше 20% — слишком размытые требования.

Доля релевантных откликов. Процент кандидатов, прошедших первичный скрининг. До AI-генерации: обычно 15-25%. После: целевой показатель 40-60%.

Time-to-fill. Время от публикации до принятия оффера. Конкретные вакансии сокращают этот показатель за счёт меньшего числа нерелевантных интервью.

Отказы на этапе оффера. Если кандидаты отказываются после финального собеседования, в вакансии скрыта критичная информация. Добавить недостающие условия в шаблон.

Сохранять связку «текст вакансии — метрики результата» для каждого найма. Через 5-10 вакансий накопится достаточно данных, чтобы идентифицировать паттерны: какие формулировки коррелируют с качеством откликов.

Частые ошибки при внедрении

Генерировать без входных данных. Запрос «напиши вакансию для Python-разработчика» даёт generic результат. LLM не знает контекст команды. Без входных данных результат будет лучше типичного шаблона, но хуже целевого.

Не адаптировать под площадку. Вакансия для LinkedIn (лимит 2600 символов в описании) и для HH.ru (нет лимита, но есть структурированные поля) требуют разного формата. Один промпт — одна площадка.

Пропускать ревью нанимающего менеджера. AI генерирует текст, но только менеджер знает нюансы: «мы НЕ пишем на Kafka, это планы на следующий год» или «размер команды вырастет до 8 человек через квартал». Ревью занимает 5 минут и предотвращает ложные ожидания.

Не обновлять промпты. Рынок труда меняется. Фразы, которые работали полгода назад, перестают работать. Метрики позволяют заметить деградацию и скорректировать подход.

С чего начать

1. Взять одну открытую вакансию. Не пытаться автоматизировать весь найм сразу.
2. Собрать контекст от нанимающего менеджера. 10 минут голосового сообщения или заполненный шаблон. Чем подробнее вход, тем точнее результат.
3. Запустить двухшаговую генерацию. Базовый промпт + промпт ревью из этой статьи. Скопировать, подставить данные, запустить.
4. Сравнить с текущей версией. Поставить A/B: опубликовать AI-версию на одной площадке, старую на другой. Замерить конверсию и долю релевантных откликов.
5. Итерировать. После первого найма обновить промпт на основе результатов: какие формулировки сработали, какие привели не тех кандидатов.

Цель не в том, чтобы заменить рекрутера или нанимающего менеджера. Цель в том, чтобы снять с них задачу, которую они делают плохо (написание текста), и оставить то, что они делают хорошо (понимание контекста и оценка людей).