# Как проектировать функцию с ИИ: от задачи, а не от модели

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

Published: 2025-02-21 · Source: https://subxcat.com/ru/articles/designing-ai-features · Author: SUBXCAT

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

Ниже — порядок, в котором стоит думать, прежде чем писать первый промпт.

## Начни с работы, а не с возможности

Сформулируй, что человек пытается сделать и что ему сейчас мешает. Не «сгенерировать описание товара», а «выложить сорок новых товаров до пятницы, не тратя вечер на тексты». Разница кажется косметической, но она меняет решение.

Во втором варианте сразу видно:

- нужна пакетная обработка, а не кнопка у каждого товара;
- важна скорость проверки, а не красота одного текста;
- человек всё равно будет читать результат — значит, его нужно показать удобно для правки.

Если задачу не получается сформулировать без слова «ИИ», возможно, её нет.

## Проверь, нужна ли тут модель вообще

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

Хороший тест: попробуй описать правильный ответ для десяти реальных входов. Если ответы выводятся простой логикой — пиши логику. Если для каждого нужно «понять, что имелось в виду», — это работа для модели.

## Определи провал до того, как начнёшь

Самый недооценённый шаг. Модель будет ошибаться — вопрос в том, как именно и чего это стоит. Ответь письменно:

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

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

## Решай, кто нажимает последнюю кнопку

Есть три режима, и их стоит выбирать осознанно:

- **подсказка** — модель предлагает, человек решает. Подходит почти всегда на старте;
- **черновик** — модель делает, человек проверяет перед отправкой;
- **автомат** — модель делает сама, человек видит результат постфактум.

Автомат уместен только там, где ошибка дешёвая и обратимая. Сортировка входящих по папкам — да. Ответ клиенту от имени компании — нет, пока не накопишь уверенности на реальных данных. Переход от подсказки к автомату — это решение по фактам, а не по ощущению, что «вроде работает».

## Запасной путь к человеку

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

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

Если без модели продукт перестаёт работать целиком, у тебя не функция, а единая точка отказа.

## Запиши, как поймёшь, что это работает

До запуска договорись, что будешь смотреть: доля принятых без правок результатов, сколько правят, как часто нажимают «повторить», сколько людей возвращаются к функции через неделю. Не нужно сложной аналитики — достаточно пары событий в логах. Главное — смотреть на поведение, а не на восторги в демо.

## Итог

Хорошая функция с ИИ — это обычная продуктовая функция, в которой одна часть вероятностная. Задача, критерий провала, кто принимает решение и что происходит при сбое — четыре вопроса, ответы на которые стоит записать до первого промпта. Модель потом поменяется, а эти ответы останутся.

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