Веб-скрапинг давно перестал быть «пять строк на BeautifulSoup». Сегодня реальный проект — это динамический рендеринг, ротация прокси, капчи, лимиты запросов и данные, которые приходят в трёх форматах сразу. LLM здесь работает не как «напиши мне код», а как инженер-напарник: помогает спроектировать архитектуру, разобрать чужой HTML, объяснить, почему Playwright падает на 40-й странице, и собрать нормализованный DataFrame.
Ниже — 12 промтов для полного цикла: от проектирования краулера до мониторинга падений. Каждый — с задачей и примером. Промты писал так, чтобы их можно было копировать в чат как есть, подставив свои данные.
Проектирование и архитектура краулера
1. Промт-архитектор: схема краулера до первой строки кода
Задача: не начинать с requests.get, а сначала получить карту компонентов, точек отказа и стратегии обхода.
Промт:
Ты — senior data engineer. Спроектируй краулер для сайта [описание: тип контента, примерная структура, есть ли JS-рендеринг, авторизация].
Выдай:
1. Схему компонентов (fetcher, parser, storage, scheduler) и что делает каждый.
2. Где будут узкие места при 10 000 страниц/сутки.
3. Стратегию: requests+BS4 или Playwright — с обоснованием по каждому типу страниц.
4. Точки отказа и как их заметить на раннем этапе (метрики).
5. Что хранить в state, чтобы краулер переживал перезапуск.
Пример: для каталога из 8 000 карточек товаров с бесконечной прокруткой LLM предложит гибрид: список категорий через requests, карточки через Playwright с отключёнными изображениями. Trade-off: скорость падает в 3–5 раз, но без JS данные не отдаются вовсе.
2. Разбор чужого HTML и генерация селекторов
Задача: быстро получить устойчивые CSS/XPath-селекторы по фрагменту разметки.
Промт:
Вот HTML-фрагмент страницы. Задача: извлечь [поля: название, цена, артикул, дата].
1. Дай CSS-селекторы и XPath для каждого поля.
2. Отметь селекторы, которые сломаются при изменении вёрстки, и предложи более устойчивые (по data-атрибутам, а не по позиции).
3. Напиши функцию на Python с BeautifulSoup, которая возвращает None вместо исключения, если поле отсутствует.
HTML:
Пример: вместо div > div:nth-child(3) > span LLM предложит [data-product-id] .price, что переживает редизайн блока.
Динамический рендеринг и Playwright
3. Промт для ожиданий в Playwright
Задача: убрать time.sleep() и заменить их корректными ожиданиями — главная причина «плавающих» падений.
Промт:
Напиши Playwright-скрипт (Python, async) для страницы с ленивой подгрузкой карточек.
Требования:
- ждать появления конкретного селектора, а не фиксированное время;
- прокручивать до исчезновения индикатора загрузки;
- таймаут 30 с с понятной ошибкой;
- закрывать браузер в finally.
Объясни, почему wait_for_selector надёжнее sleep.
Пример: скрипт на 20 карточек с page.wait_for_selector('.card:last-child') стабильно отрабатывает там, где sleep(3) давал то 15, то 20 элементов.
4. Промт-детектив: почему Playwright падает на середине
Задача: диагностировать падения без ручного дебага.
Промт:
Краулер на Playwright падает на ~40-й странице с [текст ошибки]. Логи прилагаю.
1. Назови 3 наиболее вероятные причины в порядке вероятности.
2. Для каждой — как проверить за 5 минут.
3. Предложи защиту в коде (retry, ротация контекста, ограничение параллельных вкладок).
Логи: [вставить]
Пример: частый ответ — утечка памяти из-за незакрытых контекстов; решение — переиспользовать браузер, но создавать новый контекст на батч из 50 страниц.
Антибот-защита, прокси и лимиты
5. Промт для ротации заголовков и прокси
Задача: собрать слой ротации, который не выглядит как бот.
Промт:
Спроектируй модуль ротации для скрапера:
- пул User-Agent, согласованный с заголовками (Accept-Language, Sec-Fetch-*);
- ротация прокси с проверкой живости перед использованием;
- экспоненциальный backoff на 429/403;
- лимит запросов в секунду на домен.
Дай код на Python и объясни, какие признаки выдают бота сильнее всего.
Пример: LLM напомнит, что несогласованный набор заголовков (мобильный UA + десктопные Sec-Fetch) подозрительнее, чем один стабильный.
6. Промт для обработки капчи и rate limiting
Задача: понять, где остановиться, а не «обойти любой ценой».
Промт:
Сайт отдаёт капчу после N запросов. Опиши:
1. Легальные стратегии снижения нагрузки (снижение частоты, кэширование, уважение robots.txt).
2. Технические варианты: сервисы решения капчи, пауза и возобновление.
3. Как встроить rate limiter (token bucket) в код.
4. Какие риски блокировки аккаунта и как их оценить.
Пример: token bucket на 1 запрос в 2 секунды с джиттером снижает частоту капчи заметно, но не устраняет её полностью — это честный trade-off, который LLM озвучит прямо.
Парсинг форматов и нормализация
7. Промт для парсинга PDF и JSON
Задача: единый пайплайн для разнородных источников.
Промт:
Нужно извлечь таблицу из PDF (прайс-лист) и JSON API в один DataFrame.
1. Какой инструмент для PDF (pdfplumber, camelot) и почему.
2. Код: PDF → DataFrame, JSON → DataFrame.
3. Как привести колонки к единой схеме (переименование, типы, единицы).
4. Что делать с объединёнными ячейками и пропусками.
Пример: pdfplumber отдаёт таблицу с многострочными ячейками — LLM предложит стратегию table_settings и постобработку, а не ручное «дотягивание».
8. Промт-нормализатор в pandas
Задача: превратить «грязные» данные в пригодный DataFrame.
Промт:
Вот сырые данные после парсинга: [пример строк].
Напиши pandas-пайплайн:
- очистка цен («1 299 ₽» → 1299.0);
- нормализация дат к ISO;
- удаление дублей по [ключ];
- обработка пропусков с обоснованием (drop vs fill);
- приведение типов и валидация.
Покажи результат на 3 примерах строк.
Пример: «1 299 ₽» и «1299 руб.» сводятся к float через str.replace с регуляркой \D, а не через цепочку if.
Мониторинг и надёжность
9. Промт для логирования и алертов
Задача: узнать о падении раньше, чем заказчик.
Промт:
Спроектируй логирование краулера:
- структурированные логи (JSON) с полями url, status, duration, error;
- метрики: доля ошибок, среднее время ответа, число пустых результатов;
- алерт при росте доли 403/пустых селекторов выше порога;
- дашборд-минимум.
Дай пример конфигурации и код логгера.
Пример: рост «пустых результатов» при статусе 200 — первый сигнал смены вёрстки, его видно за часы до полного отказа.
10. Промт для идемпотентности и перезапуска
Задача: краулер должен продолжаться с места падения.
Промт:
Сделай краулер идемпотентным: при перезапуске он не дублирует уже собранное.
1. Схема state (какие URL обработаны, хеши страниц).
2. Как хранить (SQLite/Redis) и почему.
3. Код проверки «уже собрано» перед запросом.
4. Как обрабатывать частично собранные страницы.
Пример: хранение хеша контента позволяет не только не дублировать, но и ловить изменения страниц между запусками.
11. Промт-ревьюер кода скрапера
Задача: найти проблемы до продакшена.
Промт:
Проведи ревью скрапера как senior. Ищи:
- необработанные исключения и таймауты;
- утечки ресурсов (браузер, сессии);
- хрупкие селекторы;
- отсутствие ретраев и лимитов;
- нарушения robots.txt и ToS.
Дай список проблем с приоритетом и патчами.
Код: [вставить]
Пример: типичная находка — requests.Session без timeout, из-за чего один зависший запрос вешает весь батч.
12. Промт для юридической проверки источника
Задача: не получить блокировку и претензию.
Промт:
Перед скрапингом [сайт] проверь:
1. Что говорит robots.txt и ToS о парсинге.
2. Есть ли персональные данные в целевом контенте (риски по 152-ФЗ).
3. Какие ограничения на частоту запросов разумны.
4. Что фиксировать, чтобы доказать добросовестность.
Пример: LLM напомнит, что сбор email и телефонов из открытых профилей — это персональные данные, и их обработка требует правовых оснований.
Что в итоге
Скрапинг ломается не на «сложном коде», а на скучных местах: таймаутах, хрупких селекторах, отсутствии state и нормализации. Промты выше закрывают именно их — LLM полезен как ревьюер и архитектор, а не как генератор «магического обхода».
Начните с промта №1 и №11: первый экономит дни на переделках, второй ловит то, что вы не заметите до первого бана. А если дальше пойдёте в сторону данных и SQL — загляните в разбор промтов для SQL-миграций и юнит-тестов на Python с LLM.