Схема автоматизации

Черновики описаний товаров из таблицы

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

Проверено 24 августа 2026 годаСгенерированный текст является черновиком. Характеристики, обещания и юридически значимые формулировки проверяет редактор.
СложностьБазовая
Состав связкиGoogle Sheets или Excel + автоматизация + ИИ
РезультатЗаголовок, краткое и полное описание в отдельных столбцах
Рамка внедрения

Цель и граница автоматизации

Что меняем

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

Где останавливается ИИ

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

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

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

Владелец, журнал и критерий готовности

До технической настройки назначьте одного владельца сценария «Черновики описаний товаров из таблицы». Он утверждает справочники, определяет допустимые исключения и решает, когда результат «Заголовок, краткое и полное описание в отдельных столбцах» можно использовать дальше. Администратор конструктора отвечает за доставку и права, а владелец процесса - за смысл полей и решение человека. Эти роли могут выполнять разные сотрудники.

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

До запуска модели

Какие входные данные подготовить

Идентификатор товара

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

Характеристики

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

Шаблон категории

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

Стоп-слова

Юридически значимые обещания, неподтвержденные превосходные степени и запрещенные формулировки проверяются до публикации.

Проверяемый результат

Что должно появиться на выходе

01

Заголовок

Собирается из разрешенных полей в установленном порядке и не заменяет отдельные атрибуты каталога.

02

Краткий текст

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

03

Полное описание

Структурируется под категорию и остается в отдельной колонке до редакторского статуса.

04

Список пробелов

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

До рабочих данных

Контрольные примеры для пилота

Тест 1

Передать две похожие модели с разной комплектацией.

Тест 2

Удалить обязательный материал и проверить остановку.

Тест 3

Добавить запрещенное обещание в свободный комментарий.

Тест 4

Повторно обработать отредактированную строку.

Маршрутизация

Правила решений и остановки

  1. Остановить строку без SKU или обязательного свойства.
  2. Не перезаписывать текст со статусом редактора.
  3. Направить регулируемую категорию в отдельный маршрут.
  4. Публиковать только значение с явным статусом утверждения.
Пример задания

Что передать модели

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

Создай описание товара только по переданным полям. Не добавляй сертификаты, гарантии, свойства, размеры и сценарии применения, которых нет в данных. Верни title, short_description, benefits и full_description.

Логика процесса

Как работает сценарий

01

Найти новую строку

Триггер берет строки со статусом Готово к черновику и уникальным идентификатором товара.

02

Проверить характеристики

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

03

Сгенерировать структуру

ИИ возвращает заголовок, краткое описание, преимущества и полный текст в заранее заданном формате.

04

Записать черновик

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

05

Проверить и утвердить

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

Перед включением

Проверочный список

У каждого товара есть уникальный идентификатор
Обязательные характеристики проверяются до ИИ
Ответ записывается в отдельные столбцы
Повторный запуск не создает новый черновик
Запрещенные обещания указаны в инструкции
Публикация требует статуса редактора
Где нужен контроль

Основные риски

01

Модель может добавить правдоподобное, но отсутствующее свойство.

02

Повторная обработка способна перезаписать ручную редактуру.

03

Товарные знаки и регулируемые категории требуют отдельной проверки.

После запуска

Какие показатели отслеживать

Фактические исправления

Считайте добавленные или удаленные свойства отдельно от стилистической редактуры.

Карточки с пробелами

Метрика показывает качество исходного каталога и помогает работать с поставщиками.

Время до утверждения

Учитывайте ожидание данных отдельно, чтобы не приписывать его генерации текста.

Практические вопросы

Что уточнить перед внедрением

Можно ли делать уникальный текст для каждого SKU?

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

Кто отвечает за факты?

Редактор и владелец товарных данных. Модель формирует черновик и не становится источником характеристик.

Официальная документация

Источники