Попросите ChatGPT написать сайт, и через несколько секунд получите готовый HTML. Возможно, даже с красивыми кнопками и анимацией. Только потом выяснится, что кнопки ничего не делают, страница плохо открывается на телефоне, а для запуска нужны библиотеки, о которых вы никогда не слышали.
Многое зависит от того, как сформулирована задача. Причём хороший промпт для программирования необязательно должен занимать целую страницу. Иногда достаточно указать язык, привести пример входных данных или объяснить, что должно происходить при ошибке. Разберём на конкретных примерах, как писать запросы к ИИ, чтобы получать более предсказуемый код и тратить меньше времени на исправления.
Из чего состоит хороший промпт для написания кода
Промпт представляет собой запрос, с которым пользователь обращается к нейросети. Промпт-инжиниринг помогает формулировать такие запросы с учётом задачи, контекста и ожидаемого результата.
Допустим, вы пишете: «Сделай мне сайт». Нейросеть не знает, кому он нужен, какие разделы должны быть на странице, нужен ли сервер, какие технологии разрешены и как должен работать интерфейс. Модель восполнит пробелы самостоятельно. Результат может оказаться вполне рабочим, но не соответствовать вашим ожиданиям.
Полезнее сразу передать шесть элементов:
- Задача. Что должна делать программа и для кого она предназначена.
- Технологии. Язык программирования, среда выполнения, библиотеки и их версии, если они принципиальны.
- Входные и выходные данные. Что получает программа и какой результат должна возвращать.
- Ограничения. Какие файлы нельзя менять, какие зависимости не использовать, что нужно сохранить.
- Поведение в нестандартных ситуациях. Что происходит при пустом вводе, сетевой ошибке или отсутствии данных.
- Критерии готовности. Как проверить, что задача действительно выполнена.
Именно такие принципы встречаются в рекомендациях GitHub по работе с Copilot и в руководстве VS Code по использованию ИИ-агентов. Разработчики советуют давать конкретный контекст, разбивать сложные задачи на части и проверять полученный код.
При этом нет необходимости каждый раз писать огромный технический документ. Для функции из пяти строк достаточно короткого запроса. Для приложения с регистрацией, базой данных и несколькими интерфейсами потребуется гораздо больше подробностей.
Ниже собраны 20 пар промптов для ChatGPT, Claude, Copilot и других инструментов программирования. Фрагменты кода показывают возможные различия в реализации. Это иллюстрации, а не результаты сравнительного тестирования моделей: даже на одинаковый запрос нейросеть может ответить по-разному.
Примеры 1–5. Как задавать язык, библиотеки и формат результата
Начнём с технических требований. Они помогают избежать ситуации, когда нейросеть решает вашу задачу с помощью неподходящего языка, лишних инструментов или несовместимого синтаксиса.
-
Указывайте язык программирования.
Плохой промпт: «Напиши функцию для подсчёта слов в тексте».
Хороший: «Напиши на Python 3 функцию
count_words(text: str) -> int. Считай словами последовательности символов, разделённые пробельными символами. Для пустой строки возвращай 0. Не используй сторонние библиотеки».Разница в коде. Без указания языка модель может выбрать JavaScript и написать
text.split(" ").length. Такой вариант некорректно обрабатывает пустую строку и некоторые сочетания пробелов. Для заданных условий на Python достаточноreturn len(text.split()). -
Уточняйте количество и назначение файлов.
Плохой: «Создай форму обратной связи».
Хороший: «Создай форму с полями имени, почты и сообщения. Помести HTML, CSS и JavaScript в один файл index.html. Добавь проверку обязательных полей и демонстрационное сообщение об успешном заполнении. Отправка на сервер пока не нужна».
Разница в коде. В первом случае могут появиться отдельные файлы или полноценный проект на React. Во втором оформление и логика будут находиться внутри
<style>и<script>в одном HTML-файле. А сообщение об успехе не будет создавать ложное впечатление, что данные действительно отправлены. -
Обозначайте разрешённые библиотеки.
Плохой: «Напиши код для красивого отображения дат».
Хороший: «Напиши функцию JavaScript для браузера, которая форматирует объект Date в виде 25.12.2026. Используй стандартный Intl.DateTimeFormat с локалью ru-RU, без внешних библиотек».
Разница в коде. Модель может предложить стороннюю библиотеку:
dayjs(date).format("DD.MM.YYYY")При заданном ограничении достаточно встроенного API:
new Intl.DateTimeFormat("ru-RU").format(date)Второй вариант не требует устанавливать дополнительный пакет.
-
Указывайте версию среды, если от неё зависит совместимость.
Плохой: «Объедини два словаря в Python».
Хороший: «Покажи, как объединить словари a и b в Python 3.8. При одинаковых ключах значения из b должны иметь приоритет. Исходные словари не изменяй».
Разница в коде. Оператор
a | bподдерживается для словарей начиная с Python 3.9. Для Python 3.8 подойдёт{**a, **b}. Уточнение версии позволяет избежать несовместимого синтаксиса. -
Приводите пример входных и выходных данных.
Плохой: «Сделай функцию обработки имён».
Хороший: «Напиши функцию normalizeName(name) на JavaScript. Она должна удалять пробелы в начале и конце строки и заменять несколько последовательных пробельных символов одним обычным пробелом. Пример: строка с двумя пробелами между словами "Анна" и "Иванова" должна превратиться в "Анна Иванова"».
Разница в коде. Простого
name.trim()недостаточно для обработки пробелов между словами. Нужна дополнительная операция:return name.trim().replace(/s+/g, " ");
Обратите внимание, что хороший запрос не обязан предписывать конкретную реализацию. Иногда полезнее описать поведение функции и разрешить нейросети самостоятельно выбрать алгоритм. Но совместимость и принципиальные ограничения лучше закрепить заранее.
Примеры 6–10. Как описывать интерфейс сайта или приложения
При генерации интерфейсов слова «современный», «красивый» или «удобный» дают слишком много пространства для интерпретации. Гораздо полезнее перечислить конкретные элементы, состояния и действия пользователя.
-
Опишите содержимое страницы.
Плохой: «Напиши мне сайт для мастерской».
Хороший: «Создай одностраничный сайт мастерской по ремонту велосипедов. Нужны шапка с телефоном, список из четырёх услуг, таблица цен, адрес и кнопка записи. Интерфейс на русском языке. Пока используй демонстрационные данные и явно обозначь их в коде».
Разница в коде. Вместо случайного набора блоков появится определённая структура страницы, например
<section id="services">и<section id="prices">. Нейросети также не придётся самостоятельно придумывать назначение сайта. -
Задайте требования к мобильной версии.
Плохой: «Сделай адаптивный сайт».
Хороший: «Создай страницу, которая корректно работает при ширине экрана от 320 пикселей. На узком экране карточки должны располагаться в один столбец, на широком в три. Горизонтальной прокрутки быть не должно».
Разница в коде. Вместо фиксированного
width: 960pxможно получить сетку CSS Grid:.cards { display: grid; grid-template-columns: repeat(3, minmax(0, 1fr)); gap: 16px; } @media (max-width: 700px) { .cards { grid-template-columns: 1fr; } }Такая сетка реализует заданное переключение количества столбцов. Остальные элементы страницы тоже нужно проверить на маленьком экране.
-
Объясните, как должны работать кнопки.
Плохой: «Добавь кнопку покупки».
Хороший: «Добавь кнопку "В корзину" к каждой карточке товара. При нажатии добавляй товар в массив корзины, увеличивай счётчик и показывай сообщение о добавлении. Повторное нажатие должно увеличить количество этого товара».
Разница в коде. Обычной разметки
<button>В корзину</button>уже недостаточно. Понадобится обработчик события, напримерbutton.addEventListener("click", addToCart), и логика обновления корзины. -
Учитывайте доступность интерфейса.
Плохой: «Сделай поле для электронной почты».
Хороший: «Создай поле электронной почты с видимой подписью, правильным типом ввода и сообщением об ошибке. Подпись должна быть программно связана с полем, чтобы им можно было пользоваться со скринридером».
Разница в коде. Вместо одного поля с подсказкой:
<input placeholder="Email">Появится более подходящая разметка:
<label for="email">Электронная почта</label> <input id="email" type="email" required>Для полноценной формы также потребуется обработка ошибок и их понятное представление пользователю.
-
Опишите состояния загрузки и ошибок.
Плохой: «Сделай кнопку сохранения».
Хороший: «При отправке формы показывай на кнопке текст "Сохраняем..." и временно блокируй повторное нажатие. После успешного ответа сервера показывай подтверждение. При ошибке возвращай кнопку в исходное состояние и выводи сообщение».
Разница в коде. Вместо одного вызова
saveData()потребуется управление состоянием:button.disabled = loading; button.textContent = loading ? "Сохраняем..." : "Сохранить";Сама функция сохранения должна правильно обрабатывать как успешный результат, так и ошибку.
Для интерфейсов особенно полезны примеры: макет, скриншот, описание расположения блоков или несколько конкретных размеров. Но не перегружайте запрос десятками второстепенных требований. Сначала добейтесь корректной структуры, затем отдельно дорабатывайте оформление.
Примеры 11–15. Как задавать логику, обработку данных и ошибок
Программа может выглядеть правильно и при этом неверно считать, сортировать или сохранять данные. Поэтому для вычислений и работы с внешними сервисами важно объяснять ожидаемое поведение, включая нестандартные случаи.
-
Уточняйте правила сортировки.
Плохой: «Отсортируй массив чисел».
Хороший: «Напиши JavaScript-функцию для сортировки чисел по возрастанию. Исходный массив не изменяй. Для [10, 2, 30] результат должен быть [2, 10, 30]».
Разница в коде. Обычный
numbers.sort()по умолчанию сравнивает элементы как строки, поэтому может дать неожиданный порядок. Для чисел подойдёт:return [...numbers].sort((a, b) => a - b);Копирование через
[...numbers]позволяет сохранить исходный массив. -
Оговаривайте пограничные случаи.
Плохой: «Напиши функцию среднего арифметического».
Хороший: «Напиши функцию average(numbers) для массива чисел на JavaScript. Для [2, 4, 6] возвращай 4, для массива из одного элемента возвращай сам элемент, для пустого массива возвращай null».
Разница в коде. Без проверки длины массива вычисление может закончиться значением
NaNили ошибкой. Указанный результат требует отдельной ветки:if (numbers.length === 0) return null;Так становится понятно, что функция должна делать при отсутствии данных.
-
Описывайте обработку ошибок API.
Плохой: «Получи список пользователей с сервера».
Хороший: «Напиши асинхронную функцию JavaScript, которая получает JSON с /api/users. Если HTTP-ответ неуспешный, выбрасывай ошибку с кодом статуса. При сетевой ошибке передавай ошибку вызывающему коду. Не возвращай пустой список вместо ошибки».
Разница в коде. Простого
return response.json()недостаточно для контроля HTTP-ошибок. Послеfetch()понадобится проверка:if (!response.ok) { throw new Error(`HTTP ${response.status}`); } return response.json();Теперь вызывающий код сможет отличить успешный пустой список от неудачного запроса.
-
Уточняйте формат данных.
Плохой: «Прочитай CSV-файл и выведи таблицу».
Хороший: «Напиши Python-скрипт для чтения CSV с заголовками. Кодировка UTF-8, разделитель запятая. Поля могут содержать запятые внутри кавычек. Используй стандартный модуль csv, сохрани названия столбцов».
Разница в коде. Деление строки через
line.split(",")некорректно обработает некоторые CSV-поля. Для заданного формата подойдётcsv.DictReader(file), который учитывает правила кавычек и возвращает записи с именами столбцов. -
Объясняйте, где должны храниться данные.
Плохой: «Сделай список задач, чтобы он сохранялся».
Хороший: «Создай список задач для одного пользователя. Храни записи в localStorage браузера. Загружай их при открытии страницы и сохраняй после каждого изменения. Если сохранённые данные повреждены, покажи ошибку и предложи восстановить пустой список».
Разница в коде. Вместо обычного
const tasks = []потребуется чтение сохранённых записей черезlocalStorage.getItem("tasks"), разбор JSON с обработкой ошибок и запись черезlocalStorage.setItem().Такой способ подходит для небольшого локального приложения, но не обеспечивает синхронизацию между устройствами и не предназначен для хранения секретов.
Особенно внимательно задавайте правила округления, работы с датами, часовыми поясами и денежными суммами. Если написать просто «посчитай стоимость заказа», модель не узнает сама, когда применять скидку, включён ли налог и как округлять копейки. Такие условия должны следовать из вашей задачи.
Примеры 16–20. Как получать безопасный код и исправлять существующий
Самые неприятные ошибки нередко появляются при доработке уже работающего проекта. Нейросеть исправляет одну функцию, меняет соседние файлы и случайно нарушает прежнюю логику. Для таких задач особенно важны ограничения и проверки.
-
Требуйте безопасную работу с базой данных.
Плохой: «Напиши запрос для поиска пользователя в SQLite по ID».
Хороший: «Напиши функцию Python для поиска пользователя по user_id в SQLite. Используй параметризованный SQL-запрос, не вставляй пользовательский ввод в SQL через форматирование строк».
Разница в коде. Опасная реализация может выглядеть так:
sql = f"SELECT * FROM users WHERE id = {user_id}"При параметризации значение передаётся отдельно от SQL:
cursor.execute( "SELECT * FROM users WHERE id = ?", (user_id,) )Такой способ защищает от SQL-инъекций через подстановку значения. Но авторизация и проверка прав пользователя всё равно нужны.
-
Указывайте правила хранения секретов.
Плохой: «Добавь подключение к API по ключу».
Хороший: «Напиши серверный код Node.js для обращения к API. Получай секретный ключ из переменной окружения API_KEY. Не вставляй его в исходники, ответы клиенту и журналы. Если переменная отсутствует, возвращай понятную ошибку настройки».
Разница в коде. Вместо
const API_KEY = "секретный-ключ"используетсяprocess.env.API_KEY. Но важно, чтобы код выполнялся на сервере, а переменная окружения действительно была задана. -
Просите тесты с конкретными сценариями.
Плохой: «Напиши тесты для функции сложения».
Хороший: «Напиши тесты pytest для функции add(a, b). Проверь положительные, отрицательные числа и нули. Не меняй саму функцию. Покажи команду запуска тестов».
Разница в коде. Вместо одной проверки
assert add(2, 3) == 5появится несколько сценариев:assert add(2, 3) == 5 assert add(-2, 2) == 0 assert add(0, 0) == 0Однако количество тестов само по себе не гарантирует качество. Они должны проверять реальные требования к программе.
-
Ограничивайте область исправления.
Плохой: «Поиск работает неправильно, перепиши его».
Хороший: «В src/search.js поиск считает строку из пробелов непустым запросом. Из-за этого отображаются некорректные результаты. Исправь проверку пустого ввода. Не меняй интерфейс и остальные функции. Добавь тест для строки из пробелов».
Разница в коде. Вместо полной замены поиска может оказаться достаточно изменить:
if (query === "") return [];на:
if (query.trim() === "") return [];Этот пример предполагает, что
queryвсегда содержит строку. Если возможны другие типы данных, потребуется дополнительная проверка. -
Устанавливайте границы для ИИ-агента.
Плохой: «Приведи проект в порядок и исправь ошибки».
Хороший: «Изучи обработку ошибок в src/api.py. Сначала опиши найденную проблему и план. После согласования меняй только src/api.py и tests/test_api.py. Не устанавливай зависимости, не удаляй файлы и не обращайся к внешним сервисам. Запусти pytest -q, если среда позволяет. В конце покажи изменённые файлы, результаты тестов и оставшиеся проблемы».
Разница в работе. Агент получает конкретные границы, список разрешённых файлов и команду проверки
pytest -q. Он сможет подготовить ограниченный набор изменений вместо самостоятельной переработки всего проекта. Если тесты не удалось запустить, агент должен сообщить об этом, а не утверждать, что всё проверено.
Для агентной разработки важно помнить: даже точный промпт не заменяет настройки разрешений. Если агенту доступна командная строка, проверяйте запросы на выполнение опасных операций. Остановка агента также не обязательно отменяет уже выполненные команды.
Универсальный промпт для генерации кода и проверка результата
После двадцати примеров можно собрать шаблон, который пригодится для новых проектов. Необязательно заполнять каждый пункт. Оставляйте только требования, которые действительно влияют на результат.
Помоги написать программу для [описание задачи].
Язык и среда: [технологии и версии, если важны].
Функции: [что пользователь должен уметь делать].
Входные данные: [формат и пример].
Результат: [ожидаемый формат и пример].
Ограничения: [разрешённые библиотеки, файлы, условия совместимости].
Ошибки и особые случаи: [что делать при некорректном вводе или сбое].
Критерии готовности: [какие сценарии должны успешно работать].
Если для реализации не хватает существенных сведений, задай уточняющие вопросы. После генерации объясни, как запустить и проверить программу.
Для нового проекта стоит добавить требование к структуре файлов. Для существующего полезнее указать конкретные файлы, функции и поведение, которое нужно сохранить.
После получения ответа не спешите просить следующую функцию. Лучше пройти небольшую проверку:
- Сверьте результат с задачей. Все ли необходимые функции реализованы? Не добавлены ли возможности, которых вы не просили?
- Проверьте зависимости. Действительно ли нужны предложенные библиотеки и совместимы ли они с вашим окружением?
- Запустите код. Скопируйте его в рабочую среду, выполните необходимые команды и посмотрите на результат.
- Проверьте ошибки. Попробуйте пустые данные, неверные значения, повторные действия и другие подходящие сценарии.
- Попросите анализ проблем. Передайте ИИ обнаруженные ошибки и соответствующие фрагменты кода. Требуйте объяснения причины и минимальных исправлений.
- Сохраните рабочую версию. Перед крупной доработкой создайте коммит Git или резервную копию.
Если используете ChatGPT или другой обычный чат, модель может написать тесты и инструкции, но это ещё не означает, что она действительно запустила программу. Для выполнения команд нужны соответствующие инструменты и доступ к среде разработки.
При работе с Copilot, Codex и другими агентами можно поручать запуск проверок, если агенту предоставлены необходимые разрешения. Полезно требовать фактический результат команды и список файлов, которые были изменены.
И последнее: хороший промпт не обязательно должен быть максимально подробным. Избыточные инструкции иногда мешают сосредоточиться на задаче. Лучше описать нужный результат, существенные ограничения и способ проверки, а подробности добавлять по мере необходимости.
Вопросы и ответы
Как правильно написать промпт для генерации кода?
Укажите задачу, язык программирования, требования к функциональности, формат входных и выходных данных, ограничения и критерии проверки. Для сложных проектов добавьте структуру файлов и примеры ожидаемого поведения.
Как попросить ChatGPT написать программу с нуля?
Опишите назначение программы и действия пользователя. Укажите технологии, необходимые функции и условия запуска. Попросите предоставить исходный код, структуру файлов, инструкцию по запуску и способы проверки результата.
Нужно ли знать программирование, чтобы писать хорошие промпты для кода?
Для небольших программ достаточно понимать, какой результат нужен. Однако знание основ языка, структуры проекта и тестирования помогает точнее формулировать запросы и замечать ошибки в сгенерированном коде.
Почему нейросеть пишет неправильный код даже по подробному промпту?
Подробный запрос уменьшает неопределённость, но не гарантирует правильную реализацию. Модель может ошибаться в алгоритмах, использовать неподходящие библиотеки или пропускать особые случаи. Код необходимо запускать и тестировать.
Можно ли использовать один промпт для ChatGPT, Claude и GitHub Copilot?
Да, основные требования к задаче можно использовать в разных сервисах. Но запросы для ИИ-агентов стоит дополнять названиями файлов, разрешёнными действиями и командами проверки. Конкретные способы передачи контекста зависят от инструмента.
Какой промпт использовать для исправления ошибки в коде?
Укажите, что должно происходить, что происходит сейчас, как воспроизвести ошибку, её полный текст и затронутый код. Попросите найти причину, внести минимальное исправление и предложить проверку, подтверждающую устранение проблемы.
Нужно ли каждый раз писать длинный промпт?
Нет. Для короткой функции бывает достаточно двух-трёх предложений. Для сложного приложения или изменения существующего проекта потребуется больше контекста. Важнее точность требований, чем длина запроса.
