ИИ сделал не то? Возможно, проблема была в ТЗ

Знакомая ситуация.

Просишь ИИ сделать калькулятор или бота. Получаешь результат, открываешь — и первая мысль:

«Это вообще не то, что я имел в виду».

Самая простая реакция — обвинить модель.

Но в реальной разработке я всё чаще сначала возвращаюсь к собственному ТЗ.

Когда ИИ делает не то, что вы ожидали, в 80% случаев проблема не в модели — проблема в ТЗ. ИИ опирается на то, что мы описали. Если требования размыты, модель вынуждена сама заполнять пробелы — и её интерпретация легко расходится с нашей.

Для меня эти 80% — не статистика, а рабочая оценка по собственным задачам.

Вот три примера из последних проектов.

Ошибка 1. «Сделай калькулятор» без деталей

Можно попросить ИИ сделать калькулятор бетона.

Он вполне логично соберёт форму:

длина × ширина × толщина = объём.

Технически задача выполнена.

Но реальному инструменту понадобилось больше.

Разные единицы измерения.

Отдельный запас, который пользователь задаёт сам.

Показ подстановки чисел в формулу.

Корректная работа с десятичной запятой и точкой.

Копирование результата вместе с исходными размерами.

И даже правило, при котором маленький положительный объём не превращается на экране в ноль из-за округления.

Ничего из этого ИИ не обязан угадывать.

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

Ошибка 2. «Управляй заявками» без исключений

С СБРботом та же история.

Фраза «сделай Telegram-бота для управления заявками» естественно ведёт к счастливому пути:

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

Но реальный процесс оказался шире.

Ремонт выполнен.

Клиент отказался без оплаты.

Клиент отказался от ремонта, но оплатил диагностику.

Это три разных финала одной заявки.

Если их нет в ТЗ, система не знает, какой статус поставить, нужно ли считать деньги и какой следующий шаг вообще допустим.

Самое сложное начинается после слов «клиент отказался».

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

Ошибка 3. «Сделай красиво» без проверки расчётов

ИИ может собрать аккуратный интерфейс и при этом ошибиться там, где внешний вид ничего не покажет.

В калькуляторе пришлось отдельно проверять расчёты и округление.

В СБРботе — корректность финансовой логики распределения.

Если этап проверки отсутствует в самом плане работы, красивый интерфейс создаёт опасную иллюзию готовности.

Поэтому сейчас в ТЗ я стараюсь обязательно фиксировать пять вещей:

1. Точную задачу.
Что именно должна сделать система, а не общее название функции.

2. Исключения и альтернативные маршруты.
Что происходит, когда процесс идёт не по счастливому пути.

3. Формулы и правила расчёта.
Не заставлять модель угадывать бизнес-логику.

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

5. Этап проверки.
Как понять до публикации, что система делает именно то, что требовалось.

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

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

ТЗ — это и есть значительная часть этой работы.

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

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

И довольно часто проблема находится именно там.

А у вас бывало, что ИИ сделал всё буквально по запросу — но совсем не то, что вы ожидали?

Первоначальная публикация: TenChat.