Промпт для генерации кода: как формулировать

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

Из чего состоит хороший запрос

Шесть элементов. Первые три дают почти весь результат.

Задача одним абзацем. Что должно получиться и как это проверить. Не «напиши обработчик», а «функция принимает список заказов и возвращает сумму по завершённым, отменённые исключаются».

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

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

Что делать при ошибках. Бросать, возвращать пустое, логировать — у вас есть принятый способ, и он не очевиден.

Границы. Что не трогать: не менять сигнатуру, не добавлять зависимости, не переписывать соседние функции.

Формат ответа. Только код или код с объяснением. Если результат идёт в файл, объяснение мешает.

Что показывать из проекта

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

Нужный файл. Тот, куда пойдёт код.

Прямые зависимости. Типы и функции, которые вызываются.

Один похожий пример. Функция, решающая близкую задачу в том же стиле.

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

Чего показывать не надо: весь репозиторий, конфигурацию сборки, историю коммитов. Лишний контекст разбавляет внимание и увеличивает счёт — почему контекст важнее модели, но в меру.

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

Шесть формулировок, которые работают

Проверены на практике и дают заметную разницу.

«Напиши так, как написано в приложенном файле». Работает лучше, чем перечисление правил стиля.

«Используй только библиотеки, которые уже импортированы». Снимает самовольное добавление зависимостей.

«Если данных недостаточно — задай вопрос, а не придумывай». Модель охотно достраивает; явное разрешение спросить это гасит.

«Покажи только изменённые части». Для правок в существующем коде — вместо переписывания файла целиком.

«Объясни, какие допущения ты принял». Самая полезная строка: обычно там и обнаруживается расхождение с вашими ожиданиями.

«Сначала перечисли граничные случаи, потом пиши код». Список читается за минуту, вы отбираете нужное — и код получается сразу с учётом отобранного.

Последний приём особенно окупается: он же даёт готовую основу для тестов — как это устроено.

Что не работает

Пять привычек, которые тратят время.

Описывать стиль словами. «Пиши чисто и читаемо» не значит ничего. Показать пример дешевле и точнее.

Просить «лучший вариант». Модель не знает ваших критериев. Спросите два варианта с объяснением разницы — выберете сами.

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

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

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

Что проверять в ответе

Четыре проверки, которые стоит сделать привычкой.

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

Не появились ли новые зависимости. Каждая — ваше решение, а не её.

Обрабатываются ли ошибки. Сгенерированный код часто предполагает, что всё пройдёт удачно.

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

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

Работа с ошибками

Отдельный сценарий, где модель полезна больше всего.

Показывайте текст ошибки целиком. Со стектрейсом, а не пересказом.

Прикладывайте код, где она возникла. Не только строку, а функцию.

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

Скажите, что уже пробовали. Иначе получите те же советы по кругу.

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

Сколько это стоит

Считаем, потому что расход здесь определяется контекстом, а не длиной ответа.

Файл с зависимостями — это тысячи токенов на входе. Ответ обычно короче. При ставках за миллион даже сотня задач в месяц обходится недорого — как считать токены.

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

В каталоге на 9 сентября 2026 года 49 позиций в пятнадцати семействах, из них 38 текстовых. Платные позиции начинаются от 1 ₽ за миллион, шесть текстовых тарифицируются по нулевой ставке — что там доступно.

Как выбрать модель под код

Коротко, потому что подробно разбирали отдельно.

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

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

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

Как работать с длинной задачей

Отдельный порядок для случаев, когда нужен не один метод, а модуль.

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

Начните с интерфейса. Сигнатуры, типы, что откуда приходит. Согласуйте это, а потом просите реализацию — тогда части сойдутся между собой.

Просите заглушки для несделанного. Явные, а не молчаливо возвращающие пустоту: так видно, что ещё не готово.

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

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

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

Чего мы не утверждаем

Не даём готовых промптов. Они пишутся под стек и соглашения проекта; чужие переносятся плохо.

Не сравниваем модели по качеству кода. Своих замеров мы не делали.

Не обещаем, что проверки ловят всё. Они ловят несуществующие вызовы и новые зависимости; логические ошибки ловит ревью.

Цифры каталога — на дату. Состояние на 9 сентября 2026 года; актуальное в живой выдаче.

Что нужно, чтобы попробовать

Ключ заводится за минуту на keydealer.ru/login — почта и пароль, без документов и без зарубежной карты. Оплата российской картой в рублях, один ключ на весь каталог: перебрать три модели на своих задачах — правка строки в конфигурации.

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

Что держать в голове

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

И просите перечислить принятые допущения. Именно там обнаруживается расхождение между тем, что вы имели в виду, и тем, что модель поняла, — до того, как код попадёт в проект.

Как мы проверяем факты и что храним из запросов — на странице о проекте и в llms.txt. Проверить на своей задаче: keydealer.ru/login.