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

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

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

Что найдете внутри:

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

27 промптов для разработчика мобильных приложений

1. Выбор архитектурного паттерна для нового приложения

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

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

Текст промпта:

*****

Ты – опытный архитектор мобильных приложений с глубокими знаниями паттернов проектирования.

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

Контекст проекта:
– Тип приложения: [опишите тип, например, “маркетплейс товаров” или “фитнес-трекер с офлайн-режимом”] – Платформа: [укажите платформу, например, “iOS на Swift” или “кроссплатформенное на Flutter”] – Размер команды: [укажите, например, “1 разработчик” или “команда из 4 человек”] – Планируемый масштаб: [опишите, например, “MVP на 3 месяца” или “долгосрочный продукт с активным развитием”] – Ключевые технические требования: [перечислите, например, “работа офлайн, синхронизация, push-уведомления”]

Сравни минимум 3 паттерна (например, MVP, MVVM, Clean Architecture или другие подходящие) по критериям:

1. Сложность входа и кривая обучения
2. Тестируемость кода
3. Масштабируемость при росте функциональности
4. Подходимость для указанного типа приложения

Формат ответа: таблица сравнения + финальная рекомендация с обоснованием в 3–5 предложениях. Укажи конкретные риски при выборе каждого паттерна. Избегай общих фраз – только конкретные аргументы применительно к описанному проекту.

*****

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

2. Составление технического задания на функцию приложения

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

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

Текст промпта:

*****

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

Задача: составь детальное техническое задание на разработку функции мобильного приложения.

Исходные данные:
– Название функции: [укажите, например, “авторизация через номер телефона” или “фильтрация товаров по категориям”] – Платформа: [укажите, например, “Android” или “iOS и Android одновременно”] – Краткое описание от заказчика: [вставьте описание, например, “пользователь должен входить по SMS-коду без пароля”] – Связанные функции: [перечислите, например, “профиль пользователя, корзина, история заказов”]

Структура технического задания:

1. Цель функции и ожидаемый результат
2. Пользовательские сценарии (минимум 3: основной, альтернативный, ошибочный)
3. Требования к интерфейсу (экраны, состояния, переходы)
4. Технические требования (API, хранилище, безопасность)
5. Критерии приемки – конкретные, проверяемые условия
6. Что явно выходит за рамки задачи

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

*****

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

3. Код-ревью фрагмента кода

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

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

Текст промпта:

*****

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

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

Фрагмент кода:
[вставьте код для проверки]

Платформа и язык: [укажите, например, “iOS, Swift 5.9” или “Android, Kotlin”] Контекст использования: [опишите, например, “метод загрузки данных из сети с кэшированием” или “обработчик нажатия в адаптере списка”]

Проверь код по следующим критериям:

1. Читаемость и соответствие принятым соглашениям по именованию
2. Потенциальные утечки памяти и проблемы с жизненным циклом
3. Обработка ошибок и граничных случаев
4. Производительность и лишние операции
5. Тестируемость кода
6. Безопасность (если применимо)

Формат: для каждой найденной проблемы – строка с проблемой, объяснение почему это проблема, исправленный вариант кода. В конце – общая оценка качества кода по шкале 1–10 с обоснованием. Не хвали без причины – только честный разбор.

*****

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

4. Оптимизация производительности экрана с длинным списком

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

Решение: Промпт дает пошаговый план диагностики и конкретные техники оптимизации под выбранную платформу.

Текст промпта:

*****

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

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

Описание проблемы:
– Платформа: [укажите, например, “Android с RecyclerView” или “iOS с UITableView” или “Flutter с ListView”] – Симптомы: [опишите, например, “список тормозит при быстрой прокрутке, особенно когда элементы содержат изображения”] – Количество элементов: [укажите, например, “от 50 до 500 элементов” или “бесконечная подгрузка”] – Что уже пробовали: [опишите, например, “добавили кэширование изображений, не помогло” или “ничего не пробовали”] – Текущая реализация (если есть): [вставьте ключевые фрагменты кода или опишите подход]

Дай ответ в структуре:

1. Диагностика: как найти узкие места (конкретные инструменты и метрики для указанной платформы)
2. Причины торможения: топ-5 типичных причин для данного случая с объяснением механизма
3. Оптимизации: конкретные техники с примерами кода, от простых к сложным
4. Проверка результата: как измерить улучшение в цифрах

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

*****

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

5. Проектирование навигации в многоэкранном приложении

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

Решение: Промпт помогает спроектировать логичную структуру навигации с учетом пользовательских сценариев и платформенных стандартов.

Текст промпта:

*****

Ты – UX-архитектор мобильных приложений с глубоким знанием платформенных рекомендаций по проектированию интерфейсов.

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

Параметры приложения:
– Тип и назначение: [опишите, например, “приложение для записи к врачу” или “личный финансовый трекер”] – Платформа: [укажите, например, “iOS” или “Android” или “обе платформы”] – Основные разделы: [перечислите, например, “главная, каталог, корзина, профиль, история”] – Целевая аудитория: [опишите, например, “люди 40–65 лет, не очень опытные в смартфонах” или “молодежь 18–30 лет”] – Ключевые пользовательские сценарии: [опишите 2–3 главных действия, например, “найти врача → записаться → получить напоминание”]

Предоставь:

1. Схему навигации (текстовое описание иерархии экранов с вложенностью)
2. Рекомендуемый тип навигации (нижняя панель, боковое меню, вкладки, стек) с обоснованием
3. Потенциальные проблемы выбранной структуры и как их избежать
4. Нестандартные переходы и модальные экраны – где использовать и почему
5. Что точно не стоит делать для данной аудитории

Тон: профессиональный, конкретный. Ссылайся на платформенные рекомендации (HIG для iOS, Material Design для Android) там, где это применимо.

*****

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

6. Написание автотестов для критической функции

Проблема: Автотесты пишутся в последнюю очередь или не пишутся вовсе – а потом регрессия обнаруживается уже после релиза.

Решение: Промпт генерирует набор тестов с покрытием основных, граничных и ошибочных сценариев под конкретную функцию.

Текст промпта:

*****

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

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

Параметры:
– Платформа и язык: [укажите, например, “Android, Kotlin, JUnit5 + Mockk” или “iOS, Swift, XCTest”] – Тестируемая функция: [опишите, например, “метод авторизации пользователя по токену” или “функция расчета итоговой суммы корзины со скидками”] – Код функции или ее описание: [вставьте код или подробно опишите логику] – Уже используемые зависимости: [перечислите, например, “Retrofit, Room, Coroutines” или “URLSession, CoreData”]

Напиши тесты, покрывающие:

1. Основной (счастливый) сценарий
2. Граничные значения входных данных
3. Ошибочные входные данные и некорректные состояния
4. Асинхронные операции (если применимо)
5. Зависимости от внешних сервисов (с применением заглушек)

Для каждого теста: название в формате “что тестируем – при каком условии – ожидаемый результат”, код теста, комментарий о том, почему этот тест важен. Код должен быть рабочим и следовать принятым соглашениям платформы.

*****

Почему это работает: Требование назвать тест в формате “что – при каком условии – результат” заставляет нейросеть писать читаемые, самодокументированные тесты. Явное перечисление типов сценариев исключает ситуацию, когда покрыт только счастливый путь.

7. Разработка схемы базы данных для офлайн-режима

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

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

Текст промпта:

*****

Ты – архитектор данных с опытом проектирования офлайн-режимов в мобильных приложениях.

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

Параметры проекта:
– Тип приложения: [опишите, например, “приложение для учета расходов” или “корпоративный мессенджер”] – Платформа и инструмент хранения: [укажите, например, “Android с Room” или “iOS с CoreData” или “Flutter с SQLite через drift”] – Основные сущности данных: [перечислите, например, “пользователь, транзакция, категория, счет”] – Логика синхронизации: [опишите, например, “данные синхронизируются при появлении сети, сервер всегда приоритетнее” или “конфликты разрешаются по последнему времени изменения”] – Ожидаемый объем данных: [укажите, например, “до 10 000 записей на пользователя”]

Предоставь:

1. Схему таблиц с полями, типами данных и связями
2. Поля для отслеживания состояния синхронизации (обязательно)
3. Стратегию обработки конфликтов с примерами
4. Индексы для оптимизации запросов
5. Типичные ошибки при проектировании офлайн-схем – чего избегать

Формат: схема в виде структурированного описания + пояснения к ключевым решениям.

*****

Почему это работает: Явный запрос полей синхронизации и стратегии конфликтов закрывает самые частые пробелы в проектировании офлайн-режима. Пункт про типичные ошибки превращает результат из схемы в готовое решение с защитой от известных граблей.

8. Написание документации к программному интерфейсу модуля

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

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

Текст промпта:

*****

Ты – технический писатель с опытом документирования мобильных SDK и библиотек.

Задача: напиши документацию к публичному программному интерфейсу модуля мобильного приложения.

Параметры:
– Платформа и язык: [укажите, например, “iOS, Swift” или “Android, Kotlin”] – Название модуля: [укажите, например, “NetworkManager” или “AuthService”] – Назначение модуля: [опишите в 1–2 предложениях, например, “отвечает за все сетевые запросы приложения с автоматическим обновлением токенов”] – Публичный интерфейс (код): [вставьте код класса/протокола/интерфейса]

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

1. Краткое описание назначения (1 предложение)
2. Описание каждого параметра с типом и допустимыми значениями
3. Описание возвращаемого значения
4. Возможные исключения или ошибки
5. Пример использования с кодом
6. Предупреждения о нетипичном поведении (если есть)

Используй стандарт документирования для указанного языка (DocC для Swift, KDoc для Kotlin). Тон: технический, точный, без лишних слов.

*****

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

9. Анализ и обработка отзывов пользователей из магазина приложений

Проблема: Сотни отзывов в РуСторе или AppStore читаются часами, а выводы из них делаются субъективно – кто-то замечает только хвалебные, кто-то – только критику.

Решение: Промпт структурирует анализ отзывов и превращает хаотичный поток мнений в приоритизированный список задач для команды.

Текст промпта:

*****

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

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

Исходные данные:
– Отзывы пользователей: [вставьте текст отзывов, можно скопировать из магазина приложений] – Тип приложения: [укажите, например, “приложение для доставки еды” или “образовательное приложение”] – Что интересует больше всего: [уточните фокус, например, “проблемы с производительностью” или “все категории равномерно”] – Период сбора отзывов: [укажите, например, “последние 30 дней после обновления версии 2.1”]

Структура анализа:

1. Распределение тональности (положительные / нейтральные / отрицательные) с процентами
2. Топ-5 тем, которые встречаются чаще всего – с примерами цитат
3. Критические проблемы, требующие немедленного внимания – с оценкой частоты упоминания
4. Скрытые запросы – что пользователи хотят, но не говорят прямо
5. Приоритизированный список задач для команды разработки (срочные / важные / желательные)

Формат: структурированный отчет с четкими выводами. Не пересказывай отзывы – только аналитика и выводы.

*****

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

10. Подготовка описания приложения для магазина

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

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

Текст промпта:

*****

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

Задача: напиши описание приложения для публикации в магазине.

Параметры приложения:
– Название: [укажите название приложения] – Категория: [укажите, например, “здоровье и фитнес” или “финансы”] – Магазин: [укажите, например, “РуСтор” или “AppStore” или “Google Play”] – Основная функция: [опишите главное, что делает приложение, в 1–2 предложениях] – Ключевые возможности: [перечислите 5–7 главных функций] – Целевая аудитория: [опишите, например, “молодые родители” или “малый бизнес”] – Главное конкурентное преимущество: [укажите, чем отличается от аналогов] – Ключевые слова для поиска: [перечислите, например, “учет расходов, бюджет, финансы, деньги”]

Напиши:

1. Короткое описание (до 80 символов) – цепляющий слоган
2. Полное описание (400–500 слов) со структурой: крючок → проблема → решение → возможности → призыв
3. Список из 5–7 пунктов с ключевыми возможностями (для раздела “Что нового” или маркированного блока)

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

*****

Почему это работает: Структура “крючок → проблема → решение → возможности → призыв” основана на проверенной логике убеждения, а не на интуиции. Разделение на короткое и полное описание закрывает сразу два формата, которые нужны при публикации.

11. Проектирование системы push-уведомлений

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

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

Текст промпта:

*****

Ты – эксперт по мобильному маркетингу и техническому проектированию систем уведомлений.

Задача: спроектируй систему push-уведомлений для мобильного приложения.

Параметры:
– Тип приложения: [опишите, например, “приложение для онлайн-обучения” или “сервис доставки”] – Платформа: [укажите, например, “iOS” или “Android” или “обе”] – Основные события для уведомлений: [перечислите, например, “новый урок, напоминание о занятии, достижение, комментарий преподавателя”] – Инфраструктура: [укажите, например, “Firebase Cloud Messaging” или “Яндекс Push” или “собственный сервер”] – Ограничения: [укажите, например, “нельзя отправлять между 22:00 и 8:00” или “пользователь сам выбирает типы уведомлений”]

Предоставь:

1. Категории уведомлений с приоритетами (критические / важные / информационные)
2. Логику управления частотой – как не задолбать пользователя
3. Персонализацию – какие данные использовать для таргетинга
4. Технические требования к реализации на указанной платформе
5. Метрики эффективности – что измерять и какие значения считать нормой
6. Типичные ошибки при запуске системы уведомлений

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

*****

Почему это работает: Запрос метрик эффективности переводит проектирование из режима “сделали и забыли” в режим измеримого результата. Пункт про управление частотой – это защита от главной ошибки, которую совершают при запуске уведомлений.

12. Разработка стратегии монетизации приложения

Проблема: Монетизацию добавляют в последний момент, не думая о совместимости с продуктовой логикой – и пользователи либо не платят, либо уходят.

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

Текст промпта:

*****

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

Задача: разработай стратегию монетизации для мобильного приложения.

Параметры:
– Тип и функция приложения: [опишите, например, “приложение для медитации и работы со стрессом”] – Целевая аудитория: [опишите, например, “работающие люди 25–45 лет, готовые платить за качество”] – Конкуренты и их модели: [опишите, что известно о конкурентах, например, “основные конкуренты работают по подписке 299 рублей в месяц”] – Текущая база пользователей: [укажите, например, “приложение новое, пользователей пока нет” или “10 000 активных пользователей в месяц”] – Ограничения: [укажите, например, “нет ресурсов на сложную техническую реализацию” или “магазин запрещает определенные модели”]

Предоставь:

1. Сравнение 3–4 подходящих моделей монетизации (подписка, разовая покупка, условно-бесплатная модель, реклама) с плюсами и минусами для данного случая
2. Рекомендуемую основную модель с обоснованием
3. Ценовые рекомендации с учетом российского рынка
4. Механику реализации – что конкретно платное, что бесплатное
5. Типичные ошибки при запуске монетизации в данной нише
6. Метрики для оценки успеха модели

Тон: аналитический, конкретный. Без фраз “зависит от ситуации” без объяснения, от чего именно зависит.

*****

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

13. Написание плана обработки ошибок в приложении

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

Решение: Промпт создает системный план обработки ошибок с классификацией и стандартизированными подходами для всего приложения.

Текст промпта:

*****

Ты – старший разработчик мобильных приложений с опытом проектирования надежных систем обработки ошибок.

Задача: создай план обработки ошибок для мобильного приложения.

Параметры:
– Платформа: [укажите, например, “Android” или “iOS” или “Flutter”] – Тип приложения: [опишите, например, “приложение с активной работой с сетью и локальной базой данных”] – Критические функции, где ошибка недопустима: [перечислите, например, “оплата, авторизация, сохранение данных пользователя”] – Текущий подход к ошибкам: [опишите, например, “try-catch в отдельных местах без единой системы” или “пока ничего нет”]

Создай план, включающий:

1. Классификацию ошибок (сетевые, ошибки данных, ошибки бизнес-логики, системные) с примерами каждой
2. Стратегию для каждого класса ошибок: что показывать пользователю, что логировать, что делать автоматически
3. Единый механизм перехвата ошибок для всего приложения (с примером кода для указанной платформы)
4. Сообщения об ошибках для пользователя – принципы написания с примерами (хорошо vs. плохо)
5. Систему журналирования ошибок – что фиксировать и куда отправлять
6. Тестирование обработки ошибок – как проверить, что все работает

Формат: структурированный документ, пригодный для использования как стандарт в команде.

*****

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

14. Анализ конкурентных приложений перед разработкой

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

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

Текст промпта:

*****

Ты – аналитик мобильного рынка с опытом конкурентного анализа приложений.

Задача: проведи структурированный анализ конкурентных приложений.

Параметры:
– Ниша: [укажите, например, “приложения для учета личных финансов” или “сервисы онлайн-записи к врачу”] – Список конкурентов для анализа: [перечислите 3–5 приложений, например, “Дзен-Мани, CoinKeeper, Toshl”] – Планируемое приложение: [опишите кратко, что планируется разработать] – Фокус анализа: [уточните, например, “хочу найти незакрытые боли пользователей” или “хочу понять, чем отличиться”]

Для каждого конкурента предоставь:

1. Основное ценностное предложение (в 1–2 предложениях)
2. Сильные стороны – что делают хорошо
3. Слабые стороны и жалобы пользователей (из отзывов в магазинах)
4. Модель монетизации и ценовая политика

Общие выводы:
5. Незакрытые потребности пользователей – что все конкуренты делают плохо
6. Возможности для дифференциации – где можно выиграть
7. Функции-ловушки – то, что кажется нужным, но не дает преимущества

Формат: таблица для сравнения конкурентов + текстовые выводы. Конкретика, без общих слов.

*****

Почему это работает: Пункт “функции-ловушки” защищает от одной из самых дорогих ошибок – копирования конкурентов в тех местах, где они сами ошибаются. Это неочевидный угол анализа, который большинство пропускает.

15. Составление плана выпуска обновления приложения

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

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

Текст промпта:

*****

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

Задача: составь план выпуска обновления мобильного приложения.

Параметры релиза:
– Платформа: [укажите, например, “iOS (AppStore)” или “Android (Google Play и РуСтор)”] – Что входит в обновление: [перечислите, например, “новая функция авторизации через Госуслуги, исправление 3 критических ошибок, обновление дизайна главного экрана”] – Текущая версия: [укажите, например, “версия 3.2.1”] – Целевая дата выхода: [укажите, например, “через 2 недели”] – Размер команды: [укажите, например, “1 разработчик и 1 тестировщик” или “команда из 5 человек”]

Составь план, включающий:

1. Подготовка к релизу (что проверить за неделю до отправки)
2. Требования к описанию обновления для магазина
3. Тестирование перед отправкой – минимальный набор проверок
4. Поэтапный выкат (если применимо) – как снизить риски
5. Мониторинг после релиза – что смотреть в первые 24–48 часов
6. План отката – что делать, если что-то сломалось

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

*****

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

16. Проектирование системы аналитики в приложении

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

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

Текст промпта:

*****

Ты – аналитик продукта с опытом проектирования систем сбора данных в мобильных приложениях.

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

Параметры:
– Тип приложения: [опишите, например, “приложение для онлайн-записи к специалистам”] – Ключевые бизнес-цели: [перечислите, например, “увеличить конверсию из регистрации в первую запись, снизить отток пользователей”] – Платформа аналитики: [укажите, например, “Яндекс.Метрика для приложений” или “Firebase Analytics” или “собственное решение”] – Платформа приложения: [укажите, например, “iOS” или “Android” или “обе”] – Что уже отслеживается: [укажите, например, “только установки и активные пользователи” или “ничего”]

Предоставь:

1. Ключевые воронки для отслеживания (с учетом бизнес-целей)
2. Список событий для каждой воронки – название события, параметры, когда срабатывает
3. Пользовательские свойства – что сохранять о каждом пользователе
4. Дашборд – какие метрики смотреть ежедневно, еженедельно, ежемесячно
5. Ошибки при настройке аналитики – что чаще всего упускают

Формат: таблица событий (название / параметры / триггер / зачем нужно) + текстовые пояснения по воронкам.

*****

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

17. Написание технического задания для дизайнера интерфейса

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

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

Текст промпта:

*****

Ты – продуктовый менеджер с опытом постановки задач дизайнерам мобильных интерфейсов.

Задача: напиши техническое задание для дизайнера на разработку экрана или функции мобильного приложения.

Параметры:
– Что нужно разработать: [опишите, например, “экран профиля пользователя с возможностью редактирования данных” или “онбординг из 4 экранов”] – Платформа: [укажите, например, “iOS” или “Android” или “обе, с учетом различий”] – Пользовательский сценарий: [опишите, например, “пользователь хочет изменить аватар и номер телефона”] – Технические ограничения: [перечислите, например, “изображения не более 5 МБ, телефон проверяется через SMS-код”] – Стиль и брендбук: [укажите, например, “ссылка на существующий дизайн-файл” или “стиль минималистичный, цвета компании: синий #1A73E8, белый”] – Что точно должно быть на экране: [перечислите обязательные элементы]

Задание должно включать:

1. Цель экрана и контекст использования
2. Все состояния экрана (загрузка, заполненное, пустое, ошибка, успех)
3. Поведение элементов при взаимодействии
4. Технические ограничения для дизайнера
5. Что оценивается при приемке работы

Тон: конкретный, без двусмысленностей. Дизайнер не должен угадывать намерения.

*****

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

18. Разработка плана нагрузочного тестирования

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

Решение: Промпт создает план нагрузочного тестирования с конкретными сценариями и инструментами для обнаружения проблем до продакшена.

Текст промпта:

*****

Ты – инженер по надежности систем с опытом нагрузочного тестирования мобильных сервисов.

Задача: разработай план нагрузочного тестирования для мобильного приложения и его серверной части.

Параметры:
– Тип приложения: [опишите, например, “приложение для трансляций спортивных событий”] – Ожидаемая нагрузка: [укажите, например, “до 10 000 одновременных пользователей в пиковые моменты”] – Критические функции: [перечислите, например, “авторизация, загрузка ленты, отправка сообщений”] – Текущая инфраструктура: [опишите, например, “один сервер на Яндекс.Облаке, PostgreSQL, Redis”] – Инструменты, которые есть в наличии: [укажите, например, “Яндекс.Танк” или “любые доступные”]

Предоставь:

1. Сценарии нагрузочного тестирования (нормальная нагрузка, пиковая, стрессовая)
2. Метрики для мониторинга – что измерять и какие пороговые значения считать критическими
3. Пошаговый план проведения тестирования
4. Инструменты для каждого типа тестирования с кратким описанием
5. Интерпретация результатов – как понять, что нашли проблему
6. Типичные узкие места в мобильных сервисах – что проверить в первую очередь

Формат: структурированный план, пригодный для немедленного использования.

*****

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

19. Составление соглашения о конфиденциальности и пользовательского соглашения

Проблема: Юридические документы копируются с других приложений или генерируются шаблонно – и не отражают реальную логику обработки данных конкретного приложения.

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

Текст промпта:

*****

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

Задача: составь основу для политики конфиденциальности и пользовательского соглашения мобильного приложения.

Параметры:
– Название и тип приложения: [укажите, например, “приложение для телемедицины” или “маркетплейс услуг”] – Какие данные собирает приложение: [перечислите, например, “имя, телефон, геолокация, история покупок, фотографии”] – Где обрабатываются данные: [укажите, например, “серверы в России, Яндекс.Облако”] – Передаются ли данные третьим лицам: [укажите, например, “да, платежной системе СБП и аналитике Яндекс.Метрика”] – Целевая аудитория: [укажите, например, “совершеннолетние пользователи” или “в том числе несовершеннолетние”]

Составь черновик, включающий:

1. Политику конфиденциальности – разделы: какие данные собираем, зачем, как храним, как пользователь может их удалить
2. Пользовательское соглашение – основные права и обязанности сторон
3. Соответствие 152-ФЗ “О персональных данных” – ключевые требования для данного типа приложения
4. Формулировки согласия на обработку данных

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

*****

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

20. Генерация идей для новых функций приложения

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

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

Текст промпта:

*****

Ты – продуктовый стратег с опытом развития мобильных приложений от MVP до зрелого продукта.

Задача: сгенерируй идеи для новых функций мобильного приложения.

Параметры:
– Текущий продукт: [опишите, что уже есть, например, “приложение для записи к мастерам маникюра: каталог мастеров, запись, отзывы, оплата”] – Текущие проблемы пользователей (если известны): [перечислите, например, “пользователи хотят видеть расписание мастера на неделю вперед, жалуются на отмены”] – Стратегические цели: [укажите, например, “увеличить частоту использования приложения” или “привлечь новую аудиторию”] – Ограничения: [укажите, например, “команда из 2 разработчиков, бюджет ограничен”]

Сгенерируй идеи в 4 категориях:

1. Быстрые улучшения (до 2 недель разработки) – то, что сразу улучшит опыт пользователя
2. Средние функции (1–2 месяца) – новые возможности с ощутимым эффектом
3. Большие функции (3+ месяца) – стратегические изменения продукта
4. Нестандартные идеи – то, чего нет у конкурентов

Для каждой идеи: название, описание в 2–3 предложениях, потенциальный эффект для пользователя и бизнеса, оценка сложности реализации. Минимум 3 идеи в каждой категории.

*****

Почему это работает: Разбивка по срокам разработки сразу создает дорожную карту, а не просто список идей. Категория “нестандартные идеи” стимулирует выход за рамки очевидного копирования конкурентов.

21. Написание инструкции для бета-тестировщиков

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

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

Текст промпта:

*****

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

Задача: напиши инструкцию для участников бета-тестирования мобильного приложения.

Параметры:
– Название и тип приложения: [укажите, например, “приложение для учета рабочего времени”] – Что нужно проверить в первую очередь: [перечислите, например, “регистрация, добавление записей, экспорт отчета в PDF”] – Платформы участников: [укажите, например, “Android 10–14, разные производители” или “iOS 16–17”] – Срок тестирования: [укажите, например, “5 дней”] – Как участники отправляют отчеты: [укажите, например, “через форму в Яндекс.Формах” или “в общий чат”]

Инструкция должна включать:

1. Приветствие и объяснение цели тестирования (коротко, 3–5 предложений)
2. Как установить приложение (пошагово для указанной платформы)
3. Сценарии для обязательного тестирования – конкретные шаги
4. Что особенно важно проверить и почему
5. Как правильно описать найденную ошибку (шаблон отчета)
6. Что делать, если что-то непонятно

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

*****

Почему это работает: Шаблон отчета об ошибке – это ключевой элемент, который большинство пропускает. Без него тестировщики присылают “у меня что-то сломалось” без возможности воспроизвести проблему.

22. Написание кода интеграции с платежной системой

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

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

Текст промпта:

*****

Ты – разработчик мобильных приложений с опытом интеграции платежных систем на российском рынке.

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

Параметры:
– Платформа и язык: [укажите, например, “Android, Kotlin” или “iOS, Swift”] – Платежная система: [укажите, например, “Тинькофф эквайринг” или “ЮКасса” или “СБП через НСПК”] – Тип оплаты: [укажите, например, “разовая оплата” или “подписка с автосписанием”] – Что уже есть: [опишите, например, “серверная часть на Python, документация к API платежной системы есть”]

Предоставь:

1. Пошаговый план интеграции с указанием, что делается на стороне приложения, а что на сервере
2. Примеры кода для ключевых шагов (инициализация платежа, обработка результата, обработка ошибок)
3. Критические ошибки, которые нельзя допустить (безопасность, двойные списания, незакрытые транзакции)
4. Тестирование платежной интеграции – как проверить без реальных денег
5. Типичные проблемы при интеграции и их решения

Код должен быть рабочим, с комментариями к критическим местам. Безопасность – в приоритете над краткостью кода.

*****

Почему это работает: Явный приоритет безопасности над краткостью кода – это сигнал нейросети не срезать углы в критических местах. Разделение ответственности между приложением и сервером убирает главный источник путаницы при интеграции.

23. Создание плана поддержки пользователей внутри приложения

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

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

Текст промпта:

*****

Ты – эксперт по клиентскому опыту в мобильных приложениях с опытом построения систем поддержки.

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

Параметры:
– Тип приложения: [опишите, например, “сервис аренды самокатов” или “приложение для онлайн-обучения”] – Размер команды поддержки: [укажите, например, “1 человек на полставки” или “нет выделенной команды”] – Типичные вопросы пользователей (если известны): [перечислите, например, “как вернуть деньги, как изменить тариф, почему не работает функция X”] – Бюджет на инструменты: [укажите, например, “минимальный” или “можем подключить платный инструмент”]

Спроектируй:

1. Структуру раздела “Помощь” внутри приложения – разделы и логику навигации
2. Топ-10 вопросов и ответов для базы знаний (на основе типичного поведения пользователей данного типа приложения)
3. Сценарий самообслуживания – как пользователь решает типичные проблемы без участия команды
4. Когда и как эскалировать вопрос к живому специалисту
5. Инструменты для организации поддержки – варианты с учетом бюджета (российские решения в приоритете)
6. Метрики качества поддержки – что измерять

Тон ответов в базе знаний: теплый, человечный, без канцелярита.

*****

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

24. Анализ причин низкого удержания пользователей

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

Решение: Промпт организует диагностику удержания с анализом ключевых точек оттока и конкретными гипотезами для проверки.

Текст промпта:

*****

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

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

Параметры:
– Тип приложения: [опишите, например, “приложение для изучения иностранных языков”] – Текущие метрики (если есть): [укажите, например, “Day 1 retention 40%, Day 7 – 15%, Day 30 – 5%”] – Данные о поведении пользователей: [опишите, что известно, например, “большинство пользователей не завершают регистрацию, до первого урока доходят 30%”] – Онбординг: [опишите, например, “3 экрана с объяснением, потом сразу регистрация”] – Что уже пробовали улучшить: [укажите, например, “добавили push-уведомления, не помогло”]

Предоставь:

1. Анализ типичных причин оттока для данного типа приложения (с объяснением механизма каждой)
2. Диагностику: какие данные нужно собрать, чтобы точно найти проблему
3. Топ-5 гипотез для улучшения удержания – с описанием, как проверить каждую
4. Изменения в онбординге, которые чаще всего дают быстрый результат
5. Что точно не поможет (распространенные ошибки при работе с удержанием)

Формат: структурированный анализ с приоритизацией гипотез по потенциальному эффекту и сложности реализации.

*****

Почему это работает: Запрос “что точно не поможет” защищает от трат времени на популярные, но неэффективные решения. Приоритизация гипотез по эффекту и сложности сразу создает план действий.

25. Написание технического задания на разработку серверной части

Проблема: Разработчик приложения и разработчик серверной части говорят на разных языках – и в итоге интеграция превращается в бесконечные уточнения и переделки.

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

Текст промпта:

*****

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

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

Параметры:
– Тип приложения: [опишите, например, “приложение для бронирования переговорных комнат в офисе”] – Основные функции: [перечислите, например, “авторизация сотрудников, просмотр расписания, бронирование, отмена, уведомления”] – Ожидаемая нагрузка: [укажите, например, “до 500 пользователей в день, пик 9:00–10:00”] – Технологические предпочтения: [укажите, например, “Python/FastAPI” или “без предпочтений”] – Интеграции: [перечислите, например, “корпоративный каталог пользователей LDAP, Яндекс.Календарь”]

Техническое задание должно включать:

1. Архитектуру серверной части (компоненты, их взаимодействие)
2. Описание программного интерфейса – для каждого метода: адрес, метод запроса, параметры, формат ответа, коды ошибок
3. Модель данных – основные сущности и их поля
4. Требования к безопасности и авторизации
5. Требования к производительности и надежности
6. Что выходит за рамки задания

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

*****

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

26. Разработка политики хранения и обновления данных в кэше

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

Решение: Промпт создает системную политику кэширования с правилами для разных типов данных и стратегиями инвалидации.

Текст промпта:

*****

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

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

Параметры:
– Тип приложения: [опишите, например, “новостное приложение с персонализированной лентой”] – Платформа: [укажите, например, “iOS” или “Android” или “Flutter”] – Типы данных в приложении: [перечислите, например, “лента новостей, профиль пользователя, настройки, медиафайлы, счетчики”] – Требования к актуальности: [опишите, например, “лента должна обновляться каждые 5 минут, профиль – при каждом открытии”] – Ограничения устройства: [укажите, например, “приложение должно работать на устройствах с 2 ГБ RAM”]

Разработай политику, включающую:

1. Классификацию данных по типу кэширования (не кэшировать / кратко / долго / постоянно)
2. Стратегию для каждого типа данных с обоснованием срока хранения
3. Стратегии инвалидации кэша (по времени, по событию, принудительная)
4. Поведение при отсутствии сети – что показывать из кэша
5. Управление объемом кэша – когда и что удалять
6. Примеры кода для реализации ключевых стратегий на указанной платформе

Формат: таблица классификации данных + описание стратегий с примерами кода.

*****

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

27. Подготовка плана перехода приложения на новую версию платформы

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

Решение: Промпт создает план миграции на новую версию платформы с анализом рисков и пошаговыми действиями.

Текст промпта:

*****

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

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

Параметры:
– Платформа: [укажите, например, “iOS 17 → iOS 18” или “Android 13 → Android 14”] – Текущее состояние приложения: [опишите, например, “приложение поддерживает iOS 15+, написано на Swift 5.8, использует UIKit”] – Критические функции: [перечислите, например, “авторизация через Face ID, push-уведомления, работа в фоне”] – Срок: [укажите, например, “нужно завершить до выхода официального релиза операционной системы”] – Ресурсы: [укажите, например, “1 разработчик, 20% рабочего времени”]

Предоставь:

1. Анализ ключевых изменений новой версии платформы, влияющих на приложение
2. Список компонентов приложения, требующих изменений – с приоритетами
3. Устаревшие компоненты и методы, от которых нужно отказаться
4. Пошаговый план миграции с временными оценками
5. Тестирование после миграции – что проверить обязательно
6. Типичные ошибки при обновлении платформы – чего избегать

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

*****

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

Типичные ошибки при работе с запросами для нейросети в разработке

1. Отправлять запрос без контекста проекта и платформы. Нейросеть генерирует универсальный ответ, который подходит “для всего” – а значит, не подходит ни для чего конкретного. Ответ про Android бесполезен iOS-разработчику, и наоборот.
2. Просить написать “код для функции” без описания существующей архитектуры. Сгенерированный код будет технически правильным, но несовместимым с тем, что уже есть в проекте – и переписывать его придется вручную.
3. Копировать сгенерированный код без проверки граничных случаев. Нейросеть хорошо пишет основной сценарий, но часто пропускает обработку ошибок, нулевых значений и состояний гонки – именно там прячутся баги, которые всплывают в продакшене.
4. Задавать несколько вопросов в одном запросе. Когда запрос содержит три разных задачи, нейросеть отвечает поверхностно на каждую из них – вместо того чтобы дать глубокий ответ на одну. Одна задача – один запрос.
5. Не указывать версию языка или фреймворка. Kotlin 1.8 и Kotlin 2.0 – это разные языки в части новых возможностей. Swift для iOS 15 и Swift для iOS 17 отличаются по доступным API. Без версии ответ может быть технически устаревшим или неприменимым.
6. Использовать сгенерированные юридические и пользовательские соглашения без проверки юристом. Нейросеть создает разумную основу, но не несет ответственности за соответствие актуальному законодательству. Штраф по 152-ФЗ может обойтись значительно дороже часа работы юриста.
7. Не уточнять запрос после первого неудовлетворительного ответа. Первый ответ – это черновик. Если результат не подошел, большинство разработчиков начинают заново, вместо того чтобы уточнить: “Перепиши пункт 3, учитывая, что используется реактивный подход”.
8. Просить написать архитектуру без указания размера команды и горизонта развития. Чистая архитектура для команды из одного человека на трехмесячный MVP – это избыточная сложность. Простой подход для долгосрочного продукта с командой – это технический долг с первого дня.
9. Принимать сгенерированные тесты как полное тестовое покрытие. Нейросеть пишет тесты для очевидных сценариев, но не знает специфику бизнес-логики конкретного приложения. Тесты – хорошая основа, а не финальное решение.

Сравнение слабых и сильных запросов для разработчика мобильных приложений

Задача	Слабый запрос	Сильный запрос	Почему важна разница
Выбор архитектуры	Какую архитектуру выбрать для приложения?	Выбери архитектуру для приложения-маркетплейса на Swift для команды из 2 человек с планом развивать продукт 2+ года. Сравни MVP, MVVM и Clean Architecture по тестируемости и масштабируемости.	Без параметров проекта ответ будет теоретической лекцией без практической ценности
Проверка кода	Проверь мой код.	Проведи код-ревью этого метода на Kotlin. Проверь утечки памяти, обработку ошибок и тестируемость. Для каждой проблемы покажи исправленный вариант.	Без критериев проверки нейросеть дает общие комментарии, а не системный разбор
Оптимизация списка	Как ускорить список в приложении?	Список на RecyclerView с изображениями тормозит при быстрой прокрутке на Android 12. Уже добавили Glide для кэширования изображений. Дай диагностику с инструментами и конкретные оптимизации с примерами кода.	Контекст уже сделанного исключает повторение советов, которые уже не помогли
Написание тестов	Напиши тесты для моего класса.	Напиши тесты на XCTest для метода calculateDiscount() в Swift. Покрой основной сценарий, граничные значения (скидка 0%, 100%), некорректные входные данные и поведение при nil. Для каждого теста – название в формате “что/при каком условии/результат”.	Явное перечисление типов сценариев гарантирует полное покрытие, а не только счастливый путь
Описание в магазине	Напиши описание для моего приложения.	Напиши описание для приложения учета расходов в РуСторе. Аудитория – люди 30–50 лет, главное преимущество – синхронизация с картами Сбера и Тинькофф. Нужно: слоган до 80 символов, полное описание 400–500 слов по структуре “крючок → проблема → решение → возможности → призыв”.	Структура описания и параметры аудитории заменяют размытое “напиши хорошо” конкретным техническим заданием
Push-уведомления	Помоги настроить уведомления.	Спроектируй систему push-уведомлений для образовательного приложения на iOS через Firebase. Категории: напоминание об уроке, достижение, комментарий преподавателя. Нужна логика управления частотой, примеры текстов для каждой категории и метрики эффективности.	Категории уведомлений и требование текстов-примеров превращают абстрактную задачу в готовое решение

Неочевидные советы по работе с запросами для нейросети в мобильной разработке

1. Добавляйте в запрос фрагмент уже существующего кода из проекта, даже если он напрямую не связан с задачей. Нейросеть автоматически адаптирует стиль, соглашения по именованию и подходы к тому, что уже есть в проекте – и результат требует значительно меньше доработки.
2. Просите нейросеть сначала задать уточняющие вопросы, прежде чем давать ответ. Это особенно ценно для архитектурных и проектных задач: нейросеть сама выявит, каких параметров не хватает, и ответ будет точнее с первой попытки.
3. Указывайте, что уже пробовали и почему это не сработало. Без этой информации нейросеть с высокой вероятностью предложит именно то, что уже не помогло – и придется тратить время на повторное уточнение.
4. Для задач оптимизации просите указать ожидаемые числовые результаты до и после. Это заставляет нейросеть предлагать только те оптимизации, эффект которых можно измерить – и отсекает советы из серии “это может помочь”.
5. Сохраняйте удачные промпты с заполненными переменными в отдельный файл сразу после получения хорошего результата. Шаблоны для код-ревью, написания тестов и документации используются регулярно – и каждый раз составлять запрос заново означает терять время без причины.
6. Разбивайте большие задачи на последовательность запросов, передавая результат предыдущего в следующий. Запрос “спроектируй архитектуру → теперь напиши схему базы данных для этой архитектуры → теперь напиши программный интерфейс для модуля данных” дает значительно более связный результат, чем один большой запрос на все сразу.
7. Просите нейросеть указать, какие допущения она сделала при ответе. В мобильной разработке нейросеть часто предполагает конкретную версию платформы, определенную библиотеку или подход – и если это допущение неверно, весь ответ нужно переделывать. Явное перечисление допущений экономит время на проверку применимости результата.