Почему ИИ «тупит» без ТЗ: Психология LLM и ошибка новичка
1.1. Главная ошибка новичка в вайбкодинге
Самая распространенная ошибка при попытке создать приложение с помощью ИИ — отправка обобщенного, абстрактного запроса.
Пример неэффективного запроса (НЕПРАВИЛЬНО): «Сделай мне сервис для бронирования столиков в ресторанах с авторизацией, личным кабинетом, оплатой и интерактивной картой».
Почему так делать нельзя (Причины и последствия):
1. Хаос в файловой структуре: ИИ не имеет жестких рамок и начинает создавать десятки пустых файлов и несвязанных модулей, пытаясь охватить все указанные функции одновременно. 2. Иллюзия работы и несовместимость: ИИ выбирает случайные библиотеки и архитектурные решения, которые часто не состыковываются друг с другом. Код выглядит объемным, но при запуске выдает каскад ошибок. 3. Невозможность локализации ошибок: Запрос сразу задействует сервер, UI, базу данных и внешние API. При возникновении ошибки вы не сможете определить, на каком именно слое произошел сбой. 4. Переполнение контекста: Из-за огромного объема сгенерированного за один раз кода нейросеть мгновенно исчерпывает лимит памяти, забывает начальные условия и начинает галлюцинировать.
Как нужно делать правильно:
Необходимо сначала сформировать текстовый документ ТЗ (PRD), зафиксировать границы MVP, а затем передавать задачи ИИ строго по одной через каскадный промптинг.
Пример правильного первого запроса (КАК НУЖНО): «На основе раздела 5 нашего файла @PRD.md создай статическую верстку главной страницы сервиса бронирования: шапка с логотипом и список из 3 тестовых карточек ресторанов. Пока не создавай базу данных, логику авторизации и систему оплаты. Выдай только визуальный каркас».
1.2. Аналогия: ИИ как гениальный, но дикий строитель
Представьте, что вы наняли строителя, который умеет возводить стены с молниеносной скоростью и знает все мировые строительные стандарты.
Неправильный подход:
Вы говорите строителю: «Построй мне красивый современный дом».
Почему так делать нельзя:
Строитель не станет задавать уточняющих вопросов. Не имея понимания ваших реальных потребностей, он выберет случайные стандарты из своей памяти. Завтра он заложит фундамент под трехэтажный замок, послезавтра решит, что вам нужен бассейн на крыше, а через неделю построит туалет посередине гостиной. Проект станет непригодным для жизни и перегруженным лишними конструкциями.
Как нужно делать правильно:
Передать строителю (ИИ) точную чертежную документацию (PRD): размеры комнат, этажность, список материалов и жесткие ограничения («дом строго 1-этажный, бассейн не строить, материал — брус»). ИИ должен выполнять работу поэтапно: сначала фундамент, проверка; затем стены, проверка; затем крыша.
1.3. Принцип минимальной неопределенности
Каждая абстрактная фраза в вашем запросе увеличивает количество вариантов реализации в геометрической прогрессии.
┌─────────────────────────────────────────────────────────┐ │ Запрос: «Добавь систему уведомлений» │ ├─────────────────────────────────────────────────────────┤ │ ИИ вынужден угадывать: │ │ • Уведомления по Email? Telegram? SMS? Push на экране? │ │ • Где хранить историю уведомлений? В базе данных? │ │ • В какой момент отправлять? При регистрации? Оплате? │ └─────────────────────────────────────────────────────────┘
Разбор подхода к добавлению функций:
НЕПРАВИЛЬНО: «Добавь систему уведомлений». ПОЧЕМУ НЕЛЬЗЯ: Запрос содержит максимальную степень неопределенности. ИИ сам выберет случайный транспорт (например, сложную рассылку через внешний SMS-шлюз), потребует ввода платных API-ключей и усложнит архитектуру там, где это не требовалось. КАК НУЖНО: «Добавь локальное всплывающее текстовое сообщение (Toast) «Столик успешно забронирован!» на экране при клике на кнопку «Забронировать». Уведомление должно плавно появляться в правом верхнем углу и автоматически исчезать через 3 секунды. Внешние сервисы отправки Email или SMS не использовать».
Главное правило вайбкодера: ТЗ — это инструмент устранения неопределенности. Чем меньше у ИИ поводов фантазировать, тем выше качество готового продукта.