Фильтры товаров на сайте связывают с данными каталога, а агенты проверяют сочетания параметров

Заказ фильтра начинается с карты полей. Для каждой характеристики нужно указать источник, единицу измерения и поведение при пустом значении.

Поставщик пишет мощность в ваттах, другой в киловаттах. В фильтре оба значения должны попасть в одну шкалу; агенту передают правило перевода вместе с примерами из выгрузки.

Повторить подписи чекбоксов недостаточно. Если поля уже разошлись между модулями, пригодится приём из разбора технического долга: одно правило преобразования и проверка его применения.

Возьмём учебный каталог насосов. В нём четыре модели и шесть вариантов; все данные ниже придуманы для объяснения и не описывают магазин клиента.

Каждая карточка представляет модель, а цена и наличие относятся к варианту. Наше условие приёмки: выбранные параметры должен выполнять один и тот же вариант.

В документации Shopify фильтры соединяются через «И», а значения одного фильтра через «ИЛИ». Для нашего задания это значит «220 или 380 В» вместе с заданной мощностью и наличием.

Н2 нельзя показать по сочетанию «220 В и 2,2 кВт». У этой модели есть оба значения, но у разных вариантов. Именно такую ошибку проверка каждой галочки отдельно пропустит.

Н4 не подходит под заданную мощность. Отсутствующее значение нельзя заменять нулём или считать совпадением; при снятом условии по мощности модель снова участвует в отборе.

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

Число над выдачей должно описывать все подходящие карточки в категории. Считать только загруженную страницу опасно: остальная часть каталога ещё не попала на экран.

Число возле значения требует отдельного определения. Оно может показывать результат после выбора или число совпадений с остальными условиями; договорённость записывают до вёрстки.

Algolia обновляет значения и счётчики вместе с результатом запроса. На больших индексах счётчик бывает приближённым; его точность нужно учитывать при показе и приёмке.

Ценовая граница тоже требует соглашения. В справке Tilda на 7 октября 2026 для ценового фильтра указан допуск ±1%.

В её примере диапазон 100–1 000 ₽ возвращает товары от 99 до 1 010 ₽. Это заданное поведение платформы; для собственного фильтра допуск или точные границы выбирают отдельно.

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

Агенту можно поручить подготовку сценариев и кода проверок. Но список правильных товаров должен опираться на контрольные данные, а не на ответ того же фильтра.

Перебор растёт быстро. В упрощённой модели шесть фильтров по десять значений дают 10⁶, то есть 1 000 000 сочетаний; это арифметика примера, не объём задания вашему магазину.

Попарные сочетания сокращают перебор, но не гарантируют полноту. NIST предупреждает об этом прямо; важные для бизнеса сочетания проверяют независимо от выбранного способа покрытия.

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

В правилах для агентов стоит закрепить запрет подгонять ожидаемые ответы под новую реализацию. Если правило меняется, сначала согласуют новые примеры.

Решение о выпуске остаётся у ответственного за магазин. Порядок проверки и отката нужен заранее: ошибка фильтра способна спрятать продаваемые товары.

На vibecoding.ru инженер ведёт машину агентов. Она строит сайт с каталогом и лентой; собственного клиентского кейса товарного магазина у нас нет.

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

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

В магазин переносится способ работы. Для поля мощности нужен один перевод единиц; для результата нужен эталонный набор, а для ошибки загрузки отдельное состояние.

Контрольный набор берут из вашего каталога. Туда должны попасть товары с пропусками и варианты с разными остатками; проверка только на аккуратных демонстрационных карточках этих случаев не увидит.

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

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

Подписка на агентную разработку «Один проект» стоит 250 000 ₽ в месяц на 7 октября 2026. Это один продукт и один поток работы, а не цена отдельного фильтра.

Такой формат имеет смысл при очереди доработок магазина. Для разовой настройки штатного фильтра сначала проверьте возможности вашей платформы.

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

Следующий результат работы нужно назвать заранее. Кроме фильтров это счётчики, сохранение выбранных параметров и протокол с найденными расхождениями.

Оценить готовность команды к такому заказу поможет тест для руководителя. После него легче обсуждать, кто задаёт правила и кто принимает результат.

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

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

Найденное расхождение возвращается в задачу и становится новой проверкой. Так следующий импорт каталога проверяют уже с учётом прошлой ошибки.

1. Свяжите параметры с полями каталога, задайте единицы, границы цены и поведение пропусков.
2. Согласуйте наборы правильных товаров, включая пустой результат и совпадения у разных вариантов одной модели.
3. Поручите агенту повторяемые проверки; сравнивайте идентификаторы, счётчики и результат по сохранённой ссылке.
4. После обновлений каталога возвращайте расхождения в задачи и добавляйте проверку на каждый разобранный случай.