Промпт-инжиниринг на деле: опыт, который экономит часы

Привет, Хабр!

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

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

Как меняется ваша роль

В классическом программировании вы пишете код руками и контролируете почти каждую деталь сами. В вайбкодинге картина другая: вы меньше «печатаете», но больше управляете. Вы ставите задачу, задаёте границы, проверяете результат и вносите правки. По сути, это не отказ от разработки, а другой способ её вести. Такой подход особенно полезен в code generation, где исследования и обзоры отдельно отмечают роль формулировки задачи, ограничений и итеративной правки.

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

Ошибка, которая мешает большинству

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

Люди часто слишком долго подбирают формулировки, читают советы про «правильные слова», пытаются написать запрос «как надо» и в итоге тратят больше времени на сам промпт, чем на задачу. На практике обычно выигрывает не один идеальный запрос, а нормальный цикл: спросил, посмотрел, уточнил, поправил. Исследования по instruction following и обзоры по prompt engineering как раз показывают, что поведение модели сильно зависит от того, насколько ясно и конкретно дана инструкция, но окончательный результат обычно рождается в нескольких итерациях, а не в одной попытке.

Ещё одна частая ошибка — остановиться на первом ответе. Получили не то, сказали «ну ладно» и пошли дальше. А надо было просто уточнить задачу. В этом смысле вайбкодинг — это не одиночный запрос, а диалог. Если диалог оборвался после первой реплики, ничего хорошего обычно не выходит.

Разные стратегии работы с промптами

Один из моментов, из-за которого возникает больше всего путаницы — это длина и детализация промптов.

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

На практике это не так.

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

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

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

Ещё одна проблема — не учитывать контекст задачи.

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

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

Если вы не уверены — проще начать с короткого запроса и двигаться итерациями. Если уверены — можно попробовать сразу сформулировать задачу подробно. В реальной работе чаще всего используется комбинация: сначала общее описание, потом уточнения.

И главное — не зацикливаться на поиске «правильной» стратегии. Она всегда зависит от задачи, модели и вашего опыта.

Базовый принцип работы с кодом

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

Это не абсолютный закон, но в большинстве рабочих задач он полезен. Когда вы просите «перепиши всё красиво», модель часто начинает менять не только нужный кусок, но и соседнюю логику. В результате код выглядит чище, а ломается чаще. Для code generation это типичная проблема: слишком широкая инструкция провоцирует слишком широкие изменения.

Гораздо лучше формулировать задачу локально: «добавь новый обработчик», «измени только этот модуль», «не трогай остальной код», «покажи только изменённые части». Такой подход не всегда идеален, но он заметно снижает шанс сломать уже работающую часть проекта.

Тонкости работы с нейросетями: что важно понимать заранее

Перед тем как писать промпты, полезно принять одну простую вещь: модель не всегда ведёт себя так, как ожидает человек. Она может расширять задачу, додумывать детали и принимать на себя слишком много свободы, если вы не обозначили границы. Это хорошо видно и в исследованиях по instruction following, и в работах про prompt injection: модели умеют следовать инструкциям, но бывают уязвимы к конфликтующим или враждебным подсказкам, а значит, границы и приоритеты в тексте имеют значение.

Первая тонкость — контекст не бесконечен. Да, современные модели часто умеют работать с большим объёмом текста, но их «эффективное» использование обычно хуже, чем заявленный максимум. В недавнем исследовании по реальному контекстному окну показано, что производительность может заметно падать намного раньше формального лимита, причём это зависит от типа задачи. Поэтому повторять важные ограничения и не перегружать диалог лишним текстом — не каприз, а нормальная практика.

Вторая тонкость — не все советы одинаково полезны для всех моделей. Сильная модель может нормально работать с более свободным и подробным описанием, а более слабая — нуждаться в жёстких рамках. Это объясняет, почему у разных людей один и тот же совет работает по-разному: многое зависит не только от промпта, но и от модели, и от того, как именно вы с ней работаете.

Ключевые слова, которые реально помогают, и те, которые не очень

Не все формулировки одинаково полезны.

Слабые и слишком общие фразы вроде «сделай лучше», «улучши архитектуру», «перепиши красиво» обычно дают расплывчатый результат. Модель не знает, что именно для вас «лучше», и начинает трактовать задачу по-своему. В коде это особенно рискованно: общие слова часто приводят к ненужным перестройкам.

А вот более конкретные формулировки обычно работают лучше:

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

Это не магические фразы, а просто ясные ограничения. И именно они помогают модели меньше фантазировать.

Отдельно стоит сказать про «не делай X». В реальной работе отрицательные формулировки часто звучат хуже, чем позитивные ограничения. Вместо «не переписывай весь код» чаще полезнее писать «измени только этот файл» или «добавь новый код без изменения существующего». Не потому что у модели есть «позитивное мышление», а потому что так понятнее, что именно считается допустимым результатом.

Русский против английского: что лучше

Честный ответ такой: и русский, и английский работают. Но не одинаково.

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

Если модель ответила кодом на английском, это нормально. Код почти всегда так и выглядит. А вот если модель начала отвечать на другом языке, чем вы ожидали, это просто повод уточнить: «объяснение — на русском, код — на английском».

Как экономить токены: практические приёмы

Токены — это то, за что вы платите (или бесплатный лимит). И то, что влияет на скорость работы. Больше токенов — дольше ответ, дороже запрос. Поэтому экономить токены полезно.

Первый принцип: никогда не просите переписать весь код.

Если у вас файл на 500 строк, а вы просите переделать одну функцию в середине, не кидайте модель весь файл и не просите «перепиши всё». Модель сгенерирует 500 строк ответа. Вы потратите кучу токенов. Вместо этого покажите только ту функцию, которая нуждается в изменении, и скажите «дай только изменённую версию этой функции, остальное не трогай».

Второй принцип: работайте кусками.

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

Третий принцип: не отправляйте лишний контекст.

Модели часто советуют давать много контекста. Это не всегда правильно. Если вы пишете простую функцию, не надо скидывать всю архитектуру проекта. Модель отвлечётся на лишние детали и может сделать не то. Давайте ровно столько контекста, сколько нужно для решения задачи.

Четвёртый принцип: используйте точечные правки.

Вместо того чтобы просить переписать функцию целиком, скажите: «в этой строке замени X на Y». Или: «добавь проверку после 15-й строки». Модель это понимает. И ответ будет коротким.

Пятый принцип: запрашивайте только изменения.

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

Как выглядит реальная работа

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

Допустим, вам нужно добавить новую кнопку в существующий бота. Первый запрос может быть совсем коротким. Ответ, скорее всего, будет неидеальным. Тогда вы уточняете: не переписывай код, работай только с этим хендлером, покажи куда вставить фрагмент, остальное не трогай. И вот уже результат становится заметно полезнее. Это не «слабый промпт», а нормальная рабочая итерация.

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

Готовые шаблоны промптов

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

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

Напиши телеграм‑бота на Python с использованием библиотеки aiogram, базы данных sqlite, логирования и конфигурации через.env. Раздели проект на части, не пиши всё в одном файле. Суть бота в том, что…

Для сайта одной страницей:

Создай чёрно‑белый сайт‑визитку с крутым шрифтом и именем автора в шрифте Syne ExtraBold 800. Все формы на сайте сделай округлёнными. Добавь анимацию liquid glass, тёмную тему, прозрачность. Всё в одном файле index.html. Сделай страницу с информацией: телеграм, вк, почта. Добавь моковые данные и красивое оформление.

Когда проект уже существует и нужно внести изменения:

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

Когда случилась ошибка:

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

Когда нужно точечное исправление:

В этом коде [вставка кода] на строке [номер] замени [что] на [на что]. Покажи только исправленную строку.

Эти шаблоны не делают результат идеальным. Но они позволяют быстрее начать и держать процесс под контролём.

Почему иногда всё равно получается плохо

Даже хороший промпт не гарантирует идеальный ответ. Модель может неверно понять детали, пропустить условие, выбрать не тот подход или просто не увидеть важную часть контекста. Это нормально. Так устроена сама работа с LLM: они умеют следовать инструкциям, но не являются безошибочными, а их поведение зависит и от формулировки, и от длины контекста, и от сложности задачи.

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

Практические принципы

Чтобы работа не разваливалась, полезно держать в голове несколько простых вещей.

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

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

Третье: не расплывайтесь в формулировках. Чем точнее вы объясняете задачу, тем меньше модель начинает «додумывать».

Четвёртое: всегда указывайте формат ответа. Нужен только код — пишите это. Нужны пояснения — тоже пишите.

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

Итог

Промпты в разработке — это не отдельная эзотерическая дисциплина. Это просто способ поставить задачу так, чтобы модель не ушла в сторону.

Хороший результат обычно появляется не из одного «сильного» запроса, а из нормальной работы:
задача, ограничение, ответ, правка, уточнение, ещё одна правка.
И вот этот цикл, а не красивые слова, действительно экономит время.

Если смотреть честно, главная польза вайбкодинга не в том, что он «заменяет разработку». Польза в том, что он ускоряет рутину, если вы понимаете, что делаете. А если не понимаете — тогда никакой промпт не спасёт. И именно это, пожалуй, самый трезвый вывод из всей темы.

Полезные ссылки

«A Systematic Survey of Prompt Engineering in Large Language Models» — обзор по prompt engineering и практикам формирования запросов.

«Large Language Model Instruction Following: A Survey of Progresses and Challenges» — обзор по тому, как модели следуют инструкциям и где у них остаются слабые места.

«A Survey on Large Language Models for Code Generation» — обзор именно по генерации кода и тому, как LLM применяются в разработке.