Как создать приложение с помощью ИИ: от идеи до первого релиза

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

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

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

Один и тот же сценарий можно реализовать в разной форме:

• веб-приложение открывается по ссылке и подходит, когда важен быстрый доступ через браузер;

• Telegram-бот подходит для последовательного диалога, команд и уведомлений внутри мессенджера;

• мобильное приложение уместно, когда сценарий зависит от возможностей устройства, отдельной установки или поведения, которое трудно получить в выбранном браузере или боте.

Это не рейтинг форматов. У каждого варианта будут свои ограничения, публикация и поддержка. Поэтому выпишите действия человека и отметьте, какие из них требуют камеры, геолокации, фоновой работы, локального хранения или уведомлений. Затем проверьте, что действительно нужно первой версии. Желание видеть иконку на экране телефона само по себе не объясняет выбор мобильной разработки.

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

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

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

В учебном трекере сценарий выглядит так:

1. Пользователь открывает форму новой тренировки.

2. Выбирает дату и вводит длительность.

3. Сохраняет запись.

4. Видит ее в истории.

5. Закрывает приложение, запускает снова и находит ту же запись.

Это уже вертикальный срез. Он соединяет интерфейс, правило проверки, хранилище и повторный запуск. Экран без сохранения не завершает сценарий. База без способа добавить и прочитать запись тоже не дает пользовательского результата.

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

Отдельно решите, где живут данные. Локальное хранение подходит для учебной версии на одном устройстве. Синхронизация между устройствами уже потребует сервера, доступа пользователя, передачи данных и обработки сетевых ошибок. Это не «небольшая настройка», а новый слой проекта. Его можно добавить позже отдельным вертикальным срезом.

У формы есть не один внешний вид. Она бывает пустой, заполненной, отправляющей данные и показывающей ошибку. История бывает пустой и содержащей записи. Для каждого состояния подпишите, что видит человек и что он может сделать дальше.

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

Ручные проверки записывайте как последовательность действий и наблюдаемый ответ. «История работает» проверить нельзя. «После повторного запуска в истории есть запись с выбранной датой и длительностью» уже задает приемку.

До начала генерации соберите короткую спецификацию:

• одно предложение с действием и результатом;

• список полей и правил;

• состояния формы и истории;

• место хранения данных;

• пять ручных проверок;

• список функций, отложенных после первой версии.

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

Спецификация описывает продукт, но агенту нужен еще и контекст проекта. Сохраните исходники в репозитории и добавьте README с командами установки, запуска и проверки. GitHub Docs показывает базовую работу с репозиторием, файлами и коммитами. Здесь коммит нужен не для отчета о занятости, а как принятая точка, к которой можно вернуться.

Первый запрос к агенту может выглядеть так:

Изучи существующий проект и README. Нужно добавить форму учебной тренировки с полями «Дата», «Длительность» и «Заметка». Пока не меняй файлы. Сначала опиши текущее устройство проекта, предложи минимальный план и перечисли файлы, которых коснется изменение.

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

Полезный цикл состоит из пяти действий:

1. Выберите один пункт спецификации.

2. Попросите агента предложить изменение и способ проверки.

3. Выполните изменение.

4. Запустите записанные проверки и посмотрите ошибки.

5. Просмотрите затронутые файлы и сохраните принятый результат коммитом.

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

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

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

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

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

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

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

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

Для учебного трекера пройдите как минимум такие случаи:

• создайте запись с допустимой датой и длительностью;

• оставьте обязательное поле пустым и проверьте сообщение;

• введите недопустимую длительность и исправьте ее без повторного заполнения формы;

• закройте приложение полностью, откройте снова и найдите запись;

• создайте несколько записей и проверьте их порядок в истории;

• перезапустите устройство или эмулятор и повторите основной сценарий.

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

Добавьте проверки, связанные с особенностями проекта. Если есть сервер, посмотрите поведение при медленной или недоступной сети. Если используются уведомления, проверьте разрешение, отказ от него и повторный запуск. Результат записывайте как действие, ожидание и наблюдение. Это позволит отличить воспроизводимую ошибку от общего впечатления «иногда ломается».

В официальном руководстве Android по подготовке релиза отдельно перечислены настройка приложения, создание и подпись релизной сборки, а также ее тестирование. Значит, команда запуска из среды разработки не заменяет релизный файл. Запишите в README точную команду сборки, место результата и способ установить его на тестовое устройство. Ключ подписи не храните в репозитории.

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

Первую версию можно передать ограниченной группе через выбранный тестовый контур и собрать обратную связь до публичной страницы. Если вы идете в App Store, сверяйтесь с текущими App Review Guidelines. В официальном списке перед отправкой есть проверка сбоев, полноты метаданных, доступа к аккаунту для ревью и работоспособности бэкенда.

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

Разрыв между прототипом и релизом проходит через несколько дисциплин: постановку задачи, контроль изменений, работу с данными, сборку, сервер и защиту секретов. Если хочется пройти этот маршрут на собственном проекте с общей логикой, а не собирать его по разрозненным подсказкам, программа курса «Вайбкодинг на максималках» включает работу с Codex, Git и GitHub, Docker, базой данных, деплоем и защитой секретов. Мобильное приложение указано на лендинге как один из возможных проектов, а не как гарантированный результат для любого брифа.

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

Передача сборки тестовой группе завершает подготовку релиза и открывает отдельный этап: поддержку установленной версии.

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

Для каждого замечания сохраните:

• версию сборки и модель устройства;

• действие перед проблемой;

• ожидаемый результат;

• фактический результат;

• снимок экрана или текст ошибки, если они есть;

• возможность повторить проблему.

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

Учебный трекер можно считать готовым к первому тестовому релизу, когда:

1. Один пользователь создает корректную запись и видит ее после повторного запуска.

2. Неверный ввод не очищает заполненную форму и сопровождается понятным сообщением.

3. Чистая установка проходит без ручных настроек среды разработки.

4. Релизная сборка создается по записанной инструкции.

5. Исходники соответствуют отдельному принятому коммиту, а секреты не находятся в репозитории.

6. Известен способ получить сообщения об ошибках и передать следующую сборку тестовой группе.

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

Начните с одного предложения: «Пользователь делает [действие], приложение сохраняет [данные] и после [проверки] показывает [результат]». Ниже перечислите поля, состояния, пять ручных проверок и то, чего пока не будет. Затем создайте репозиторий, сохраните исходное запускаемое состояние и отдайте агенту только первый пункт.

Так идея получает не набор экранов, а маршрут до версии, которую можно установить, проверить и улучшить по конкретному наблюдению.