Как вывести прототип на базе AI в продакшен

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

Прототип и продакшен: что на самом деле меняется

У прототипа один внимательный пользователь: вы. Вы знаете, какие кнопки нажимать, вводите разумные данные, а если что-то ломается, пожимаете плечами и просите AI исправить. В продакшене много невнимательных пользователей, любопытных и изредка враждебных. Код не обязан стать «корпоративным»; ему нужно справляться с ситуациями, с которыми прототип никогда не сталкивается.

Остальная часть руководства проходит по каждой строке таблицы.

Шаг 1: Зафиксируйте объём и запишите основные сценарии

Прежде чем что-либо укреплять, решите, что такое первая версия. Выпишите три–шесть сценариев, которые важнее всего, — например, «регистрация, создание проекта, приглашение коллеги, оплата». Они станут вашим тестовым сценарием, целями мониторинга и тем, что вы проверяете после каждого изменения.

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

Шаг 2: Тестируйте как посторонний, затем сделайте проверку повторяемой

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

• Неверный ввод: пустые обязательные поля, имя из 5000 символов, email без @, отрицательное количество, дата в прошлом.
• Обновление страницы и кнопка «назад»: перезагрузите оформление заказа на полпути; нажмите «назад» после отправки формы. Не создаётся ли что-то дважды?
• Две вкладки, два пользователя: войдите под двумя разными аккаунтами и попробуйте открыть страницы друг друга, меняя ID в адресе.
• Медленно и на маленьком экране: экран размером с телефон и ограниченное соединение (в инструментах разработчика браузера его можно сымитировать).
• Пустые состояния: совершенно новый аккаунт без данных. Прототипы часто создаются с примерными данными и без них выглядят сломанными.

Затем сделайте проверку повторяемой. Минимум — письменный чек-лист, который вы проходите перед каждым релизом. Лучше — попросите AI написать автоматические тесты для самых важных сценариев:

Добавь автоматические сквозные тесты для этих сценариев: регистрация по email, создание проекта, приглашение второго пользователя и завершение оплаты в тестовом режиме Stripe. Также добавь тесты, которые подтверждают, что пользователь не может просмотреть или изменить проект другого пользователя, поменяв адрес в URL.

Тесты, которые доказывают, что пользователь не может что-то сделать, — именно то, чего чаще всего не хватает прототипам.

Шаг 3: Основы безопасности, которые пропускают прототипы

Большинство проблем безопасности в приложениях, созданных с помощью AI, не экзотические. Это отсутствующие проверки. Пройдите этот список и посмотрите более полный чек-лист безопасности для приложений, созданных с помощью AI:

• Авторизация на сервере. Скрытая кнопка — это не безопасность. Каждый запрос, который читает или меняет данные, должен проверять на сервере, что вошедший пользователь имеет на это право. Если ваше приложение использует базу данных с правилами на уровне строк, проверьте, что они включены и протестированы.
• Секреты вне браузера. API-ключи для платежей, email или AI-провайдеров должны храниться в серверных переменных окружения, а не в клиентском коде. Если непонятно, что это значит, прочитайте что такое переменные окружения и секреты.
• Валидация на сервере. Браузер можно обойти, поэтому повторите на сервере каждую важную проверку.
• Вход сделан правильно. Используйте хорошо проверенную библиотеку или сервис аутентификации, а не самописное хранение паролей. Наше руководство как добавить вход в приложение описывает варианты.
• Ограничение частоты запросов для входа, регистрации, сброса пароля и всего, что отправляет письма или вызывает платный API.
• Понятные ошибки. Пользователи должны видеть «что-то пошло не так»; подробности идут в ваши логи, а не на экран.
• Замените всё, что утекло. Если боевой ключ когда-либо вставлялся в чат, коммит или скриншот, замените его у провайдера.

Промпт, который покрывает сразу многое:

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

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

Шаг 4: Узнавайте о поломках — логи и мониторинг

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

1. Серверные логи. Убедитесь, что ошибки логируются с достаточным контекстом для воспроизведения: какой маршрут, ID пользователя (не пароль и не данные карты), форма входных данных. Если приложение только выводит сообщения в консоль, попросите AI добавить структурированное логирование.
2. Отслеживание ошибок. Сервис вроде Sentry или аналогичный инструмент собирает исключения фронтенда и бэкенда, группирует их и присылает вам уведомления. Для небольшого приложения бесплатных тарифов этих сервисов часто достаточно; актуальные лимиты смотрите на их сайтах.
3. Проверки доступности. Внешний сервис, который каждые несколько минут загружает главную страницу и один ключевой API-маршрут и оповещает вас, если они не отвечают. Так ловятся проблемы, из-за которых приложение вообще перестаёт писать логи.

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

Шаг 5: Резервные копии и путь назад

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

• Код. Храните проект в системе контроля версий, чтобы любое изменение можно было отменить. Многие AI-конструкторы сохраняют чекпоинты ваших файлов; синхронизация с Git-репозиторием даёт копию и вне конструктора.
• Данные. Откат кода не откатывает базу данных. Неудачная миграция или кнопка удаления с ошибкой могут уничтожить записи, которые никакой чекпоинт кода не вернёт.

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

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

Шаг 6: Производительность, которая держится на телефоне

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

• Загрузите данные реального размера. Попросите AI заполнить несколько тысяч записей и посмотрите, какие страницы тормозят. Списки обычно нуждаются в постраничном выводе, а база — в индексах по столбцам, которые вы фильтруете и сортируете.
• Уменьшите изображения. Слишком большие картинки — самая частая причина медленной загрузки страницы. Попросите изображения с изменённым размером и сжатием и ленивую загрузку ниже первого экрана.
• Измеряйте. Запустите Lighthouse в инструментах разработчика Chrome для живого URL в мобильном режиме. Разумные цели — Core Web Vitals от Google: Largest Contentful Paint в пределах 2,5 секунды, Interaction to Next Paint не более 200 мс и Cumulative Layout Shift не более 0,1.
• Следите за задержками «пробуждения». Хостинг, который засыпает без нагрузки, экономит деньги, но первый визит после тишины будет медленнее. Для нового приложения это часто разумный компромисс; просто знайте, что так происходит.

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

Шаг 7: Операционные основы

Несколько небольших вещей отделяют хобби-приложение от того, которому доверяют люди:

• Собственный домен с HTTPS. См. как подключить собственный домен.
• Транзакционная почта с подтверждённого домена для подтверждения регистрации и сброса пароля — описано в как отправлять письма из приложения.
• Политика конфиденциальности и условия, которые описывают, что вы на самом деле собираете. Не копируйте заявления о соответствии требованиям, которых вы не выполняете.
• Канал поддержки — хотя бы контролируемый адрес электронной почты.
• Отдельные тестовые и боевые ключи для платежей и почты и понятная запись о том, какая среда какой ключ использует.

Шаг 8: Аккуратная передача

Рано или поздно над приложением будет работать кто-то ещё: фрилансер, новый сооснователь или вы сами через полгода. Упростите это:

• README, где сказано, как запустить приложение, какие переменные окружения ему нужны (только имена, никогда не значения) и как его развернуть.
• Чек-лист основных сценариев и автоматические тесты.
• Краткое описание архитектуры: фронтенд, бэкенд, база данных, сторонние сервисы и где что размещено.
• Список доступа: кто имеет административный доступ к домену, хостингу, базе данных, аккаунтам платежей и почты. Держите эти аккаунты на рабочей почте, а не на личной.
• Код в Git, желательно синхронизированный с репозиторием, которым владеете вы. Если позже вы можете сменить хостинг, прочитайте как экспортировать приложение, созданное с помощью AI, и разместить его самостоятельно.

AI может составить большую часть этого за вас:

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

Чек-лист готовности к продакшену

• Основные сценарии записаны и протестированы, включая «нельзя получить доступ к чужим данным»
• Авторизация и валидация на сервере для каждого маршрута с данными
• Нет секретных ключей в клиентском коде; утёкшие ключи заменены
• Ограничение частоты запросов для входа и всего, что стоит денег
• Отслеживание ошибок и проверки доступности отправляют уведомления на почту, которую вы читаете
• Резервные копии базы хранятся вне хостинга приложения, и хотя бы одно восстановление проверено
• Постраничный вывод и индексы проверены на реалистичных данных
• Собственный домен, подтверждённый домен отправки, политика конфиденциальности
• README и список доступа для следующего участника

Работа с Mythex

Если вы создали прототип в Mythex, большинство этих шагов — это промпты в том же проекте. Введите /test, и Mythex пройдёт по живому предпросмотру как пользователь и сообщит о сломанных сценариях — см. App Testing. Ключи попадают в секреты проекта, а не в чат; каждый успешный ход агента сохраняет чекпоинт ваших файлов, к которому можно вернуться; публикация даёт живой URL с хостингом, а база данных оплачивается из того же баланса кредитов (лимиты хостинга объясняет, как приложения и базы засыпают и просыпаются). Чекпоинты охватывают файлы, а не строки базы данных, поэтому всё равно планируйте резервные копии данных. На плане Pro можно подключить собственный домен и экспортировать код или синхронизировать его с собственным репозиторием GitHub для передачи.

Вопросы