СтатьиQlikИнструментыUI Kit Поиск RSS →
← Все статьи
скилыClaude CodeCursorAI skillsPlaywrightбраузермаркетплейсOzonWildberriesDNSавтоматизацияИИЧернов пишет

Браузерный скил: когда API нет

Браузерный скил: когда API нет

Тебе нужна цена и наличие товара на маркетплейсе - Ozon, Wildberries, DNS. Казалось бы, мелочь: дёрнул данные, сравнил, принял решение. Но ты лезешь искать API площадки и упираешься в стену. Публичного интерфейса нет. Партнёрский - только для продавцов и через долгое согласование. А цена нужна сейчас.

И вот тут возникает соблазн собрать “парсер”. Звучит как что-то серое и хрупкое: сегодня работает, завтра вёрстка поменялась - и всё развалилось. Плюс совесть скребёт: а можно ли вообще так делать, не прилетит ли бан, не нарушаю ли я правила.

Хорошая новость: для разовой задачи “узнай цену по ссылке” не нужен ни большой парсер, ни знание тонкостей. Нужен один скил, который ведёт себя честно: сначала ищет нормальный путь через API, а если его нет - аккуратно читает только то, что и так видит любой посетитель страницы. Разберём, как это устроено и почему это нормальный, а не “хакерский” подход.

В чём идея

Скил - это короткая инструкция для ассистента: как называется, когда применять и что сделать. По описанию (description) ассистент сам подхватывает скил, когда твоя просьба попадает под триггер: “проверь цену”, “есть ли в наличии”, “сколько стоит на Озоне”.

Главная мысль урока - в порядке действий. Сначала API, и только потом браузер. Есть у площадки публичный или партнёрский интерфейс - бери его: это быстро, формат не плывёт, и ты играешь по правилам. API нет - тогда читаем витрину браузером, но честно платим за это цену. Браузер - последнее средство, а не первое.

А цена такая. Витрина - живой и хрупкий источник. Вёрстка меняется без предупреждения, и однажды твой селектор просто перестанет находить цену. Это не баг твоего скила, это природа браузерного подхода. API такого не делает - потому он всегда предпочтительнее.

Чтобы скил был устойчивее, в нём есть два технических приёма. Первый - auto-waiting вместо пауз. Не “подожди три секунды и надейся, что прогрузилось”, а “дождись, пока на странице появится сам элемент с ценой”. Браузер ждёт ровно нужный узел - и не падает на медленном интернете и не тратит время на быстром. Второй - устойчивые селекторы: цепляться за смысл и видимый текст, а не за автосгенерированные классы вида “a1b2c3”, которые меняются при каждой пересборке сайта.

И отдельно - этика, без неё браузерный скил делать нельзя. Читаем только публичные данные карточки, то, что видит любой человек без логина. Уважаем robots.txt и правила площадки. Ставим паузы и лимит на частоту, не долбим витрину в цикле. И честно про сами площадки: Ozon и Wildberries активно защищаются от роботов, и на первой же попытке headless-браузер, вероятнее всего, получит пустую страницу или капчу. Это нормальная природа этих площадок, а не баг твоего скила. DNS в этом плане мягче. Стабильная блокировка - это сигнал остановиться, а не повод обходить защиту. Один проход - один-два товара. Массовый парсинг чужой витрины - это уже другая история и другая ответственность.

Почему это вообще работает? Современный ассистент и так умеет управлять браузером (например через Playwright): открыть страницу, дождаться элемента, считать текст. Ему не хватало понятной инструкции с триггером и с правилами поведения. Скил ровно это и даёт - и заодно держит тебя в рамках приличия.

Как себе сделать

Не пиши этот скил руками и тем более не садись кодить парсер. Отдай задачу своему ассистенту - Claude Code, Codex, Cursor, Gemini, любому. Он сам разберётся, куда положить файл, и сам выберет, чем управлять браузером. Просто скопируй промпт:

Создай мне скил, который узнаёт цену и наличие товара на маркетплейсе (Ozon, Wildberries, DNS), когда у площадки нет публичного API.
Срабатывай на просьбы вроде "проверь цену по ссылке", "сколько стоит на Озоне", "есть ли в наличии". На вход - ссылка на карточку или название товара и площадка.
Сначала проверь, есть ли публичный API площадки: если есть - бери API. Если API нет - открой карточку через управление браузером (например Playwright).
Не ставь фиксированные паузы (sleep) - используй auto-waiting: жди появления самого элемента с ценой. Бери устойчивые селекторы (по смыслу и видимому тексту), а не хрупкие автоклассы. Цену приведи к числу, наличие читай по тексту или состоянию кнопки.
Соблюдай этику: только публичные данные, уважай robots.txt, ставь паузы и лимит частоты, при капче остановись и не обходи защиту.
Ответ давай одной строкой: товар, цена в рублях, наличие, площадка и дату. Не смог считать цену - честно скажи и приложи ссылку, не выдумывай число.

Если ассистент скажет, что Playwright не найден - попроси его установить: pip install playwright && playwright install chromium (или npm install playwright). Без этого браузер не откроется, скил тут ни при чём.

Как понять, что заработало: кинь ассистенту ссылку на карточку товара и спроси “цена и наличие?”. Если он сам, без подсказок, откроет страницу, дождётся цены и ответит строкой с числом, наличием и датой - триггер поймался, скил живой. И ещё один нормальный, не ошибочный исход: ассистент упёрся в капчу или пустую страницу (особенно на Ozon и WB) и честно об этом сказал, а не выдумал число. Это значит, скил ведёт себя правильно - площадка просто не пустила, и так и должно быть. Дальше проси любой товар теми же словами.

И всё. Ты собрал браузерный скил для случая, когда нормального пути через API просто нет - и при этом не написал ни строчки кода руками и не превратился в “парсер-ферму”. Один раз описал правила - дальше ассистент сам решает, когда хватит API, а когда честно сходить в браузер.

Смотреть полностью

Коротко