Почему сборка не получилась: причины и что делать

Почему сборка не получилась

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

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

Что означает «сборка не получилась» на самом деле?

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

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

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

Какая причина стоит за каким симптомом?

Таблица собрана по тому, что люди пишут в первом сообщении после неудачной сборки. Слева симптом их словами, справа то, что обычно лежит в основе.

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

Почему один общий промпт даёт средний результат?

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

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

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

Когда чинить правкой, а когда собирать заново?

Считается арифметикой. Правка стоит 3 кредита, сборка 6. Пока исправлений одно или два, правка выгоднее. Начиная с трёх подряд дешевле переписать описание и собрать заново, и результат обычно выходит цельнее, чем залатанный.

Есть и содержательный признак. Правьте, когда общая идея верна и мешают детали: текст, порядок блоков, лишний раздел. Пересобирайте, когда неверна сама постановка: не тот тип проекта, не та аудитория, не то целевое действие. Правками фундамент двигается дорого и с компромиссами.

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

Как собрать вторую попытку, чтобы она попала?

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

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

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

Полезный приём для тех, у кого вторая попытка тоже не попала: возьмите один из 25 готовых шаблонов (пять из них игровые) и правьте его вместо сборки с нуля. Шаблон задаёт структуру, которая заведомо работает, и дальше остаётся заменить содержание на своё. Это заметно короче, чем пытаться описать структуру словами с третьего раза.

Когда дело не в описании, а в границах?

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

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

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

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

Что сделать прямо сейчас с неудачной сборкой?

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

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

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