ИИ как функция внутри прототипа

Пользователь продукта нажимает «Сгенерировать описание товара». Это совсем не то же самое, что открыть отдельную вкладку с ChatGPT. Приложение само, из своего кода, отправляет запрос к API модели (тема «Модели ИИ», тема «Софт: чат, плагин, API, агент») с уже готовым, заранее продуманным промптом. Потом получает ответ и показывает его прямо в интерфейсе продукта, без единого лишнего клика. Пользователь может вообще не подозревать, какая конкретно модель стоит за кнопкой. Для него это просто ещё одна функция приложения.

• Текстовый ИИ внутри интерфейса — автогенерация описаний, подсказки при заполнении формы, суммаризация длинного текста, встроенный чат-помощник. Технически агенту нужно передать четыре вещи: какую модель вызывать, какой system prompt зашить в код, что показывать, пока ответ ещё не пришёл, и главное — где живёт API-ключ (об этом ниже). System prompt здесь тот же, что в теме «Фундамент», только теперь пишет его не пользователь чат-бота, а сам продукт. Бывает, что сценарий не укладывается в один вызов модели и требует нескольких шагов подряд. Например: «сначала разбери запрос пользователя, потом реши, какой из трёх инструментов вызвать, потом оформи ответ». Для этого существуют graph-фреймворки (например, LangGraph). Они описывают многошаговый сценарий не как один большой промпт, а как схему из шагов и переходов между ними, где каждый шаг — отдельный, проверяемый узел. Собирать это самому не обязательно. Полезно знать другое: за фразой разработчика «у нас сложный ИИ-сценарий с несколькими шагами» на схеме обычно стоит такой граф, то есть управляемая последовательность, а не один большой промпт. Подробно про уровни «один агент — конвейер — граф» и типовые схемы — в теме «Своя обвязка».
• Изображения на лету — генерация аватара, вариаций дизайна, обложки прямо в потоке работы пользователя, без похода во внешний генератор изображений.
• Голос и распознавание — голосовой ввод вместо печати, надиктовка заметки, распознавание объекта на загруженном фото. Здесь работают те же принципы TTS/STT и мультимодальности, что и в темах «Генерация голоса и аудио» и «Фундамент». Разница в том, что они встроены внутрь продукта, а не живут отдельной функцией чат-бота.

Исходное фото

Плоская иллюстрация

Глина

Акварель

Мягкое 3D

Промпт

Turn this portrait into a profile avatar in [flat illustration / clay / watercolor / soft 3D] style, keep facial features and pose, plain background, square

• Состояние ожидания. Ответ модели приходит не мгновенно. Нужен явный индикатор «генерирую», иначе замёрзший интерфейс выглядит как поломка.
• Что показать, если модель ошиблась или не ответила. Это прямое продолжение принципа graceful failure из темы «Принципы дизайна ИИ-продуктов». Нужен понятный fallback, а не пустой экран.
• Где живёт ключ. В фронтенд-прототипе (Lovable, одиночный HTML, артефакт) агент по умолчанию впишет API-ключ прямо в браузерный код. Любой, кто откроет страницу, заберёт его и будет тратить твои деньги. Вдобавок Anthropic API по умолчанию блокирует запросы из браузера (CORS), так что кнопка может не заработать вовсе. Правило одно: ключ только на сервере — в serverless-функции, Supabase Edge Function или API-роуте. Сам ключ лежит в переменной окружения, файл .env внесён в .gitignore, а в консоли провайдера выставлен месячный лимит расходов. Подробнее — в теме «Безопасность вайбкодинг-проекта».
• Стоимость каждого вызова. В личном чате есть лимит сообщений (тема «Тарифы и лимиты»). Здесь каждое нажатие кнопки пользователем стоит владельцу продукта реальных денег через API. Подробный разбор чуть ниже.
• Доверие и разметка результата. Если результат сгенерирован ИИ и показан как есть, явно обозначь это в интерфейсе. Выдавать его за обычный контент продукта нельзя (см. тему «Этика, приватность и ограничения», принцип маркировки ИИ-контента).

Когда продукт сам обращается к API модели, платит за это не пользователь, а владелец продукта: по токенам на входе и выходе (тема «Тарифы и лимиты», глоссарий). Разница с личным чатом принципиальная. Там стоимость размазана по месячной подписке и незаметна. Здесь каждый клик по кнопке — конкретная, посчитаемая сумма, которая напрямую влияет на прибыльность продукта.

Простой пример на пальцах. Короткий вызов текстовой модели (промпт плюс ответ на пару абзацев) стоит доли цента: у Claude Haiku 4.5 и Sonnet 5.5 по ценам на октябрь 2026 это десятые доли цента за одну генерацию. Сумма кажется незаметной, пока не умножить её на масштаб. 1000 пользователей, каждый нажимает кнопку «Сгенерировать» в среднем 5 раз в день. Это уже 5000 вызовов в день. При условной цене в полцента за вызов за месяц набегает реальная сумма. Её лучше заложить в стоимость продукта заранее, чем обнаружить постфактум в счёте от провайдера. Генерация изображений и особенно видео стоит на порядки дороже одного текстового вызова (темы «Генерация изображений», «Генерация и монтаж видео»). Если ИИ-функция продукта генерирует картинки или видео, пересчитай юнит-экономику отдельно. Интуиция с текстовых моделей здесь подведёт.

Механика простая. Один раз прогони её на бумаге ещё до того, как агент начнёт писать код:

(стоимость одного вызова) × (сколько раз в среднем один пользователь вызывает функцию за период) × (число пользователей) = стоимость ИИ-функции для бизнеса за этот период

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

Добавь в форму создания товара кнопку «Сгенерировать описание»: по нажатию отправляй название и категорию товара в модель [модель]. Вызов модели — только через серверную функцию /api/generate; ключ берётся из переменной окружения и не попадает в клиентский код. Состояния: загрузка со спиннером, ошибка сети и таймаут 20 секунд с понятным текстом, пустой ответ. Результат вставляй в поле описания с возможностью отредактировать вручную. Прежде чем писать код, скажи, где у этого проекта будет жить серверная функция.

Придумай 3 места в приложении [описать продукт], где ИИ-функция реально решает задачу пользователя, а не добавлена просто чтобы был ИИ

Спроектируй состояние загрузки и состояние ошибки для кнопки "Сгенерировать с ИИ" — что видит пользователь в обоих случаях

Мы планируем разрешить безлимитную генерацию картинок в приложении. Модель: [название], цена одной картинки: [цена с сайта провайдера]. Активных пользователей — 1000 в месяц, в среднем [N] генераций на человека. Посчитай стоимость API в месяц и предложи разумный лимит. Считай только по моим цифрам, своих не добавляй

Без модели, цены и объёма модель назовёт цифру с потолка.

У нашего продукта тариф $10/мес, ИИ-функция — текстовая генерация, вызывается в среднем 8 раз на пользователя в месяц. Модель [название], цена [X] $ за миллион входных и [Y] $ за миллион выходных токенов, средний вызов — [N] токенов на входе и [M] на выходе. Посчитай примерную стоимость API на одного пользователя и скажи, какая доля тарифа уходит на эту функцию

Проверь этот экран с ИИ-функцией на маркировку: понятно ли пользователю, что результат сгенерирован, а не написан человеком