Карточку товара на сайте собирают из единых данных, а агенты проверяют варианты и наличие

Что заказывать, если описание и кнопка покупки расходятся? Начните с карты полей. Разработчик должен показать, откуда карточка берёт каждое значение.

Каталог хранит характеристики, шаблон показывает их покупателю. Ручная копия цены в описании создаёт ещё одно место для обновления.

В учебном примере покупатель выбирает чёрный чайник. Карточка и корзина должны получить идентификатор чёрного варианта. Совпадение названий этого не доказывает.

Единые данные не требуют хранить всё в одной базе. Каждому полю назначают ответственную систему, а витрина получает согласованный набор значений.

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

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

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

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

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

Отсутствие остатка не всегда запрещает заказ. В Shopify возможность продажи отделена от наличия на складе. Магазин утверждает правило предзаказа.

Shopify предупреждает: один из способов обновить корзину не проверяет количество уже добавленного товара. Проверка добавления не покрывает этот шаг.

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

ИИ-агент готовит общий шаблон и проверки переходов. Решение о предзаказе, резерве и допустимой давности остатков принимает магазин вместе с инженером.

Начните с задачи с критерием готовности. Для чёрного чайника критерий конкретный: тот же вариант виден на странице и попадает в заказ.

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

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

Общий шаблон ещё не гарантирует полные данные. Мы встретили потерю поля при создании новости, а устаревшие сведения нашли при переделке карточки инструмента.

Карточка Gemini описывает ИИ-инструмент. В ней нет складского остатка или доставки. Из этой истории берём проверку свежести, а не опыт торговли.

Инженер ведёт машину агентов на vibecoding.ru. Ниже два её урока: один касается передачи данных, другой проверки фактов перед публикацией.

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

Работу нашей машины можно посмотреть на /open. Сам объём изменений не доказывает, что корзина магазина работает; это доказывает проверка выбранного товара.

Приёмка не заканчивается словом агента «готово». Инженер сверяет результат с правилами и принимает работу. Кто отвечает за ошибки агента, разобрано в соседней статье.

Начните с действующего шаблона и товара, на котором видна ошибка. Работа со старым кодом начинается с фиксации поведения.

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

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

Регулярные доработки действующего магазина можно вести по подписке «Один проект»: 250 000 ₽ в месяц, один продукт и один поток работы на 7 октября 2026.

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

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

После выпуска считайте расхождения вариантов и отказы заказа по причинам. Новая ошибка возвращается инженеру и становится новым сценарием проверки.