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

Промпт-инжиниринг - это просто грамотное ТЗ для нейросети

Промпт-инжиниринг - это грамотное составление технического задания для нейросети. За технологичным термином стоит привычная рабочая задача: сформулировать, что именно нужно получить на выходе. Автор разбора промпт-инжиниринга на Habr описывает суть прямо: под этим названием скрывается «вполне банальная задача: грамотное составление ТЗ нейросети».

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

Второй факт, который меняет подход к запросам: нейросеть работает как парсер, который учится на огромных массивах данных и запоминает порядок идущих в них символов. Пример из того же разбора: если в десяти статьях написано «2 + 2 = 4», модель запомнит комбинацию и после «2 + 2» выдаст «4». Она воспроизводит паттерн, а не выводит математику. Для большинства пользователей ИИ при этом остаётся «шайтан-машиной, которая якобы знает всё» (источник). Вывод простой: чем точнее заданы входные условия и шаблон ответа, тем предсказуемее результат.

Почему «ты программист» не работает

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

Ты программист. Добавь экспорт отчёта в наш сервис.

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

Тот же запрос, но с контекстом, рамками и форматом:

Продукт: внутренний сервис отчётности отдела продаж.
Стек: Python 3.11, FastAPI, PostgreSQL, SQLAlchemy 2.x.
Существующее: модуль reports/service.py, функция build_report(report_id: int) -> dict.
Задача: добавить выгрузку собранного отчёта в XLSX.
Рамки: не менять публичные методы API, не добавлять зависимостей вне openpyxl.
Формат ответа: diff по файлам и список изменений.

Разница в объёме переданной информации, а не в вежливости к модели. Роль без контекста остаётся декоративной.

Нейросеть не знает всё: как это меняет подход к запросам

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

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

Как составлять запросы к нейросети: пошаговый разбор

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

1. Описать контекст проекта: что за продукт, стек, ключевые модули, текущее состояние кода.
2. Задать рамки и запреты: что можно менять, что нельзя, какие библиотеки допустимы.
3. Указать формат ответа: готовый патч, список шагов, таблица или псевдокод.
4. Сформулировать задачу нумерованной последовательностью с однозначными идентификаторами.
5. Убрать неопределённые объекты: «это», «то», «его» и прочие местоимения без явных ссылок.

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

Контекст проекта: что именно сообщить модели

• назначение продукта в одном-двух предложениях;
• язык и фреймворки с версиями (Python 3.11, FastAPI, PostgreSQL 15);
• ключевые модули и файлы, которых касается задача;
• текущие ограничения: нагрузка, совместимость, legacy-участки;
• фрагменты существующего кода, если они есть.

Достаточно 5-7 строк. Полная выгрузка репозитория не нужна и часто вредит: модель теряет фокус на лишних деталях.

Рамки и запреты: как не получить лишнего

Запреты снижают вероятность галлюцинаций и лишних сущностей. Без них модель склонна переписать модуль целиком, потянуть новую библиотеку или изменить сигнатуру метода, который вызывается из десятка мест.

Сравните два блока ограничений:

Сделай, как считаешь лучше.

Запрещено: менять публичные методы API; добавлять зависимости вне openpyxl и стандартной библиотеки; переписывать модуль целиком.
Разрешено: добавить приватный метод в reports/service.py и точку входа в reports/api.py.

Второй вариант оставляет модели свободу внутри зоны, где изменения безопасны, и явно закрывает всё остальное.

Формат ответа: код, шаги или объяснение

Формат задают под этап работы. На старте полезен план и объяснение, на этапе правок - готовый diff. Рабочие формулировки:

• «верни diff по файлам, без полного листинга модулей»;
• «оформи как нумерованный список шагов с указанием файла для каждого»;
• «сначала объясни логику решения, потом приведи код»;
• «сведи варианты в таблицу: подход, плюсы, минусы, риски».

Простыня на 400 строк без структуры почти всегда требует ручного разбора. Заданный формат экономит время заметнее, чем кажется.

Неопределённые объекты: почему «это» и «то» ломают промпт

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

Пример абсурдного результата из-за расплывчатого промпта

Возьмём промпт: «добавь это в тот модуль, чтобы он работал с его данными». Здесь три неизвестных: что добавлять («это»), куда («тот модуль») и с чьими данными работать («его»).

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

Как переписать промпт с однозначными идентификаторами

Каждое местоимение заменяется на конкретное имя. Вместо «это» пишем «функция calculate_total в файле billing.py», вместо «то» - «таблица orders в схеме public», вместо «его» - «поле orders.customer_id».

Было: добавь это в тот модуль, чтобы он работал с его данными.
Стало: добавь проверку поля orders.status в функцию create_invoice файла billing.py, используя значение orders.customer_id.

Нумерованная последовательность шагов с идентификаторами помогает модели не терять объекты на длинном промпте:

1. в файле billing.py найти функцию create_invoice;
2. перед вызовом calculate_total добавить проверку поля orders.status;
3. при статусе cancelled вернуть ошибку InvoiceError с кодом 409.

Чек-лист простой: пройдитесь по готовому промпту и замените каждое «это», «то», «его», «там», «тот самый» на точное имя файла, функции или поля.

Примеры промптов для нейросетей: удачные и неудачные

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

Улучши эту функцию, она работает медленно.

Удачный вариант для той же задачи:

Функция get_user_orders в orders/repository.py делает запрос в цикле по списку из 200 id.
Задача: переписать на один запрос с фильтром WHERE orders.user_id IN (...).
Рамки: сохранить сигнатуру get_user_orders(user_ids: list[int]) -> list[Order]; не менять модель Order.
Формат ответа: diff по файлу и одна строка пояснения, что изменилось.

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

Промпт для написания кода нейросетью: разбор на задаче добавления функции

Сквозная задача: добавить в IT-продукт выгрузку отчёта в XLSX. Неудачный промпт:

Напиши код для экспорта отчёта.

Удачный промпт:

Продукт: сервис отчётности отдела продаж.
Стек: Python 3.11, FastAPI, PostgreSQL, SQLAlchemy 2.x.
Существующее: reports/service.py с функцией build_report(report_id: int) -> dict, возвращающей словарь с полями title, rows, totals.
Задача: добавить endpoint GET /reports/{report_id}/export, который отдаёт XLSX на основе build_report.
Рамки: build_report не менять; новых зависимостей вне openpyxl не добавлять; формат .xlsx, имя файла report_{report_id}.xlsx.
Формат ответа: diff по файлам, комментарии только к неочевидным местам.

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

ИИ - консультативный помощник, а не истина в последней инстанции

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

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

Как запрашивать несколько вариантов и объяснение логики

Формулировки, которые работают:

• «дай три альтернативных решения и для каждого укажи ограничения»;
• «объясни пошагово, как ты пришёл к этому выводу»;
• «перечисли допущения, которые ты сделал, потому что данных не хватало»;
• «укажи, в каких случаях твоё решение не сработает».

Сравнение вариантов снижает риск слепого доверия: если два подхода опираются на разные допущения, слабое место видно сразу. Просьба объяснить логику помогает заметить ошибку в рассуждении до того, как она попадёт в код. Требование перечислить допущения вытаскивает на поверхность то, что модель достроила сама.

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

Что нужно знать о своём проекте, чтобы промпт сработал

Основа промпт-инжиниринга - знание своего предмета, а не набор шаблонов. Автор разбора подчёркивает: ключевое условие - знание мелких аспектов своей деятельности, то есть профессионализм, а человек, не разбирающийся в архитектуре своего проекта, не сможет составить ТЗ для добавления новых функций (подробный разбор).

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

Практический порядок действий: сначала опишите свой проект в заметке - модули, потоки данных, ограничения. Затем формулируйте задачу под конкретную функцию, с рамками, запретами и форматом ответа. Универсального промпта, который сработает без знания контекста, нет.

Промпт-инжиниринг не требует заучивания десятков техник. Требуется ясность в том, что вы делаете, и привычка проверять то, что вернула модель.

Подписаться на канал