Вайбкодинг для маркетплейсов

Зачем статья:

• Хочу поделиться примером применения AI-агентов на практике, даже если не программируешь,

• Выделить очевидные ограничения вайбкодинга,

• Показать как достигнут результат в 1416 строк кода, автоматизация мониторинга 1500 файлов менее чем за 5 минут, интеграции с Telegram и GitHub Pages, и экономия сотен часов рутинной проверки,

• Чуть-чуть о важности бизнес-исследований.

Идея

Маркетплейсы с точки зрения покупателя мне понятны, а вот у продавца возникает масса вопросов: как выложить товар, как продавать, куда отправлять заказы. Начал изучать статьи Т-банка, проходить курсы и анализировать базы знаний Озона, Wildberries и Яндекс.Маркета. Пока пролистывал сотни страниц базы Озона (их, кстати, ~770 только для продавцов, не считая разделов по API, ПВЗ и зарубежной версии), заметил, что нет никакой отдельной рубрики или раздела с обновлениями. Нет ничего, что помогло бы быстро замечать изменения: ни подписки, ни рассылки, ни один из информационных каналов Озона не сообщает о мелких правках и обновлениях в базе знаний.

Вместо того чтобы анализировать, как другие решают эту проблему, я сел и начал делать свой продукт — инструмент, который автоматически находит и показывает различия в базе знаний Озон, сравнивая версии за сегодня и вчера.

Что на старте?

Знания и опыт

• По опыту работы проджект-менеджером разбираюсь в базовых процессах разработки и основах программирования;

• Интересуюсь нейросетями: отсюда есть понимание как формулировать промты и как использовать нейросети для решения прикладных задач;

• Из работы в «Золотой Короне» знаком с принципами интеграции через API и взаимодействием между системами.

Инструменты

• Несколько месяцев назад пробовал разрабатывать телеграм-ботов на Python, там и освоил Visual Studio Code;

• Работа в Экспобанке дала понимание возможностей и предназначения GitHub, после чего узнал о GitHub Copilot.

Так и сформировался мой базовый starter-pack для запуска проекта.

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

Как это реализовать?

Оставил выбор за GitHub Copilot, потому что:

• не хотелось отдавать деньги за идею, которая может не выгореть (не удастся написать код),

• удобно сразу запускать код (в отличие от Codex),

• терпимо с точки зрения работы с большим количеством файлов — разбил процессы на части.

Далее работа в формате вопрос-ответ с ChatGPT 4o или 4.1 либо в браузере, либо в самом Copilot. Надо было найти последовательно ответы на вопросы:

1. На каком языке программирования писать?

2. Чем он лучше, чем другие?

3. Какие самые популярные и удобные решения есть для каждого подпроцесса?

4. Найденное решение — лучшее?

К сожалению, итераций, за которые я задавал каждый из этих вопросов было не менее 10. То есть создавать код с нуля? либо с другими библиотека, архитектурой, либо вообще на другом языке приходилось до 10 раз.

Как этого избежать? Использовал промт: [описание идеи]+[помоги построить архитектуру процесса и выявить наиболее оптимальный путь к реализации процесса]

Понимание архитектуры нельзя аутсорсить нейросети, потому что «лучших» и «оптимальных» решений множество — а значит AI может переписывать код и предлагать альтернативы бесконечно — это бесполезно, если ни одно из решений не попробуешь. Поэтому сам для себя изучал вопрос за вопросом:

Инсайт: для такого рода вопросов стоит включать/выключать search, причем в разных чатах — ответы часто были разными, GitHub Copilot редко производит поиск сам, поэтому предпочтительнее браузерная версия

Так я выбрал node.js для реализации захода в браузер для большинства процессов: краулера, который обходит все страницы https://seller-edu.ozon.ru/ и парсера, который сохраняет снэпшоты страниц, а затем и процесса сравнения.

Разберу на примере парсера шаг за шагом как создавался код:

1. Создать MVP — не нужно парсить все 770 страниц. Надо попробовать спарсить одну, тогда запрос:

Напиши код, который будет открывать браузер, заходить на сайт https://seller-edu.ozon.ru/, сохранять HTML-файл со всеми исходными стилями в папку D:\Projects\MarketUpd

2. Тестируем результат кода, смотрим нет ли подсвеченных ошибок. Если есть — решаем их с помощью агента. Ошибок закончились — идем дальше.

3. Теперь «масштабируем» технологию:

Дополни код так, чтобы открывались все страницы из списка файла D:\Projects\MarketUpd\sites_ozon.txt, каждая строчка — это ссылка. Сохраняй результат каждого скачивания в отдельную подпапку. Подпапку называй по последним двум сегментам URL, если сегментов меньше двух, то пиши root\единственный сегмент.

4. Допиливаем фичи:

Дополни код так, чтобы при сохранении HTML-файла сохранялся только блок div class = document, наименование каждого файла сделай «дд-мм-гггг_title страницы»

5. Добавляем логи:

Дополни код так, чтобы формировался файл с подробным логированием каждого действия по пути D:\Projects\MarketUpd\log

Иногда приходилось переписывать каждый шаг, менять подход и корректировать промт. Это основной минус вайбкодинга — ты видишь только результат, а залезть в процесс и сам разобраться не можешь, потому что у тебя нет для этого компетенций.

Например, основные процессы парсинга и сравнения претерпели следующие изменения:

1. Сначала это был код на Python, который парсил не HTML, а создавал PDF-файлы, заходя в браузер. Затем уже работал со сравнением PDF — оказалось, что это в разы тяжелее, потому что PDF имеет неочевидную структуру.

2. Переписал код на Node.js, пробовал сохранять скриншоты, думая, что результат распознания будет качественнее. Затем сравнивал скриншоты. Но чтобы качественно распознать отдельные блоки текста, списком, заголовков и семантически их объединить — потребовалось уйма запросов, а результат был печальным. К тому же скриншоты формировались некорректно.

3. Переписал код на формат сохранения HTML — сохранялся только текст, без оформления. Читать было невозможно.

4. Снова вернулся к PDF.

5. Небольшой чилл, чтобы все обдумать. И потом эврика — надо же просто попросить сохранить все стили. Вновь вернулся к сохранению HTML и все заработало!

Инсайт: если вы не уверены как описать что вам нужно — используйте примеры. Например, первый раз я не мог понять почему коду не удается распознать дату из наименования. Тогда я написал: …вот пример наименования файла «11-07-2025_Карантин цен»… И агент сразу понял, что даты изначально искались с видом 11.07.2025 вместо 11-07-2025. Иногда это огромные примеры — это тоже подойдет

Кратко расскажу про результат каждого этапа:

1. Краулер (tree_crawler.js) — использую все данные своего личного браузера, а также дополнений обхода защиты, чтобы сайт Озона пустил меня в браузере с помощью Puppeter. Затем поиск на каждой странице ссылок, из которых формируется список, удаляются дубликаты и происходит рекурсивный обход каждой. Так может делать с любым сайтом. Вторым этапом происходит сравнение файла с ссылками за сегодня со вчерашним. Новые или удаленные ссылки добавляются выделяются для отслеживания апдейтов.

2. Парсер (parcer_html.js) — открывает каждую найденную с помощью краулера страницу в браузере (puppeter) и затем сохраняет html, обрабатывает его.

3. Сравнение (compare.js) — запрашивает у пользователя даты, которые надо сравнить в терминале, затем производит сравнение и формирует комбинированный файл с встроенным интерфейсом для удобного просмотра. Пример есть тут. После сравнения страницы публикуются в GitHub Pages и становятся доступными для просмотра (тут тоже было непросто настроить взаимодействие по ssh, но нейросеть помогла разобраться)

   

4. Отправка в телеграм-канал постов. Создан бот, который добавлен как админ в канал. И написан код, который собирает изменения за сегодня и в нужном форматировании публикует пост (sender.py) — тут решил не париться, все изначально работало на питоне, так и оставил.

Что меня обрадовало:

• Действительно код работает и это удалось сделать не разбираясь в программировании.

• Разобраться в любой теме можно с помощью нейросети, поиска в гугле и вдумчивого понимания ответов.

• Многие задачи реализуются чрезвычайно быстро — сравнение происходит за 4 минуты, а обрабатывается ~1500 файлов — это круто, когда думаешь о том, что самостоятельно даже не смог бы найти мелких различий.

Минусы всей работы кода:

• Он работает только локально. Была попытка переноса на VPS, мне удалось разместить все необходимые файлы на рег.ру, но по результатам исполнения кода я не смог обойти защиту Озона от ботов и парсеров, имитировав свой личный браузер.

• Есть ещё над чем поработать в сравнении — можно улучшить способ сравнения и его логику

• Длительность — краулер работает около 40 минут, а парсер — 1 час 20 минут. Остальной код исполняется за минут 5, потому что не имеет задержек, необходимых для обхода защиты сайта Озон.

Итого:

• 7 дней (около 70 часов) вайбкодинга

• 1416 строчек кода

• 2 интеграции (с Telegram API и GitHub Pages)

• Куча радости от маленьких побед — тут рил, когда что-то работает уже радуешься, потому что:

• ~28000 суммарно запросов и ~14 бесплатных аккаунтов использовано суммарно

Этот опыт полезен, но важнее другое — вся проделанная работа не имеет смысла, т. к. 18.07.2025 вышла новость от Озон, что они будут развивать рубрику «Что нового в базе знаний» и вся ценность, получаемая от продукта исчезла. Это можно было исследовать, расспросить продавцов о их нуждах и болях, и возможно тогда было бы понятно, что это не проблема, а лишь закрытие собственной нужды. Далее буду применять опыт с более обширным исследованием. Также буду рад передать продукт для применения в других сферах/сайтах