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

> Как использовать LLM для создания описаний вакансий, которые привлекают квалифицированных специалистов, а не спамеров ключевых слов. Промпты, шаблоны, примеры до/после.
> Author: Roman Belov · Published: 2026-03-27 · Source: https://futurecraft.pro/ru/blog/ai-job-descriptions/

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

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

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

Типичная вакансия собирается из трёх источников: шаблон с прошлого найма, список требований от тимлида, корпоративное описание компании из 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 желательных. По данным внутреннего отчёта HP, растиражированного Harvard Business Review, женщины откликаются на вакансию только при соответствии 100% требований, мужчины — при 60%. Чёткое разделение расширяет разнообразие воронки.

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

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

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

Генерация качественной вакансии через LLM требует структурированного контекста. Принцип тот же, что в [документировании процессов](/ru/blog/sop-generator-ai-documentation/): чем точнее входные данные, тем полезнее результат.

### Шаг 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, записывает результат обратно в документ.

```python
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-5.4",
        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. **Итерировать.** После первого найма обновить промпт на основе результатов: какие формулировки сработали, какие привели не тех кандидатов.

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

---

*Нужна помощь с автоматизацией HR-процессов и AI-генерацией вакансий? Я помогаю стартапам внедрять AI-решения и строить продукты — [belov.works](https://belov.works).*