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

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

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

Что считать веб-приложением

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

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

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

Веб-приложение не становится нативным мобильным приложением только потому, что хорошо работает на телефоне. Публикация в App Store или Google Play требует отдельного процесса и не должна подразумеваться в задаче на браузерный продукт.

Как выбрать один сценарий для MVP

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

Пользователь, проблема и главное действие

Запишите три строки:

1. Пользователь: кто выполняет действие и в какой ситуации.
2. Проблема: что сейчас теряется, задерживается или требует ручной сверки.
3. Результат: какое наблюдаемое состояние должно появиться после действия.

Для мастерской пользователь не «любой бизнес», а менеджер, который принимает заказ по телефону. Проблема не «низкая эффективность», а отсутствие одного актуального статуса: сведения разбросаны по переписке и бумажным листам. Результат — заказ с ответственным, сроком и текущим этапом в общей доске.

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

Что сознательно отложить

Составьте список «не в первой версии». Он защищает MVP лучше, чем длинный список пожеланий. Для примера туда попадут:

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

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

Спроектировать экраны, роли и данные

Для первого прототипа достаточно нарисовать прямоугольники на бумаге. Каждый экран должен отвечать на один вопрос или поддерживать одно действие.

Опишите роли глаголами. Менеджер создает и редактирует заказ. Сотрудник видит назначенные заказы и меняет этап. Владелец видит все заказы и управляет участниками. Название роли без списка разрешений ничего не дает.

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

Подготовить промпт для WUNA

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

Создай браузерное веб-приложение для небольшой мастерской. Оно помогает команде видеть текущий этап каждого заказа.

Роли:
- менеджер создает и редактирует заказы;
- сотрудник видит назначенные ему заказы и меняет этап;
- владелец видит все заказы и управляет участниками.

Этапы заказа: новый, согласование, в работе, готов, выдан, отменен.

Данные заказа: номер, название, краткое описание, имя клиента, контакт, срок, этап, ответственный, дата создания и дата изменения.

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

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

Критерий первой версии: менеджер создает заказ, назначает сотрудника, сотрудник меняет этап, владелец видит изменение.

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

Собирать приложение по этапам

Интерфейс и навигация

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

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

Данные и авторизация

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

В WUNA можно использовать встроенную базу или подключить свою Supabase. Выбор зависит от объема, контроля и сложности проекта. Актуальные условия и ограничения нужно сверять в руководстве о том, как подключить данные.

Ошибки и пустые состояния

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

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

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

Тест-план перед публикацией

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

Основной и ошибочные сценарии

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

Затем проверьте ошибки:

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

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

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

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

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

Доступ, мобильная версия и производительность

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

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

Граница между прототипом, пилотом и рабочим запуском

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

Публикация, домен и экспорт

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

На дату подготовки статьи API, GitHub и экспорт исходного кода относятся к тарифу «Бизнес». Условия могут измениться, поэтому проверяйте тариф перед архитектурным решением. Если внешняя система должна получать данные, сначала определите формат обмена, авторизацию, лимиты и поведение при недоступности. Состав возможностей можно сверить в разделе о том, что доступно через API.

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

Ограничения AI-разработки и момент для специалиста

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

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

Частые вопросы

Можно ли создать приложение одним промптом?

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

Нужно ли уметь программировать?

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

Это будет мобильное приложение?

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

Как понять, что MVP готов?

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