Первая сборка редко бывает финальной: за ней начинается цикл правок, и на него уходит заметная часть времени и генераций. Расплывчатое «сделай получше» даёт результат, который снова приходится переделывать. Ниже — как формулировать правки, чтобы ИИ-команде не приходилось угадывать задачу, как группировать изменения, разумно расходовать лимит и в какой момент правку проще отдать разработчику.
Как устроен редактор: чат слева, превью справа
В редакторе Roboweb две части: слева чат с ИИ-командой, справа превью проекта. Вы пишете правку обычными словами, команда вносит изменения, превью показывает результат. Первое описание продукта — отдельная тема, ей посвящена статья о том, как описать продукт для ИИ-команды. Здесь речь о следующем этапе — доработке того, что уже собрано.
Перед первой правкой пройдите проект как посетитель:
- прочитайте первый экран так, будто видите его впервые;
- нажмите на каждую кнопку и пройдите по всем пунктам меню;
- заполните форму, в том числе с ошибками — с пустым полем, с неполным телефоном;
- если есть каталог и корзина — добавьте товар и дойдите до оформления заказа;
- если есть личные кабинеты — зарегистрируйтесь и войдите.
Всё, что заметили, записывайте списком в заметки, а не отправляйте в чат по мере обнаружения. Список понадобится, чтобы сгруппировать правки.
Формула хорошей правки: что, где, каким должно стать и зачем
Хорошая правка отвечает на четыре вопроса: что изменить, где это находится, каким оно должно стать и зачем это нужно.
- Что — конкретный элемент: кнопка, заголовок, раздел, поле формы.
- Где — страница и место: «в первом экране главной», «в карточке товара», «в подвале».
- Каким должно стать — результат, который можно увидеть и проверить в превью.
- Зачем — цель. Она помогает выбрать решение, когда вариантов несколько, и не сломать то, что работало.
Примеры правок до и после:
- Плохо: «Кнопка какая-то не такая». Хорошо: «В первом экране главной сделай кнопку „Оставить заявку“ заметнее: контрастный цвет, крупнее текст. Сейчас она сливается с фоном, и на телефоне её не замечают».
- Плохо: «Добавь цены». Хорошо: «После раздела „Услуги“ добавь раздел с ценами: три пакета, у каждого название, цена „от“, три-четыре пункта состава и кнопка заявки. Нужно, чтобы клиент понимал порядок цен до звонка».
- Плохо: «Сделай красивее». Хорошо: «В разделе „Как мы работаем“ шаги идут одной длинной колонкой. Разложи их в ряд карточками на компьютере и оставь столбиком на телефоне, чтобы раздел не растягивался на несколько экранов».
Визуальные и функциональные правки: разные формулировки
Визуальные
Описывают, как элемент выглядит и где стоит. Они срабатывают лучше, когда вы:
- ссылаетесь на то, что уже есть в проекте: «такого же цвета, как кнопка в шапке»;
- говорите, что должно стать главным, а что второстепенным;
- отдельно упоминаете телефон, если проблема заметна именно там;
- не используете термины, в значении которых не уверены: простое описание надёжнее.
Функциональные
Описывают поведение: кто что делает и что после этого происходит. Их удобнее всего писать сценарием. Пример: «Посетитель на странице услуги нажимает „Записаться“. Открывается форма: имя, телефон, выбор услуги из списка. Все поля обязательные. После отправки заявка сохраняется, посетитель видит сообщение „Спасибо, мы перезвоним“, форма очищается».
В функциональной правке назовите:
- Кто действует — посетитель, зарегистрированный пользователь, сотрудник.
- С какими данными — какие поля и какие из них обязательные.
- Что происходит после действия и что видит человек.
- Что должно случиться при ошибке — пустое поле, неверный формат.
Функциональную правку проверяйте сценарием целиком, а не взглядом на превью. После публикации по ссылке отправьте тестовую заявку и убедитесь, что она появилась в разделе «Заявки с проектов». Если правка по сути автоматизирует рутину — заявка вместо звонка, личный кабинет вместо переписки, — полезно сначала решить, какие процессы важнее; об этом статья об автоматизации рутины.
Сколько правок в одном запросе
Правило простое: связанные изменения — вместе, несвязанные — по отдельности.
Связанные касаются одного места и должны быть согласованы между собой. Например, для раздела с тарифами: порядок карточек, тексты, выделение основного варианта и кнопки. Если разбить их на четыре запроса, каждый следующий может разойтись с предыдущим.
Несвязанные — это разные места и разные задачи: цвет подвала, новое поле в форме, текст на странице «О компании». Отправленные одним сообщением, они усложняют проверку: если что-то пошло не так, трудно понять, какая часть запроса к этому привела.
Ещё несколько правил:
- большое изменение — новый раздел или страницу — просите в два шага: сначала структура, потом детали;
- противоречия снимайте до отправки: «сделай строже» и «добавь ярких акцентов» в одном запросе тянут в разные стороны;
- если результат не устроил, не пишите «переделай», а объясните, что именно не так и каким оно должно быть.
Генерации и пакеты энергии: как расходовать лимит разумно
Сборка и правки в редакторе расходуют лимит генераций. На бесплатном тарифе «Пробный» их 10 разово, на Премиуме за 990 ₽ в месяц — 30 ежемесячно. Эти числа указаны для стандартного режима: в нём одна генерация списывает 1 единицу, а в усиленном режиме для сложных проектов («Максимум» в редакторе) — 9. Если лимита не хватило, докупаются пакеты энергии:
| Пакет | Цена |
|---|---|
| 12 запросов | 490 ₽ |
| 25 запросов | 990 ₽ |
| 54 запроса | 1 990 ₽ |
| 145 запросов | 4 990 ₽ |
Что помогает расходовать лимит бережно:
- собирайте правки в список и отправляйте продуманными группами, а не по одной мысли за раз;
- формулируйте по формуле «что — где — каким — зачем»: самая затратная правка та, которую приходится переделывать;
- исправляя неудачный результат, уточняйте задачу, а не повторяйте исходную фразу;
- мелкие правки текста копите и отправляйте вместе, если они относятся к одному разделу.
Если пакеты приходится докупать каждый месяц, сравните итоговую сумму с тарифами Профи: младший из них стоит 1 990 ₽ в месяц за 60 запросов и до 5 проектов. Все варианты собраны на странице тарифов.
Когда правку проще сделать в коде руками
Правки словами удобны для структуры, текстов, внешнего вида и новых разделов. Но бывают ситуации, где разработчик в выгруженном коде справится быстрее и надёжнее:
- Точная подгонка. Нужен конкретный отступ или особое поведение элемента, а после двух уточнённых запросов результат всё ещё не тот.
- Нестандартная логика. Расчёты с множеством условий, особые правила доступа, связка с вашими внутренними системами.
- Проверка перед запуском. Ревью безопасности, типов данных и производительности — работа человека, который читает код.
- Своя команда разработки. Если продукт дальше ведут программисты, им удобнее работать в репозитории со своими процессами.
Разработчик может забрать готовый каркас на Next.js + Prisma и дорабатывать код руками — экспорт доступен на тарифе Премиум. Что оказывается внутри архива и с чего начать, разобрано в статье о структуре экспорта.
Одно предупреждение: после ручных доработок код живёт своей жизнью в вашем репозитории. Решите заранее, где основная версия продукта, чтобы не вести две параллельные — одну в редакторе, другую у разработчика.
Следующий шаг: откройте свой проект, пройдите его как посетитель и запишите пять правок по формуле «что — где — каким — зачем». Связанные отправьте одним запросом, остальные — по одной.
