Привет. Я давно заметил одну простую штуку: карточка товара начинает продавать лучше, когда она собрана не “на вдохновении”, а из нормальных исходников — таблицы характеристик, честных фото и реальных вопросов покупателей. ИИ тут не заменяет голову, а превращает рутину в конвейер: забирает данные, дописывает смысл, держит формат и не даёт развалить структуру.
Я у себя в мастерской делаю так: сначала нормализую таблицу, потом прогоняю фото через vision-модель, отдельно вытаскиваю FAQ, а уже после этого через n8n собираю заголовок, описание, блок преимуществ, характеристики и ответы на частые вопросы. В статье покажу схему, промпт, контроль качества и чек-лист перед выгрузкой.
Сразу скажу главное: если хочешь автозаполнение карточек маркетплейса, то не корми модель хаосом. Чем чище таблица характеристик товара, чем аккуратнее фотографии и чем ближе FAQ к реальным вопросам клиента, тем меньше потом ручной правки. Это и есть вся соль.
Содержание
- Почему связка таблица + фото + FAQ реально работает
- Как выглядит схема в n8n
- Как подготовить исходники
- Что писать модели и какой формат ответа требовать
- Пошаговый workflow
- Что должно выйти на выходе
- Где обычно начинаются косяки
- Чек-лист перед публикацией
- FAQ
Почему связка таблица + фото + FAQ реально работает
Когда карточку пишут с нуля руками, автор почти всегда плавает между двумя крайностями. Либо получается сухой набор полей, либо начинается рекламный стендап, а полезной конкретики кот наплакал. Таблица характеристик держит факты, фото добавляют визуальный контекст, а FAQ подтягивает живой язык клиента. Вот на этом стыке и рождается нормальная карточка.
Таблица отвечает за точность: размеры, материал, состав, вес, комплектацию, совместимость, ограничения по использованию. Фото помогают модели понять форму, фактуру, цвет, элементы конструкции и сценарий применения. FAQ закрывает возражения: “подойдёт ли для…”, “как ухаживать…”, “что внутри коробки…”, “есть ли запах…”, “насколько жёсткий материал…”. Когда я свожу эти три слоя вместе, получается не абстрактный текст, а контент, который реально помогает выбрать товар.
Плюс такой сборки ещё и в том, что генерация описания товара из характеристик становится управляемой. Ты не надеешься на фантазию модели, а задаёшь ей коридор. Для маркетплейса это важно: площадки любят структуру, покупатель любит ясность, а продавец любит когда карточки выпускаются пачкой, а не по одной штуке в полдня.
Как выглядит схема в n8n
У меня рабочая схема обычно собирается из шести узловых кусков. Первый принимает исходники: строку из Google Sheets, CSV, Airtable или Data Table внутри самого n8n. Второй чистит поля: единицы измерения, пустые значения, дубли в характеристиках, кривые заголовки колонок. Третий блок прогоняет фото через анализ изображения. Четвёртый вытаскивает и нормализует FAQ. Пятый идёт в LLM с жёстким требованием вернуть JSON по схеме. Шестой валидирует результат и либо кладёт карточку в выгрузку, либо шлёт на ручную проверку.
В свежих версиях n8n мне нравится то, что тут уже есть нормальные кирпичики под такую сборку: OpenAI node для текста и анализа изображения, Information Extractor для вытаскивания структуры из входящих кусков текста, Structured Output Parser для ответа по JSON Schema и Evaluation node для проверки того, насколько ответ вообще держится заданных правил. Короче, городить монстра из случайных костылей уже не надо.
Если исходники прилетают извне по вебхуку, очень советую сразу держать под рукой материал про защиту вебхуков и дублей запросов. А если хочешь потом замерять качество ответов модели, пригодится разбор про метрики AI Evaluations в n8n.
Как подготовить исходники
Таблица характеристик
Самая частая беда тут смешная и грустная одновременно: продавец даёт таблицу, где в одной колонке “Материал”, в другой “Состав”, в третьей “Ткань/основа”, а внутри то слова, то артикулы, то полполя пустое. ИИ такое переварит, но результат будет гулять. Я сначала привожу таблицу к одной логике: одно поле — один смысл. Если есть размер, то только размер. Если есть комплектация, туда не надо подмешивать преимущества.
Ещё совет из практики: держи отдельно обязательные характеристики и отдельно маркетинговые заметки. Например, “вес 430 г” — это факт. А “удобно брать в дорогу” — это уже интерпретация. Когда эти вещи лежат в разных колонках, карточка товара через ИИ и n8n получается заметно чище.
Фото
Фотографии нужны не только для красоты. Модель по ним хорошо вытаскивает видимые детали, но только если снимки честные: нормальный свет, понятный ракурс, крупные планы на фурнитуру, фактуру, разъёмы, швы, упаковку, комплектацию. Я обычно даю минимум четыре изображения: главный ракурс, бок, деталь и фото в использовании. Для маркетплейса ещё важно, чтобы основное фото читалось сразу и не было перегружено лишними декоративными штуками.
Когда фото слабые, начинается веселуха: модель додумывает то, чего нет, путает оттенки, неправильно понимает материал. Поэтому я всегда делаю маленький этап QA: vision-модель возвращает список того, что она уверенно увидела, и список того, в чём сомневается. Сомнения не идут в карточку автоматически.
FAQ
FAQ — это золото, если он собран из реальных вопросов, а не выдуман “для объёма”. Я обычно беру вопросы из чатов поддержки, отзывов, комментариев под товаром, почты отдела продаж и заметок менеджеров. Потом через n8n их схлопываю: похожие формулировки объединяю, мусор отбрасываю, а на выходе оставляю 5–8 нормальных вопросов. Именно они дают тексту ту самую приземлённость, которую покупатель считывает за секунды.
Кстати, если ты пока не решил, где хранить все эти промежуточные данные, посмотри моё сравнение внутренних таблиц n8n и Google Sheets. Для карточек это реально полезный выбор, потому что от него зависит, насколько легко потом обновлять сотни SKU.
Что писать модели и какой формат ответа требовать
Мой принцип простой: не просить “сделай красиво”, а давать модели роль, входные данные, рамки и чёткий формат. Я прошу вернуть JSON с конкретными полями: title, short_description, bullets, attributes, faq, seo_snippet, image_alt, image_title, warnings. Плюс отдельно пишу, что нельзя придумывать характеристики, которых нет в таблице и которые не подтверждаются фото или FAQ.
Ещё я добавляю пару жёстких правил. Первое: если поле пустое, модель должна поставить null, а не выдумывать. Второе: если фото и таблица спорят между собой, приоритет у таблицы, а конфликт улетает в warnings. Третье: если вопрос из FAQ касается того, чего нет в данных, модель пишет короткий нейтральный ответ и помечает это место как требующее проверки. Такой режим резко снижает количество дичи в готовой карточке.
Для массовой сборки это вообще must-have. Когда ты делаешь описание товара по фото и характеристикам на десятках позиций, ручное вылавливание фантазий модели начинает бесить уже на третьем товаре. А жёсткая схема ответа сильно экономит нервы.
Пошаговый workflow: как я это собираю
1. Забор строки товара
Старт может быть разный: Form Trigger, Webhook, cron по таблице, обновление в базе. Я люблю вариант, где есть отдельный статус “готов к генерации”. n8n забирает строку только по этому статусу, чтобы не цеплять сырые черновики.
2. Нормализация полей
Дальше Code node или Set node приводит данные к единому виду. Граммы в граммы, сантиметры в сантиметры, пустые ячейки в null, списки в массивы. Тут же удобно раскладывать комплектацию и преимущества по разным полям. Если этого не сделать, модель потом смешает половину всего в один абзац.
3. Анализ фото
Через анализ изображения я прошу вернуть видимые свойства товара, заметные детали, цветовую палитру, упаковку и сценарии использования. Это не заменяет карточку, а даёт вторую линию фактов. Если у тебя товар визуально сложный, этот шаг очень выручает.
4. Сбор FAQ
На этом этапе я или беру готовый список вопросов, или прогоняю массив сообщений через Information Extractor, чтобы собрать чистый блок “вопрос → короткий ответ”. Хорошая практика — хранить FAQ отдельно от основной карточки, чтобы потом обновлять его по новым обращениям.
5. Генерация карточки
Теперь всё это уходит в LLM. В промпте я прошу собрать заголовок, краткое описание, 5–7 буллетов, таблицу атрибутов для выгрузки, блок FAQ и микро-SEO. На выходе сразу требую JSON. Через Structured Output Parser или валидацию по схеме видно, где модель сорвалась с формата.
6. Проверка и ручной стоп-кран
После генерации я делаю пару проверок: длина заголовка, пустые поля, повторяющиеся буллеты, конфликт между фото и таблицей, наличие предупреждений. Если что-то не сходится, карточка не летит дальше автоматически. Она падает в очередь на человека. Вот тут очень в тему моя заметка про ручную контрольную точку для ответов ИИ.
7. Запись результата
Готовую карточку я складываю обратно в таблицу, CMS, базу или в очередь на публикацию. Если массивы идут в Google Sheets, не забывай правильно раскладывать их по строкам и колонкам, иначе таблица потом поедет и начнётся грязная ручная правка.
Что должно выйти на выходе
Нормальный результат — это не один текстовый кирпич, а набор готовых частей, которые удобно загрузить в карточку:
-
заголовок — короткий, предметный, с видом товара и ключевой особенностью;
-
краткое описание — одна ёмкая подводка, что это и кому подходит;
-
буллеты — выгоды и важные факты читаемыми кусками;
-
характеристики — чистый структурированный блок для выгрузки;
-
FAQ для карточки товара — ответы на реальные вопросы покупателей;
-
alt и title изображения — чтобы контент потом нормально лег в WordPress или другую CMS;
-
служебные предупреждения — где нужна ручная проверка.
Когда всё это собирается в одном проходе, у тебя появляется уже не просто черновик, а почти готовый пакет данных. Дальше можно докрутить соседние процессы. Например, после публикации пустить в работу автоответы на вопросы о товарах через Telegram и n8n, чтобы FAQ пополнялся живыми формулировками, а не стоял мёртвым блоком месяцами.
Где обычно начинаются косяки
Первый косяк — грязные характеристики. Второй — фото, где половина товара в тени, а вторая блестит так, будто это реквизит из каталога люксового декора. Третий — попытка выжать из ИИ окончательную истину, хотя исходники сами себе противоречат. Четвёртый — желание выпускать карточки сразу в прод минуя промежуточную проверку. Пятый — отсутствие нормальных статусов у товара: сыро, на проверке, готово, опубликовано, требует уточнения.
Ещё частая проблема — смешивать SEO, фактологию и стиль в одном абзаце. Я делаю проще: сначала собираю факты, потом выгоды, потом вопросы покупателей, а уже после этого связываю всё в читаемый текст. Такая последовательность здорово спасает, когда нужно генерация карточек товаров не для одного товара, а для целого ассортимента.
Чек-лист перед публикацией
-
У каждого товара есть чистый ID и понятный статус.
-
В таблице нет дублей характеристик с разным смыслом.
-
Фото дают общий вид, детали и сценарий использования.
-
FAQ собран из реальных обращений, а не выдуман на бегу.
-
Модель возвращает JSON по схеме, а не свободный поток текста.
-
Конфликты между таблицей и фото уходят в предупреждения.
-
Карточка проходит ручную проверку на первых партиях.
-
Для обновлений есть отдельный workflow, а не ручное редактирование всего массива.
Вот и весь рабочий рецепт. Не самый глянцевый, зато живой: таблица даёт точность, фото добавляют контекст, FAQ приносит голос покупателя, а n8n склеивает всё это в конвейер. Когда один раз нормально настроишь схему, дальше карточки начинают собираться заметно бодрее, а правки уже идут не по каждому слову, а по делу.
FAQ
Можно ли собирать карточки только по таблице характеристик?
Можно, но текст будет суше, а часть полезных деталей потеряется. Фото и FAQ делают карточку живее и точнее.
Нужен ли отдельный промпт под каждую категорию товаров?
Лучше держать общий каркас и отдельные блоки правил по категориям. Так проще масштабироваться и обновлять логику.
Стоит ли сразу публиковать карточку после ответа модели?
На старте я так не делаю. Сначала проверяю выборку руками, смотрю где модель врёт, и только потом отпускаю часть потока в автоматическую публикацию.
Что делать, если FAQ постоянно меняется?
Хранить его отдельным слоем данных и пересобирать только нужные части карточки. Так быстрее и чище, чем переписывать весь товар целиком.