Введение
Представьте: вы сидите над куском кода, который отказывается работать третий час. Глаза слипаются, а баг всё ещё не найден. Знакомо? В 2026 году такое случается реже — если знать, как правильно попросить помощи у ИИ.
ChatGPT и GPT-4 стали незаменимыми инструментами в арсенале современного разработчика. Но многие до сих пор используют их как «умный поисковик», а не как коллегу-мидла, который всегда онлайн. Секрет в промтах — правильно составленный запрос превращает нейросеть из генератора «воды» в инженера, который понимает контекст вашего проекта.
В этой статье — 20 проверенных промтов для программирования, отладки и рефакторинга. Каждый я тестировал лично в реальных задачах: от микросервисов на Go до фронтенда на React. Без воды, только рабочие конструкции.
Почему GPT-4, а не ChatGPT?
GPT-4 — это движок, который стоит за ChatGPT Plus (и другими интерфейсами). Если у вас есть доступ к GPT-4 через API или подписку — вы получаете:
- Контекст до 128K токенов (можно «скормить» целый модуль)
- Многомодальность: можно загружать скриншоты кода, диаграммы
- Лучшее понимание сложной логики (по тестам HumanEval — 87% против 67% у GPT-3.5)
Если работаете через бесплатный ChatGPT — часть промтов адаптируйте под меньший контекст. Но лучше оформить подписку: $20 в месяц окупаются за пару часов сэкономленного времени.
Как читать промты?
Каждый промт — это шаблон. В квадратных скобках [описание] — то, что вы подставляете под свою задачу. Фигурные скобки {инструкция} — мои пояснения, вставлять не нужно. Текст до двоеточия — тип задачи.
1. Промты для написания кода
1.1. Функция по спецификации
Когда использовать: Нужно быстро набросать функцию с чёткими требованиями.
Промт:
Напиши на [язык] функцию, которая [описание задачи].
Требования:
- Вход: [тип данных, пример]
- Выход: [тип данных, пример]
- Обработка ошибок: [какие исключения]
- Производительность: O([сложность])
Добавь docstring и комментарии на русском.
Пример:
Напиши на Python функцию, которая находит топ-3 самых частых слова в тексте.
Требования:
- Вход: строка текста
- Выход: список кортежей (слово, частота)
- Обработка ошибок: пустая строка → пустой список
- Производительность: O(n)
Добавь docstring и комментарии на русском.
Результат: GPT-4 выдаёт готовую функцию с Counter из collections, проверкой на пустой ввод и корректным docstring. Можно сразу копировать.
1.2. Генерация boilerplate-кода
Когда использовать: Нужно быстро создать скелет модуля, класса или API-эндпоинта.
Промт:
Сгенерируй boilerplate для [тип компонента] на [язык/фреймворк].
Включи:
- Базовую структуру с импортами
- Обработку основных HTTP-методов [если API]
- Логирование
- Конфигурацию через переменные окружения
Не добавляй бизнес-логику — только скелет.
Пример:
Сгенерируй boilerplate для REST API на FastAPI.
Включи:
- Базовую структуру с импортами
- Обработку основных HTTP-методов
- Логирование
- Конфигурацию через переменные окружения
Не добавляй бизнес-логику — только скелет.
Результат: Получаете файл main.py с роутами, Pydantic-схемами, настройками через pydantic-settings. Экономит 15-20 минут на старте проекта.
1.3. Реализация алгоритма по описанию
Когда использовать: Нужно реализовать алгоритм, который вы понимаете концептуально, но не помните детали реализации.
Промт:
Реализуй алгоритм [название] на [язык].
Описание: [краткое описание алгоритма]
Требования:
- Итеративная реализация (не рекурсивная, если не указано иное)
- Сложность: [O-нотация]
- Тестовый пример: [вход → ожидаемый выход]
Покажи пошагово, как работает алгоритм, в комментариях.
Пример:
Реализуй алгоритм бинарного поиска на Python.
Описание: поиск элемента в отсортированном массиве путём деления пополам.
Требования:
- Итеративная реализация
- Сложность: O(log n)
- Тестовый пример: [1,3,5,7,9], ищем 5 → индекс 2
Покажи пошагово, как работает алгоритм, в комментариях.
1.4. SQL-запрос по описанию
Когда использовать: Нужно быстро написать запрос, не отвлекаясь на синтаксис.
Промт:
Напиши SQL-запрос для [СУБД] который:
[описание задачи]
Схема таблиц:
[название таблицы 1]: колонка1 (тип), колонка2 (тип)
[название таблицы 2]: колонка1 (тип), колонка2 (тип)
Связи: [как таблицы связаны]
Условия: [фильтры, сортировка, лимит]
Оптимизируй запрос (используй индексы, избегай SELECT *).
Добавь EXPLAIN ANALYZE для проверки.
Пример:
Напиши SQL-запрос для PostgreSQL который:
находит 10 самых продаваемых товаров за последний месяц
Схема таблиц:
products: id (int), name (varchar), price (decimal)
sales: id (int), product_id (int), quantity (int), sale_date (timestamp)
Связи: sales.product_id = products.id
Условия: sale_date >= текущая_дата - 30 дней, сгруппировать по product_id, отсортировать по сумме quantity DESC, лимит 10
Оптимизируй запрос (используй индексы, избегай SELECT *).
Добавь EXPLAIN ANALYZE для проверки.
2. Промты для отладки
2.1. Анализ ошибки по stack trace
Когда использовать: Есть ошибка, но непонятно, в чём первопричина.
Промт:
У меня ошибка в [язык/фреймворк]:
[вставьте полный stack trace]
Код, который вызывает ошибку (контекст):
[вставьте 20-30 строк кода]
Объясни:
1. Почему возникает ошибка
2. Какая строка вызывает проблему
3. Как исправить (с кодом)
4. Как предотвратить в будущем
Пример:
У меня ошибка в Python/Django:
Traceback (most recent call last):
File "/app/views.py", line 45, in get
data = some_function(request.user.id)
File "/app/utils.py", line 12, in some_function
result = User.objects.get(id=user_id)
File "/lib/python3.11/site-packages/django/db/models/manager.py", line 85, in manager_method
return getattr(self.get_queryset(), name)(*args, **kwargs)
File "/lib/python3.11/site-packages/django/db/models/query.py", line 496, in get
raise self.model.DoesNotExist(...)
django.contrib.auth.models.User.DoesNotExist: User matching query does not exist.
Код, который вызывает ошибку (контекст):
# views.py строка 40-50
def get(self, request):
user_id = request.user.id
data = some_function(user_id)
return JsonResponse(data)
Объясни:
1. Почему возникает ошибка
2. Какая строка вызывает проблему
3. Как исправить (с кодом)
4. Как предотвратить в будущем
Результат: GPT-4 чётко укажет на отсутствие пользователя в БД, предложит использовать get_object_or_404 или try/except, и даст пример обработки.
2.2. Поиск бага по симптомам
Когда использовать: Нет явной ошибки, но код работает не так, как ожидается.
Промт:
У меня баг в [язык/фреймворк]. Симптомы:
- [что происходит]
- [что должно происходить]
- [при каких условиях проявляется]
Код (релевантная часть):
[вставьте код]
Входные данные (пример):
[вход]
Ожидаемый выход:
[выход]
Фактический выход:
[выход]
Найди причину и предложи фикс.
2.3. Code review через GPT-4
Когда использовать: Нужно быстро проверить код на потенциальные проблемы перед ревью коллеги.
Промт:
Проведи code review следующего кода на [язык]:
[вставьте код]
Проверь:
1. Безопасность (SQL-инъекции, XSS, утечки данных)
2. Производительность (узкие места, лишние запросы)
3. Читаемость (нейминг, структура, комментарии)
4. Соответствие best practices для [язык/фреймворк]
Для каждой проблемы укажи: severity (critical/major/minor), строку кода, объяснение и suggested fix.
Пример:
Проведи code review следующего кода на Python:
def get_user_data(user_id):
query = f"SELECT * FROM users WHERE id = {user_id}"
return execute_query(query)
Проверь:
1. Безопасность
2. Производительность
3. Читаемость
4. Соответствие best practices для Python
Для каждой проблемы укажи: severity, строку, объяснение и suggested fix.
2.4. Сравнение двух реализаций
Когда использовать: Есть два способа решить задачу, нужно выбрать лучший.
Промт:
Сравни два подхода к решению задачи [описание задачи]:
Подход A:
[код A]
Подход B:
[код B]
Сравни по критериям:
- Производительность (Big O, реальные замеры)
- Читаемость
- Поддерживаемость
- Обработка edge cases
Какой подход лучше и почему?
3. Промты для рефакторинга
3.1. Упрощение сложного кода
Когда использовать: Есть «спагетти-код», который нужно сделать читаемым.
Промт:
Выполни рефакторинг следующего кода на [язык]:
[вставьте код]
Цели:
- Уменьшить сложность (разбить на функции/классы)
- Улучшить читаемость (понятные имена, комментарии)
- Устранить дублирование
- Сохранить ту же функциональность
Покажи:
1. Исходный код с проблемными местами (комментарии)
2. Рефакторированный код
3. Что изменилось и почему
3.2. Перевод с одного языка на другой
Когда использовать: Нужно перенести логику с одного языка на другой.
Промт:
Перепиши следующий код с [язык_источник] на [язык_цель]:
[вставьте код]
Условия:
- Сохрани ту же логику
- Используй идиоматичные конструкции [язык_цель]
- Не используй прямые аналоги библиотек, если есть нативные решения
- Добавь комментарии для неочевидных моментов
3.3. Оптимизация производительности
Когда использовать: Код работает, но медленно.
Промт:
Оптимизируй следующий код на [язык] по производительности:
[вставьте код]
Контекст:
- Размер входных данных: [примерный размер]
- Текущее время выполнения: [время]
- Целевое время выполнения: [время]
- Ограничения: [память, время, зависимости]
Предложи 3 варианта оптимизации с оценкой сложности и компромиссов.
3.4. Добавление типов (TypeScript/Python)
Когда использовать: Есть код без типов, нужно добавить аннотации.
Промт:
Добавь строгую типизацию в следующий код на [TypeScript/Python]:
[вставьте код]
Требования:
- Используй [TypeScript: strict mode / Python: type hints]
- Для внешних зависимостей используй [DefinitelyTyped / stub files]
- Добавь generics где уместно
- Не меняй runtime-логику
4. Промты для архитектурных решений
4.1. Проектирование API
Когда использовать: Нужно спроектировать REST или GraphQL API.
Промт:
Спроектируй API для [описание системы].
Требования:
- Тип: [REST / GraphQL / gRPC]
- Основные сущности: [список]
- CRUD-операции: [какие нужны]
- Аутентификация: [JWT / OAuth / API Key]
- Пагинация: [cursor / offset]
Для каждого эндпоинта укажи:
- HTTP-метод и URL
- Request/Response схема (JSON)
- Коды ответов
- Пример запроса и ответа
4.2. Выбор технологии
Когда использовать: Нужно выбрать между несколькими инструментами/фреймворками.
Промт:
Сравни [технология A] и [технология B] для задачи [описание].
Критерии:
- Производительность (latency, throughput)
- Сообщество и поддержка
- Кривая обучения
- Стоимость (лицензии, инфраструктура)
- Совместимость с [существующий стек]
Дай рекомендацию с обоснованием.
4.3. Проектирование базы данных
Когда использовать: Нужно спроектировать схему БД для новой функциональности.
Промт:
Спроектируй схему базы данных для [описание системы].
Требования:
- СУБД: [PostgreSQL / MongoDB / MySQL]
- Основные сущности и их атрибуты: [список]
- Связи: [one-to-many, many-to-many]
- Ключевые запросы: [какие будут чаще всего]
- Ожидаемый объём данных: [количество записей]
Предложи:
1. ER-диаграмму (текстовое описание)
2. SQL-скрипт создания таблиц с индексами
3. Примеры основных запросов
5. Продвинутые техники
5.1. Работа с legacy-кодом
Когда использовать: Нужно разобраться в старом коде без документации.
Промт:
Я работаю с legacy-кодом на [язык]. Помоги разобраться:
Файл: [путь к файлу]
[вставьте код]
Ответь на вопросы:
1. Что делает этот модуль/функция?
2. Какие входные данные ожидает?
3. Какие побочные эффекты?
4. С какими другими модулями взаимодействует?
5. Какие есть потенциальные баги или проблемы?
Создай документацию в формате README для этого модуля.
5.2. Генерация тестов
Когда использовать: Нужно быстро покрыть код тестами.
Промт:
Напиши unit-тесты для следующего кода на [язык] с использованием [фреймворк тестирования]:
[вставьте код]
Покрой:
- Основной сценарий (happy path)
- Edge cases (пустые значения, граничные условия)
- Ошибки (исключения, неверные входные данные)
Для каждого теста укажи: название, входные данные, ожидаемый результат.
5.3. Написание документации
Когда использовать: Код готов, но нет документации.
Промт:
Напиши README для проекта на [язык/фреймворк] со следующей структурой:
Текущий код/описание:
[вставьте описание или ссылку на код]
Разделы:
1. Название и краткое описание
2. Установка (с примерами команд)
3. Использование (примеры кода)
4. API Reference (если библиотека)
5. Конфигурация (переменные окружения)
6. Разработка (как запустить тесты, линтер)
7. Лицензия
Используй понятный русский язык, добавляй примеры.
6. Пример из реальной практики
Недавно я работал над микросервисом на Go, который обрабатывал вебхуки от Telegram. Возникла проблема: при высокой нагрузке (1000+ запросов/сек) сервис начинал терять сообщения. Я использовал такой промт:
У меня Go-сервис, который принимает вебхуки от Telegram и сохраняет их в PostgreSQL.
Симптомы:
- При нагрузке >500 RPS начинаются ошибки "connection pool exhausted"
- Часть сообщений теряется (не доходят до БД)
- CPU utilisation ~80%, но latency растёт
Код (основной обработчик):
[вставка кода]
Конфигурация:
- Go 1.21
- lib/pq для PostgreSQL
- http.Server с таймаутами
- max_connections в PG = 25
Найди узкое место и предложи 3 варианта решения с оценкой сложности внедрения.
GPT-4 быстро указал на проблему: в коде не закрывалось rows.Close() после запроса, из-за чего соединения не возвращались в пул. Второй проблемой было отсутствие буферизации входящих запросов. Решение: добавить defer rows.Close(), внедрить буфер через канал и worker pool. Всё это заняло 20 минут вместо 2-3 часов ручного дебага.
Заключение
Эти 20 промтов покрывают 90% ежедневных задач разработчика: от написания кода до архитектурных решений. Ключ к успеху — конкретика. Чем точнее вы опишете контекст, входные данные и ожидания, тем качественнее будет ответ.
Не бойтесь экспериментировать: пробуйте разные формулировки, комбинируйте промты, добавляйте свои требования. GPT-4 — это инструмент, который учится у вас так же, как вы учитесь у него.
И помните: даже самый умный ИИ не заменит понимания основ. Промты экономят время, но не отменяют необходимости разбираться в том, что вы делаете. Используйте их как ускоритель, а не как костыль.
Сохраните эту статью в закладки — и в следующий раз, когда застрянете на баге, просто скопируйте подходящий промт.
Комментарии