Разница между «ChatGPT написал бесполезный код» и «ChatGPT написал код, который я закоммитил почти без правок» почти никогда не в модели. Она — в промпте. Программисты, которые получают от нейросети действительно рабочий результат, задают вопросы иначе, чем те, кто разочаровывается после первой попытки.
В этой статье — конкретные приёмы составления промптов для написания, ревью и отладки кода, с примерами «было / стало».
Почему плохой промпт даёт плохой код
Языковая модель не читает мысли — она достраивает наиболее вероятное продолжение текста на основе того, что вы ей дали. Если в запросе нет контекста о языке, стиле, окружении и ограничениях, модель заполняет пробелы усреднёнными предположениями. Отсюда типичные жалобы: «код не в том стиле», «использует устаревшую библиотеку», «не учитывает мой кейс».
Хороший промпт для кода почти всегда закрывает пять вопросов:
- Что нужно сделать (задача).
- На чём это должно работать (язык, версия, фреймворк, окружение).
- Как это должно быть написано (стиль, соглашения, ограничения).
- Что уже есть (существующий код, контекст проекта).
- Как проверить, что результат правильный (тесты, ожидаемое поведение, граничные случаи).
Структура сильного промпта
Рабочий шаблон, который можно использовать почти для любой задачи по коду:
Роль: [кто ты в этой задаче — опционально]
Контекст: [что за проект, какой стек, что уже сделано]
Задача: [что конкретно нужно написать/исправить/отрефакторить]
Ограничения: [версия языка, стиль, что нельзя использовать]
Формат ответа: [только код / код + объяснение / с тестами]
Пример (было):
Напиши функцию для сортировки списка
Пример (стало):
Контекст: Python 3.11, проект на FastAPI, используем type hints везде. Задача: напиши функцию, которая сортирует список объектов
Orderпо полюcreated_atпо убыванию, с fallback наid, если даты совпадают. Ограничения: без внешних зависимостей, только стандартная библиотека. Формат ответа: только код с докстрингом, без объяснений.
Второй вариант почти гарантированно даст код, который не придётся переписывать.
8 практических приёмов
1. Указывайте версию языка и ключевых библиотек
«Напиши на Python» и «напиши на Python 3.12 с использованием match-выражений» — это разные промпты с разным результатом. Без версии модель может предложить синтаксис пятилетней давности или, наоборот, слишком новый для вашего окружения.
2. Давайте существующий код как контекст
Вместо описания «у меня есть класс с методом X» вставьте реальный фрагмент кода. Модель гораздо точнее продолжает существующий стиль (именование переменных, обработка ошибок, комментарии), чем воображает его с нуля.
3. Проговаривайте граничные случаи явно
Если для функции важно поведение при пустом списке, null, дублирующихся значениях или превышении лимита — перечислите это в промпте. Модель обрабатывает только то, о чём её попросили; она не обязана угадывать все edge cases за вас.
Пример:
Учти: список может быть пустым, элементы могут повторяться, значение
amountможет быть отрицательным — в этом случае выбрасывайValueError.
4. Просите объяснение отдельно от кода
Смешанный ответ («вот код с комментариями по ходу») сложнее скопировать и вставить. Если нужен и код, и разбор — попросите формат: сначала чистый блок кода, потом отдельным списком — пояснения к ключевым решениям.
5. Разбивайте большую задачу на этапы
Просьба «напиши мне REST API с авторизацией, базой данных и тестами» в один промпт обычно даёт поверхностный результат по каждому пункту. Лучше идти по шагам: сначала структура проекта, затем модели данных, затем эндпоинты, затем тесты — с уточнением контекста на каждом шаге.
6. Задавайте формат для ревью кода
Просьба «посмотри на код» даёт расплывчатый ответ. Конкретная структура работает лучше:
Проверь этот код на три вещи: (1) потенциальные баги, (2) проблемы производительности, (3) нарушения PEP8. Для каждой найденной проблемы укажи строку и предложи исправление.
7. Просите тесты сразу с граничными случаями
Напиши unit-тесты на pytest для этой функции. Обязательно покрой: нормальный случай, пустой ввод, некорректный тип данных, значение на границе диапазона.
Так вы получаете не формальные тесты «для галочки», а тесты, которые реально ловят баги.
8. Используйте итеративное уточнение вместо одного идеального промпта
Не обязательно с первого раза формулировать безупречный запрос. Рабочий паттерн: получить черновой вариант → указать конкретную проблему → попросить исправить именно её, не трогая остальное («не меняй сигнатуру функции, исправь только обработку исключения на строке с open()»). Это быстрее, чем пытаться предугадать всё заранее.
Промпты для отладки (debugging)
Отдельная категория — когда код уже написан, но не работает. Здесь важно дать модели максимум диагностической информации:
Контекст: [язык, окружение]
Код: [фрагмент, где предположительно ошибка]
Ожидаемое поведение: [что должно происходить]
Фактическое поведение: [что происходит на самом деле]
Текст ошибки: [полный traceback/stack trace, если есть]
Что уже пробовал: [чтобы не предлагали то же самое]
Промпт вида «почему не работает» без traceback и без описания ожидаемого поведения — одна из главных причин, почему модель предлагает нерелевантные исправления.
Чего стоит избегать
- Слишком общих формулировок («сделай код лучше», «оптимизируй это») без критерия — модель не знает, что для вас значит «лучше»: читаемость, скорость, память, длина.
- Отсутствия ограничений по зависимостям. Если нельзя добавлять новые библиотеки — скажите это заранее, а не после третьей попытки.
- Слепого копирования без ревью. Даже качественный промпт не отменяет проверки кода — особенно в части безопасности (валидация ввода, SQL-инъекции, обработка секретов).
- Игнорирования лимита контекста. Для больших файлов лучше присылать релевантный фрагмент с кратким описанием остального проекта, а не весь файл целиком без выделения сути.
Шаблон-чеклист перед отправкой промпта
- [ ] Указан язык/фреймворк и версия
- [ ] Есть контекст существующего кода (если применимо)
- [ ] Прописаны граничные случаи
- [ ] Указан желаемый формат ответа
- [ ] Указаны ограничения (зависимости, стиль, производительность)
- [ ] Для отладки: приложен полный текст ошибки
Итог
Качество кода от ChatGPT почти линейно зависит от качества промпта. Разница между посредственным и отличным результатом обычно не в «секретной магической фразе», а в банальной конкретике: версия языка, реальный контекст проекта, явно прописанные граничные случаи и понятный формат ответа. Освойте привычку формулировать запросы по структуре «контекст → задача → ограничения → формат» — и большая часть кода, который вы получаете, будет требовать минимальных правок.
