AI-конструктор с AI-функциями: что есть, а чего нет

Здесь надо разделить две разные вещи. Zugo сам собран вокруг модели: вы описываете проект текстом, и он появляется. А вот готовой интеграции, которая встраивает работу с языковой моделью внутрь вашего продукта, в списке подключений нет. Такие функции добавляются через экспорт кода в GitHub и подключение своего провайдера.

Чем «AI, который собирает» отличается от «AI внутри продукта»?

Путаница возникает из-за одного слова в двух ролях, и она стоит людям недель.

Первая роль: модель как инструмент сборки. Вы пишете «сайт студии йоги с расписанием и формой записи», и через минуту получаете работающие страницы. Модель здесь работает на этапе создания, а в готовом проекте её нет: сгенерированный сайт это обычный код, который открывается у посетителя без всякого обращения к нейросети.

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

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

Какие интеграции у Zugo есть на самом деле?

Список конечный, и честнее назвать его целиком, чем описывать общими словами.

Интеграция	Что она даёт проекту
Supabase	База данных, вход пользователей, хранение файлов
Stripe	Приём оплаты и подписки
GitHub	Экспорт исходников в ваш репозиторий
Vercel	Деплой проекта на ваш аккаунт хостинга
Resend	Отправка писем от проекта
Свой домен	Постоянный адрес вместо имя.zugo.run
Google Analytics	Статистика посещений в вашем аккаунте

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

Как тогда добавить AI-функцию в свой проект?

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

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

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

Затем разработчик добавляет обращение к выбранному провайдеру. Ключ хранится на стороне сервера, а не в коде страницы: ключ, попавший в браузер, публичен по определению, и его находят чужие люди быстрее, чем вы успеваете это заметить.

Наконец, проект разворачивается на вашей инфраструктуре, например через Vercel. Как устроена выгрузка кода, подробно разобрано в статье про экспорт приложения в GitHub.

Что можно сделать без модели внутри продукта?

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

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

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

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

Правило простое: модель в рантайме оправдана там, где ответ нельзя заранее посчитать, потому что он зависит от произвольного ввода пользователя. Всё остальное дешевле сделать один раз.

Какие ожидания от «AI внутри» чаще всего не оправдываются?

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

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

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

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

«Никто не будет злоупотреблять». Будут. Открытая функция, обращающаяся к платному провайдеру, привлекает автоматические запросы, и без ограничений счёт растёт без всякой пользы для вас.

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

Сколько это стоит?

Разделим два кошелька, потому что их постоянно смешивают.

Работа в конструкторе считается в кредитах. Сборка стоит 6 кредитов, правка 3, многостраничная платформа 12 за первые три страницы и по 3 за каждую следующую. Режим Hi-Fi вдвое дороже: сборка 12, правка 6. Бесплатный тариф даёт 5 кредитов, Pro стоит $25 в месяц за 200 кредитов, Business стоит $99 в месяц. Двести кредитов это 33 быстрых сборок или 16 полных платформ.

Работа модели внутри вашего продукта считается отдельно и оплачивается провайдеру, которого выберет разработчик. Эти расходы зависят от числа обращений, а значит растут вместе с аудиторией. Заложите их в экономику продукта заранее: функция, которая нравится всем и стоит доли цента за вызов, при росте становится основной статьёй расходов.

Как проверить идею до того, как писать код?

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

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

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

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

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

Где проходит честная граница?

Три вещи стоит назвать прямо.

Готовой кнопки «добавить AI-помощника» в конструкторе нет. Если вам её обещают, речь идёт о другом продукте, и лучше уточнить это до оплаты.

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

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

Что делать дальше

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

Если после этого модель внутри продукта всё ещё нужна, выгружайте код и подключайте провайдера с разработчиком. Что уже есть из готового, разобрано в соседних статьях: Supabase для базы и входа и Stripe для оплаты. Собрать первую версию и проверить объём оставшейся работы можно на zugo.dev.